Last time I went over the initial implementation of NPC movement. This weekend, I hooked up the NPC walk and run animations, as well as properly computing the speed that NPC should be moving at according to the chosen animation. I also fixed the bug I observed last time, where NPCs would zoom around corners.
First the bug. Here’s a better view of what used to happen:
What turned out to be happening is that I had a bug in a piece of code that tried to determine if an animation had overshot its destination. This code was originally written for doors, and was never properly tested for directions that aren’t axis-aligned. Honestly, this code was probably written late at night… reading it now it doesn’t make much sense.
The solution was much simpler. Before I update the position, I make note of the animation direction. Then after the update, I compute what the next direction will be. If the two directions are pointing in opposite directions (e.g. the dot product is negative), then we’ve overshot the destination. Keep in mind that NPC movement is comprised of a series of these segment animations.
The next step was to hook up the walk and run model animations, as well as determining their speeds. The MDL file format contains some information about the total distance traveled during an animation sequence, so it was trivial to take that information and compute the speed using the length of the animation. And here it is!
And here’s that same sequence but using the “run” animation instead:
You’ll notice that we’re still not rotating the model. That’ll come next week, when I tackle computing the direction for each path segment, as well as determining the best way to interpolate between them.