Introduction to Game AI

My new position requires me to develop some “human like” game AI. So, I thought I can keep a blog about the journey. Sure, it will be fun after two years full of with CG. So, here’s the very first entry:

There is a clear difference between academic (research) AI and game AI. Goal of the research in AI is to create a real intelligence through artificial means. However, game AI focuses on intelligent behavior that provides to the players an enjoyable challenge or assistance. For this task, sometimes having a simple rule or state based AI may be enough. On the other hand, depending on your expectations, you may also need to apply some higher level of AI techniques or even some machine learning. Nevertheless, all AI techniques are used only for one thing: Making a decision.

For making a decision, the agent needs to perceive the environment. This perception is limited with what the agent and its AI needs. For example, if we are dealing with the ghost always turning left in Pac-Man, then we can only send the junction information to the agent. However, if we are dealing with a bot AI in a shooter game, then the information needed by the bot will be more than just junctions. Sending this information also depends on the system you are working with. You can query an object, or a subsystem, and so on.

Conditions and related actions are the core of the AI. For a very simple AI, you can open your file and hard-code all the rules, conditions, and actions. However, when you go towards more complex decisions, your hard-coded basic code will begin to include series of conditional rules, different outcomes, etc. So, you will need to extend your code by using some special approaches. Maybe you will even meet with AI scripting.

One of the base approaches for game AI is FSM (finite state machine). FSM uses some certain states of AI to make decisions. Here, the states become actions and the edges become conditions. For example, in a basic FPS bot, you may have states such as search, shoot, and die. In search state, the bot just walks around randomly and tries to find the player. When the bot “sees” the player, then its FSM goes to shoot state and the bot starts shooting. If the player flees, then the bot goes back to search state. If the bot gets shot, then it goes to die state.

Another option can be using decision trees. Decision trees have conditions (nodes) and corresponding actions (leaves). You can use any kind of tree structure (binary tree, etc.). Decisions are made by traversing the tree. This traversal starts at the root and ends at one of the leaves. During the journey, you may go through a series of decision points.

As you can guess, FSM and decision trees are useful for simple behaviours, but when you start working on complex ones, they both can become really messy. Number of the states can grow enormously, transitions between the states can get tangled, or you can end up with a huge tree that you have no idea about the nodes.

You can try to mix FSM and decision trees to cope with these issues, or consider to use hierarchical FSM. However, if you are working on a big project, or after “human like” behaviours, then you should change your approach to other methods such as Goal-Oriented Action Planning (GOAP), or behavior trees. These are also the approaches used in games such as F.E.A.R., Silent Hill, Max Payne 3, GTA San Andreas, etc.

Another point to have a better (a more challenging, or “human like”) AI is making your AI learn and adapt itself to the game. This is especially important for the games having deep mechanics and innumerable options for the game play.

Currently, I am working with behavior trees and having an adaptive AI is one of the next steps in the agenda. So, I will focus on these parts in the future, in an another article. But, by the time, you can visit the following links for detailed information: