Re: [AD] Data file directory

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> Under Linux, or Unix in general, it's not normal for applications to work 
> in that way.  Unless a binary's directory is in the search path, you must 
> specify the path even if it's the current directory (just `./'). Most 
> applications install their binaries into directories in the search path, 
> and have their data files in places like /usr[/local]/share/progname. Data 
> files that might need writing (high score tables, for example) go in 
> /var/... instead.

How well does that model apply to a typical computer game, though? Maybe 
this is just my DOS background speaking, but it seems to me that the Unix 
system is designed very much around the idea of a multiuser system where a 
few standard apps are made available by the sysadmin. Games are quite 
different to this because:

- You don't run them on multiuser machines. Graphics-intensive programs 
don't work well by remote, and in any case, no sane sysadmin will be 
allowing random accounts on a multiuser machine to run suid root games.

- Games are ephemeral. Rather than a handful of standard programs that are 
required to be available, most people install many of them at regular 
intervals, play them for a while, then get bored and want to reclaim that 
space. For this, it strikes me as quite important for the game to be 
self-contained so that it can easily be deleted when you want to do that.

So I think there is quite a strong case for Unix games that install into a 
subtree of your home directory (that's where I tend to put things while I'm 
playing around with them, and with a game, I delete it after that first 
period of playing around, rather than moving it to some more permenant 
location), or perhaps into a subtree of /usr/local/games (note that in a 
completely stock Red Hat 6.0 installation, /usr/games/fortune is not in the 
default path).

This is really up to the individual author, though, since everyone is liable 
to have different ideas.

> I thought it might be good to add a function to return a directory for 
> reading data files and possibly a different one for reading writable files 
> (subject to permissions still, of course).

I certainly don't mind that if people think it would be useful, but I doubt 
I would use it myself. I can't help feeling that this is a slightly odd 
thing to abstract, since it is trivial to do this yourself on Unix, while 
the problem simply doesn't arise on DOS or Windows. This means that the API 
function would essentially end up as a series of "return standard Unix 
directory name" calls, which would all just be defined to the program 
directory on other platforms: not perhaps a bad thing, but kind of pointless 
since it would just be another layer of code for people to learn, and to use 
this properly you would have to understand the difference between readonly 
data, per-user configs, etc, and if you understood that you might as well 
just use getenv("HOME"), "/var", etc, directly. It seems like a Unix person 
would not need these functions to be in Allegro at all, while a non Unix 
person wouldn't understand what they were or how/why to use them...

What do other people think about this? Would you have a use for such 
routines if they were included?


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."