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
_______________________________________________
Enigma-devel mailing list
Enigma-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/enigma-devel
