Create a networking API

Currently on Roblox, developers get very little control over networking. With Roblox pushing 200 player servers, adding a way for developers to optimize networking in games seems like a good next step but there was nothing on the 2020 roadmap so I’m making this request

The networking API should add functions that allow developers to create custom efficient replication for non-humanoid characters, manually download assets (only download required maps, vehicles, tools, etc instead of dumping it all in ReplicatedStorage) and the ability to subscribe/unsubscribe to replicated instance changes

15 Likes

My main two concerns is that it is currently impossible to isolate anything requiring physics on the server from replication in any simple manner and that we are forced to use PlayerGUIs to replicate only to one client, which is somewhat annoying to set up.

A new ServerWorkspace instance would be of help, being able to interact with anything within the current Workspace, without replicating its children to any client. Or even better, a service which allows us to create world models which only replicate to selected clients. And, of course, a way to replicate any instance that doesn’t require any of the Workspace’s functionalities.

Personally I think that networking should work like this:

  • We should have control (or somehow be given control) over instance replication and property replication to player(s)
  • This control should include blocking, manipulating, and creating changes per client (e.g. telling the client a property changed to something when it didn’t change, or didn’t change to that thing, explicitly not telling the client about a change)
  • This control should not include the loading of assets imo
  • This control should be easily managed through scripts at runtime

I propose the following:

  • A unified service/instance to produce replication changes (as a list or single change, to a list, single player, or all players)
  • A unified service/instance to block replication changes (as a list, or all changes, to a list, single player, or all players)
  • A unified service/instance to subscribe to replication (on a list of instances, or a single instance, to a list, single player, or all players)

This unified service would need to be able to give developers control over what happens. I feel that this could be done by connecting (or hooking) certain changes. These could be disconnected, but would block those changes automatically. In order to bypass the hook, a replication event could be produced, ignored, or changed within the callback by code using arguments supplied to code. I feel that basing this off of return value could cause performance issues, and having multiple connections for the same property doesn’t make sense, so I feel that it should work similarly to BindableFunctions.

Perhaps these replication changes could be controlled through a Replicator instance which could be told to handle certain properties, or allow others to pass.

I think that an API that would work well could potentially look like this:

  • Replicator - Controls replication of a target
  • RbxScriptConnection Replicator:Subscribe(string propertyName, function callback) - Subscribes to a property change. Only effects properties that fire Changed, that means physics changed aren’t included, however this can already be partially achieved through Heartbeat/Stepped with minimal performance cost, and really, should be done client side anyway. Parent property would control ancestry replication. The callback would include: instance, beforeValue, afterValue and would return a newValue to be replicated to the client. When the connection is disconnected the property is released from being blocked. Upon resubscribing newer connections take priority and bubble up to older ones.
  • RbxScriptConnection Replicator:SubscribeDescendant(callback) - Would behave exactly the same as a normal subscription in every way except it intercepts the
    Parent property changes of instances being added or removed to the Replicator’s target.
  • Instance Replicator.Target [read-only]

This Replicator could be created similar to how Tweens are created with TweenService. There could be a ReplicatorService of some kind which could produce these instances for a given target. In fact, these could behave in many ways like Tweens.

This is pretty much all I feel that I have to say about this. I definitely would love more control over replication as it’d allow me as a developer to do some really cool stuff with my games in a much easier and quicker fashion than before. This would definitely improve my workflow.

2 Likes