
Minimizing the Pain of Lockstep Multiplayer - Impossible
http://www.gamasutra.com/blogs/DanielCollier/20151124/251987/Minimizing_the_Pain_of_Lockstep_Multiplayer.php
======
metabrew
(famous?) Age of Empires article on lockstep multiplayer: 1500 archers on a
28.8 modem:

[http://www.gamasutra.com/view/feature/131503/1500_archers_on...](http://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php)

------
e12e
Reminds me of Croquet (a foss real-time 3d multiverse system similar to second
life) and the TeaTime protocol/system:

[http://dl.acm.org/citation.cfm?doid=1094855.1094861&preflayo...](http://dl.acm.org/citation.cfm?doid=1094855.1094861&preflayout=flat)
(sadly paywalled)

Essentialky if you model your world/simulation as objects and events/messages,
and you can isolate input (user input, possibly clock ticks) - and you can
order external inputs in a (distributed/consistent) log (a la apache kafka) -
then you can have a simulation that runs in parallel and lock-step across many
clients.

------
hcarvalhoalves
Sounds like the kind of thing you want to implement in a functional language,
to have strong guarantees of determinism.

Have some threads waiting on input (controls, network), dispatch to pure
functions running the simulation, stream render commands to a rendering
component. You can even consider the RNG as one of the input streams to keep
the core pure.

I'm not into game programming but this got me interested in implementing a toy
RTS!

~~~
panic
Functional languages can't help you when architectures, standard libraries and
compilers implement floating point slightly differently. Cross-system
determinism is a totally different property than referential transparency.

~~~
hcarvalhoalves
Ah, sure. I wasn't proposing it's a solution to floating point
incompatibilities, but for the lock-step engine.

------
jasonwatkinspdx
The title reminds me of one of my all time favorite simple hacks.

This was from an RTS game circa 2000, can't remember which. They were p2p
broadcast lockstep as the above, and UDP based. Since the bandwidth is so
trivial (boils down to what 10 fingers and a mouse can do), they'd just repeat
the last N messages in every packet as brute force forward error correction.
Lose a packet? Just wait for the next one.

~~~
dxhdr
Delta encoding is the more general technique you're describing. It's used by
most latency-sensitive networked games today, first made popular in Quake 3 I
believe. The general idea is to keep resending all changes in state since the
most recent ACK.

