Zen of Networked Physics
When i did my talk at AGDC this year, instead of using powerpoint i wrote my own presentation layer in OpenGL, then overlaid it on top of my networked physics demo program. ‘How hard could it be?’ i thought before i started. Oh if only i knew…
Crunch time aside, integrating my demo and presentation text allowed me to switch seamlessly between the two, which was absolutely fantastic because i had a load of visualizations already coded to help explain the main points in my talk. For example, i was able to show ‘ghosts’ of the cube so you could see the client, server and proxy (round trip) simulations simultaneously, showing how they always stayed perfectly in sync. I also had a nice visualization of the ‘history buffer’ of stored moves used for corrections with client side prediction, red and blue smoothed versions of the client and proxy, and was able to adjust latency and packet loss on the fly to show how the system behaved under varying conditions.
Now you too can play around with this demo program, and i’m releasing the source code too. You’ll need to download the latest Visual C++ 2005 beta and platform SDK from MSDN if you want to build the source code yourself using my project files, but i’ve also included a binary for those who arent interested in such things.
So what does the demo do? Well effectively its a networked rigid body simulation of a cube, where the cube can strafe and jump like an fps character. The idea is that it is possible to generalize the techniques used in first person shooter netcode to network any physics simulation given that you keep the simulation deterministic, drive the physics from input and have strong ownership of objects by clients. Indeed you could easily apply the techniques presented in this talk to a racing game, flight simulator or anything else where each client controls a single object on the server.
The key techiques presented are ‘client side prediction’ (predicting physics ahead locally while applying corrections from the server in the past), which eliminates latency for the client, and ‘important moves’ which eliminate snapping due to packet loss. This demonstration implements both techniques perfectly, so it is possible to set 50% packet loss and 2 seconds latency and still have a perfectly smooth simulation on the client. I’m pretty proud of this achievement 
To control the cube just use the arrow keys to move, and space to jump. Escape toggles presentation mode and pagedown goes to the next page in the talk. Various other keys exist to control the visualizations, the amount of latency and packet loss, and the important move system. See the ‘readme.txt’ in the zip file for details.
Is there any more detail document about this program?
or some theories or principles about it?
there is a set of physics articles that cover the foundations of this program, the last article explains the networking – the only thing it doesnt cover is the “important moves” concept
http://www.gaffer.org/articles
cheers
I first want to thank you for your physics articles. They lay out basic but fundamental ideas. I wish very much that there were more.
I was wondering if you could explain the “important moves” concept, and also elaborate on more general networking techniques for games where ownership is not so clear.
Thanks.
when ownership is not clear, use a peer-to-peer lockstep model, but i would not recommend this, its much better to have a server.
cheers
regarding important moves.
the trick is that to combat packet loss, you send all input data since the last acked frame from the server, important moves are just an optimization, eg. when you have binary inputs (left,right,forward,back,jump) -> important moves are the moves when values change. 0->1, 1->0. its just delta compression.
Great visualization. Could this be implemented in Shockwave under Havok physics?
Hi!
Thanks for that interesting article.
I’m trying to make a scene with deterministic behavior based on input’s user on Windows, but I founded a problem… float precision.
When I launch two executions in the same machine using the same recorded input stream I obtain different results.
How can fix it (avoid use of fixed point) ? Using _controlfp_s or similar perhaps?
Thanks a lot.
yes it is true that it is virtually impossible to get deterministic floating point across different machines,
if you absolutely require determinism, one solution is to use integer math, another is to write your own floating point emulation implementation — trading speed for deterministic behavior
my recommended solution is that you dont require exact determinism (eg. dont do lockstep networking), but instead follow the techniques in zen of network physics, and allow for a rewind and correction phase when things desync for any number of reasons, packet loss, non-determinism (which you should MINIMIZE but can never really eliminate…), and so on.
cheers
check the download link please..
yes. unfortunately the download link is broken since ace-host.net deleted my entire site last weekend, i’ll have it back online shortly — i have to rebuild it from backups cheers
back online now, cheers
Would it be possible to use rounding of FP values to create an absolutely deterministic system even between 32bit and 64bit systems? I think it would be possible and the overall loss of precision should be completely irrelevant. In essence we would trade precision for the ability to reproduce results. Maybe 28bit precision? Rounding would need to be done at significant points to avoid compounding errors. Having a zero fill system for the last 2-4 bits would likely not impact performance too much on well designed processors.
its certainly possible, but you still have to deal with the differences of FP hardware implementation – it would also be quite slow because you’d have to explicitly store to memory and reload into FP to truncate precision at each step
i’d be inclined to just write my own 64bit integer based routines, or emulated floating point routines in software if i were to take this approach
but i wont because there are other ways of handling the problem! dont rely on absolute determinism! – just trust your result to be *mostly* the same and have the ability to correct for error over time as it drifts
cheers