Multiplayer over Internet and pitfall of floating-point
To this topic my attention was attracted by
wistful consequences of attempt to play Quake III through Internet. I
now have a cable ISP, and the bottleneck of dial-up connection is
No, I can't complain for gameplay itself. Playing in team with real
humans is much more interesting, than with bots. But at end of the
month, after calculation of the traffic...
Of course, I suspected, that Q3's information flow is heavy, but
whole fifty US dollars for just few days of harmless entertainment...
is obviously too much!
Client-client vs. client-server
How worked the multiplayer in past days (beginning
from Grandfather Doom,
and ending with Duke Nukem and its clones)?
All computers, after they establish the connection,
simultaneously loaded game level, and they all waited until slowest one
will finish loading. Then they begin game (also simultaneously),
sending each other only information of player movement control, i.e.
which keys were pressed, and how much mouse was moved.
With all this, game engine worked only on integer
mathematic, and due this, when identical player control command info
affected identical physical game worlds, these game worlds worked on
all computers synchronously.
That was typical client-client architecture. Its
great advantage, in comparsion with modern client-server one, was much
lesser network traffic: after all, when there are only two players,
only information about states of two objects travels through network.
Not as in modern games: players, plus herd of monsters, plus flying
missiles, plus elevators, and even plus blood splashes...
Unfortunately, disadvantages of that architecture
were great too (let's set aside for now question about speed difference
between floating point and integer on modern processors): At first, all
players were forced to enter game level simultaneously, you couldn't
join skirmish when it was in progress.
At second, if there were any interferences or errors
in the information flow, then all computers became "out of sync" and
game was untimely finished.
At third, game world couldn't advance to next game
tic until all control information from all players was received. It
caused significant degradation of game smoothness, depending on number
of players and overall quality of all their connections (and there is
no one ideal thing in this world, including computer networks)
My suggestion: let's breathe new life into this cadaver!
Well... returning to things, I wrote about in the preface: Let's Q3
play the capitalists (or those fortunates, who has lot of
neighbors-gamers in one LAN)
My suggestion, on other hand, is for those, who want to write games
that will be suitable for common people not burden with extra money or
Now, what we start with?..
A). We will build game engine only with integer
mathematic. Isn't very easy to write such code, and run-time
calculations aren't too fast... On other hand, physical game world
takes not too much percentage of processor time.
B). We'll add support for home-bred networks, like: three
computers connected by COM and LPT ports, one of them is connected by
modem or Inet with fourth and fifth ones... In real world in general,
and particularly in Russia often appear even more interesting things.
C). We'll return to client-client architecture, but with
many significant improvements (see below). But in this case, nothing
can prevent us from choosing one of computers to be the "server". But,
unlike modern servers, it will only coordinate the game process, not
hold the game physics solely and feed clients with states of visible
objects as true servers do.
How to do it:
A). We'll add possibility of forward interpolation
(prediction) of entire game world. I.e., if client not receives another
information packet with opponent data, it not freezes, but at first
remembers game world state (for all objects), and calculates next game
tic using predicted opponent data.
After next game tics, when delayed packet comes, client restores
that remembered game world state (for all objects!), and quickly
all these tics, but now using real opponent data.
As result, significantly increases load of physic algorithms for all
clients, if there is just one low quality connection in network (but
this is question of physic algorithms efficiency), but dramatically
decreases information content, flowing through network, thus saving
user's money, or just allowing to play by very bad phone line, that not
allows playing modern client-server games because of low bandwidth.
Disadvantage of this architecture is that it becomes much harder
to write program. Beside saving bandwidth, advantages aren't too big,
but nevertheless, they are significant. Because it allows using in the
game a various objects with very complex behavior algorithms, that are
impossible to interpolate forward (predict) in the traditional
B). We'll add possibility to join game in progress.
Although it seems impossible, really it's very simple.
Let's assume, that a new client connects to functioning game network.
Pseudoserver finds client that has best (or cheapest) connection with
the new joined one, and gives him command: connect this one.
Network member does next two things in order to connect the new client:
at first, it makes a game world snapshot, and from this moment, begins
to record opponent data of all other network members. Then it begins
transmitting that game snapshot to the new client. Snapshot may be
quite heavy, and transmitting can take some time (a minute, for
example). After snapshot was transmitted, the new client creates a
whole game world using it. Ok, but it is absolutely obsolete...
At second, the network member begins to transmit to the new client the
opponent data, that it recorded all this time, and does it with maximum
speed, that connection bandwidth allows. The new client processes that
opponent data as fast as it can, and after some period of time it
becomes synchronized with all other computers in the game session.
Then it can join game by adding own player object.
That's all. We got the possibility to join game in progress. Though,
not instantly, as in client-server architecture, but we all know, that
there no such thing, as free cheese...
People!!! Don't be lazy! Criticize this
article; mail me your opinion! Because in the dispute births the