Using ValueBases to replicate values cross server/client - downsides?

Hello ladies and germs. I’m writing to inquire about the efficacy of using ValueBase objects to communicate values between server/client - specifically for individual players. I understand well that I can use remote objects for this, however for primitives such as integers it seems more intuitive to create a IntValue on the server within the Player object and hook it’s .Changed event on the player’s client. I don’t know if this incurs any unnecessary overhead though and I don’t know what to search on the devforum to find related topics. Any help here would be appreciated, thank you!

Edit: Moved from #help-and-feedback:game-design-support to #help-and-feedback:scripting-support in an attempt to get feedback quicker

3 Likes

Using a RemoteEvent will have less overhead than using an IntValue (in terms of memory, latency, etc). However, if using IntValues allows for your development process to be more maintainable and easier for yourself to understand, then it perfectly acceptable.

2 Likes

Also there is a functional difference

2 Likes

This was what I was looking for. Thanks. I extend my thanks to @0x_7777 as well.

2 Likes

Clarification: For a single value an IntValue should have less memory or latency overhead compared to a remote.

If it is updated frequently (>15 Hz) the Value object has coalescing of replicated property updates that cannot be replicated with Remotes in Lua. Less importantly, Tte update packet should be smaller by a few bytes.

For an independent server set value that does not need to be bundled with other values the Value object is the clear choice. e.g. for something like a countdown clock NumberValue FTW.

8 Likes

I use value instances maybe more than remotes for server → client replication of object states. It’s actually really awesome, the packet coalescing and automatic filtering of unchanged values makes it super slick.

in my implementation, I just call object:SyncProperty("propertyname") and it automatically creates a value instance of the appropriate type if it doesn’t exist, and sets the value. The client listens for these values and updates state. I don’t have to worry about how much I spam this, because it’s automatically throttled to replicate at no more than 15 Hz. I don’t have to filter redundant updates if the value is unchanged, that’s also handled automatically. If you can get over the idea of remote purism, it’s a clear winner IMO.

7 Likes

@ContextLost @Defaultio

Thank you each for your input here, it’s invaluable. My goal here is to create a simulator-esque game that can support servers of 75+ users, so I’d love to cut down on overhead/redundancy wherever possible. I believe I now have all of the information I need regarding this topic.

Same. I use RemoteEvents for one-off events, but prefer to observe value objects that are synchronized using Roblox’s as a source of truth.

I think this tends to lend itself towards easier to understand code.

1 Like