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?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

(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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
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...
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.

Build an E-Commerce Site with Angular 5

Learn how to build an E-Commerce site with Angular 5, a JavaScript framework used by developers to build web, desktop, and mobile applications.

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.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Game Programming

From novice to tech pro — start learning today.