Re: Server-based FPS

[Josef Spillner <dr_maux@users.sourceforge.net>]

On Sunday 05 January 2003 23:18, Steve Baker wrote:
> 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.

A trade-off between accuracy and performance has to be found for these 
updates. For example, while relative position changes (unit went 3 steps 
ahead) can be encoded using small numbers (i.e. one byte per unit, using 
bitmasks), transmission errors usually affect all consecutive actions. OTOH, 
absolute position changes (unit went to [152,9995]) don't have this drawback 
but result in more network traffic.
(Even though this disadvantage can be rendered void by taking into account 
that multicasting such moves only needs to be done for those units which 
appear on the player's screen or interact with nearby units.)

In MMRTS games, game specific optimizations can be done to take some load off 
the main server, e.g. by maintaining several levels of trust to allow 
intermediate servers (or clients even) to perform local actions on their own. 
Setting up server-side assertions is very important here.
True distributed algorithms or concepts probably exist, but I'm not aware of 
any :(

Josef

-- 
Free operating systems. Free software. Free games.