[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
2. Server receives the request, decides it is a valid request and
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
each action a player performs.
Even using UDP i should have a significant amount of time between the
(pressing fire) and the actual action (my gun fires).
All of this is true.
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.
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
keep a consistent scene?
Fixing this may force server to update the entire situation to each
many times per second, with an excessive load for the network.
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.
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
it changes speed, otherwise they'll have very different positions.
Server must inform all the clients about all the positions of the
at the moment they change speed, or it must be sure they all have the
posistion (ie: clients are syncronyzed).
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.
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.
The only way I see to ensure syncro. is each client sending a "i'm
next frame" message to server, and server replying back "goto next frame"
when all clients are ready.
Wich I suppose being painfully slow.
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.
- Server-based FPS
- From: "Francesco Orsenigo, Xarvh Project" <firstname.lastname@example.org>