Article
files/QUESTIONS

The Secret to Designing Behavior Logic in Layers

Alex J. Champandard on February 1, 2008

In any part of your game, as the design gets more complex you’ll find it increasingly hard to build the logic to implement it. Whether it’s animation control, movement, individual orders, squad behaviors, level scripting, or game logic you’ll find the same problems as the system gets bigger.

The question is, how do you manage the interaction between all these layers of logic in the game? More to the point, how do you make sure each layer stays manageable too? As Ian Morrison noted in this thread of the forums (registration and introduction required):

“One thing I’ve noticed, though, is that a lot of AI development ties the animation VERY closely to the decision making, such that the animation is capable of interfering with decisions!”

Layering is certainly a solution to this kind of problem, but certain approaches are better than others.

Giving the Right Kind of Orders

The trick is to let the lower-level handle the complexity, but still retain enough control at a higher-level when necessary. It’s very simple:

“Orders to lower-level systems should consist of a finite task that terminates, then leads into a looping state that requires no supervision.”

This is a very powerful idea, and almost too easy to dismiss or ignore. Yet I’m willing to bet a majority of design problem you have in your game could be solved by applying this idea to part of the logic.

State Machine Orders



Figure 1: The anatomy of a perfect order as a finite task then a looping state.

Of course, if you want to leave even more responsibility to the underlying system, you can let it figure out part of the order, for example:

  • Deduce the most appropriate task(s) based on the current state and the requested state.

  • Induce the best state to use from an order consisting of a task only.

The higher level system should be willing to give up freedom whenever it can, but this approach also allows it to request very specific results.

Some Examples

These ideas are applicable anywhere, but these are some of the most useful:

  1. Animation — Trigger a transition (i.e. a gesture like ducking) into a looping cycle (i.e. a posture like crouching).

  2. Movement — Request locomotion (e.g. walking) to a destination point where a repeating behavior can be played (e.g. standing).

  3. Behavior — Ask to advance using cover to a target and then defend it by patrolling.

  4. Groups — Order leap-frog to fall backwards and then hold the position around a waypoint.

  5. Levels — Setup waves of attackers then a quiet period waiting for the next “phase.”

In fact, setting up an interface that supports this task / state combination is a great way to start the development of any logic in a large system!

Consequences

Here’s what starts to happen when you design systems using this approach:

  • You don’t baby sit the lower-level system in any way.

  • You give it orders and let it run, potentially for a while without having to worry.

  • You don’t keep track its state or mirror its logic at a higher-level.

  • You let the lower-level system remember the state variable for you!

  • You work by reacting to changes in the lower-level system only.

I’ll purposefully keep this article short emphasize that this is a very simple trick that’s very widely applicable. Remember: the best orders consist of finite tasks followed by looping states.

Have you used this trick to help design your behaviors? Do you think it could help you structure your logic better? An for a bonus question, how do goal-driven system help with such a design?

Discussion 1 Comments

bknafla on February 2nd, 2008

A very nice article about layering in game AI (or even in the whole game architecture) is "An Orwellian Approach To AI Architecture" by Igor Borovikov: https://www.cmpevents.com/Sessions/GD/AnOrwellianApproachToAIArchitecture_01.doc Hierarchies help decoupling and he identifies rules how different layers should communicate with each other (lower levels only report changes but don't request actions while higher levels observe them and send them the tasks). AI is build from agents that are organized into a tree. Leave agents might be finite-state machines that control a specific non-player character while higher level agents might be squad leader AI that coordinate their child agents. Igor also separates between dispatching agents (control logic) and collection agents (a collection owns its children and therefore controls their creation and destruction). Agents communicate via message passing to be decoupled. A nice article about separating AI and animation is published by Yordan Gyurchev: http://www.gyurchev.com/docs/NPC%20Mechanics.pdf He separates high level decision making that sends commands to be executed to the low level character mechanics (action execution) a bit like the idea Alex describes above. Character mechanics are like a low-level agent that gets commands to execute (walk to pos x,y,z) and update their state and the associated animation from frame to frame. Commands are like messages. The mechanics agents send status reports to the higher level decision making agent - like "starting action", "stopping action", "entering action loop" or "ignoring command" (if a command can't be executed, for example you can't walk while being paralyzed). Cheers, Bjoern

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!