0
\$\begingroup\$

I've create smaller games which simply needed a class which basically opens an INI file (with feather-ini-parser library) with config values for the whole game (rendering ops, music, bindings).

But I want to go to medium-larger projects and my current configuration managing system I used earlier will be getting more complicated when my engine grows. I need a new config manager system and I tried to research but found nothing. My current config manager for 'mid-large games' is this:

The ConfigManager class interface:

    class ConfigManager
    {
    protected:
        class INIFile
        {
        protected:
            std::string id;
            ini_t ini;
        public:
            INIFile(std::string &id, Poco::Path& filename);
            ~INIFile();

            void Destroy() { delete this; }
            std::string& getId() { return id; }
            ini_t& getINI() { return ini; }
        };

        typedef std::vector<INIFile*> INIFiles;
        INIFiles files;
    public:
        ConfigManager();

        bool openConfiguration (Poco::Path& filepath, std::string& id);
        void closeConfiguration(std::string& id);

        void flushConfigsToDisk();

        void getConfiguration(Ogre::String &id, ConfigModule& mod);
        void setConfiguration(Ogre::String &id, ConfigModule& mod);
    };

ini_t is a typedef of an INI Reading/Writting library (feather-ini-parser) this class is instanced in the main Engine class (avoid Singleton use), id is the unique identifier to the file opened like "Input", "MyGameCfg", "Rendering", etc. the ConfigModule is a "section" from the INI file opened and it's structure is:

    class ConfigModule
    {
        friend class ConfigManager;

    protected:
        optValuesVector keyValues;
        Ogre::String section;
        bool is_empty;
        bool nominal;

    public:
        ConfigModule();
        ~ConfigModule();

        Ogre::String getOptionVal(Ogre::String& key);
        Ogre::String setOptionVal(Ogre::String& key, Ogre::String& val);

        bool is_empty() { return is_empty; }
        bool status() { return nominal; }


    };

ConfigModules are "wrapped C++ INI sections" and stored in specific game classes like Input, GameLogic, Rendering classes. Instead to invoking an instance of the ConfigManager every time to get an setting every time, the ConfigManager is ONLY invoked when some of the game classes needed to write configurations and re-parse the config file with the new values.

My Question is: Is this a good approach (at least I feel this system has it's flaws, probably change configuration formats from INI to Lua ) to handle multiple configurations in large games? or there is another better design I can follow?. Thanks.

\$\endgroup\$
  • \$\begingroup\$ What do you mean by "multiple configurations"? \$\endgroup\$ – Kromster Jan 28 '15 at 5:25
  • \$\begingroup\$ Yeah used in many areas of the engine itself \$\endgroup\$ – Cristopher Sosa Jan 28 '15 at 20:04
2
\$\begingroup\$

Your system looks fine.

I am more used to having all of my configurations for a game in a single file but I also work on very large projects where I have folders of configurations. Your system as described above should be able to handle both of those situations just fine. I do not see any concerns you may be perceiving in the question nor do I foresee any that you may run into either.

As to your thoughts of changing it from an INI format to Lua, that is completely up to you and no general 'this is better than that' rule exists. Just make sure that it fits your needs. If you have Lua in your engine already for other purposes (Its how you script game play or UI components or AI logic checks, etc) then it may make sense to change the configuration files over to use it as well. Maintaining less technology can make things simpler in the long run.

Just to be clear, adding in Lua processing just for a configuration file parser is probably overkill, especially when you already have a parsing system in place.

Hope this helps.

\$\endgroup\$
0
\$\begingroup\$

In my opinion, it depends on what you need of course, but I personally really like the way this configuration parser was written.

https://github.com/LaurentGomila/SFML/wiki/Source:-Settings-Parser

It's under the SFML wiki, but rest assured it has no dependencies on the library. You only need standard C++.

It is template code so you can assuredly expand on it without too much effort, if you wish to use it as a base.

It also has write capabilities.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.