[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).
No - it's a lot more complicated than that.

It's more like:

* Player presses 'shoot'.
* Local computer decides you hit the other bad guy and
  starts all the animations.
* Message goes to server.
* Server decides what REALLY happened and sends corrective
  action back to player's computer if you missed.
* You may find that although it *LOOKED* like you hit the
  guy - he didn't die.

There are serious temporal anomalies that the server has to
manage. Because of the lag through the network, each computer
has to extrapolate the positions of the other players from the
last valid data they sent us.  However, they may have moved
somewhere else in the meantime.  You can actually get into some
really nasty tangled messes with this kind of thing.

(eg Player 1 and Player 2 both think they picked up the *same* box of ammo
from the floor - but the server doesn't agree with one of them)

There have been LONG discussions about this on the web and at technical
conferences - from what I gather, all solutions are disgusting kludges
and they all break down under some circumstances.  The result of all this
is that the server remains the ultimate authority but the clients have to
make some 'decisions' locally - but be prepared to reverse those decisions
when the server reports back the "true" situation some time later.

All of this is also much complicated by the desire to detect and prevent
cheating andf the unfortunate fact that to get high bandwidth, you need
to use UDP protocol - but UDP is inherently unreliable.  To get a reliable
connection, you need TCP protocol - but whilst it's 100% reliable, it
has both poor latency and lower bandwidth.

Some games (I believe Quake is one of them) use UDP for things like
"the player moved six inches forwards" and TCP for "the door is now
open".  This means that one-time events never get 'lost' (which is
critical if the client is allowed to make local decisions) - but
the high bandwidth events (like people moving around) use the
higher bandwidth protocol.  If a player's position update gets
lost, it's not the end of the world because another one will
be coming along in a tenth of a second or so.

Online FPS games are definitely not for the feint of heart!  It'll
take lots of nasty kludging and there will always be problems and
compromises that you'll just have to live with.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net>    WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
           http://tuxkart.sf.net http://prettypoly.sf.net