Re: Relative path in game? SOLVED

[steve <sjbaker1@xxxxxxxxxxx>]

Ingo Ruhnke wrote:
> On Sat, Oct 14, 2006 at 12:40:38AM +0200, Frédéric Lopez wrote:
>
> > All the commercial and free games I have installed do follow the FHS, 
> > putting their data in /usr/local/games/<name of the game>, their 
> > binaries in /usr/local/bin/ and their user files in 
> > ~/.<name_of_the_game>. I fail to see why you do think this way of doing 
> > things is outdated.
>
> The FHS helps you nothing to find the location of your data files, it
> simply forces you to use a specific directry. If the user wants to install
> the game in his home directory, under /opt/, somewhere else (they a
> directory that is exported via NFS) or maybe in a different named 
> directory because he has two different version installed at once the 
> FHS becomes totally unusable and you have to resort to other magic
> to find out where the data is. In short hard-compiled paths make you
> binary non-relocatable. Binreloc fixes this problem in an elegant way,
> using an installer application that writes the install path into
> some config file is of course another way to make it work, but I prefer
> binaries that I can simply untar and run and those only work reliable
> if you find the location of the binary.

I agree that FHS and other 'standards' don't help at all here.  I can
tell you from painful experience that end users will want to put your
game where they want to put it - and to hell with any standards.

The reasons are many - but here are some:

1) "I don't have any space left on that partition"
2) "My IT department have write-protected that directory"
3) "That directory is on an NFS partition and our network is
   too slow to run your game from it"
4) "I want to run it on CD-ROM so it doesn't consume disk space"
5) "I want to put it there - that's how I organise my system and
   it's none of your business how I set up MY computer"
6) "I want to put it on a shared partition so I can use it on any
    computer"
7) "I want to put it on a live CD distribution"
8) "I'm putting together the XXX Linux distro and our policy is not
   to put games there"  (where 'XXX' is both RedHat and SuSE on
   different occasions).

So you truly cannot dictate to your end users where they must put
the files...forget it.  So FHS (and earlier standards) simply don't
help here.  Whilst we can ENCOURAGE people to put games in the right
place - we cannot force them to do so.

Furthermore, while I (or someone else) is developing the game, we may
want half a dozen different versions on the same computer - you don't
want them picking up data files from each other's directories!

So - IMHO - keep all of your game assets (sources, binaries, libraries,
scripts, shaders, data files...everything) in a single directory tree
named something pretty unique.

When the user installs the game, provide an installer script that asks
him where he'd like to put the game - with the default being the 'right'
place according to FHS.

  Where would you like the game to be installed [/usr/local/mygame] ?

Now your installer knows the place where it's installed.  It can write
a simple shell script that says:

   #!/bin/sh
   export MYGAME_DIRECTORY="...whatever the user entered..."
   ${MYGAME_DIRECTORY}/mygame

That script should be written to someplace on the users' PATH that we
have write access to.  Make a list of likely places (/bin, /usr/bin,
/usr/local/bin, /usr/share/bin, etc) - note the ones the script
doesn't have write access to - then offer those that survive as default
choices to the user.

  Where would you like the 'mygame' startup script to be placed?
  1) /bin/mygame  (requires that you re-run this installer as 'root')
  2) /usr/bin/mygame
  3) /usr/local/bin/mygame
  4) ~/bin/mygame
  5) somewhere else
  Please enter a number 1 through 5 :

Issue a warning if the path he chooses is not on his $PATH right now.

Once that is done, the user runs the script to start the game, and
the game itself can note where the current working directory is - and
then do a 'chdir(getenv("MYGAME_DIRECTORY"));' and have all of it's
files precisely where they were during development.  It's worth having
it say that if the 'MYGAME_DIRECTORY' shell variable has not been set
then set it to "."

This approach has some major advantages:

1) If the game runs at all - it has all of the files it needs for sure.
2) You can have the startup script parse command line options like
   'uninstall' - which only has to do a simple recursive delete of
   $MYGAME_DIRECTORY - then delete itself.  If it can't find itself
   then you only left a 100 byte script lying around which is not the
   end of the world.
3) The startup script can also check that the game is truly installed
   in $MYGAME_DIRECTORY and provide intelligent diagnostics if it's
   not.
4) The instructions for developers are now very simple - just run
   './mygame' from the development directory.  Since 'MYGAME_DIRECTORY'
   will be unset, the game executable will default it to "." and all
   will be well - no matter how many versions of the game are installed.
5) It's very easy to have the installer do fancy things like make sure
   that old versions of the game are correctly cleaned up by trying to
   run 'mygame uninstall' before doing the installation.