/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.
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:
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.
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.
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/.
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 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
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.
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.
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.
[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.