Object synchronization (for physics based games)

We just found it to be a lot of effort to write the code that creates Strings/bytes for every object in the code and additional code that deciphers it and converts it into real data and even more "annoying" to always keep that code up with the current state of the game. We find it kind of hard to imagine that no one else has come across this problem, but we

Our first attempt was:
1) Server builds sync packages which contain position + rotation updates all as byte arrays
This usually ended in a mess with Java's ByteBuffers but we got it working for some basic parts
2) Client receives sync packages and decodes the byte array and applies updates
Like for 1) it was a mess with bytes[/quote]

Hmm, Java?

implement Serializable, add GUID, done. Just keep classes sent over network simple to avoid deep copies. They should also be stateless (as in, have no class invariants) to avoid having to write custom serializers.

If classes are kept simple (primitives, lists, maps, ...) and POJOs (no complex construction, dependencies), there's no extra work. They should be kept that way anyway for sake of security.

To pack/unpack, just write instances of Object to ObjectOutputStream, ObjectInputStream to reverse. Managing GUIDs may be a bit annoying, but I don't recall it as ever being a problem. And today one might just hook a post-commit hook on git to generate those and keep versions up to date. They can be frozen once a milestone release occurs.

If you google around github, there are some other encoders which offer better buffer representation (smaller, less metadata). For security, you can later filter the type of instances you're allowed to send/receive. Could be done through reflection.

Raw Serialization is pretty simplistic and has some gotchas, but if staying away from JEE and Bean horrors it is quite straightforward, even though .net became vastly superior in this area.

One example about how to go about this:class SyncUpdate implements Serializable {
List<Vector2D> positionUpdates;
List<Vector2D> velocityUpdates;
List<String> otherUpdates;
};Your code now just adds stuff to these lists, then sends instance of SyncUpdate. Other end reads it and that's it. Your code only ever works with Java. It should be pretty simple to go from here.

[color="#1C2837"]What you want is a library for marshaling/demarshaling. There are many different approaches you can take.[color="#1C2837"]What you need to do is three things:

1) Make sure you can pack messages into packets such that the remove end can unpack the messages -- typically, this is a byte or two of length information per message within the packet.
2) Make sure that you can tag each message so that the remote end knows what particular code should receive that message -- typically, this is a byte or two of object ID, where "object" may be a player avatar, or a subsystem (such as the ammunition manager, or whatever)
3) Make sure that you tag each message such that the receiving code knows what to do with it -- typically, this is a type code of some sort.

One way of approaching this is to build marshaling on top of reflection. Unfortunately, C++ does not have reflection, so you'll have to add it yourself.
A few articles on this subject:
http://www.enchanted.../cpp-reflection
https://github.com/j...-and-Properties (code for my article in Game Engine Gems 2 about this)

[color="#1C2837"]http://www.enchanted...2-introspection[/quote]


Hi, thanks for your reply.
We were doing something similar to this in our previous version (luckily we are using Java, so serialization and reflection are both available, thanks for the links anyways!).

We had a working version were the initial state of the game could be loaded on the client, and objects could be added by the server.
The main problem I had was how to write the code that synchronizes the changes in game objects for all clients. We have game-object structures that contain a list of physical and graphical properties as well as game logic code. We were able to get the parts of the engine (physics, graphics) across the network but we never found a way of writing nice code to synchronize the varying game logic of each object. But it seems like there is no way around writing separate code for each object? Most objects are just crates or bullets anyways and don't really need any synchronization but there are others like the player figure itself which consist of a lot of attributes and whenever we wrote new code for the player we had to extend the synchronization code aswell, which was kind of annoying.

Hmm, Java?

implement Serializable, add GUID, done. Just keep classes sent over network simple to avoid deep copies. They should also be stateless (as in, have no class invariants) to avoid having to write custom serializers.

If classes are kept simple (primitives, lists, maps, ...) and POJOs (no complex construction, dependencies), there's no extra work. They should be kept that way anyway for sake of security.

To pack/unpack, just write instances of Object to ObjectOutputStream, ObjectInputStream to reverse. Managing GUIDs may be a bit annoying, but I don't recall it as ever being a problem. And today one might just hook a post-commit hook on git to generate those and keep versions up to date. They can be frozen once a milestone release occurs.

If you google around github, there are some other encoders which offer better buffer representation (smaller, less metadata). For security, you can later filter the type of instances you're allowed to send/receive. Could be done through reflection.

Raw Serialization is pretty simplistic and has some gotchas, but if staying away from JEE and Bean horrors it is quite straightforward, even though .net became vastly superior in this area.

One example about how to go about this:class SyncUpdate implements Serializable {
List<Vector2D> positionUpdates;
List<Vector2D> velocityUpdates;
List<String> otherUpdates;
};Your code now just adds stuff to these lists, then sends instance of SyncUpdate. Other end reads it and that's it. Your code only ever works with Java. It should be pretty simple to go from here.

This is what we did in our previous version. What I had most problems with is - in your code example - the "otherUpdates" part. how exactly do games with a lot of code create those? Is there any way around writing individual sections for each object that you create?

Thanks for your replies,

Tehforsch

Have an example of how it's currently done?

implement Serializable, add GUID, done.