Now as we made clear where all the files should go. The question is how to install the game? The game can come into source or binary form, can use just a few MB's or thousand of them. If the game is small it is the best to just use the standard ways of installing software under Linux, which are tar.gz files containing the source, or for binary distributions use packages files like RPM or debian packages, you can also use tar.gz binary distribution, but then they would not check if the correct libraries are installed, that causes lots of trouble for example with mixed libc5, glibc2.0 and glibc2.1 installation. So if you are not having much time while developing its better to not start creating tar.gz binaries and instead make the source as easy compile able as possible.
The source package should always be a tar.gz file which installs in a single directory tree and is after unpacking installable with a:
$ ./configure $ make $ make install
This way of installation is the standard way for most software and is very common for the most users, so it will cause the lessest trouble. This way can be easily obtained with autoconf and automake. If you are using a non standard way of doing installations, you should change it to the lock and feel of the above or even better switch over to automake and autoconf, since it will give you all that and also stuff like automatic distribution packaging and library checking, etc.
The task of package creation is more or less complex. You can probably get some simple packages to work for your distribution, but maintaining different packages for different distribution, which you don't have, is probably a bit hard, since you can't test them easily. It is a very good idea to find somebody who will packaging the stuff for you and test it, this will save you a lot of work and ensure that the package will work.
If your game is very big, so that it is distributed on CD, there could be some trouble. Packages of your program will be impossible, since you would have to distribute three or more different packages (.rpm, .deb, tar.gz), that will probably blowup the CD space. So the easiest solution is to just distribute a tar.gz file with a installation script and documentation on how to do the installation manually. The install script should ask what the user wants to install and where to install it, it should also create a install log, so that the game find its datafiles after installation without user interactions. The script should probably perform the following task:
If you release a new version of your package it is a good idea to also make a patch or update available, so that the user is not forced to download the complete game again.
If you changed only the source, you can create a patch
file, with diff. The patch file can be applied using
patch. For more informations see
info patch and
info diff. The problem is that diff/patch can't
handle binary files, so it is impossible to use them with
alone if you changed some datafiles or changed the
If you changed the directory layout or added some new files you will have to use a hand build update script. The script should first check for the games install directory and than start patching and updating.
If you distributed your game as RPM you might ask, but how to patch that? A way to do that was mentioned by Pierre Phaneuf <email@example.com>. You could create an update script and a Source RPM, the script will than catch all the installed datafiles from their directories, build a new RPM from the Source RPM using the datafiles and then install the new RPM. But aware that this is only theoretical and was never been tested in practice.