Statistics: Posted by ozonex — 28 Jan 2018, 16:13

I'd like to chime in on this topic.

I just started looking at Box2D to play with at home and one of the first questions i have about it.. is it deterministic?

I work at Gas Powered Games and i can tell you first hand that floating point math is deterministic. You just need the same instruction set and compiler and of course the user's processor adhears to the IEEE754 standard, which includes all of our PC and 360 customers. The engine that runs DemiGod, Supreme Commander 1 and 2 rely upon the IEEE754 standard. Not to mention probably all other RTS peer to peer games in the market. As soon as you have a peer to peer network game where each client broadcasts what command they are doing on what 'tick' number and rely on the client computer to figure out the simulation/physical details your going to rely on the determinism of the floating point processor.

Heres a quick break down of what we do..

Our time step is fixed at 0.1f second, we use this timestep for all our math on the simulation thread. Each client simulates their own world/physics/steering/pathing etc etc. and theres TONS of float based math going on. Hash all position/rotations and CRC check them across clients and if the CRC check fails we pause the game with a big flashing DESYNC error.

When the CRC check fails we know that on Tick x client y had a 'desync'. As devs we turn on desync logging to try and hunt down why a single unit (out of a thousand units) would have a single pos bit off from another machine. Usually it's because theres a uninitialized variable ( which would result in random memory on each machine ). Or because something isn't done in the right order or tick.

In DemiGod the smaller grunts use full steering (ie repulse/attract accumulation to determine facing direction and movement like you see with steering boids) All of that craziness, completely deterministic.

The Ageia PhysX guys came in and showed us their technology and hardware, wanted us to use it in Supreme Commander to do its physics but we couldn't do it.. and thats because their software is not deterministic. You have to actually go through the code and actively care about determinism.

In short, we had to implement our own (more basic) physics code to ensure we had determinism.

Getting to the point of all this. We should not blame the floating point processor for not having this feature. The IEEE standard is a standard that our shipped games rely on for our games to stay in sync across PCs over the Internet for both PC and 360 hardware. For a game like supreme commander its nice to have the clients do all the work and yet still be in sync across different machine speeds.. have you seen Supreme Commander? its insane. And because we made our code base deterministic we have replays you can load/save etc.

I'm driving this point home for encouragement. I would love to see Box2D be completely deterministic, as there really isn't a good 2D physics solution or 3D solution out there that I know of that has the deterministic love poured into it.

Imagine Box2D with gameplay mechanics like Braid or speed up, slow down like in the Matrix and have the simulation completely in sync across all machines. that would freakin rock!

Ok so whats the solution? Well for starters we have to stop pointing the finger at the floating point processor and start pointing it at our lack of ninja strength. Then suck down some moutain dew, wrap a black t-shirt around our face ( leave a slit for the eyes ) then, while staring hard at the flat light, slam those plastic squares!


You'll want to build some way of recording sync data... we use a sync file log for each TICK containing the end CRC (of all positions/orientations etc) as well as all kinds of positional / ordering logging information. I use macros throughout our codebase, like this:

gpDesyncLog("gpnav: tick[%d] got pos[%f,%f,%f]", tick, pos.x,pos.y,pos.z");

When desync logging #define is enabled, that macro will printf spew that text to a log file (one per tick)... the files build up over time and when a desync is detected ( by CRCs not matching across machines ) we pause the game, run a diff tool on the log directory of all the tick log files and retrace where the desync happened and fix it.

Once you fix all the desyncs, your physics will work great over the network where each client is doing all of its own work and everything is in sync perfectly across ticks.

Its work.. and that's why you gotta get ninja on it. But I believe its worth it. It would kick serious rear if Box2D had this feature.

Unless theres a random function called or if you cant make the order of operations deterministic, or unless theres something im missing entirely, i don't see why Box2D couldn't become deterministic given some serious ninja action. Much like how continuous physics was added, someone just needs to kick serious a**, thats all there is to it.

I wish good physics libraries had this feature.. I believe in the future they will have it.

Anyway theres my 4 cents.. if its in your heart and its strong for this feature.. you gotta go after it!

- Elijah

Statistics: Posted by Katharsas — 28 Jan 2018, 16:09