Planning is Essential in Writing Multiplayer Network Code

I must say that proper planning is crucial when it comes to programming multiplayer games. Our Edoiki game network code is much simpler now compared to what it was in the beginning of the project – and I’m polishing the code even more.

I’ll give an example.

First I used multiplayer code where client would ask server “if he can do things”. If client needed to pick object, there would be separate code for “pick object”. If client needed to move somewhere, there was a separate code for “move”. Almost every action had separate packet building codes, ACKing (acknowledging – or basically saying “I received your packet”) codes and so on.

Now things are designed much simpler: clients only send input commands (like “clicked certain mouse button” or “certain object in screen”) – there’s no separate code for different actions: there’s only code for sending inputs, and that’s it. This has made things much easier in the client end, and also in the server end. Now server checks received input commands, ACKs them, and sends “what happened” information to all clients. There’s a class (or class like way as Blitz3D is not object oriented) for network objects, and server changes the states of these objects, and tells clients what updates have happened. In all simplicity, there’s just two main elements that need to be taken care of “client input commands” and “server’s network object state updates”. Use of bit masks has given me way to use the same functions for state updates: now there’s no need to create separate code for moves, attacks, health changes, etc. – I simply use the server to update object states (in one piece of code) and magic happens.

I believe that reading high level information about how to create network code is important if you want to make efficient network code. My first pieces of multiplayer code are awful to watch today, but I’m extremely pleased with what I have now.

Here’s some articles I’ve found very useful:

And here’s some more links where you can find lists of more articles:

From that list I’d say the Quake 3 networking model really hit me: their way to deal with things in all simplicity is brilliant. They decided to use quite pure server client system and there’s one major idea: there are no reliable or unreliable messages. The concept of “sending only non-ACKed changes” is – in my opinion – simple and efficient.

I will write more helpful articles about what I’ve learned and give better insight in the future, but for now I suggest taking a look at some of those articles.

Juuso Hietalahti


  1. Hi Juuso,
    Im a brazilian reader and I made a prototype of a (very simple) network game without any planning, this was very VERY dificult! This articles will help me a lot! Thanks!
    This is a nice blog and I read it every day…

    ( Sorry, but my english don’t help me ;( )

  2. Hey Juuso,
    I’m a web programmer, I do most of my work in PHP/MySQL, and I’m also familiar with Visual Basic and the basics of C (as in hello-world). I want to make an MMORPG game like http://www.runescape.com. The point is that the user accounts are to be stored on the server side, and whenever a user buys membership.. or trains a skill, etc the account is updated in the server database. This way I can eliminate most of the piracy/cheating/cracking issues.

    Now onto my question. As you can see I’m familiar with programming, I’ve been doing PHP coding for about 2 years and I can also learn other languages quickly. How would you suggest I go about learning how to make my first MMORPG? What programming language I should use, what library/framework, etc etc etc. Can you give me a list of things I need to learn in order to be in the condition to write the MMORPG? You could also write a walk-through type of article on how to make an MMORPG for someone familiar with the basics of programming.

    I’m asking you because you seem to be doing what I want to do, so you’re the best person to ask this question.Thanks!

  3. @zppz: yes, replays have been considered for 2 reasons: (1) debugging / tracking errors and (2) just for fun.

    There’s no screenshot yet because I’m using placeholders at the moment. Our 2D artist is no more in the project, and the 3D art people have just started their work… I will put something out when we have something fancy to show.

  4. Nice. I think you will find that this also makes implementing replays a piece of cake, if it makes sense for your game.
    Speaking of which, I’ve been hanging out for a screenshot for a long time – have I just missed them somewhere or is there really none available yet…

Comments are closed.