## [Algorithms] 3rd person adventures - The saga continues!

 [Algorithms] 3rd person adventures - The saga continues! From: Diogo de Andrade - 2005-10-31 15:28:59 ```Hey all! My saga on building a 3rd person action game continues... After some experimenting with different methods of generating a navigation mesh for AI (which the best was basically my first algorithm, raycast based, with some subdivision allowed), I've stumbled with a bigger problem that I didn't even see coming... What I'm aiming at is a 3rd person platformer (think Ratchet & Clank, but not nearly as complex)... I have an environment modeled by my artist on the modeler tool (that is, no world builder tool), and I want to put my main character walking around the world... Besides the obvious camera problems that seem endemic to all 3rd person games, but that are reaching some solution, I'm having problems moving my character through the wall... I can make the character walk around "glued" to the ground fine (just raycast from his current (x,y-EPSILON,z) position along the vector (0,-1,0), get the first intersection, and that's the ground, and put the character there), but I can see lots of problems looming on the horizon, mainly: 1) The character should not fall on the abyss, that is, his walking should be limited to areas where he can walk (no falling into the void) 2) The character should not go through static objects (it's ok to go through dynamic objects such as enemies, etc) 3) The character should be able to go up steps, etc... I can see two different solutions to these problems: a) Use the collision detection + response to handle the walking; put simply, see if the character's bounding box intersects the world and if it does, get the normal of that collision and do the sliding thing b) Use the AI navigation mesh to handle where the char can go or not The problem I see with a) above is that it seems like a very error prone approach... The bounding box of the char will almost certainly intersect the ground at some given moment, and doing collision response for that case (and steps, for that matter) seems like a big accident waiting to happen.=20 The problem with b) is that I have to generate a finer-grained nav-mesh for the character, since the AI one doesn't go very near the obstacles (it's not important for the AI reasoning to get very close to the trees, etc), while the character should be able to go around obstacles by sliding, which demands a closer grained mesh... Well, my current algorithm generates a pretty good mesh for AI, but a very bad one for navigation... b) also has the problem of not allowing nice jumps without being mixed with a) in some form (although can't see the problem of that mixing)... Another solution I see for the problem of b) is make the designer draw the navmesh himself, but that sounds like so much work (and so error-prone) for a small developer like ourselves that I almost despair... So, my question is: how do people around here handle this? What's the "normal" way of making this? Thanks in advance! Diogo de Andrade Creative & Technical Director Spellcaster Studios diogo.andrade@... http://www.spellcasterstudios.com =A0 ```