A Gentle Introduction to AI
A two-part article about designing and implementing AI bots in a battle royale game for Apple Arcade
When we were developing Butter Royale, some of the core requirements were to make the game available both online and offline, with players being able to get into matches in 30–40 seconds or less. Aside from the initial connection needed to download the game from Apple Arcade, players had to be able to play and enjoy the game without necessarily going online first.
In order to support offline play, we couldn’t merely rely on other humans for our match-making needs, but would also need non-human opponents contained on each player’s individual device. In other words, we needed…
…bots!
Hello there! My name is Geir Ove, and I’m a game designer/amateur juggler at Mighty Bear Games. In this two-part article I’ll outline the steps we took to design and implement bots in Butter Royale, starting with the early design and evaluation of AI frameworks, and following up with a more in-depth dive into the gritty details in a second article.
Please, sit back and make yourself comfortable, gentle reader, as I take you on a journey through time to explore how we came to implement those bots! You see, it all started back in the mid-1920s, when the world was still displayed in black and white and corona mostly existed in people’s minds as a refreshing summer beverage… (story continues after image)
Scoping the Design Through Mind-Mapping
…then, roughly 94 years later, we started looking into creating bots for our new game, and launched that process by mapping out actions that normal players could perform in the game, using online, freely available mind-mapping services like MindMeister¹.
We went through a couple of iterations of this mind map, and the basic decision tree it contained became more detailed and more accurate with each iteration.
Going through this process from a “possible player actions” perspective helped us scope the early design and come up with a plan for:
- The actions a bot should be able to perform, like moving, collecting items and shooting.
- The common player strategies a bot could try to emulate, like circle strafing in combat, fleeing when low on health and ambushing players from… well… bushes, of course!
- How bots should react to events like safe zone shrinking or taking environment damage.
The mind-map was not a final, cast-in-stone blueprint for how the bots should behave, but it was a guide to keep us on the right track and make sure we focused on the important parts we got around to the implementation phase.
Learning from Previous Projects
“…make sure that bot AIs can be easily setup, iterated on and maintained by designers…”
Before I go on, I should note that this was not our first attempt at doing bots; in an earlier game a couple of years back — World of Legends² — we also made use of bots to provide players with easy opponents.
The bots in WoL were setup using a very engineer-focused and script-based AI framework that controlled bots server side, and required recompiling the server to have any AI changes go into effect. As a result, making even minor changes to the AI scripts required engineering support, and iterating on or debugging those changes was a slow process.
One important lessons we took away from the above-mentioned experience, which remained in the forefront of our thoughts going forward with bots in our new project, was to make sure AI bots could be setup, iterated on and maintained by designers, without having to rely too much on engineers.
This meant more up front work for the engineers to ensure the initial implementation was solid, but it also freed them up to work on other features later, leaving the bulk of AI tweaking and iterating to design.
Evaluating AI Systems and Frameworks
With that in mind, and with a solid plan in place, we were able to start evaluating different options for making our bots come to life, including:
- Finite State Machines² — The classic starting point for most designers and developers wanting to do something with AI. Useful for setting up linear, scripted encounters and gameplay. Shows its limitations with more dynamic gameplay, where it can quickly become a complex mess of potentially hundreds of states and transitions between these.
- Behaviour Trees³— The next step up from FSM (depending on your needs). Easy to setup initially, read, debug and expand, but very large trees can become prohibitively costly to evaluate. Expanding will also eventually reach a point where, like FSM, it can become a maintenance nightmare. Rules and AI choices are specifically defined by the designer.
- Utility AI⁴— Allows setting up dynamic and (sometimes) unpredictable gameplay, with the AI prioritising behaviours based on the score of each available option under the circumstances at hand. Easy to design and to extend; good for complex, goal-based behaviours. Potentially takes a lot of testing and iterating to get the scores for the different options right, and can be hard to debug whether the bot’s actions are due to “emergent behaviour” or a bug in your scoring system.
- AI Planning⁵ — Amongst the most recent contestants to enter the arena, AI Planners try to procedurally find the best course of action to reach a particular goal in an optimised way. The AI is given a goal, some possible actions, and the AI is then “let loose” to figure out how to best reach the goal. The upside of this is that you get an AI with emergent-style behaviour. The downside is that you get an AI with emergent-style behaviour. The designer risks losing control over what the AI does, potentially leading to unpredictable and/or unwanted behaviour.
All these AI systems have their own pros and cons in regard to the depth and complexity of the AI and to the ease of setting up, testing and iterating on the system, and all come with their own multitudes of frameworks and plugins — so how to choose one method over the others?
Process of Elimination
Going back to our mind map from earlier, we knew our bots needed to be somewhat predictable, with just a few overarching goals that would drive their base behaviour, such as:
- Avoiding the danger zone
- Seeking the safe zone
- Collecting stuff
- Fighting opponents
- Helping out Squad members
At the same time, the bots needed to be able to jump between those goals in a dynamic fashion, without delay, as the situation demanded. For a more varied player experience, we also wanted a variety of AI profiles, each with a different set of priorities and difficulty level. These requirements effectively took FSM (too limited) and AI Planners (too unpredictable) off the board.
Some of the other frameworks and plugins we found were too experimental and unproven in the field, or were only published for older Unity versions and no longer received updates. None of these were given much consideration, as we had very limited development time (6 months) and couldn’t afford to do a lot of experimentation and prototyping with potential dead end solutions.
Other deciding factors came down to how easily we could incorporate an existing, proven AI framework into our game, and whether said framework would work on all the platforms we needed to support (iOS, MacOS, tvOS).
Unity’s AI Planner was a serious contender for a while, until we realised it didn’t work well with the version of ECS⁶ (Unity’s Entity Component System) we were using. It was also still a young framework at the time, and lacking extensive documentation and implementation examples.
Near the end of our evaluation process, we were leaning towards Behaviour Tree and Utility AI systems, with the Utility AI eventually losing out as we landed on a BT framework which aligned closely with our requirements and allowed us to proceed ahead at full steam.
The winner: NodeCanvas⁷
End of Chapter One — or “How Good Planning Resulted in Quality Bots”
I will go into more detail about how we used NodeCanvas to setup our Behaviour Trees and AI Profiles in the next article, but for now I’ll leave you with this:
The process we went through with mind-mapping, along with the evaluations we did to make sure we chose the right framework, played an important part to ensure that the quality of our bots was up to snuff.
Our bots in fact ended up mimicking player behaviours to such an extent that many actual players (and at times, members of our own team) still to this day have a hard time consistently telling human and AI opponents apart!
Of course, any game AI that doesn’t continuously receive updates (or updates itself!) will display patterns and styles of play that can be identified over time — but for beginner Butter Royale players these patterns are not immediately clear, and it often takes a substantial amount of time for players to tell bots and humans apart with 100% certainty.
That is a testament to the up-front planning we did with mind maps, to the chosen AI framework and the engineer (Yo, Khalid!) who evaluated, integrated and extended said framework to support our AI needs, to the extra time we had available for iterating on and polishing the feature, and last — but not least — to the continuous feedback we got from the rest of the team through the internal playtests that were held multiple times every week.
It also helped that we implemented machine learning, block chain and virt[Inner Editor Voice: No, we did not. Stop. You’re done. This article is OVER.]
Thanks for sticking with me so far! In part 2 of this article, if my inner editor voice lets me, I will go into more detail about how we designed and implemented our behaviour trees and AI profiles in NodeCanvas. Stay tuned!
Also, if you’re interested in reading more about some of the things mentioned in this article, please check out the resources listed below!
[1]: MindMeister. Online mind mapping application that allows its users to visualize, share and present their thoughts via the cloud
https://www.mindmeister.com/
[2]: FSM. Finite State Machines
https://en.wikipedia.org/wiki/Finite-state_machine
[3]: Behavior Trees
https://en.wikipedia.org/wiki/Behavior_tree
[4]: Utility AI
https://en.wikipedia.org/wiki/Utility_system
[5]: AI Planners
https://planning.wiki/guide/whatis/aip
[6]: ECS. Entity Component System, part of a Unity framework for writing optimized, data oriented code
https://learn.unity.com/tutorial/entity-component-system
[7]: NodeCanvas. Node-based Visual Behaviour Authoring framework for Unity
https://nodecanvas.paradoxnotion.com
A Gentle Introduction to AI was originally published in Mighty Bear Games on Medium, where people are continuing the conversation by highlighting and responding to this story.
