I once used determinism as an AI tool: ran a copy of the physics simulation to 'look into the future' and predict the movement of what visually looks like a chaotic system. This prediction could then be fed to some AI agents and give the appearance of 'intuition'.

That sounds brilliant. If you want to write more about how that worked, I would like to read it.

This was for a basketball game that will remain unnamed; I was not around when the game was released, and it's been many years since then, so I don't know if this stayed or not.

I wrote a 99% deterministic physics system for the ball trajectory during shots and passes, which gave the ball an incredibly natural behaviour. When a shot was taken, the system simulated up until the ball went below the rim's height, so it knew if the shot would hit or miss, and where was the best position to go for the rebound.

Once in a while the prediction would fail. Determinism is freaking hard, but luckily the game didn't rely on it for networking or anything else.

While debugging I also made the experiment of feeding this into the announcers and color commentary. The result was funny and disturbing in equal parts, definitely not a good idea.

Also one of the hardest patterns to do right (explained somewhere else)... one small glitch in the world state and the state goes out of sync.

Yes, these are very subtle. For example, floating point computation has different precision depending on the machine. This might lead to small differences in the game state, which grow over time (chaos theory yay). It is really hard to hunt such bugs. The fix might look like this:

  - double result = x * y * z;
  + double tmp = x * y;
  + double result = tmp * z;

The intermediate value x*y is rounded to double precision afterwards, whereas it had machine precision before.

(disclaimer: second hand war story from OpenTTD, might not be entirely accurate)

Indeed, if determinism is very important, fixed-point arithmetics should be preferred over floating point arithmetics - at least in the game engine, for the rendering floating point should be fine.

Note that fixed-point arithmetics is almost identical to integer arithmetics, thus easy to implement. If you define your physical units small enough (e.g. velocity as pixels/ms instead of pixels/s), then you can use integer arithmetics right away without any confusion.

One minor drawback is that you don't have easy access to cos(), sin(), sqrt(), etc. without going through floating point. However, you usually don't need those in the game engine anyway. For instance, instead of "sqrt(xx + yy) < r", just write "xx + yy < r*r".

The major drawback is that you now might have to deal with integer overflows (and underflows). You should deal with them in floating point, too, but these are more unlikely there. One might think that this won't destroy determinism if you are using e.g. always 32 bit integers on all platforms, but note that some kinds of (signed) underflows or overflows are technically undefined, at least in the C standard, so some compilers might do optimizations that lead to different underflow/overflow results than expected.

Floating point arithmetic is deterministic if you are careful enough:

> "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 adheres 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."

See http://gafferongames.com/networking-for-game-programmers/flo...

This is an interesting article (well, in large part collection of quotes/resources) on the interaction of deterministic synchronization and floating-point: http://gafferongames.com/networking-for-game-programmers/flo...

There seem to be conflicting opinions from game developers about whether you can coax determinism out of IEEE 754 floating point, if you're careful about it. From what I've read, the IEEE 754-2008 revision is supposed to take the goal of reproducible results more seriously as well, but I'm not sure how widely implemented or reliable its efforts in that department are.

x87's 80-bit floats should be avoided for deterministic game state, not to mention how much faster SSE generally is.

I had a problem in flash where iterating over a dictionary, order being different on different platforms, so updating all the game objects would happen in different orders.

But it always worked on my computer!