Advertisement

Simple Shooter

Started by June 26, 2006 02:31 PM
1 comment, last by kvp 18 years, 7 months ago
I want to create a simple deathmatch shooter, with say 8 players. My happy day scenario: (Where everyone has a goodo connection) 1) Clients send data to the host -- a client acting as the host 2) Host waits to receive data from all clients 3) Host sends all the data to the clients, with the deltaTime (time since the host last recieved all the data). 4)Every client, including host, updates there own world using the data, and the deltaTime. 5) The world is rendered, goto(1) Is this anywhere in the right direction...
Insufficent Information: we need more infromationhttp://staff.samods.org/aiursrage2k/
That's great for a RTS. For an FPS, you typically have to accept some out-of-sync.

1) client sends data t1 to host
2) client uses its own data and received data from others to render
3) client sends data t2 to host
...
9) host echos data t1 to other clients
...

When rendering data from other clients, you typical forwards extrapolate somehow, say using dead reckoning, or something better (such as lerping between two extrapolated positions).
enum Bool { True, False, FileNotFound };
Advertisement
The usual way is:
-clients send their input to the client acting as a server on a regular basis
-the server updates its simulation with a fixed step rate
-the server sends updates to all clients with a fixed rate
-clients always render what they get from the server

Pros:
-if a client skips an input send, the server just assumes it didn't want to send anything
-if a client misses an update, it doesn't update its display until the first update that gets through
-the whole process is asynchronous, so a great level of packet loss is tolerable

Cons:
-if a client has a missing packet in the input direction, it can not move for a brief period of time
-if a client has a missing packet in the update direction, it can see everything freeze then jump forward for a brief period of time
-if a client connection has a high latency then the client will see the delay between the keypress and the start of the movement (this is called lag)

To combat the 3 cons, one can use dead reckogning where the client intra- or extrapolates updates to fill gaps caused by missing packets. The server can also do extrapolation, by assuming that if a packet is missing and a key was pressed then it remains pressed until it gets an explicit input packet with a key up or a certain number of frames elapse.

Viktor

This topic is closed to new replies.

Advertisement