[Net] MultiplayerReplicator state sync. #51788
Conversation
Faless
force-pushed
the
mp/4.x_replicator_sync
branch
from
3509aaf
to
b94d812
Compare
Like the spawn/despawn feature, it can be completely overridden with 2 custom callables. The callables will be called with the list of tracked objects. In SERVER mode, objects are automatically tracked, while in CUSTOM mode you can manually track them via `track`/`untrack` (but that's optional). The default sync only happens from server to client, with batch updates, over unreliable channel (but with custom ordering). The default sync will warn you, if your state representation gets too big.
Faless
force-pushed
the
mp/4.x_replicator_sync
branch
from
b94d812
to
b05cb0f
Compare
|
Opinions? :) @jonbonazza @AndreaCatania |
There was a problem hiding this comment.
Just a couple comments/questions regarding data structures, but otherwise looks solid! My opinion generally would be to use LocalVector (maybe even reserve a few elements) over Lists, unless there is going to be a lot of insertion and deletion from the middle of the collection.
core/io/multiplayer_replicator.h
Outdated
| @@ -63,31 +70,52 @@ class MultiplayerReplicator : public Object { | |||
| Vector<uint8_t> packet_cache; | |||
| Map<ResourceUID::ID, SceneConfig> replications; | |||
| Map<ObjectID, ResourceUID::ID> replicated_nodes; | |||
| Map<ResourceUID::ID, List<ObjectID>> tracked_objects; | |||
There was a problem hiding this comment.
Is Map<> and a List<> the right data structure to be using here. Is there any reason to use a tree over HashMap or OAHashMap?
There was a problem hiding this comment.
As mentioned above, the order is important, and must be consistent with the track/untrack order, and List ensures that.
Regarding Map, yes, tracked_objects could be HashMap<ResourceUID::ID, List<ObjectID>> as you say (given we don't care about the ResourceUID::ID order in this variable). I'll fix that. Thanks!
| bool raw = false; | ||
| List<Variant> state; | ||
| }; | ||
| Map<ObjectID, struct EncodeInfo> state; |
There was a problem hiding this comment.
OAHashMap here? Does ordering of the ObjectIDs matter in this tmp collection?
There was a problem hiding this comment.
Yes, order is important, because we do not send the IDs to the clients (which saves us quite a few bytes).
So the first ObjectID tracked, will be the first element in the state update, and the last ObjectID tracked wil be the last.
Well, there are likely going to be a lot of deletion in the middle (not insertions). |
|
The interface is great already, @Shatur proposed to use it for the net sync, and I think it's a great idea. Maybe we will need to expand the interface a bit. Would it be fine change it a bit (add few other APIs and in case change others) once we start using this? |
|
Sounds good, we can talk details in the next networking meet: |
|
Yup, I can show the NetSync interface. |
|
Merging as discussed in the
|
Faless
changed the title
Like the spawn/despawn feature, it can be completely overridden with 2 custom callables.
The callables will be called with the list of tracked objects.
In SERVER mode, objects are automatically tracked, while in CUSTOM mode you can manually track them via
track/untrack(but that's optional).The default sync only happens from server to client, with batch updates, over unreliable channel (but with custom ordering).
The default sync will warn you if your state representation gets too big.
This PR is based on #51534 .Now merged, so based on master.See attached project for an example: proj_spawn.zip.
Docs mostly done, will need proper tutorials soon.