Yeah, good luck!
Note we also just store remotes in ReplicatedStorage and fire them, but we do this OOP trick a lot too. Just depends on the scenario we’re programming for.
1 Like
I think using multiple remotes will be better because if a lot of players are using artillery at the same time the server will process them one by one which will delay feature remotes (never tested this so not sure)
you can try both methods and see which one is more performant
Single RemoteFunction or Multiple? - Development Discussion - Developer Forum | Roblox
All network throughput is ultimately trafficked through the same tunnel. Whether it’s one remote, or several remotes, generally speaking there will be no difference in latency. The server processes each request serially but I’ve had test sessions suggest that they are processed in parallel. The behavior in question was two different event requests being processed at the exact same time, leading to some errors I was getting. Putting the events in a sort of queue system to be scheduled with task.wait to run fixed the issue. I have not experienced it since.
The only time using one remote to network the entire game becomes a problem is in the hands of the developer. One event for everything sounds like a beautiful wonder, but that also means developers can’t get insight on what an event specifically handles at first glance. This can create confusion especially considering if you’re going to use one event, you will most likely have some sort of id argument at the receiving end to process which type of request is being…requested.
Performance hurdles or “throttling” only come into play when the requests themselves take a while to execute. For example, if you have an event that obtains every descendant in the DataModel that has a certain name (meaning there will be a for loop and a check for Name), this will take a while to execute and return a result.
From my testing, if an event is fired and literally just has a blank function or something really simple like to increment a server variable, I have never ran into the issue of throttling even when I hooked the event on RunService.PreRender (never do this without some sort of hardcoded throttle on your end lol, i only did this for testing).
2 Likes
Yhmmm, the problem here was more of an OOP reference kind of thing, but still it’s nice to know, soo in the end more remote events are the same as one? or is it different? ik there can be little bit more performance due to no need for id and stuff, but still?
In general, I would still use separate remotes for everything, and have some sort of Event library handle requests as if everything was just one singular event. For example,
If you had some sort of reference to your Event library like this,
local Event = require(script.Event)
…and you wanted to, say fire to topic FireWeapon,
Event:Fire("FireWeapon", ...)
…and on the libraries end, it can parse this request to figure out which event to use. Generally, for my work, I have the library fallback to a singular event with an id argument if the topic is not recognized as a specific event so the request can still be received by the client/server. If an event with a name matching the requested topic is found, it will use that event instead.
For consistency, you would also want to implement a way to listen for these topics, from the fallback event or from a specific event. Your specified Event library could handle this as well,
Event:Listen("FireWeapon", function(...: any?)
-- Do sum work
end)
1 Like
yhmmm, still using invidual remote per player seems more performant in terms of organisation/references, anyways thx for help
1 Like