It has been quiet here, but the work is still on going. Not super exciting work, but creating solid frame work for this game and others to come.
The videos that I have shared previously have been thrown together code for proving out some technical concepts that I have never worked with before. Generating 3D meshes programmatically is something I played around with a bit back in the XNA days, but never optimized it. Additionally, I have been learning the ins and outs of the Unity Navigation System and about 3D animations.
With a lot of the more difficult (at least for me) stuff figured out I wanted to take a step back and look at how this game and any future games should be structured. I am familiar with SOLID principles and am a big fan of dependency injection, so I spend some time seeing how they might work in game design. In my travels ran across a older video presented by Ryan Hipple about the topic of Scriptable Objects.
This really resonated with me. Back in the day I remember spending at least half as much time on creating tools as I did on the core game logic. Level editors with scripted events for Corrupted, level, item and monster editors for Dungeons of Desolation. Instead of just programming the game, I made frameworks for making interesting things that didn’t require coding. I had be very resistant to doing any tooling work in Unity for some reason… maybe because it already is a tool and developing tools in tools seemed redundant to me.
After taking a step back, I went to the whiteboard and started drawing out relationships. Not everything is worked out yet, but I am much happier with the direction it is going and do not feel so overwhelmed by it.
The new system will allow me to write reusable building blocks that can create many interesting experiences with out having to type it out as code. It seems silly to me that a designer would spend hours/days trying to explain how things should look or function to a programming team, when the programming team could just create tools to allow them to do it themselves.
Now I can implement behaviour trees that allow me to quickly make new an interesting behaviours for NPCs. Below is a sample for a worker. The player can control the high level state of the NPC and the tree will take care of the rest.
One of the most interesting things I landed on is having player’s character is being run by a behaviour tree as well. The PlayerControlled node allows the player to provide the input to the entity. It also allows them to map actions to button presses that are executed through child nodes.
The player’s character being driven by a behaviour tree also allows it to be controlled for cut scenes or other events.