Article
ProceduralAnimation_Video.medium

Animation-Driven vs. Procedural Locomotion in Games (and Last Call for Members)

Alex J. Champandard on October 7, 2008

IMPORTANT: You have slightly less than 15h to sign-up as a member of AiGameDev.com’s brand new continuous training program. After the launch week ends, the doors will close and the charter price will disappear. Find out more, click here.

When it comes to locomotion, there are two general approaches in the games industry: one is bottom-up (or animation driven) which provides more realism at the cost of responsiveness, and the other is top-down (or procedural) which allows the AI to be more reactive at the cost of motion quality.

I brought this subject up in the live Q&A earlier today. Here’s the video (11 min, 11 Mb):

The reason I brought this up is that I’m currently implementing the animation system for the AiGameDev.com sandbox, and of course we’ll need to implement both as a proof of concept to learn from — but also because this is a great foundation to have in place because it helps find trade-offs between realism and responsiveness.

Discussion 4 Comments

alexjc on October 8th, 2008

[B]Angel,[/B] Thanks for watching the video, and for taking the time to post your thoughts. I always appreciate these kinds of discussions. [quote]The communication between the Animation Layer through the AI Logic should be made by exposing all its relevant internal state and events to the AI, so the AI can monitor and control them. What do you think about it?[/quote]That makes sense for animation systems that are simpler than the AI, as you describe them. I guess an assumption that I was making is that I see animation logic as incredibly complex, almost as much if not more than the AI itself. As such exposing all the animation's internals to the AI is a bit overwhelming, and could be a waste of time for an AI programmer. You don't want to baby sit the animation system, you want to give it concise "orders" and let it figure out what you want -- with a little negotiation if necessary. That's why I think this becomes quickly very complex, and of the domain of multi-agent communication and planning, because both components are so complex that they simply cannot be "exposed" in their entirety to the other without significant increase in complexity. As such, I see the challenge as finding a way to get those two systems to negotiate such that they can keep all their complex internal logic "hidden" yet still find a good compromise. I hope that makes sense. My 10 minute video doesn't do justice to the topic, but it's a start! Alex

hellokeith on October 8th, 2008

Alex, I was thinking about your mention of a hybrid approach. So your AI logic can use motion capture data as a base and then alter it dynamically to better fit the situation. How about pre-computing a certain number of skeletal iterations? Say you have 300 motion captures (I have no idea if that is a typically low or high number). And then you have your AI procedures that can work off those captures to re-compute 3000 skeletal positions, with some acceptance/rejection logic so that you get as vast and different positions as possible. The benefits could be that you only have to run the intensive pre-computation once for every game skeleton type and save real-time processor cycles for other things.

alexjc on October 9th, 2008

[B]hellokeith, [/B]Typically the process of manipulating, overriding and warping motion capture is easily fast enough to be done at runtime. Using memory for these things if you can calculate them isn't generally desirable. But you're right, in some cases for things like animation mirroring, it makes more sense to do that offline. Alex

alexjc on October 18th, 2008

[QUOTE]What I was trying to remark is the fact the Animation Layer should be autonomous, and offer a good interface and easy interface for the AI to manipulate it, but without been dependent on the AI. This independence is beneficial, because, for instance, that animation layer will be probably the same for the player character, and the AI layer cannot ask the player what to do next. I think the AI should be think as a replacement for the player, and given that, it is good to isolate it so no other game system has direct dependencies with it.[/QUOTE] [B]Angel,[/B] That's a really interesting subject. I agree that you don't want the animation system to [I]depend [/I]on the AI, or knowing what's going to happen in the future. But if that information is available, then the animation system should use it. This is the only way you'll get realistic animation, as the alternative will be very reactive and have little insight into what could happen next. With AI, you already have a huge amount of information about what you know will happen, so sharing that with the animation system makes things both more efficient and more realistic. I think sticking to a "player-only" animation system is one of the biggest things holding back AI-Animation integration. Of course, there should be ways to do both -- supporting player and AI with the same animation system. Alex

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!