We’ve rewritten the character sound system for improved server-side performance. (Actually, we just got rid of the whole server part.)
Changes
Avatar sounds will no longer be located in the Head. They will instead be in the HumanoidRootPart.
Character.Sound will no longer exist. There will be one script in PlayerScripts named RbxCharacterSounds.
The old system was turning into a server-side CPU bottleneck in games with lots of players. As the number of players grows, the server spends O(players^2) time replicating sounds between players. This was unscalable.
We fixed this by removing all server logic – instead of manually replicating sound states up from clients->server->other clients, one LocalScript just listens for humanoid state changes and triggers them locally. Network overhead is zero.
The speedups can be dramatic; In a 100 player test server, server CPU utilization dropped 40% by switching to the new system.
Finally, moving sounds from Head to the avatar’s RootPart reduces unwanted doppler effects and sound offsets caused by animations.
Before
After
If you currently fork or replace the avatar sound system, this change won’t affect you.
Timeline
We’ll be turning the new system on Monday, October 28.
If you anticipate any breakage in your game, respond here or DM me for a temporary opt-out.
If you have forked sound scripts, we recommend unforking to enjoy the performance benefits of the new system!
On a lot of my projects, I usually create my own character sound script because there is no reason for the server to be involved (other than replicating humanoid state changes). Also because I like different material footstep sounds. I am so glad to see this as a default. Great work!
Sweetness!, Sound like it will be a little easier to make custom character sounds as well if i understand right, i still need to get around to increasing the volume of the “oof” for maximum meme effectiveness.
Just when I was thinking of gutting the script too because of the way that it was being handled. Not only have I been saved a few hours of needless work to rectify the problem that was the former sound script, but it’s awesome to see the employment of zero-overhead “replication” via localising everything.
It’s very good to hear that the avatar is still moving forward with improvements, because the avatar is one of the most important aspects of the platform and sometimes there are less-than-desirable effects when working with them. A 40% server CPU use decrease is unimaginably valuable.
A question about the sound script: how scalable is this system intended to be? If a single LocalScript handles playback on its own end, then it could be possible to fork or use the current layout of the new script to be able to handle NPC sound playback as well. That would be awesome!
The change is very much appreciated. The server now has less involvement in potentially expensive operations, the complaints about remote spam can finally end and this provides an indirect good learning resource about relying less on the server.
This is going to be so, SO useful. I’ve been using the LoadCharacter function for a system I’ve made where you can select a creature to go as, and I’ve seen a lot of the RemoteEvents exhausted.
Given the information in the thread, I assume that what the LocalScript does is log all character humanoids, listen for state changes and play the sounds according to the humanoid’s state. Essentially with that, you get the benefit of a server-driven character sound system with replication by remotes but without actually involving the server.
If this is the case, then you will be able to hear other players’ sounds.
It shouldn’t be. In what regard to exploiting are you asking for?
Most cases of exploitation are nullified by the fact that it’s client-sided. The server is still involved in the backend when it comes to determining, setting and replicating various states. A client modifying their own character doesn’t quite mean that other clients will be affected by the change as well.
At best, most changes in attempt to leverage the sound system will only affect oneself. I don’t know if you have any specific concerns in regards to exploiting. What’s on your mind? State replication? Changing of sounds? Playback manipulation? So on.
Can we get access to this system early for testing purposes? Even if it’s just giving out a script. It could be handy to test backwards compatibility & prepare for this change.
