Thankfully, it’s publish. For all you programmers out there, I just published an article in Game Engine Gems 2. It’s titled, ‘Believable Dead Reckoning for Networked Games’ and it’s something I’m particularly proud of. I researched the topic extensively, so I hope it will help save some serious development time. Time that is better spent improving game play!
Game Engine Gems 2
But, I’m getting ahead of myself. Let me back up. As game devs, we like to hit 60 frames per second (aka Hz). This is particularly important because our brain processes vision from our eyeballs at about 72 Hz (90 for peripheral motion). So, if we get too far below this, the brain starts to perceive gaps in data – which are annoying. Unfortunately, at 60 Hz, each frame only lasts 16 milliseconds, which isn’t very much time to get a position report from someone all the way in California. Bummer.
In practice, this becomes a very major problem for any sort of networked game. Players don’t care about networks, lag, latency, bandwidth, server ping, or any of that jazz. They just want to have fun and they darn sure don’t want to see networked vehicles jittering, bouncing, or warping all over the place. Never mind that it took 100 ms to get the data out and back again, making it fundamentally impossible to depict exactly where someone is right now. Your players just don’t care. They expect us to figure out all the ‘voodoo’ and make things act in believable ways.
Enter dead reckoning, also know as ‘client side prediction’ or once upon a time, ‘zero ping’. Dead reckoning was originally used by early sailors to help them find their way home, across oceans, using only stars. (Thank God for Google maps!) In this chapter, I discuss pretty much everything you need to know about dead reckoning. It starts with the basics, works through the theory, and builds up an entire solution (including algorithms and source code). It presents existing techniques as well as a new technique I call ‘projective velocity blending’. In hindsight, that sounds like a fun way to decorate a birthday cake…
If I could print the whole article here, I would. But, here’s at least a short excerpt to get you started:
“Bob isn’t a bad developer; he just made some reasonable, but misguided assumptions. After all, the basic concept is pretty straight forward. Dead Reckoning is the process of predicting where an actor is right now by using its last known position, velocity, and acceleration. It applies to almost any type of moving actor including cars, missiles, monsters, helicopters, and characters on foot. For each remote actor being controlled somewhere else on the network, we receive updates about its kinematic state that include its position, velocity, acceleration, orientation, and angular velocity. In the simplest implementation, we take the last position we received on the network and project it forward in time. Then, on the next update, we do some sort of blending and start the process all over again. Bob is right that the fundamentals aren’t that complex, but making it believable is a different story.”
A little bit of the process is described on the Wikipedia entry for Dead Reckoning.