Dev Blog
Hi, this is the Stranded III development blog (see also Forum Thread, Comment Thread).
Entry 45 - Network Message Generator & Emergency Drinking Wat - June 6, 2016
Network Messages
In Counter-Strike 2D and Carnage Contest I used the possibly simplest way to send and receive network messages: Encoding and decoding everything manually in code.
This means for every network message type like shooting your gun or moving the player I had to write some code to send/serialize and also some code to receive/deserialize the data.
Benefits of this:
Maximum flexibility: You can do everything (e.g. special error handling) and send everything
Optimization: The flexibility also allows you to optimize the structure of messages so they are as small and efficient as possible
Problems with this approach:
Much work: You have to write a lot of send/receive code which is typically pretty dull
Error prone: Changes can easily break stuff. Send and receive code always has to be synchronized
Hard to change: If there's a change in the underlying networking system which requires changes in the send/receive code then you're screwed because you have to touch code for every single message you have
There is an alternative solution: Define the message structure and then auto-generate code for serialization and deserialization of the message.
Google's Protocol Buffers work exactly like that. The "problem" is: Google's system is designed to handle changes in messages without breaking. This certainly is a nice feature but of course it comes at a cost: The messages are bigger because you can't simply rely on the order of the data.
There are also other comparable solutions but they are either not very well known (which means that they potentially have more bugs) or they are commercial, have weird limitations or also have more overhead than necessary.
Therefore I implemented my own network message definition system to generate code which serializes my network messages in an efficient (= small) way. It fully relies on the right order of the data. This makes different versions of messages incompatible with each other but it also minimizes overhead - which is more important for my use case.
Supporting compatibility and extensibility is a requirement for my system anyway. So how is that possible? Condtions are the answer. They can be part of the message definitions.
This doesn't make messages compatible out of the box but I can design them to be compatible by adding conditions, which make use of the game version. This is mainly important for handshaking / server list / join messages because you aren't able to join a server which runs a game version which is different from yours.
Conditions can also be used to modify the payload of the messages based on values in the messages themselves. This is a thing I did for some messages in Counter-Strike 2D already to minimize traffic while keeping the amount of different message types low - which is important because the message type is sent as a byte, allowing a maximum of 256 different messages.
Emergency Drinking Water
A visit of the Internationales Maritimes Museum Hamburg inspired me to make the following super detailed and complicated model...
click to enlarge
Yup... it's basically some water in a plastic bag. It could safe your life!
Aaand did you spot the missing letter? I already fixed that but only after preparing that image...
In Counter-Strike 2D and Carnage Contest I used the possibly simplest way to send and receive network messages: Encoding and decoding everything manually in code.
This means for every network message type like shooting your gun or moving the player I had to write some code to send/serialize and also some code to receive/deserialize the data.
Benefits of this:
Maximum flexibility: You can do everything (e.g. special error handling) and send everything Optimization: The flexibility also allows you to optimize the structure of messages so they are as small and efficient as possibleProblems with this approach:
Much work: You have to write a lot of send/receive code which is typically pretty dull Error prone: Changes can easily break stuff. Send and receive code always has to be synchronized Hard to change: If there's a change in the underlying networking system which requires changes in the send/receive code then you're screwed because you have to touch code for every single message you haveThere is an alternative solution: Define the message structure and then auto-generate code for serialization and deserialization of the message.
Google's Protocol Buffers work exactly like that. The "problem" is: Google's system is designed to handle changes in messages without breaking. This certainly is a nice feature but of course it comes at a cost: The messages are bigger because you can't simply rely on the order of the data.
There are also other comparable solutions but they are either not very well known (which means that they potentially have more bugs) or they are commercial, have weird limitations or also have more overhead than necessary.
Therefore I implemented my own network message definition system to generate code which serializes my network messages in an efficient (= small) way. It fully relies on the right order of the data. This makes different versions of messages incompatible with each other but it also minimizes overhead - which is more important for my use case.
Supporting compatibility and extensibility is a requirement for my system anyway. So how is that possible? Condtions are the answer. They can be part of the message definitions.
This doesn't make messages compatible out of the box but I can design them to be compatible by adding conditions, which make use of the game version. This is mainly important for handshaking / server list / join messages because you aren't able to join a server which runs a game version which is different from yours.
Conditions can also be used to modify the payload of the messages based on values in the messages themselves. This is a thing I did for some messages in Counter-Strike 2D already to minimize traffic while keeping the amount of different message types low - which is important because the message type is sent as a byte, allowing a maximum of 256 different messages.
Emergency Drinking Water
A visit of the Internationales Maritimes Museum Hamburg inspired me to make the following super detailed and complicated model...
click to enlargeYup... it's basically some water in a plastic bag. It could safe your life!
Aaand did you spot the missing letter? I already fixed that but only after preparing that image...