Can SceneReplicationInterface be made overridable?

[justinian]

I'm working on a multiplayer game, where I'd like to only replicate objects to players within some detection range of them. It seems like I really only need to override SceneReplicationInterface, but to make this custom multiplayer implementation, my GDExtension needs to reimplement SceneMultiplayer, as well as SceneCacheInterface and SceneRPCInterface. I could just copy these over wholesale from the multiplayer module, but that seems like a lot of duplication and maintenance overhead.

In the initial proposal, #3459, @Faless wrote:

A lower level replication API, (part of MultiplayerAPI) will be used by the higher level nodes to implement those functionalities and an extensible MultiplayerReplicatorInterface will allow overriding the behaviour globally, or on a per-node basis.

The lower level API will accept Object parameters (and not just nodes), but the default implementation will only work using the higher level nodes.

The MultiplayerReplicatorInterface will receive the MultiplayerSpawner or MultiplayerSynchronizer as configuration for the nodes being spawned/synced.

I assume this didn't happen because some of the functionality was split out and pushed up into MultiplayerAPI or into MultiplayerSpawner, which you can override as a whole. But what I want is essentially just what SceneMultiplayer does, but with finer control on which object replicates.

I'd be happy to submit a proposal and a PR for this myself, but I'm not yet versed in Godot's C++ code enough to know what an idiomatic design for allowing such an override would be. I'd love some direction on the appropriate way to implement it. (Just something like adding a SceneMultiplayer::set_replicator(), or something more akin to MultiplayerAPI::set_default_interface()?)

[Faless]

There are various reasons why SceneMultiplayer is not extensible.
First, its internals has already changed during 4.x releases, and it will keep doing so as we add more features to it, we can't really guarantee internal API compatibility.
Second, in every use case presented, either the same thing could be achieved via composition (extending MultiplayerAPI), or extending it wouldn't have been enough, since the internals still needed to make some assumptions that were then not compatible with the requirements of the extended version.

You can think of it this way, MultiplayerAPI is like the PhysicsServer, while SceneMultiplayer is like GodotPhysics.
You can extend (replace) the PhysicsServer with say GodotJolt, but you can't extend GodotPhysics itself.
In this sense, MultiplayerSpawners, MultiplayerSynchronizers, and SceneReplicationConfig are meant to be reusable by your own implementation if you desire.

If you can elaborate on your use case, I may be able to provide better feedback.

[justinian]

That makes sense - I definitely understand not wanting to expose those APIs to keep the ability to change the internals.

As for why my use case doesn't work with extending - I'm basically wanting to do what SceneMultiplayer and friends are doing, but instead of just reacting to peer connect/disconnect, base replication of objects to clients on proximity. It seems like I would be able to do that if I could replace SceneReplicationInterface with one that kept track of objects sent per-client, instead of one master list of TrackedNodes. (Of course, I'd also need a seperate system to keep the octtree or some other method of proximity checking.)

Unless there's something I'm not aware of, that's not something I can do by composing with existing MultiplayerSpawner and SceneMultiplayer currently. I had also just assumed based on #3459 and the name SceneReplicationInterface that there was some intention of eventually making that class an interface that could be implemented by extensions. If you have suggestions of other avenues I might explore other than recreating my own version of SceneReplicationInterface I'd definitely be open to other ideas.

[Faless]

If what you need is fine grained control over which client can see which spawned node (and receive its updates), have a look at the visibility API of MultiplayerSynchronizer.
There isn't much documentation yet, but there's some examples here godotengine/godot#62961
And here the original proposal is here: #3904

[justinian]

Oh wonderful, that does look like what I need. Thanks!