Jump to content
  • Advertisement
Sign in to follow this  

network protocol design

This topic is 5480 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I'm looking to design a protocol for a game which isn't time critical like an FPS or anything, but much simpler and turn based. I'm hopefully going to add a sort of lobby and chat facility too. I'm pretty good with actual sockets programming and the usage of select() so that's not really a problem. Up until now the only protocols I've written have been for basic client/server chat systems just as a practice, and I'm sure they weren't done very well at all anyway. It was mostly done in a human readable format using string processing functions to process the protocol messages. e.g something like this would be a message from client: "LOGIN username password clientmajor clientminor" to client: "LOGIN_OK" Where I'm looking to add some network support to a tile based game I've already got mostly working, the network protocol requirements are going to be a little more complicated than the simple chat server projects I've worked on in the past, and I'm sure my existing way of doing things is not going to work out too well. I've found lots of fragmented pieces of information around the net and in the gamdev articles on the subject, but nothing really useful as of yet. Questions that I'm finding hard to answer at the moment are things like: 1) Should chat/administration/lobby features run on a different server to the actual games and have a different protocol design? 2) What's a good design for a protocol packet? What's a good way of constructing and parsing these packets progmatically at each end? It seems to me that it's one of those things that's so easy to go away and do, but hard to do well. I could go away now and design a quick system that would have tiles moving on a remote machine using a simple human readable protocol using string functions and the like, but I'm sure it would be sloppy, hard to scale and improve and very un-optimized. I realise the answer to a lot of these questions is affected by the nature of the game. Mine is a turn based, non time critical game that seems to lend itself to TCP connections. Can anyone give me any good books, tips, links to sites, first hand info or anything they think could help me out? I'd really appreciate it. Like I said, I could go away and do this now, but past experience tells me that would be a bad idea... I really want to get this right. Many thanks, Daniel

Share this post

Link to post
Share on other sites
If there are absoultely no real-time elements to your game, I think the implementation will be quite straightforward.

You should probably have all in-game chat broadcast through the game server. The master/lobby server should forward chat messages for lobby-only chat.

Separating the lobby-chat/master-server may give you some redudancy security in that if one server goes down, part of the game can still operate. (ie. if lobby-chat server goes down, at least players can still join games OR if master-server goes down, at least you can still join the lobby server to tell people what went wrong).

By "programatically parsing packets" do you mean as in the architecture/class-layout of the packet code or do you mean the low level data bits that each packet sends? For low level data-bits, don't get too fancy. Send non-real numbers (ie. no floats or doubles) *if you can* because there may be difference in how various machines implement reals... but even then, the difference is extremely small.

Don't bother compressing your data as well since you wont' be sending too much of it (it's turn based!). This will make it a lot easier for you.

Each packet should have a packet header that tells it a) the ID, and b) the size of the packet. Having fixed packet sizes are much easier to deal with (you don't have to check bounds/be scared of buffer overrun). Favour fixed-sized packets if you can and always remember that your game has no realtime constraints. This allows you to check if a packet is of the right size and that your code is sending packets that at least look ok.

For architecture, you want to make sure that you don't couple the surrounding game tightly with your packets. That is, try to assume as little as you can with the actual game that the packet is for. This'll allow you to use the same packet code for future turn-based projects. Perhaps implement something like the Command design pattern. Also, there's a gamedev article on here that talks about factories and packets called something like "Why factories rock my multiplayer world"... that should give you some ideas.

Another thing is you might want to have clients send actions instead of data. What I mean is, let's say client moves tank to position (x,y). Instead of sending a TankMovedToXYPacket, first send a "SelectedTank" packet. Then send a "MoveActionToXY" packet. This is more work but it means you can upgrade/tweak play-balance parameters on the server without forcing players to redownload the new client. You can also support simple mods/player-tweaks in this way. This will also help you when you're debugging various things.

After all that, please take my advice with a grain of salt because a) though I've written realtime multiplayer games, I haven't written a turn-based one yet b) I am still learning a lot too.

ps: I think your choice of TCP is a good one.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!