I want to take a moment to point out two really great articles I read recently from “Gaffer on Games.” The first is an easy guide to implementing RK4 in your integrator:
http://gafferongames.com/game-physics/integration-basics/
This is one of those things I always thought I should probably get around to but it’s not critically important (Rift is full of such things). However in my recent work with the AI and steering it’s become more important. My problem with steering isn’t one of programming, it’s one of actually knowing what to do. The answer is sort of like “Turn as fast as you can until you get to the point just before you’ll overshoot under full turning in the opposite direction and blah blah blah.” It’s hard to get your head around. What’s worse is the part about “the point just before.” This assumes you can sort of see into the future a bit to know what’s about to happen. And if your integrator is a big pile of math you don’t understand, then there’s really no way to know what’s about to happen. So now I’m back to the article I previously mentioned. It very clearly lays out how the RK4 integration step happens. It even shows you the code in good old fashioned C. This is a huge thing for guys like me who go a bit cross-eyed when I start seeing math filled with Greek. Armed with this code I was able to create functions that simply tell me how far my object will turn (or move linearly) with a given force and time step. I can start to see into the future.
However that raises a new problem… what’s the time step? If you’re like me then your game is basically a big loop that runs the AI, then the physics, then redraws, and then repeats. The time step is always just how much time has elapsed since the last loop. Unfortunately this time step varies greatly from when you’re just a lone ship in deep space, to when you’re in the middle of a huge dogfight with missiles and lasers zipping around. How can we know how far into the future to look? I had been dreaming up a system of averaging the previous X number of time steps and then using that as my probable next step. It’s not perfect but maybe it would be “good enough” (Rift is also filled with code that meets this less then stringent criteria). However I was saved by another article on that same site:
http://gafferongames.com/game-physics/fix-your-timestep/
Simply put, decouple your physics time step from your game loop time. No, you don’t need multiple threads. You just accumulate time until enough has passed to run your physics. Then you run your physics until all that time is used up. So let’s just say that you would like your physics to run 10 times a second, or once every 0.1 seconds. When you’re out by yourself in deep space and your game loop is taking 0.02 seconds to run then you simply add those up until you get to 0.1 and then you fire off the physics. You end up with 5 redraws for one physics step. Now suddenly you’re in a big space battle and your refresh rate crashes to 0.3 seconds. Your game may look like crap, but if you just run 3 physics steps per loop your physics will continue to function smoothly. But don’t stop at my explanation, go read the article, it’s much more in depth and interesting.
So from those two articles I can look into the future, and I know exactly how far to look into the future. Suddenly my AI can start to do wonderful things. It can say “Well, if I hit the brakes now I’ll stop too soon, but if I wait one time step and hit the brakes then I will go too far.” That knowledge of the future should come in handy. I hope. I still haven’t figured out exactly how to make the steering work, but at least I feel like I’m heading in a good direction. Thank you “Gaffer on Games” for the wonderful articles.