Commit graph

4 commits

Author SHA1 Message Date
Max Hilbrunner
5b25457794 Multiplayer networking renames/simplification
Removes _networking_ prefix from some methods and members, now that multiplayer has been largely moved out of Node and SceneTree and is seperated into its own set of classes.
2021-09-08 12:05:54 +02:00
Fabio Alessandrelli
bf9aae09ba [Net] Move multiplayer to core subdir, split RPCManager.
Move multiplayer classes to "core/multiplayer" subdir.

Move the RPCConfig and enums (TransferMode, RPCMode) to a separate
file (multiplayer.h), and bind them to the global namespace.

Move the RPC handling code to its own class (RPCManager).

Renames "get_rpc_sender_id" to "get_remote_sender_id".
2021-09-07 11:14:30 +02:00
Fabio Alessandrelli
b05cb0fd7d [Net] Add state sync to replicator.
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.
2021-08-18 12:37:45 +01:00
Fabio Alessandrelli
d4dd859991 [Net] MultiplayerReplicator with initial state.
Move the former "spawnables" functions to a dedicated
MultiplayerReplicator class.
Support custom overrides in replicator.
Spawn/despawn messages can now contain a state.
The state can be automatically encoded/decoded by passing the desired
object properties to `spawnable_config`.
You can use script properties to optimize the state representation.
2 Callables can be also specified to completely override the default
implementation for sending and receiving the spawn/despawn event.
(9 bytes overhead, and there's room for improvement here).
When using a custom implementation `spawn` and `despawn` can be called
with any Object, `send_spawn`/`send_despawn` can receive any Variant as
a state, and the path is not required.

Two new functions, `spawn` and `despawn`, convey the implementation
independent method for requesting a spawn/despawn of an Object, while
`send_spawn` and `send_despawn` represent the more low-level send event
for a Variant to be used by the custom implementations.
2021-08-18 10:21:29 +01:00