Practical Application - Organization         Your application has to live somewhere

Your application has to live somewhere. On Windows you'll probably have a nice MSI installer that defaults to somewhere in the Program Files directory. On Linux it'll probably end up somewhere in the /usr/local or /opt tree. But either way, you should NEVER assume anything (at least anything that did not come with your game's distribution package) to be in a certain place on the host machine. You cannot even expect the user to install everything to C:\Program Files.

So what you do in that case is

  • Operate using only paths relative from the application root
  • Use conventional system-dependent locations for storing application configuration and user-modifiable content data


You will want to install your game's executable to the root of whatever directory your user specifies. So for example, if your game gets installed to C:\Program Files\MyGameCompany\ReallyCoolFPS then your main executable might be C:\Program Files\MyGameCompany\ReallyCoolFPS\game.exe. In your game code you always will reference other resources and executable modules in relative form. For example, you might store your maps in C:\Program Files\MyGameCompany\ReallyCoolFPS\maps. Anywhere in your game code, when you want to retrieve something from your maps/ folder, you use "maps/" and not "C:\Program Files\MyGameCompany\ReallyCoolFPS\maps". Better yet, make it a constant stored in a main constant definition file accessed by all game code files that need it, so that you can change it easily (instead of trying to find the 624 different places you hardcoded it in your game code). This falls under coding "best practice" anyway, so you probably already do that. Don't you? ;) Also, strongly resist the urge to install anything to a system directory; it's a mess to clean up on un-install and you end up with DLL hell even if the OS or shared-object naming schemes are there to help you. Keep whatever you need close at hand, meaning put everything in your MSI or RPM under the application's installation root; your executable is guaranteed to find it and you always have explicit control over which module versions you are using (which you don't when depending on dynamic-linker search paths).

The other bullet above refers to the fact that you cannot always be certain of write-access to the game's installation directory. Windows XP Home comes to mind, as does applications installed by root to /usr/local (typically not writable by user accounts). So you have to write configuration data and user-defined data to the place on each system conventionally defined for this purpose. On Linux you can create anything you want under $HOME (accessible using the getenv() system API), and on Windows you will want to use the Application Data folder, under \Documents And Settings\<username> and \Documents And Settings\<username>\Local Settings — you get this information using the SHGetFolderPath() API, as we'll see. [Alternately you can use char *userpath = getenv( "USERPROFILE" ) on a Windows system.] Either way, you want to create a subdir in this directory to hold your application's user-specific data.

Beyond that it is up to you how you organize your application's code and data modules and directories.

Prev <<< Practical Application - IntroductionPractical Application - Foundation >>> Next


Call to undefined function mb_split()Call to undefined function mb_split()Call to undefined function mb_split()Call to undefined function mb_split()