Engine Configuration

Game engines are usually configurable:

  • Graphics configs (window sizes, detailing, etc.)
  • Audio configs (volume, etc.)
  • Development configs (player character maximum walk speed, etc.)

Restoring Configurations

Configurations are useful only if they can be stored and loaded later.

  • Text configuration files
    • The most common method. Windows has .ini files, there is also JSON, XML, etc.
  • Compressed binary files
    • This is what you used to use when consoles didn't have a hard drive to store data to. On memory cards, you'd have to use their binary format to store both configurations, saved games, etc.
  • Command-line options and Environment Variables
    • Obviously useful for development, not so much for the final game.
  • Online user profiles
    • You can delegate configuration (where appropriate) to a user's profile if you're using an online service like Xbox Live.
    • This will require an Internet connection to load configurations though.
  • Per-User options
    • Differentiate between global options and user-level options.
    • On Windows machines, you could store the data in C:\Users\{User}\AppData.

Case Studies

  • Quake engine
    • Uses console variables aka cvars, which are float globals that must be interpreted by the engine console.
    • cvars are stored in a global linked list, each containing a name, its value, a set of flag bits, and a pointer to the next cvar in the linked list.
  • OGRE engine
    • Uses text files in ini format. There are three such files: plugins.cfg, resources.cfg, and ogre.cfg.
  • Naughty Dog engine
    • All options are members of a mutable global struct.
    • They developed an in-game menu system to mutate the global configuration options and even invoke commands.
    • A menu item has the memory address of the variable, and it can directly control its value.
    • Menu settings are saved in an INI-style text file.