[Enigma-devel] network 2-player game

[Ronald Lamprecht]

Some experiences and thoughts about a future network 2-player game feature.

A few months ago I fiddled with enigmas event handling to get some 
practical experience how the game behaves on queuing and delaying 
events. I did that because I had 3 different approaches for a network 
game solution. When I did knew what basic features enigma needs to 
support I did postpone the direct efforts and did concentrate on the 
features for the next release.

But of course I will share the results if there is interest:

Tacvek wrote:
> AIUI there wold not be a need for the levels to be in sync. This is because the 
> way the
> server-client split was designed, only one of the the two would be running the 
> underlying engine.
> The other player would be running just the client end of Enigma, which would be 
> sending information about input to the server,
> and displaying images/playing sounds when the server commands it to.
> If that model is kept then it would be entirely possible to be playing levels 
> that are part of a levelset you do not have locally.
> (The other player would be the server).

Really?

Do not get confused by the class naming. The current networking approach 
is a pure client-client-class conversation as the client is the major 
part of the event-handling. The server-class is something like a 
god-class that creates the world (level). Even though it is possible to 
send all information about display changes form one engine to the other 
you should not underestimate even this logical data stream if you have 
10 fast moving actors on the screen. And the receiver will expect a 
steady stream of upcoming display information.

Besides that, have a look at the timing: Enigma is a "physical" 
simulation with an event time basis of 10 ms, the actors moves are 
integrated on a 2.5 ms (!) basis. An internet roundtrip even on UDP 
basis as we do, will take something in between 200 - 1500 ms ! The 
demands of enigma are due to complex physical simulation dimensions 
higher than on other networking games.

In a classical client/server approach the client player would react on 
some visual backfeed he receives from the server. Until his events 
reaches the server the physical simulation would have proceeded 200 - 
1500 ms. I guess the client player would loose control of his marble 
very quickly!

By calculating the world on both engines we can easily half the delay. 
Of course we need 100% synchronical running engines - that means same 
levels, libs,... and same random seeds.

But I fear that users still will demand less delay - and I am sure that 
is possible: If we can caculate one world on a 2.5/10 ms basis we can 
calculate 2 worlds, too. Thus we can let our server-god class generate 2 
worlds in parallel: one world the synchronized secure world and one 
world  an extrapolation to the current point of time, including all 
events of the user of this engine and an extrapolation of the events of 
the other player. This extrapolation is what the user sees - with all 
his moves in time. If the events from the other users show up a 
difference to the extrapolation beyond acceptance and from time to time 
(~ 2s ?) we have to recalculate the extrapolation on basis of the 
synchronized world. This means from time to time some glitches on the 
other marble, but instant reaction on the own marble and absolutly no 
logical mismatches on the long time basis.

The demanding task of the network game is not the event queueing and 
networking stuff but the cloneing of the world! I started with the Lua 
world part -- that is the reason we need to upgrade to Lua 5, because it 
supports serialization.

Any comments and additional ideas?

Ronald