GameProducer.Net » Planning is Essential in Writing Multiplayer Network Code
Planning is Essential in Writing Multiplayer Network Code
December 16th, 2006 :: Permalink :: Trackback
Posted in Game Development
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.
GameProducer.Net » Planning is Essential in Writing Multiplayer Network Code
Planning is Essential in Writing Multiplayer Network Code
December 16th, 2006 :: Permalink :: Trackback
Posted in Game Development
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:
* Quake 3 Networking model
* 1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond
* RakNet programming tips
* Valve’s Source multiplayer networking
* Latency Compensating Methods in Client/Server In-game Protocol Design and Optimization
* Unreal networking
* Networked Physics
* The TRIBES Engine Networking Model
* Designing Fast-Action Games For The Internet
And here’s some more links where you can find lists of more articles:
* Gamedev.net articles list
* Indiegamer.com networking thread
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 user 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.
