Hi there, For starters, I have already learned how to program simple client/server network applications as well as I have studied and implemented asynchronous I/O when scalability matters. What I would like to find out about now is to design an application protocol for a game. I currently do not know, for sure, what an efficient application protocol design for games. I am familiar with those Internet application protocols such as HTTP, FTP, telnet and the likes, however, I am pretty sure they are probably not the best examples to follow when it comes to games. While there are many types of games out there with different requirements, I would particularly like to know for a few major genres, for instance, the difference between RTS, MMORPG, FPS, turn-based multi-player. Well, my misconception of application protocol for games must be really really small/compact, can be transmitted and received fast and processed fast as well. The choice of the transport protocol, TCP or UDP, is really about the requirements of the game genre as I have read pretty much from articles and previous posts.

Games just use raw sockets and either TCP or UDP or a combination of both.

The protocol, if you can call it that, is just made up network packet formats specific to that game. You want to send the least data possible so you pack things and whatnot according to the specifics of what the game needs.

A format can be as simple as a header that contains a type followed by a switch statement to handle the different types, or as complex as the game requires.

-me

All networked games need to do one single thing: synchronize game state.

Since game states between genres differ drastically, there are no guidelines (compactness isn't really a general requirement).

The main guideline is, that transport must transfer minimal amount of state (doesn't matter how big that in network traffic is). Reducing your packet size by 20% won't help you as much as reducing send rate from 50 to 10 Hz.

With that in mind, protocol will usually follow the design of the game, the game isn't built on top of it.

The larger a game is, the higher level it'll be. For complex worlds sending marshalled structures and RPC/MPI calls is much more practical, since there's so much different data to be sent.

But everything begins with state synchronization. How will you transfer game state between server/client or clients. Which data, how often, etc. After you know that, you simply define that information in form of network structures.

As with all things - optimize last. Don't worry about size, form, shape until you have something running. That'll be hard enough to begin with in the first place.

Quote:Original post by Antheus
As with all things - optimize last. Don't worry about size, form, shape until you have something running. That'll be hard enough to begin with in the first place.

Alrighty then, I guess I'll just think of something simple to implement first before worrying about performance issues. Heh, I thought I could get away with building a sound foundation from the beginning and now to worry about it later.