Object Oriented Replication (need advice)

Help and Feedback Scripting Support
#1

Id like to preface this by stating this is an advanced scripting question, please dont answer if you dont have any valuable input. Thanks!

Ive recently been prototyping an object oriented game, and now want to tackle replication.

Lets use a turret as an example, what i would do is have two modules, one for the client, and one for the server. The client handles things like turning, input, etc, the server handles authentication (Ie, player interacts with object, server module recieves request, then gives info back to initial client making request to create their own client object). The server module isnt really the topic of this post, but i thought throw it in here.

Now what i want to do, is have the turret object persistently created accross all clients (that is, to have the same id), store the persistent objects on the server for players joining, and then when i want to update say, the angle the turret is facing at, i can have the host client (in this case the pilot of the turret) send a request to the server to update their turret, with info like objectId, function name, params, etc. When the request meets the other clients, theyd see if an object in their store matches the objectId, and then if so execute the function with the given params. Thus turning the turret, and replicating it. Heres a diagram.

image
image784×391 23.2 KB

What im trying to ask is if this form of replication is viable, and not overcomplicating things, and if there are any other viable alternatives for an object derived game design model.

I want to reuse as little code as possible, which is what i would be doing were this conventional programming.

Thanks!

3 Likes
#2

Changes will replicate from server to client, and not the other way around. If you want each player to have their own turret, then you can simply create one server side. Each player will be able to see each other’s turrets as well as their own. If you wanted each player to only see their own turret, you could use ReplicateStorage to hold the turret model, then have a local script copy it into workspace.

Then if you wanted each player to be able to update their turret properties (angle for example), you’d use a remote event which triggers a server side function that’ll update the turret property. As it’s done server-side, all the changes made will automatically replicate to all clients.

Trying to use a broadcast topology like you mentioned would be inefficient as you’d end up with lots of unnecessary network traffic. If you wanted a player to be able to update objects belonging to other players, you could pass the player IDs to the server with your request and the server would update those objects.

You generally don’t have to worry about the fine details of replication too much as the majority of it will be handled by ROBLOX.

2 Likes
#3

updating values on the server would be inefficient, say i want to smooth out the transition period, doing that on the server would result in jitter and more network traffic. Thats why i have this solution.

2 Likes
#4

Since I have no idea how the rest of your game is set up I can’t comment on how well this method would apply to your use case, but from my own experimentation, I can at least tell you that this kind of OOP Replication is completely possible.

Of course, there’s a few things you want to do like data compression, rate limiting, and interpolation/extrapolation if you’re handling movement. But if you’ve optimised everything properly, there’s no reason this kind of replication shouldn’t work. Make sure to create some kind of ‘ownership’ system (basically your own version of NetworkOwnership) to help prevent bad actors from exploiting the custom replication.

I myself have been experimenting with custom replication as well, mostly because Roblox’s default replication isn’t suitable for my niche use case. But if this kind of setup suits your game, then best of luck to you! Hope everything goes smoothly.

TL;DR: Yes, it’s completely possible. Suitability depends on use case.

2 Likes
#5

Yep it’s possible.

I think a better option than Objects is to use ECS which is basically in my words objects but modular and more component based. Here is my code based example for a status system, however keep in mind this is just one method and you could create your own similar system like others have done with ECS as long you go Component-Based.

Plus this makes it easier in my opinion to seperate what should be a client system, server system, or perhaps shared and you can just drag and drop the system modules to where they belong in the future.

To go more concrete.

For this you can just use Instances and pass the reference around as they have a unique ID guranteed by roblox system. No need to use Http:GenerateGUID() and stuff or an incremental ID system 1,2,3,4, … .

image

For the same Instance ID, you can generate one client object and one server object which you will have to do anyway as client and server is seperate.

Replication between these two objects such as server sided unique properties, or client sided unique properties will be completely up to you and as viable as you can make it.

2 Likes