Multiple or a Single RemoteEvent?

I have read in places about using a single remote event and function for the entire game, instead of one for each specific event/function. I have also seen it suggested that this somehow is good for memory conservation and might help a game run faster.

Is this true? How does this work?

Thanks!

6 Likes

No. Use whatever is most readable.

22 Likes

thank you, readability is my preference :slight_smile:

2 Likes

No, using a single remote event for all players would slow the game down a lot as remote events and scripts throttle. Instead what I do is make one remote event, one remote function and a dedicated script to run those events for each player as they join. This way the remote event only handles requests from one player, minimising script activity and preventing throttling.

5 Likes

Most games can be better architectured with multiple IMO

4 Likes

Do you have any source for this? As far as I can find, the only limitations are on the servers data send/receive limit as a whole (which is 50 KB/s).

3 Likes

I don’t have any source. I just found out it was bad from experience when I made a whole game on 1 single remote event and the requests took seconds to go through :pensive:

1 Like

I would move any kind of server-sided verification or request rate-limiting to functions you connect to your remotes instead of creating a completely separate remote for it. Doesn’t seem like it’s entirely necessary for this to exist.

Thakns for the input everyone! WHere is there information about throttling of remote events?

Right now I use a separate remote for each thing ANY player can do that requires one. Then all players share that event. IF I have a game with say 16 or 24 players, and they all do that event X times inside X seconds, when do I get throttled?

Does the single event get throttled? Does the player? How does this work? Thanks!

1 Like

Within the ’ -- Do stuff ’ area I have some events which fire back to the client. Essentially, this prevents the server from throttling the client (i.e. if an exploiter abused a remote event/function). You’re right though, this doesn’t prevent client-to-server throttling. Hope that makes more sense now.

1 Like

That’s pretty intensive for sanity checking. I think the whole rate limiting business is a shaky place to be in, since I normally need my remotes active at all times. I block any incomplete requests or ones without complete credentials and pass complete requests.

To each their own though. If it works for you, that’s all that matters.

unless someone else is in the mix

3 Likes

Once the sanity threshold’s been met, it only stops requests from the specific player for the specific task, represented by atype, for 10 seconds. Without exploits, you’d have to be actively trying to hit this limit (e.g. by changing your character in my game 10 times within 10 seconds) but even then it’d be really hard to achieve!

1 Like