[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Article] Linux Games Install and Directory Guide (update)



Hi,
I have updated my  Installation and Directory Guide (anyone know a
better name?). The sgml source along with *.dvi, *.tex, *.html files
is available at: 
           
            http://privat.schlund.de/g/grumbel/misc/

I have not checked the spelling yet, so be warned ;-)
Critic and corrections are *very* welcom! I have *no* real experience
with some parts of this article (like CDRom installation, install
scripts, etc.), so if someone ever tried something like that, please
comment. I need also some infos on what infos I should add.

I have attached the txt version below:
-------------------------------- snip ---------------------------------
  Linux Games Install And Directory Guide
  Ingo Ruhnke, grumbel@gmx.de

  v0.2, Begin: Tue Aug 17 23:11:43 1999, LastUpdate: Sun Aug
  22 15:23:43 1999

  This document gives an overview how to install games under Linux and
  how to put the files in the correct directories according to the FHS.

  ______________________________________________________________________

  Table of Contents


  1. What is different between DOS/Windows and Linux?

  2. The directories and how to handle them

     2.1 The different between
     2.2 Which files are needed by a game?
     2.3 Where to put the files?
        2.3.1 Binaries
        2.3.2 Static Datafiles
        2.3.3 Shared libarys
        2.3.4 Save games
        2.3.5 Hiscores
        2.3.6 Config files
     2.4 How to find the files and how to make the game relocatable?
     2.5 How to allow extra levels or similar stuff?
     2.6 How to handle data from a cd-rom?

  3. How to install the game?

     3.1 How to install the source?
     3.2 How create packages?
     3.3 How to handle CD-Rom installation?
     3.4 How to create update or patch distribution?
        3.4.1 Using diff/patch
        3.4.2 Using hand build update scripts
        3.4.3 Patchig a RPM

  4. Some tips about of to make that with automake/autoconf?

     4.1 Tweaking the path
     4.2 How to find out where the package is installed?


  ______________________________________________________________________

  1.

  What is different between DOS/Windows and Linux?

  DOS and Windows use a very simple way of handling the directories. If
  you install a programm all data goes to a single directory. The
  programm don't has to worry about were to place the files, it can
  handle that as it likes to do.

  Under Linux the thing looks a bit different, the complete file system
  is only one big tree, there is no seperation into different drives and
  the data of a programm is mostly spread over this filesystem tree.
  There is a standard document, the Filesystem Hierarchy Standard, which
  descripes where the files belong, most games which I know do not
  follow this standard or following only some of its rules. For standard
  software documentation goes to /usr/doc/, binaries go to /usr/bin/,
  data files goes to /usr/share and so on. So the installation is a bit
  difficult, since the data should go to it correct directory. This as
  different reasons, one of them is for example that you should be able
  to mount the share/ directory remout over a network, since it should
  only contain system indepented files, while bin/ for example contains
  system depended binaries which can be shared over different machine
  types. For games there are some special directories reserved, they
  differ a bit from the standard directories, but not much. A lot of
  games at the moment don't use that directories, this document should
  give a introduction on how to handle all that directories and how to
  avoid throuble.


  2.

  The directories and how to handle them

  2.1.  /usr/local .

  The different between /usr/  and

  Before I start with some more detailed description, there is one thing
  you should know. There is a directory /usr and there is a directory
  /usr/local, they contain both the same subdirectories, but the
  different is that all stuff under /usr is handled by the distributions
  pakage 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 themself
  into /usr. In the following text I will refer only to /usr, because
  things under /usr/local are the same just in another start diretory.


  2.2.

  Which files are needed by a game?

  So before we a going to install a game we first have to thing 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:


    binarys (or executables)

    graphics

    musics

    sounds

    packed datafiles

    levelfiles

    shared libaries

    script files

    save games

    hiscore files

    config files

    etc.


  2.3.

  Where to put the files?

  2.3.1.

  Binaries

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


  2.3.2.

  Static Datafiles

  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 seperate the diretory
  any further, but I recommon it, since it will ensure that you will not
  end up in chaos, if the project groves.


  2.3.3.

  Shared libarys

  Some games use shared libarys which are linked at run time, this
  allows the game much more flexibility, because levels and enemys 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 libaries should also placed under
  /usr/share/, but that is not correct. Since /usr/share/ is only for
  architecture independent files and shared librarys are not
  architecture independent, they depend on a specific type of machine
  architecture. So they should be placed under /usr/lib/games/$GAME/.


  2.3.4.

  Save games

  A lot of games offer the posibility 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 normaly 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
  seperated into some subdirs like save/ and demo/.


  2.3.5.

  Hiscores

  Hiscores are similar to save games, but they are not eqal. The
  different is that save games or mostly interesting for personal use,
  while hiscores are interessting 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 shoud 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


  2.3.6.

  Config files

  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, but it will prevent chaos in the future. 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. Then the game will allways know where it was installed. The
  problems come when you are trying to install a binary. If the game is
  packed in a debian or RPM package, then the package maintainer should
  have 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 should 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.  In a binary the path is hard coded into the binary, so
  what to do? 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.


  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
  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 or in $HOME, without tweaking the
  path.

  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?

  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.
  Overwriding the defaults should allways be possible using a command-
  line option or a config 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 which could improve the speed a bit. 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 possiblity 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 throuble when the
  cdrom is mounted to another directory or the computer as multible
  cdrom drives.


  3.

  How to install the game?

  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 libs are installed, that causes lots of throuble for
  example with mixed libc5, glibc2.0 and glibc2.1 installation. So if
  you are not having much time its better to not start creating tar.gz
  binaries and instead make the source as easy compileable as possible.




  3.1.

  How to install the source?

  The source package should allway be a tar.gz file which installes 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 throuble.
  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 libary checking, etc.


  3.2.

  How create packages?

  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,
  so 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.


  3.3.

  How to handle CD-Rom installation?

  If your game is very big, so that it is distributed on CD, there could
  be some throuble. 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 config file, so that the game find
  its datafiles after installation without user interactions. The script
  should probably perform the following task:


    Ask what to install (videos, level data, etc.)

    Ask where to install (/opt, /usr, /usr/local, etc.)

    Install the data

    Make sure that the game will find its data (create a config script
     or tell the user which enviroment varibales he has to set)



  3.4.

  How to create update or patch distribution?

  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.


  3.4.1.

  Using diff/patch

  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 datafiles.


  3.4.2.

  Using hand build update scripts

  If you changed the directory layout or added some new files you will
  have to use a hand build update script. I have never done that, so I
  can't give you an advice.


  3.4.3.

  Patchig a RPM

  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
  <pp@ludusdesign.com>. You can create an update scipt and a which a
  Source RPM, the script will than catch all the installed datafiles
  from theire directories, build a new RPM from the SourceRPM using the
  datafiles, then install the new RPM.



  4.

  Some tips about of to make that with automake/autoconf?

  4.1.

  Tweaking the path

  The problem with automake, which I really recomment to use, is that it
  installed the files at default in the normal places, thats perfectly
  ok, but since games are a bit different there is the need to tweak the
  pathnames a bit. That can be done by placing the following in the
  Makefile.am's



              # Tweaking the `datadir' to install the files in the correct location
              pkgdatadir = $(datadir)/games/@PACKAGE@







  4.2.

  How to find out where the package is installed?

  If you are using automake/autoconf the user has the choice to override
  the default prefix, which is /usr/local. So the question is how to I
  get the install directory? Therefore we have to hardcode the path into
  the binary, but how to accompilsh that? The problem is that we need to
  expand the variable $prefix to the full pathname, else we would end up
  with a useless string like "$prefix/". Place the following in the file
  acinclude.m4:



              AC_DEFUN(MY_EXPAND_DIR, [
                $1=$2
                $1=`(
                     test "x$prefix" = xNONE && prefix="$ac_default_prefix"
                     test "x$exec_prefix" = xNONE && exec_prefix="${prefix}"
                     eval echo \""[$]$1"\"
                    )`
              ])





  And the following into configure.in:



              MY_EXPAND_DIR(game_datadir, "$datadir/games/$PACKAGE")
              AC_DEFINE_UNQUOTED( GAME_DATADIR, "$game_datadir")





  This will create a macro called GAME_DATADIR, which will expand into
  the path where your game data resist (i.e. /usr/share/games/pingus).
  For example if the game is installed into /usr/local GAME_DATADIR will
  expand to /usr/local/share/GAME/, when you need other data then the
  one that resist in share/$GAME you can also use "${prefix}" in the
  example.

-------------------------------- snip ---------------------------------

-- 
                                  http://dark.x.dtu.dk/~grumbel/pingus/ | 
Ingo Ruhnke <grumbel@gmx.de>             http://home.pages.de/~grumbel/ |
------------------------------------------------------------------------+