While making my game, it’s gotten to that time where I need to start implementing remotes for various different purposes.
One such purpose is the player’s inventory. I use DataStore2, and I have the inventory store set to run a function that fires a remote to the player whenever that player’s inventory is changed. So on the client, the code is pretty easy:
remote.OnClientEvent:Connect(function(stuff)
--do stuff with stuff
end)
But the problem arises when I have a lot of different remotes with very different purposes. Best practice is to always do visual stuff on the client instead of the server, so I’ll need to handle remotes for everything visual, as well as remotes for anything gameplay related like timer starts, inventory updates, etc.
Do you get what I mean? When you have many remotes with many purposes, what is the best way to handle all of those purposes? Should I have one script to handle nearly every remote, or one script for each remote? If the first option, the code would get pretty messy connecting to so many remotes.
you can use one remote for multiple functions like this:
remote.OnClientEvent:Connect(function(func,...)
if func == "one" then
one(...)
elseif func == "two" then
two(...)
elseif func == "three" then
three(...)
end
end)
That’s what I did for my last game but it’s honestly kind of hard to maintain. To me it seems like there are better ways to do it, plus for this game I’m using a different RemoteEvent for every purpose (for the most part) instead of just lumping a bunch of similar remotes into one.
I started this way, and it’s a TERRIBLE practice. I switched to “one event for each command type” and it’s so much better. Code is cleaner. It’s more efficient - you no longer have to include the command type as a param. What’s one little string? It doesn’t sound like much, but this string has to cross the server-client barrier. Lots of times.
Furthermore, the way you’ve suggested gets real messy once you have to start sending other data along. One command might need a string and a number (eg name and damage), and another might need a Color3. Then you have to deal with mixed param footprints. Yuk. Yuk. Yuk.
Yea, I get how to organize the remote objects themselves in ReplicatedStorage or wherever, but I want to know different and better ways of organizing the scripting side of things.
I’m planning on using a different remote for every command as you described, but I worry that the code could get messy quick connecting to that many different remotes.
Usually I organize the remotes by the name to the respective function on the client. All remotes are within a folder. For security, I prioritize that the possibility on server without impacting performance and convenience and then server-client or client-server and finally the client.
Oh, I have almost made most of my scripts with using remoteEvents like that. Yeah I can agree, it’s really hard to maintain and sometimes you get lost while doing something. I am not using this method in my next games
It’s unclear to me which way you think is bad and won’t be doing again? Did you mean “1 event with a passed eventType param is bad” or “distinct events is bad”?
Thanks for all the replies. I’ll take what you all said into consideration.
@BrisDeveloper so you recommend that I have one script for connecting to every remote, or at least one script for connecting to a group of similar-function remotes? Or one separate script for each remote? It seems unlikely to be the latter but just checking in. Thanks