Ramblings about video game AI - Part 1 - Introduction
A little bit of background
About two years ago I started working on Project Slide, a 3D vehicle action game. All along, the plan was to keep a blog about the development but I never quite got started writing anything. Development has progressed at a steady, albeit slow, pace. Due to me doing most things myself there could have been any number of topics to cover, from level design to engine code. However, I didn’t feel like I had been doing anything particularily new or noteworthy.
A note about the name “Project Slide”. It is just a temporary project name and the finished game will be called something else. Naming is hard, and when it was time to create the code repository for the game I just went with whatever came up. I had a prototype where you would slide all over the place, thus Project Slide. Occasionally, I’ll refer to the game as just “Slide”, because typing is also hard.
This year I started working on a part of the game I had barely touched before, namely AI. That was exciting, not only because it was a part of the game that was almost completely missing, but also because AI is an area of game development I have very little experience working with. Now, after working on the AI for about two months, I feel things are progressing nicely enough to warrant a few blog posts. I am not saying this is new or noteworthy either, but it seems like a fun thing to write about. This is part one in a series of N parts. In other words, I don’t know how long this will be. Let’s find out!
We’ll look at the AI systems needed for the game, how I ended up creating those systems, the current state of the AI and what still remains to be done. This is all from the perspective of a solo developer with very little experience designing and writing AI systems, so take everything with a grain of salt. I hope you will find these posts interesting, or perhaps even useful to you in some way. However, keep in mind that we are talking about a game in development, so any “good ideas” might turn out to be bad later down the line. Feel free to ask questions or give me feedback in the comments.
This series is not going to be a “How to write your own AI system in 12 steps” kind of thing. I am not confident enough in my abilities to create AI systems to write such a tutorial. Besides, Project Slide is created using a custom game engine which means that there is little point in showing lots of code. Instead I’ll go through the concepts and ideas behind the systems in enough detail to give you an idea of how to design your own version, should you want to. Most, if not all, concepts are transferable to other engines such as Unreal or Unity.
What are we trying to make?
Project Slide is a 3D vehicle action game, set in fairly open outdoor environments. Each environment is between 0.5 and 4 square kilometers in size and contain open fields, steep cliffs, forests, buildings, beaches, valleys… In other words, they can be pretty varied. The levels are made up of height map terrains onto which meshes have been placed. The gameplay revolves around vehicular combat, cargo hauling, as well as some light physics based puzzles.
Some of the scenarios are scripted to allow for single-player story development as well as more complicated quests, but most of the fun comes from the player interacting with independent AI agents in a physics based sandbox. The vast majority of these AI agents are vehicles. They need to be able to interact with the player in a believable but entertaining fashion. Some AI vehicle types the player might encounter include:
- Scouts - fast and nimble with limited combat abilities.
- Haulers - slow and heavy, used to haul cargo and trailers around.
- Heavy attack vehicles - dangerous in combat but can be outrun by a skillful driver.
- Special vehices - Various tech/support vehicles such as traction beam lifters, repair vehicles etc.
- Boss vehicles - Extremely powerful enemies encountered during key moments.
The image on the left shows blockouts (early 3D models used to get the idea of each vehicle) of a a scout vehicle, a heavy hauler and a heavy cargo trailer. The barrels in the trailer are individual objects too and they will fall off if you drive recklessly.
The AI system needs to be flexible enough to handle all of these vehicles and roles. It needs to support both friendly and enemy vehicles. Ideally, we should be able to add new vehicle types and assign AIs to control them without having to retune the AI completely. The golden standard, which I aim for, is for all vehicles in the game to be controllable by an AI. In other words, I should be able to tell any vehicle to “go there” or “follow that car”, and it should react accordingly.
Each car has an AI “brain” which can be given direct orders, such as “go to position X”, or they can be assigned a behavior, such as “patrol this area and try to kill any hostiles you encounter”. Such a behavior is obviously much more complex than a direct order. We’ll look at the brain and how it works in more detail in the next part.
Putting the AI behind the wheel
One subtle but very important detail about the AI system in Slide has to do with how the AI agent actually drives the vehicle it controls. In some games, the AI logic directly controls the velocity or the position of the agent in the game world. This makes the AI movement code very easy to write and tune so that it fits the game; if the AI thinks a particular position in the world would be optimal it can simply “teleport” itself to that position.
An alternative approach, and the one I chose for Slide, is to consider the set of input parameters the player has available when driving a vehicle, and make those parameters available to the AI agent. In the case of a vehicle these parameters are acceleration, brake, and steering. Certain vehicles have other, special, inputs as well such as weapon or hauling controls, but the three aforementioned parameters are available for all vehicles.
This means that when an AI agent drives a vehicle around the game world of Slide, it is not allowed to “cheat” and position the vehicle as it wants. Instead it has to apply the correct amount of acceleration, braking and steering to have the vehicle move where the AI wants it to move. In fact, the vehicle has no idea whether it its driven by a player or an AI agent.
I fully expect I need to add “helpers” to the AI code, ie. things that break the rule I stated above. For example, if a quest in the game depends on an AI vehicle reaching a specific point in the game world it needs to work even when the AI makes a fatal mistake and falls off a cliff. In this case, a helper could teleport the vehicle back on track, if it detects that the AI is not on its set path. So far I haven’t added any helpers, but I probably will. I cannot hope to cover all cases, but some of them.
There are both pros and cons with this approach.
Advantages
- The vehicle reacts the same regardless what/who is driving it. The AI won’t perform any “magic” maneuvers that the player cannot do.
- The differences between vehicles will be what we expect them to be. A heavy hauler will have a slower acceleration than a scout car, but we don’t need to tell the AI to accelerate slower when driving a hauler. The physical characteristics of each vehicle will take care of these things for us, just like when a player is driving.
- All the vehicle effects work the same. The engine sound behaves the same for players/AI because the input is the same. You get the same dust particles when the vehicle skids and slides, etc.
- We get a little bit of the “human factor” for free. The AI agents will make imperfect turns, slide around, make corrections etc, just like human drivers. The AI agents are impersonating human drivers after all.
Disadvantages
- We need to actually teach the AI how to drive the vehicle. It is not enough for the agent to know the exact location it needs to drive to. It also needs to know to back up in order to not hit the pillar in front of the car, then change to first gear, turn the steering wheel to the left, apply a bit of throttle, etc. etc.
- When driving faster vehicles, the AI needs some racing skills. For exampe, it needs to know what to do when the vehicle is about to spin out of control, taking the environment into account. The material and slope angle of the road, the current angular and linear velocities etc. all affect the situation. This is tricky stuff to program and tweak.
Up next
I think this’ll do as an introduction. In the next part, which is already available, we will start diving deeper into the AI beginning with the core of it all, the brain. Hope to see you there! If you are interested in this sort thing, by all mean keep an eye on this blog as I will be uploading more parts soon.