When a player picks up an item, I would to fire their client to play a sound locally and update an image in their gui.
Should I do something like
UpdateImageEvent:FireClient(Player, itemImage)
PlayPickupSound:FireClient(Player, pickupSound)
or
ItemInteracted:FireClient(Player, itemImage, pickupSound)
Which one is more efficient in terms of data being sent? Is it negligible? I’m currently doing the first way, is it worth changing?
I’d say the second one, so that you can keep it more organized and handle everything in a single function to change the image and play the pickup sound.
Ima need more opinions just to make sure this is the better way
There’s no real difference, but I’d prefer the second one if PlayPickupSound is never called alone.
If your goal is to reduce data sent (which is negligible for this case anyway, but…) I think ItemInteracted should fire some sort of itemId instead of an itemImage and pickupSound. The client could then keep a table of what itemId maps to which itemImage and pickupSound. As a bonus, this also makes it easy to modify the itemImage and pickupSound of each item since it’s all centralized.
Within any game, it’s essential for performance to reduce the amount of data being sent over the network, as the network is volatile and the conditions will change from player to player.
With your first method, there may be a delay between the effect of your first remote to your second. This will be especially noticeable if there are many of the events queued.
I would like to suggest a small change, however. You can change a player’s GUI from the server, if it is in their PlayerGui or somewhere similar. You simply access it from the server, and it will update for the client as usual. This will cut out the requirement of using a remote altogether.
I did not know this.
Is the only way to make a sound player only for the client locally from a part to fire a remote event?
Not really, as the client has to play the sound themself to make it stay on the client.
The API for playing local sounds is only accessible on the client, so you do need a remote to do that.
Another thing, is accessing the playergui from the server “hacky” or bad practice?
Should I rely on this?
If anybody else wishes to correct me on this, please feel free.
However, I have never heard anybody saying that accessing the PlayerGui on the server is bad practice.
The changes will still replicate, so it’s basically the same as changing on the client.
Sometimes I send more complex data structures for the client to do something with their GUI, via remote events. Should I keep it this way or do it all on the server?
It really depends on how you like to organise your code. If you wish to delegate that task to the client, you can.
The only time you should do it on the server is when you really want to cut out your remote event calls.
Changing the gui from a server is a huge code stink and shouldn’t be done.
Stick to remotes.
The reason why I did it the first way is because PlayPickupSound can be played alone.
Network events should be declarative. All the server has to do is tell the clients what it saw happen. After that, the client can determine what that actually means when it comes to animations and effects and whatever.
In other words: The server is the referee and states what occurred without providing too much details. The clients are the orchestrators and they listen to the referee and handle all the details. It’s best to not mix these roles up.
For this reason, there’s probably no need for a generic “PlaySound” remote event since you’ll only ever play a sound and an animation after some sort of interaction. You never want to play a sound on its own without some sort of animation for a good user experience.
(Think about it; if you hear a sound in real life and you dont see where it came from, you are not able to draw any value from that sound except for maybe anxiety or confusion. These are usually not the feelings you are trying to invoke when playing a sound effect in a game or application.)
Simply stating that a player has interacted with an item is the ideal solution here, for reasons @XAXA as already stated.
You’ll be able to sync the item gained with the sound effect and any other effects that may occur when you interact with an item this way. You’ll also avoid having the effect of this interaction split between server and client; it can remain all on the client and you’ll be able to avoid any timing issues.
I would like to stress that this is bad advice. Please do not tamper with a player’s ui from the server after it has been initially replicated. This the wrong approach to doing things; you will not be able to ensure the client hasnt changed their UI drastically since it was first replicated through localscripts and replication from server to client has a similar delay to firing a remote event. You will not be able to ensure that the effect you’re making will replicate at all (if the client has deleted the original UI objects) or replicate in rhythm to other ui changes the client is already making
The client will know best how to animate itself.