Skip to main content
GameDev.net gamedev.net
🔒 Locked

Configuration systems

Started by dcosborn May 27, 2006 at 10:59 AM 2 replies 1.2k views
Original Post
dcosborn
dcosborn
I'm rethinking the implementation of my configuration system and I thought I'd fish for opinions and ideas. I haven't found much on gamedev.net about such systems, probably because their generally pretty simple. If you could give a general overview of how you manage your game-settings or cvars under the hood, it'd be very helpful. I've opted to use an explicit set of typed variables rather than something looser like a map of strings. The variables are global in the cfg namespace. Currently, each variable is wrapped in a transparent class which automatically updates the hardcopy of the config whenever the variable is changed via the assignment operator. In my refactoring, I'm aiming to support multiple layered "sources" of config data, including the registry, .ini files, and /etc/conf files. I'm considering switching to an explicit Update function which would commit the entire set of variables to hardcopy when called. Contrast this to the current system where every variable assignment causes a hardcopy update. Here lies the problem. Although the registry can easily perform incremental updates, files cannot. The entire file must be rewritten with even the slightest change. If you're changing many variables, the full commit Update function is more efficient (at least with the file system). If you're changing a single variable, the incremental assignment operator is more efficient (at least with the registry). If I'm supporting both of these hardcopy sources through the same interface, I need to favour one over the other. Which would you use?
xEricx
xEricx
I guess its pretty common to simply rewrite the config files when exiting the application, so with your file example, you'd simply write it once.

The downside with this method, is that if your application crash (it shouldnt ;)), the changes will be lost...

Unless you plan to have two or more instances of your application running and sharing configs (you'd also need to reopen your files constantly to see if the variable changed and close it after), I think the "write when exiting" method should do the job.

Hope this helps!
dcosborn
dcosborn
Quote:
Original post by xEricx
The downside with this method, is that if your application crash (it shouldnt ;)), the changes will be lost...

This has happened to me a few times while playing games and its really annoying. Although I'd like to think my game won't crash, we all know it probably will. ;)
Quote:
Original post by xEricx
Unless you plan to have two or more instances of your application running and sharing configs

Ah I forgot about potential synchronization issues with multiple instances. Generally, I'm only reading from the hardcopy on initialization, but I could still end up with the second copy only seeing part of a group of changes with the incremental method if the timing is right.

Maybe I could use a set of Open/Close/Write functions in my sources rather than a single incremental Set or full Update function. This way, the file source could wait until the Close function before writing, and the registry could write during each Write function while keeping the registry locked from changes by another instance. This would solve both problems.

Thanks for the helpful suggestions.
xEricx
xEricx
Well the problem with multiple instances is that say both instances modify the same parameters to different values, who wins? the last one to write its settings to the disk? An option would be to pop a "merge" window, where the user decides which settings to keep in case the current settings on disk differ from what it first read and that it has a new value for it.

I don't know about your particular set up / problem, but seriously unless you're planning to build a commercial package off of it (and event then, most commercial applications do just that), I'd simply read the settings at instanciation, and dump them when exiting. This is way simpler and you can then spend more time on more interesting / important matters :)

Cheers

Eric

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.