Cheb's Home Page

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 history...
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... This 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 luck.

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 calculates 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 client-server architecture.
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 truth...