Network protocol for Games

I'm eventually interested in programming a small netcode for a massively multyplayer game (FPS).
I need to know some basics on the protocoll development for games:
Which protocol (UDP / TCP)?
Anything special for speeding up the communication.

Also I would like to know how to send the data across the net... (sending raw structs read from memory, or some higher data encapsulation such as plaintext).
Who is Participating?
bcladdConnect With a Mentor Commented:
(1) How games send data across the wire varies, game to game. UDP is cheaper than TCP since packets don't have to be buffered and delivered in order: less overhead in the packets used (compared to payload) and less latency in getting information to the distant process. Disadvantage is no delivery guarantees.

(2) Speeding up the connection: The fastest packet is the one you don't send so send as little as you can get away with. What is the range:
(a) Client/Server model where all input is sent from client to server, all calculations done on the server, and all data for output returned to the client for rendering.
    Lots of data probably comes back down; scalability problems but every client has the exact same picture of the game.
(b) Peer/Peer model where only input signals are replicated, machine to machine, and each runs the full game with all calculations done locally.
   Lots less data; scales well; clients are more losely coupled AND can be used for cheating.

(3) Data across the net: You can send raw  data using pointers at structs/classes IF you know that all machines will be using the same processor (don't include Mac and PC versions of your code) and you can afford to send the whole struct every time a single field changes. Alternative is to send some sort of tag (indicating the object and the field) and then ONLY the changed value. Only makes sense if the tags are smaller than the remainder of the object.

Just some thoughts. Hope it helps, -bcl
SnykeAuthor Commented:
Is there a possibility to, say build a game for Linux and then build an interpreter function on other processors?
Would be nice to have no processor limits...
I think a hybrid version of your A and B is the best: game relevant data is to be calculated by the server and the clients only calculate the visualization and irrelevant stuff. There's still to define what is game-relevant and what not...
bcladdConnect With a Mentor Commented:
The limitation is if you send byte sequences EXACTLY as they appear in memory. You will read (or have read) about network byte order? I can never remember whether it is little-endian or big-endian (Intel is, I think, big endian, PowerPC/Motorola are little endian and network byte order is little endian; in any case network matches Mac). The point is that all machines that have sockets have data marshalling functions that translate host formatted multi-byte quantities (integers of various types for the most part) to network byte order and others to translate network to host ordering (htons, for example, takes a short in host order and returns a short in network order; reverse routine is ntohs). Passing information in cannonical network order is useful if you expect to have many different types of machines communicating.

It is a pain if you only really expect to have one architecture (or mainly one architecture) and you know it isn't using network byte order internally: every int you pass is translated to and from network byte order FOR NO REASON. The fix is to choose your own cannonical ordering. Then, if you add a machine architecture that is different you make that machine's version translate to/from your main machine's byte order.

Calculating what is game relevant is hard. The problem is made harder by the fact that it is dynamic. Think about it: If the client is primarily for rendering sights and sounds for me then there is no need for it to get any updates about what the postman is doing as he loads his truck downtown. However, just before he gets to my door I might hear his steps on the walk, his knock on the door, and, opening the door I would want to kill him where he stands (this is an FPS, after all). Assuming I miss and he continues on his way, he will fade from relevance when he goes around the corner of the house...or will he? What if he just wanted cover and is going to double back in 1.2 seconds to fix me good?

Relevance is important because it limits the number of objects that need to be updated and so limits the required bandwidth.

The new generation of project management tools

With’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

SnykeAuthor Commented:
Well I would be using a struct to describe the entire player and update it all at once. This way I have a consistent image of where the players are and what they are doing. I always thought that using htons on systems that internally use network styled memory will return without doing anything...
Correct. If you happen to match netowork byte order hton* and ntoh* are effectively nops.

SnykeAuthor Commented:
Really good answers all of you... couldn't decide which answer to accept but since bcladd answered the first question his one's accepted.
Even though it has already been answered, here's how I solved the problem (and got a very lean and efficient network code).

First, use UDP. Build your own network message stack and your own syn-ack management. Not every packet "has" to reach its target (i.e. a packet where you update the player positions need not be ack'ed, there's no point in resending it. If it doesn't arrive NOW, it isn't needed anymore. In a second, the packet is worthless. A packet that sends e.g. the information that the player died or one that transmits a message MUST be resent to make sure it arrives. Whenever.).

What I did was to build a "pseudo transmission control" on UDP. I used the first byte of the transmitted data for a packet-ID and the second as a flag field, telling the other computer whether this packet needs to be ack'ed, if this packet is an ack (and if, the 3rd byte was the ID of the packet ack'ed) and a few more state related things.

This way you get almost the same reliability of TCP without the bloated overhead.
All Courses

From novice to tech pro — start learning today.