[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Server-based FPS

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.