Currently in my game, I create a different SharedObject file for each different setting/data I want to preserve on the system. So the application local space ends up looking like this:
Most of those are quite small in size. But I thought it might be nicer to put all of those settings in one SharedObject file for convenience.
What do others do? Is there a recommended approach?
Combining them into one file will make them take up less space, and the program will run a tiny bit faster because you won’t be doing as many file i/o operations.
Often, developers use one SharedObject per save slot, plus one for settings. For instance, if a game offers three save slots, that’s four SharedObjects total.
In games without save slots, developers usually stick with a single file that stores both progress and settings.
Hm thanks! I think I’ll combine the settings into one.
The CustomLevelData is used by the level editor in my game. I set it up so there are 9 slots in-game. Not sure if I would explode those into 9 SharedObject files. Players can share the levels using in-game functionality, so copying the SOL file wouldn’t be necessary.
The point of using multiple SharedObjects is, each save slot has to store the same variables (“name”, “level”, “secretsFound”, etc.), and this makes it easier to keep them separate.
If each level has a bunch of key-value pairs, then go ahead. But if you compress the level into a single string or byte array, there’s probably no need.
“Strictly to m-y way of thinking …” the application-level concern, of “persisting various settings-sets,” should probably be handled, “once …” by a single, application-level actor. This single software entity knows-about all of the settings that this application needs to persist, and bears responsibility for persisting all of them … at once.
I get what you mean @sundialservices 
It could also be the other way, that each separate setting should be stored in a separate software entity, such that each one is responsible for only one specific piece of data.
In my case, I’ve decided not to change the implementation that I have, since it works. But I’ll keep both of your inputs in mind for future games. Thanks!