I am considering implementing dead reckoning to reduce the data that I need to transmit in my game. However, I'm worried about the implications it has on the other predictive measures I already have in place. In my architecture, both the server and the client run a complete simulation of the game world. The server occasionally tells the client where everything is and how fast each object is going, and the client does its best to predict where everything will be by the time the next update from the server comes. This works well (and essentially IS the client-side of dead reckoning already) when there are no unexpected forces like the player deciding to turn suddenly. Now I'm trying to add a "net force" aspect of dead reckoning. If an object is in a force-field, or if the player is simply holding down the accelerate button, I want to be able to tell the client about it once and then forget about it until the net force changes. The net force property would be easy to implement, but I worry that in order to follow it, the client would have to ignore its current physics simulation. For example, if the player is accelerating straight up, the net force on his ship might be <0, 10>. The client could follow that information via the simple newtonian equations. But when the ship hits a wall, the client will not get updated dead reckoning information (with a new net force) for some time. Meanwhile, the client will not show the ship bouncing off of the wall, because it is still following the simple newtonian equations of the last dead reckoning packet. It seems to me that the end result will be the client rendering the ship going through the wall, and then snapping back. This result is inferior to the current case, in which the client predicts the bounce, renders it, and then finds out it's right when the server sends an update. It has occurred to me that there might be some clever way to have the client determine when it should stop following the dead reckoning system. In the case above, the client could continue to follow both the physics simulation and the dead reckoning system. If the two ever disagree strongly about net force, give up on the dead reckoning system until a new packet comes from the server. This would work well for predictable forces - but then again, the whole reason I want to implement the net force property is for unpredictable forces like player input. Predictable forces are already simulated! Argh! Maybe if I calculated the difference between the physics simulator's net force for an object and the dead reckoning system's net force when the DR packet first arrives, I could look for differences in relation to THAT instead of any differences at all? I am still in the speculative stage at this point. Does anyone have any ideas? Thanks for any input~ Riley

Send changes in input state as soon as they happen. The user can't press/release buttons all that fast, anyway :-) This is similar to the concept of "important moves" in the Gaffer and Quake 3 networked physics articles.

If a message is lost, your next baseline will correct the position/velocity/force of the object.

Right, I already send changes in user input ASAP. What I'm trying to get at with this post is the conflict of having objects on the clients follow both the dead reckoning predictions AND the existing physics predictions. When dead reckoning disagrees with the physics predictions, how can I know which to follow? Dead reckoning will be more correct than the physics in many situations, and physics will be more correct than dead reckoning in many situations... I'd like to be able to predict when to use each one.

The reason to use dead reckoning is to avoid having to simulate physics on the client (which costs CPU).

If you're already running physics, then you don't need dead reckoning. You only need to figure out to do when you get a baseline update for an object that puts it somewhere other than where it actually want at the time of the update. Re-winding time and forward simulating is one popular choice, although it can get CPU intensive.

One benefit that running a dead reckoning system on top of a physics system has is that the server can use the DR system to better estimate when it should be sending updates to the client. That is, the server can send updates when the client will be out of position by some error threshold, as opposed to sending updates at 5 Hz.

It was that thinking that gave me the total mental disconnect that you have reconnected for me. As you said, and as I even mentioned in my first post, but failed to fully realize, is that a physics simulation is the client-side of dead reckoning already. I can implement DR to save on bandwidth... but I only need to do so on the server-side.

Discussing things here always brings a lot of clarity to problems for me. Thanks!