I am currently working on a factory game similar to satisfactory and factorio and need a way to replicate server state to multiple clients multiple times per second. From my research, using normal remote events are not optimal for this kind of replication as they are made to reliable and but not repeatable. I then found a rather recent addition to the roblox api known as unreliable remotes. Would using unreliable remotes be a good solution to my problem? In terms of the rate of updates, somewhere between 30 to 60 updates per second is required.
2 Likes
What is the use of this exactly? Could you please tell?
Anyways, I don’t think unreliable remotes would help. They might be even worse, because like it says its unreliable. They execute at random times. Only advantage that you can have is that it doesnt yield for a response, but really the yield is so small for normal remote events that players probably wouldn’t even notice.
If you genuinely need to do these updates between the client and the server this often you definitely need to lower the rate because this simply isn’t feasible without leading into some sort of problem.
2 Likes
One example would be handling entities on conveyors. The current implementation I am using is a similar one that the factorio devs discussed in this post (Friday Facts #176 - Belts optimization for 0.15 | Factorio). I would like to replicate the distances between the item entities to all clients after updating their positions on the server.
1 Like
Ah, so the game isn’t coded on luau. But on C++. Which has more capabilities than luau. I am on my break from scripting right now so I am a bit rusty but I do know that C++ can handle and do alot more things than roblox’s programming language pretty sure.
Yeah, I don’t think this stuff is possible on roblox (luau). But it could be on C++. To make something even remotely similiar to this you’d definitely have to reduce the speed rate of replication by a decent amount.
1 Like
looking a little further into how factorio handles its replication. It seems that all clients have their own “world states” running along with a “master” server state. Any changes made to the server state is replicated to each of the client states instead of updating several times a second. I just dont know how you would handle the latency between server and client along with any desyncs
1 Like
UnreliableRemoteEvent is best used for ephemeral events including effects that are only relevant for a short time, or for replicating continuously changing data.
This is straight from the documentation. I think unreliable remote events would work fine for your case since the server state is updating constantly. Clients should only care that they have the most up-to-date server and not worry that an update 1-2 seconds ago hasn’t come through yet.
If receiving state updates out-of-order would be an issue, you can implement your own sort of “ordering” on top of the unreliable events by including some sort of sequence number with each update. Simply drop updates that are older than the most received one (or do whatever fits best for your game).
1 Like
I set up a small test where I used timestamps to determine if the incoming packet was outdated. It seems to work fine on a locally running server but ill have to do more tests in a production environment to see if its actually viable. The issue Im facing now is the limit on the size of the data im able to send. Roblox caps the amount of data you can send through unreliable remote events to 900kb and if im sending the states of hundreds of structures that limit is going to fill up very quickly.
How are you sending the data across? Are you just sending a table containing the state?
for the previous test yes, im currently setting up a test where each event firing will only update a single part
Have you considered using serializing the server state into buffers and sending that across the remote event? It might cutdown on the bandwidth since you’re not sending unnecessary data.
Looks like the limit is 900 bytes not kilobytes which is even worse 
Edit: FWIW, right now I was able to send ~2kb buffers across the unreliable remote event so Roblox is definitely doing some compressing before sending it under the hood. Unfortunate though that the payload limit is so little.
im now wondering if sending the server state to the client at all is necessary. The reason I wanted to send the state to the client in the first place was to handle all the visuals on the client but im considering if letting roblox handle replication and just updating instances on the server is just a better solution
Yea they definitely handle a majority of the use-cases for you automatically. To me, it’s a tradeoff between control and ease-of-development.
If you can get away with using Roblox’s default replication for your needs, I say go for it. No point in making it more complicated than it needs to be. However, if you want to have complete control over what is being sent to clients and what clients will see, then you might have to develop your own system for that.
Im sure there are people out there who want to implement non physics based conveyors out there. This is what ive prototyped so far so have fun.
ConveyerImplementation.rbxl (64.8 KB)
1 Like