[Bekwnn]

The quickest path is to just start writing real time simulations of stuff and reference how other similar simulations went about implementation; terrains and erosion, cloth, fluid, etc.

It's easier if you have a bunch of random linear algebra and calculus knowledge lying around in your head, but trying to study that stuff isn't the most direct route.

[cpeterso]

I don’t have a good reference to share, but also read up on game tick loops and clock time. Processor speeds vary and thread scheduling is nondeterministic, so a stimulation code must be written carefully to produce a deterministic result.

[galkk]

I don't think that you even need to produce deterministic result in game

[setr]

Same-machine determinism is probably not too bad, and would greatly aid debugging; cross-machine determinism is mainly really useful for lockstep multiplayer I think.

But yeah it wouldn't really matter in-game unless you're trying roll time backwards/forwards as a game mechanic.

Also of note, all games can be considered simulations, with varying complexity and rules (and players given a way to interact with the system) -- from that perspective, the only requirements to implementing a game simulation is whatever is required to implement any game.

[suby]

This is correct. If you want to create a multiplayer game, you can go about it by running the simulation on everyone's computer, and sending only the inputs to the simulation across machines (Lockstep networking). This requires the simulations to be deterministic which can be tricky to get right due to differences across architectures / compilers.

This is the approach used in a lot of RTS games. Starcraft 1 and 2 both work this way. I believe the original doom used this method as well.

You can get away with not having deterministic simulations via having the server run the simulation, and sending the data required for clients to render the state of the world that they can see. This requires a lot more bandwidth and complicates the network code quite a bit (or at least demands a certain architecture for the code). You still need to run some of the simulation on the client just for having acceptable visuals due to how long it takes for data to travel from server to client (level collision might also be simulated on client for example), but this client side simulation is just for visuals. Still though it's perhaps easier to get a reliable solution working like this due to how hard it is to get deterministic simulations.

The big downside to lockstep, beside it being hard to get deterministic simulations running across machines, is that it opens you up to certain types of hacks. Because the simulation is running on everyone's machine, this allows malicious players to hack the code to do things like let them see through walls or reveal the entire map.

Some games like (some) fighting games use an approach where they just let the simulation run on the client, predicting what they think the inputs will be, and if they get data from the server which doesn't agree with the predicted inputs, the game will revert to the last known good state, and just re-run the simulation with the correct inputs. This sounds insane but if for example a player is holding down W to move forward, it's more likely that W will continue to be held down rather than being released on any given frame.

[MereInterest]

Regarding the fighting game approach, that would be an interesting application of machine learning. Given a player's previous performance in a fight, predict what they will do and use that as a better heuristic in the absence of additional input. The downside is that lag would be much less identifiable as such, because things that require volition (e.g. an attack) might be predicted and shown to an opponent even if they never happen.