Next Previous Contents

2. The directories and how to handle them

2.1 The different between /usr/ and /usr/local.

Before I start with some more detailed description, there is one thing you should know. There is a directory tree /usr and there is a directory tree /usr/local, they contain both the same subdirectories, but the different is that all stuff under /usr is handled by the distributions package system, while all stuff under /usr/local is maintained by the system administrator. So if you are providing a game as source or as a precompiled tarball it has to go to /usr/local, if you provide instead or in addition RPM or debian packages they should install them self into /usr. In the following text I will refer only to /usr, because things under /usr/local are the same just in another prefix directory.

2.2 Which files are needed by a game?

So before we a going to install a game we first have to think which files we have in a game and what types of files are they. Most games will have some or most of the following file types:

2.3 Where to put the files?

Binaries - /usr/games/

This is the easiest thing to do correct. Normal programs are placed under /usr/bin, while games get their own directory under /usr/games/. So all user visible binaries should go directly into that directory, this will be mostly just a single executable binary.

Static Datafiles - /usr/share/games/

A lot of games at the moment put there data files in a place like /usr/lib/$GAME, but games will now get there own directory so placing them into /usr/lib/ wouldn't be the correct way. The new place for static game data is /usr/share/games/$GAME. All static and architecture independent goes to that directory, like images, music files or packed datafiles. It is not required to separate the directory any further, but I recommend it, since it will ensure that you will not end up in chaos, if the project groves.

Shared library's - /usr/lib/games/

Some games use shared libraries which are linked at run time, this allows the game much more flexibility, because levels and enemy's can be created in C or whatever language they might choose, so there is no need for scripting languages or other stuff to make the game more flexible. You might guess that libraries should also placed under /usr/share/, but that is not correct. Since /usr/share/ is only for architecture independent files and shared libraries are not architecture independent, they depend on a specific type of machine architecture. So they should be placed under /usr/lib/games/$GAME/.

Save games - $HOME

A lot of games offer the possibility to save the game status and restore the state where you left the game. This data is variable and should therefore not saved under /usr/*. So were to put the savegames? Because savegames are personal data, there are best placed into the users home directory. The savegames should be placed in an extra directory for each game, like $HOME/.$GAME/. This will ensure that the directory is normally hidden and won't annoy the user. If there is more variable user specific data (like demo files, etc.) it should also be placed in that directory. Then the directory should be separated into some subdirs like save/ and demo/.

Hiscores - /var/games/

Hiscores are similar to save games, but they are not equal. The different is that save games or mostly interesting for personal use, while hiscores are interesting for other. On a multiuser system it would be interesting to fight against other peoples hiscores. So hiscore files and other dynamic data which is not meant for personal use only should be placed under /var/games/. If the game needs more then one file to hold the data it should get its own subdirectory, like /var/games/$GAME

Config files - /etc & $HOME

As for all other programms, there are two places for config files, one is /etc/ and the other is the users home directory. I'd recomment to use an extra directory for games under /etc/, but the FHS does not require this. So /etc/games/ should be the places where the global config files where placed. Local user config files should be placed under $HOME/.$GAME/, just like save games.

2.4 How to find the files and how to make the game relocatable?

Now you know where to put all files, but how to find them after installaton? If the game is compiled from source it is easy, the install prefix, which should be /usr/local by default, should be compiled into the binary. How to do this using autoconf/automake is discribed below, if you are using a non standard way, you have to do that yourself or switch to autoconf/automake, which is really recommend. This way the game will allways know where it was installed.

The problems come when you are trying distribute a binary version. If the game is packed in a debian or RPM package, then the package maintainer should set the prefix right so that the game will run fine after installaton. But what if the user wants to install the game somewhere else, for example under /opt? Then the game has to be relocatable. But what does relocatable mean? Its means that you can install a programm where ever you want it to be, you are not forced to use the standard directories. There should be allways a way to override the default path in a game. A good possibility to do that is to set the prefix directory throu a configuration file, an enviroment variable ($GAME_DATADIR or $GAME_PREFIX) or an command line option, for example --data-dir.

2.5 How to allow extra levels or similar stuff?

The problem that arrived with extra levels and similar stuff is that not all users have root access to there macines, so it is not possible or to difficult to place the files under /usr or it would be more comfortable to have them in the home directory when you are developing a level. Therefore the game should offer the possibility to read the files from $HOME/.$GAME/. The subdirectory structure in that directory should be equal to that in /usr/share/games/$GAME, so it will be possible to extract the extra level in /usr/share or in $HOME/.$GAME, without tweaking the path.

[FIXME:] At the moment I am not having much experience with shared libaries, so I can not say if it will cause throuble to placing them under $HOME/.$GAME/. I think the LD_LIBRARY_PATH has to be adjusted, but I am not sure.

2.6 How to handle data from a cd-rom?

[FIXME:] This section is only theoretical, I never tested anything from below, so be warned!

Under DOS and Windows handling the cdrom wasn't very difficult the game only needs to now the drive letter. Under Linux the situation is not much different, but instead of a drive letter we have a device name where the cd-rom is and a directory name where the cd-rom is mounted. The standard places are on the most machines /dev/cdrom, which is a link to the correct device (you normaly will newer want to touch this directly) and the directory /cdrom. But the correct location should be always be detected at installation time and stored in a human readable configuration file.

Some games allow it to install only some files to the harddrive and let all other data resist on the CD or to install all data to the harddisk. This shouldn't be to hard to include into a game, it only has to keep track of were it installed it files and then load them were there were installed. I recomment it to have a similar directory structure on the cdrom as on the harddisk, since that makes thing easier, so the programm can acces its data with:

              f = fopen(make_full_path("levels/level1.dat"), "rb");

Where make_full_path() is a function translating the relative path (here: levels/level1.dat) into a full path, which could be /cdrom/levels/level1.dat or /usr/share/games/GAME/levels/level1.dat, depending on which data was installed. Another more tricky possibility would be to use symlink. The install scripts would create symlinks for all files which aren't installed and let this symlinks point to the cdrom directory, that would be possible, but cause some trouble when the cdrom is mounted to another directory or the computer as multiple cdrom drives.

Next Previous Contents