Should I use fixed or dynamic time step in a networking game?

Question 1

You can basically throw determinism out the window if your timesteps are not synchronized. Even when they are, determinism is difficult.

Spending less computation on simulation will have real costs that may not initially be apparent. For each different setting (and in the case of dynamic timesteps/iterations, for each different individual execution) the resulting behavior on the same input can be different. You can have a user run on really slow hardware that can potentially completely cheat through your levels.

Determinism is perhaps marginally less important outside of a multiplayer engine context, however simply not having a deterministic system will make it significantly more difficult to reason about pretty much anything (gameplay mechanics, game difficulty, exploits) which can impact nearly every kind of game I can think of. Imagine a puzzle game that wasn't deterministic.

Question 2

I really believe fixing the timestep is the best way to go. I can't remember clearly enough but in one of our games we were having troubles with dynamic timesteps during collisions. Ofcourse most people would say our collision detection code was either not well written or we could use some advanced techniques like ray casting, but we ended up landing on fixed timestep with a for loop that would do the physics update whenever the delay seemed longer due to slow processing power of device or some other reason (CPU busy?), etc. The process was simple enough and we were all happy with the results :)

I think the creator of Box2D himself is in favour of fixed timestep, I read it somewhere although can't find the resource atm.

Question 3

Can we assume that you are trying to get the same results for the simulation on all clients? If so I think you need to explain your reasoning why having them all doing different calculations would be a good idea!

Or perhaps you meant that all clients will do the same calculations, but the timestep will vary during as the simulation progresses, but that is quite the headache to implement and debug. For each client to come up with the same (or at least similar) result, they will need to be using the same length timestep for each step, so you will need to send this across the network too, eg. physics step 32241 is 16ms, step 32242 is 18ms. Apart from requiring extra network traffic, each client does not know what length timestep to use until it receives this information. And where does it receive it from? Presumably the slowest client will dictate how fast everybody should be going? I can't see it working any other way. So client also have to continuously let the server know how much processing they can handle, and the faster clients will be dragged down to that level of performance.

But as Steven says, there will also be other problems even after these technical difficulties have been taken care of. Most notably the effect of gravity changes with different timestep lengths, so for example in a platformer, the height your players can jump would be continuously changing. If there are platforms that are normally just reachable, they might suddenly become unreachable when a slower client joins.

If you really did mean that each client will use just whatever timestep length it feels like, that would work but the server would need to send out an official snapshot of the world state at very very frequent intervals to get all clients snyced. Technically this would be much easier to implement, and each client would run as smooth as it could, but with more jerkiness as the world state is corrected to the official one, for clients that run either faster or slower than the server does. Hm... maybe this is the best way after all. You might be interested in this article explaining how Quake3 does something like this: http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking