Hello, I''m coding a 3rd person shooter, which will be played in a Local Area Network with about 8 players. I often heard, that TCP/IP is too slow and I should use UDP instead. In this special case mentioned above, is it really necessary to use UDP? And in general: How should I manage this network-game? My first idea: The client sends every frame its position to the server. When the player hits the fire-key, a special event-message is sent to the server. The server gets all positions, updates its internal data of the scene, does collision detection etc. and then sends back the new positions to every client.

On a LAN, you could possibly use TCP. You might still get 3-second lag spikes at times, because no LAN is lossless. You''re unlikely to send enough data that delayed-ACK is likely to cause lag.

The send/process/receive loop will work fine, although you probably need to do a little bit of dead reckoning on the clients. It also depends a little bit on how much you want to avoid making it possible to cheat on the clients.

If it''s a LAN, you could also consider just broadcasting using UDP, that way nobody needs to be server. For 8 players, that ought to work fine.

TCP is a connection-oriented or stream-based protocol. Its benefit is reliability. This protocol is robust, but slower than UCP due to error check and correction.

UDP is connnection-less or message-based protocol. It is a slimmer protocol (protocol header is fixed at 8 bytes), thus is ideal for messages/games where speed is more important than reliability.

Kuphryn

Ok, I want to have a ping of about 10-20ms.
Could that be achieved by using TCP/IP?

And how should I validate, that everyone gets the very important event-messages when I use UDP?

"dead reckoning" <--- What''s this?

Another question:
Which protocol do the most commercial games use? UDP or TCP?

Most shooters seem use UDP and my project is using Replicanet successfully. The distributed objects system let me have host migration, something which a lot of shooters don''t have, which is great. You can get the free library from www.replicanet.com

*push*

Im not sure but I believe even for a LAN 8 players fps most commercial games would use UDP. In order to get reliable UDP messages why not use Enet? With that free library you can use both unreliable (fast) messages for position updates etc AND reliable messages over different "channels".


[edited by - Borundin on April 13, 2004 11:16:25 AM]

Pretty much all commercial action games use UDP for non-essential game data. They then use either a self-written reliable transport, or TCP for essential game data. I would use TCP for the essential data because it is tried and tested, is already written and is all done for you on OS/HW. If you write your own reliable mechanism using UDP packets you get into the "I recieved your message"-->"OK" handshake scenario, when do you stop? If you loose your confirmation packet, you have to resend and it all gets a bit messy. Use TCP for any essential data.

TCP is too slow to use for sending large numbers of packets. I wrote a network system for a commercial game that had both UDP and TCP capability, if I sent the game data (ie positions/states etc) using TCP it was markedly slower.

Regarding your question on how many people you can sustain, its a simple calculation based on your bandwidth per second, the frequency you send data and the size of the data, this will give you how many players it can support. (ie your player packet is 1k in total, sent 30 times a second is 30k per second, whats your bandwidth? say 60 kps, you can support 2 players).

Your idea to have clients send thier pos to the server is bad. The client should send input data (keyboard/joystick/whatever) to the server and nothing else. The server would then use this to update the client in its world, then send it (and everybody elses) positions/orientations back to each client.

dead reckoning is a way to smooth out movement of server updated objects on the client. if the server tells you where an object is every frame at 30 frames per second then the clietn will have 30fps animation which is pretty average nowadays. However if you dropped to 20 fps or 10, and the server was still giving you the positions they would look like they jump from one place to the next. Dead reckoning gives the client a means to move the object inbetween server updates,

ie server says your at pos (1,10), one second later it tells you your at (5,10), you see the jump because of the distance traveled. Dead reckoning would provide some additional info (or you could calculate it) so you would now have "your at pos (1,10) and your velocity is(4,0) (per second say)". So each anim frame you could update the pos based on (1,10)+((4,0)*dt)(where dt is your timestep), until you get a new valid pos from the server. This way the object seems to move smoothly at all times.