Tutorial
doggr

Building AI for a Simulation Game from the Ground Up

Alex J. Champandard on October 24, 2007

Do you ever ponder about the best way to create artificial intelligence for games? Well, me too! After years of industry experience and research, it still fascinates me. But one thing is certain, it requires lots of practice…

This article launches a series of tutorials, every Wednesday on AiGameDev.com, building game AI from the ground up. The plan is to focus on incremental improvements with tangible benefits at each step. Of course, over the months, it’ll hopefully turn into a showcase of current game AI techniques.

Dog Behaviors

Figure 1: Different dog behaviors.

The simulation game involves dogs interacting together, though the design is pretty open at this stage, as it’ll be refined incrementally based on your contributions! (Be sure to join the discussion each week by leaving a comment.) This week in particular, you’ll find out what’s in place already and what the plan of attack is.

Building Blocks

Before creating the AI, you’ll need the basic ingredients of a game first! This tutorial relies on simple assets and a game engine.

Models & Animations

It’s tough to find good models and animations online, so often the best solution (if you want things to look good in the end) is to buy “stock” assets. In this case, the models look fine despite being low-poly, but they reveal a few glitches when animated. The animations won’t win any awards, but they’re better than programmer art.

Specifically, the animations available are:

  • For movement, there are animations for walking, jumpy run, turn left or right, strafe left or right, sneaking and limping.

  • There are also different postures (including transitions) such as lying down, standing on two legs, sitting and sleeping.

  • In terms of interaction, there are animations for picking-up, sniffing, licking, eating/drinking, peeing, pooping, begging and fighting.

  • Other behavioral animations include, high and low jump jump, barking, scratching, chasing tail, growling, and excitement.

No doubt it’ll be necessary to tweak the animations into a AI-friendly format, for example to add missing looping animations, or correct existing ones. Also note that all the animations are modeled at the origin, so there’s no movement in the animation data. (This affects the design.)

Game Engine

While many open-source engines have similar features, the plan here is to use Ogre3D. It provides exporters for the models and animations, and stores them in its own format for easier loading. At runtime, Ogre provides an API to play each animation, control their speed, and blend between different animations. Of course, it’s trivial to move around any entity in space using the scene manager.

Artificial Intelligence

You don’t need anything but a 3D engine and assets to start programming AI. However, this tutorial series will be developed alongside Game::AI++, an open-source library that’s in early development stages. This project will be a good opportunity to iron out the rough edges in the parts of the framework that are already implemented. Rest assured though, re-implementing the ideas in the tutorials won’t require using Game::AI++.

Getting Started

At this stage, all the basic elements of an interactive simulation are already implemented. The game view opens, models are loaded and can be displayed on screen.

Dog sitting, dog lying down.

Screenshot 2: Two inanimate dogs with static skeletons.

The next step is to work on the most basic AI features. Typically, the best place to start is to write the logic to control each actor, in particular:

  1. Moving Around — The 3D engine already supports most kinds of transformations, but these need to be exposed in an AI-friendly way. Specifically, all movement needs to be done relatively to the current position, and the parameters of movement must be easy to tweak.

  2. Playing Animations — Again, the animation system in the engine handles posing the skeleton from keyframes, but there needs to be an easy to use interface for each actor in the game. Options such as playback speed and looping should be easy to specify also.

If you have other suggestions about places to start the implementation, feel free to use the perfection game to help improve this plan of action. Post a comment below.

First Design Ideas

Here’s where you get the chance to think of simple designs that can be achieved with this simple technology. This week, there are some important restrictions:

  • The behaviors must be applicable to individual dogs only.

  • The behaviors should not require reacting to the world.

Anything else goes, so feel free to share your scary ideas about this game! Think along the lines of behaviors that are sequences of different animations and movement.

Discussion 4 Comments

Sergio on October 25th, 2007

I like that you're using an existing 3D engine and pre-packaged models and animations, and thus can focus on writing the AI. Also, specifying the resource constraints from the start helps understanding the limitations of the final game. I miss some description on how the game architecture is going to be. I don't know Ogre3D so maybe it's forcing decisions upon you, but there are two things I'd work on before starting with features like playing animations: a) Logic framework. Essentially an entity system, hierarchical or component-based, including a common class for all objects in the game, and possibly a manager with a weak reference or handle system (to avoid having to store the other dog's pointer). b) Separation between simulation and render. I like having this clear from the beginning, otherwise it's hard to split them afterwards and you end up with unwanted dependencies. There are other supporting systems that you need (input management and camera control come to mind), but I guess they are not that critical at this point, and can be easily changed. And the very first AI behaviour I would implement is also the simplest: rand(). Have dogs move around to random positions, stay there for a random amount of time before moving again, and have them play a random idle animation (lying down, barking, peeing, whatever). Emergent behaviour at its best!

Dom on October 25th, 2007

This is very interesting and I am looking forward to the next postings about this project ... I am currently looking into OGRE and thinking about possible 'behavior/AI/controller' frameworks, too In order to get a higher iteration rate in tweaking and reusability - I would use data attached to each dog: common data (emotion, desires etc) plus 'micro-behavior'/task specific data. As you say you want to start with 'movement' and 'animation', the question is what data has to be defined in what 'data-packs' (= components?). This approach of attachable 'data-groups' I often use in Virtools, too. Especially when I need to handle several entities using aprox. the same logic. I iterate through all entities that have the desired data-set attached and handle them. I can branch the code depending on the data found, so this isn't always the exact same code (path) for all inside the group. Due some Virtools design issues, this is even more efficient for bigger numbers of similar entities then duplicating and attaching the 'logic/script' onto each entity. I often refer to this as 'manager approach' in order to distinguish it from the, by Virtools users commonly used, 'behavioral approach' of attached scripts..

alexjc on October 28th, 2007

[B]Sergio[/B], I can spot the seasoned veteran here :-) Regarding your questions: a) I have a basic entity class, and I expect to use a very lightweight component system that just stores pointers within the entity to "components". Ogre3D doesn't impose many restrictions here. I can add more functionality to the game logic (e.g. fast searching of entities) quite easily later... b) Using Ogre3D helps for that. Since it handles the rendering and it's in a separate library, that naturally separates the code... So on that front, everything is good! Great advice on using [TT]rand()[/TT], I can see it taking shape (maybe a bit chaotically at first :-) [B]Dom,[/B] Thanks for your feedback. I think you're very right about the configurable data. I plan on having two kinds, first in the logic itself, so you can customize each behavior separately, then some central parameters as you said. This can be a component too, yes. I'm keen to just develop this incrementally, test driven, and rely on good code structure and refactoring to add new functionality. So we'll see how it works out :-) Alex

diegix on October 28th, 2007

If I were to test around AI techniques in a simple game like this without any need to impress anyone who is not AI coder I will not care about models neither animations. I find that avoiding any extra work in handling models, transformations, animations, transitions between animations is a good idea to reduce the extra non AI work to the minimum. Of course using Ogre will help, but using just colored dots in a 2D environment will reduce it even more. I will start implementing individual behaviors like barking, sitting, rolling. Separating the behavior implementation from the decision part. These behaviors will control animations, sounds, possible future events to the world or other characters. The decision part could be just a predefined sequence of actions or just the rand() as Sergio suggested.

If you'd like to add a comment or question on this page, simply log-in to the site. You can create an account from the sign-up page if necessary... It takes less than a minute!