Hey there! It’s been awhile, eh? Well to catch you up on what’s been going on we managed to figure out what our game title is going to be: Booyo Sitter! In it, you take care with living blob creatures (now called Booyos) as they play, float and interact with each other and the player. Since these creatures are giving off the impression that they are living, that means they have to have some sort of AI system to direct how they behave and how they react to each other and player interaction, and that’s what I’ve been working on for the past few weeks.
As our team’s design lead, it’s my job to help communicate and direct how the game works to not just the team but also to our players. In this instance, I was making an easy to follow system that I can hand off to our tech team so that they can implement the functionality. First, I broke down the behaviours in terms of emotions that I knew a Booyo should have. They are as follows:
- Idle – starting state. State in which the Booyo floats around and waits for some sort of input from the player or another Booyo
- Joyful- happens when a Booyo merges or after it pops
- Surprised – happens when a Booyo is being held
- Scared – a transitional state that happens right before popping
- Wincing – a transitional state that happens right before merging
Once the main emotions were figured out, I had to define the actions that would lead to that emotion. I wrote down a list of emotions and then a list of actions and started to come up with a diagram that I put through Viso. The end product looked like this:
So this wasn’t too bad but I knew that I could be a lot clearer in what I was trying to convey. I went to our artists and asked if it made sense to them, to which they replied that they didn’t know what these states would look like other than what the Booyo would look like. That’s when I realized that I was doing this backwards.
Fixing my Behaviour Tree
Typically AI states are treated as an action. For instance, a standard guard AI would probably have a Patroling, Searching, and Chasing states (maybe even a Fleeing state) with conditionals that would help navigate it through the behaviour tree. This way of treating AI behaviour makes it easy to understand what the game object is doing in a given state. Using the guard example again, it’s easy to know what that Patrolling means the guard is navigating space in the level in a pattern in an attempt to stop the player or NPC. However, using the behaviour tree I came up with if I said the Booyo is currently Scared, then it’s kind of vague as to what the Booyo is doing while Scared. Is it shivering? Is it moving? How long does it last?
I refactored my work and redefined my states to be action-oriented instead of emotions. The states I came up with were:
- Idle – Starting state, Booyo wanders around player
- Chirping – Booyo randomly will stop wandering to let out a little chirp
- Dancing – Transitional state that happens when two Booyos bump into each other without player interaction
- Grabbed – Booyo’s position will follow the player’s hand that grabbed it while in this state
- Thrown – Booyo is sent flying in the direction the player threw it at
- Merging – After Dancing, one Booyo will rapidly shrink while the other one rapidly grows, giving the idea of being “absorbed”. Which Booyo that is doing the absorbing is determined by Booyo size or by random if both Booyos are the same size.
- Popping – Once a Booyo has reached its maximum size, it will pop and release every Booyo that it absorbed.
Already I had way more states than when I started with but it’s already very clear how these things would behave during gameplay and how they correlate to each other. Following what I did last time, writing down the states and the actions required to get to each, I came up with a few variants of the state tree and came up with this final tree
Bringing it to the Art Team
Now I had something that showed off the logic of the behaviours really well, but now I needed something to convey what these states should look like. I asked my friend in another team what he would recommend and he said to do animatics, which are more or less rough storyboards to convey the progression and appearance. Perfect, exactly what I needed. I drew up a few sketches, threw them into a powerpoint and showed the rest of my team.
I’d like to wrap up with some things I’ve learned from this experience and what I think other designers can get from this post.
- Check in with the people you are communicating to. A big reason why I had to redo my AI tree was that I was working in a bubble for the most part. It was only when I showed my team that I noticed a big problem with its design. If the people you are communicating to is your audience, then test it. Game design is an iterative process because you’ll rarely find a solution your first go through.
- Treat AI states as actions. Seriously. Do it. Some people might tell you to only use words that end with -ing, but honestly, as long as you convey the action of what the AI is doing, that’s good enough. Even if the AI is not doing much physically, it helps frame the system a lot better and it makes it easier for other people to read.
- Don’t be afraid to use different or unconventional tools to help explain a design. At first glance, I dismissed animatics as an “animator only” tool. This couldn’t be farther from the point. Using the animatics, I was able to effectively communicate my direction to the art time so that they can have a frame to animate. This goes for any other tool or technique that might be viewed as niche or exclusive to a specific disciple. Branch out and try new stuff. If you have a weird thing you need to convey, then chances are there’s a tool that will help you convey it well.
Now that we have a clear idea of how Booyos behave, I can go into the engine and start to implement the logic. At the time of writing this, next week’s goal is to get the AI behaviour completely implemented into the game so that tech and art can come in and add the functionality and animations to bring these Booyos to life.