Resolving NPC positions

Started by
1 comment, last by rgreene 19 years, 12 months ago
I put this in the generic "Game Programming" section, but I''m not getting any bites, I''ll try here. How are you guys resolving NPC positions? Right now in our code we have steering and formation code that attempt to move guys in a specific direction -- this is all well and good, until you need to resolve the y component of an NPC. In our last project we faked a solution by allowing a tolerance of +/- on the y axis for which a character could move, if you were above the tollerance, you would simply be unable to move, if you were bellow it, the NPC would start falling due to gravity. This has a bunch of issues (what if the tollerance is too low, or worse -- too high?). So, now we''ve picked up Novodex as a rigid body simulator, and I''m thinking of using it to resolve NPC positions. If anybody saw the presentation on Starcraft: Ghost at GDC, we''re trying to replicate that effect. The idea is we have an inverted cone, where the tip of the cone represents the NPC''s feet, and you apply a momentum to the cone based on where the NPC wants to move. The height of the cone will dictate the maximum vertical space you will be able to traverse, and things like gravity implicitly work themselves out in the physics simulation. The only catch is you need to do an extra step to set the desired position, then figure out where the physics actually tells you where the NPC is. Neither of these approaches is optimal, IMHO. On one hand you''ve got to write your own external force code (gravity, explosion forces, etc) and worry about threshold tollerances. On the other hand, you''ve got to deal with tweaking the physics system to get things just right (if the cone is on near flat ground, will gravity cause it to slide down the plane?). So, what do you guys do for your NPC code?
Advertisement
Same as for the PC.

All objects are subject to the physic simulation, and moving the chars is applying a force to them so they move. Physic simulation will take care where they finally end up.
-----The scheduled downtime is omitted cause of technical problems.
Hmmm. Well I wish I could help based on experience with the physics-based characters, but for locomotion we do something quite simple with traditional keyframe cycles. We just tweak the root bone position and orientation at the current keyframe to follow a prescribed spline path that is determined within a navigation mesh system. The walkable surface can be nonflat (rolling terrain) and we have a quadtree to do a quick height lookup, and the root is adjusted up or down for this. We don''t worry about sliding, just don''t introduce it. Character stance is as animated by an artist. Nav meshes are artist generated, so its easy to prevent motion through static world geometry bits. Our games, which are training games and not entertainment games, haven''t needed jumping so far, though we do have an implementation that just runs an animation cycle to jump that really only works correctly when the jump is over flat terrain. Rather primitive, though this technique is rather limiting and soon I expect to be looking into exactly the sort of problem you''re trying to solve.

Actually, we handle NPC''s and the player character exactly the same way. The only difference is the NPC locomotion paths are determined via the AI system and the player''s character path is determined via player input. Different types of path controllers, basically that can be hot swapped easily if the player assumes control of an NPC (which he can).

Graham Rhodes
Principal Scientist
Applied Research Associates, Inc.
Graham Rhodes Moderator, Math & Physics forum @ gamedev.net

This topic is closed to new replies.

Advertisement