Re: Server-based FPS

[Gregor Mückl <GregorMueckl@gmx.de>]

Francesco Orsenigo, Xarvh Project wrote:

> How can be a server based fps like Quake II so fast?
>
> I think that the way it works should sound like:
> 1. Client has an event request -> i press CTRL, client says to server 
> "I want
> to shoot!"
> 2. Server receives the request, decides it is a valid request and 
> inform all
> clients (mine included) that "player X shoots".
> 3. Clients receives the information and displays everything.
>
> That means i must send a message back and forth between client and 
> server for
> each action a player performs.
> Even using UDP i should have a significant amount of time between the 
> request
> (pressing fire) and the actual action (my gun fires).
All of this is true.

> Also, how can i keep all the clients syncronyzed with the server?
> If the message "player X fires" arrives to my computer after 0.1" from
> keypress and 0.2" on another computer, how can the two clients display 
> and
> keep a consistent scene?
> Fixing this may force server to update the entire situation to each 
> client
> many times per second, with an excessive load for the network.
Advanced FPS systems use very clever methods to predict the future 
development of the game for about 1 second or so. The server sends 
updates based on these predictions which means that it only has to send 
the differences between the predictions the clients made and the real 
situation. This can reduce bandwidth use dramatically.

> Suppose i got multiple slow projectiles going straight.
> I call an event that changes all the speeds.
> All the clients must agree on the position of each projectile at the 
> moment
> it changes speed, otherwise they'll have very different positions.
> Server must inform all the clients about all the positions of the 
> projectiles
> at the moment they change speed, or it must be sure they all have the 
> same
> posistion (ie: clients are syncronyzed).
You would normally try to describe the projectile movements on a 
time-based manner (not in a simple frame-based one). The server tells 
the clients where and when the projectiles were fired and the clients 
can try to predict the trajactory of the projectiles. The server would 
only send updates (time and event) if something important has happend 
like the projectile hit a wall or another object.

In the case of changing speeds the update would be in the same form. The 
clients change their prediction of the projectiles' trajectoies based on 
that event they recieved from the server.

But the update will reach them after the event happend. So they will 
have to look back in time and recalculate the current location of the 
projectile based on the new prediction and the time the event happend.

> The only way I see to ensure syncro. is each client sending a "i'm 
> ready for
> next frame" message to server, and server replying back "goto next frame"
> when all clients are ready.
> Wich I suppose being painfully slow.
As far as I know this is the method that Doom used. It has the major 
disadvantage that the game can only run as fast as the slowest client 
that is connected. Modern FPS use strict time-based calculation and 
prediction and therefore have no need of synchronising their game loops.

If you want to learn more have a look at the information that is 
available on the Unreal engine. The makers have published a long 
document describing in great detail how the network communication works 
in their engine. I don't have a link to that right now, I'm afraid.

Gregor