This is something that can very easily be tested, but that wouldn’t really provide me any information about the semantics behind this nor what would be a preferable option (provided it’s not negligible).
So I’ve recently become interested in designing for memory and performance in relation to sounds. I’ve typically been content with just leaving all my sounds in the DataModel, only ever changing up the strategy when dealing with large amounts of audio (e.g. background music playlists).
As it so turns out (and this should’ve been obvious too), longer and more intense sounds take up memory so long as they exist in the DataModel. Sporting multiple audio tracks in a game, as you can probably tell, adds up. Only worth a single MB or so though per track and significantly less for sound effects, but that kind of stuff adds up especially when you’re careless with how you manage your game’s assets.
With all this in mind, my main thoughts here:
Should I resort to instancing sounds (including music) and removing any unused sounds as opposed to leaving them in the DataModel (removing unused items is good practice anyway), or is it alright to leave around?
Is either method negligible for both memory consumption and performance, thus I’m just propagating an unnecessary worry for myself here? Does it really matter if I just instance sounds or keep them around and relegate this matter to preference?
Are there any benefits or downsides to using either method? Which would be a better gamble if I were to take more factors than just memory and performance in mind, such as convenience and personal preference?
I am completely clueless on these kinds of topics. I would be grateful if you could lend me your knowledge on this. Cheers and thanks for your time.
I mean, if you have only a handful of sound tracks, a few MB is going to matter a lot less than many other processes - I see this more as a micromemory management issue which only C++ people usually care about (but there’s always a handful in other programming communities). If you have memory exceeding a self-appointed threshold, then I can see why you may want to remove unused sounds, but even then I’m sure there are much greater limiting factors affecting your game at that point. If you have a huge part density, then cutting down on sound won’t really make a difference. But if you have already optimized the greatest that you can in the limiting cases, I don’t see why you can’t turn to the smaller contributors; over time micromemroy management and micro optimizations will add up.
But again, this only really matters if you are reaching self-imposed (or even your own hardware’s) limits. I usually deal with memory in C++ a lot and for most “laggy” issues, the areas that require the most refinement are usually not one-liners and some lingering object I forgot to delete.
I don’t know the inner workings, so take my advice with a grain of salt. I might be wrong on some details here.
Assets that you upload to Roblox, such as decals, meshes and audio are all stored on the website. When you insert any of these assets into your game, you have to download the referenced asset from the website using its ID. So when you instantiate a sound which isn’t yet present in memory, you need to download its data from the website, which can take a brief moment and take up networking power.
With this in mind, inserting audio right when you need it would not be smart. It’s best to have the audio downloaded and loaded before you start playing it. So if you go for the option where you dynamically insert and remove audio, make sure you add the audio at the appropriate time.
Another thing to consider is the fact that assets are only loaded into memory once. If you have duplicate textures, they are all stored in memory in the same place. So if you have one big audio file which is referenced in many different Sound objects, you’re not actually increasing memory consumption by any significant amount once you add a second or third reference. This also goes the other way. Only when you lose all references to an asset, will it be removed from the memory.
With that all being said, here’s what I would do: Keep small sound effects and or effects that you need to play often loaded at all times. This would be sounds such as character sounds, little UI noises and the like. For audio that takes up significant amounts of memory or ‘constrained’ audio (i.e. audio that can only be played in specific situations), only load it right before you need it. So if you have a round-based game for example with maps that all have their own unique sound tracks, make sure to only load their sound tracks when those maps are loaded and used.