filesystem hierarchy standard for game developers
Ray
This is my interpretation of that document as it pertains to games,
which may or may not be the same as others' interpretation. If I've
made any serious mistakes, please point them out.
This is strictly about the Unix filesystem hierarchy standard, which
is (all or mostly) shared by Linux and BSD. Other systems may have
different standards, but I'll leave documenting them to people who
care about those systems.
There are three installation scenarios we care about in installing
games: User-specific, local, and standard.
User-specific installation is installation of a game by someone
who doesn't have root priveleges on the machine. This puts all
files in that user's home directory and owned by that user. If
the user's account (and home directory) is deleted, the game is
uninstalled. The FHS imposes no internal structure on a user-
specific installation; a game developer may structure it however
he or she likes. If you support user-specific installation,
then your installer should do it if it detects that it is unable
to get the privileges to write in the directories it would use
for a standard installation. User-specific installations are
often favored by developers who want a personal copy of the game
and its files to scribble on.
Local installation is installation of a game by hand, by the
local site administrator. Generally it is used when a standard
installation has been done but the site admin wants the local
machine (or the local network) to run a version of the game
different from the standard installation. This can be because
the game had to be changed to fit the local OS conventions or
local censorship policy, or because they don't want a tournament
to be interrupted by an automated package update, or because
they are actively modifying the game and don't want their
experimentation to affect the standard installation, etc. A
local installation installs its files where the system will
find them before it finds the files of the standard installation.
A legal game installer never does a local installation by
default: 'local' directories are reserved specifically for the
use of the site administrators. You may include an automated
way to make a local installation, but it must never be called
other than by the explicit and intentional command of a local
site administrator. In particular, ordinary package
installations, upgrades, downgrades, or removals must not affect
a local installation.
A standard installation is a game installed in a standard way -
typically by root in the course of updating or installing a
standard package, without any special effort.
I'm going to talk about a game named 'gargoyle' as an example.
Whenever you see that word in one of the directory or filenames
mentioned below, make an appropriate substitution for your game.
Where the FHS specifies a directory used only by a single game,
it doesn't specify the layout or filenames within the directory.
Thus, whenever this document talks about a set of files being
in a particular directory, you're allowed to name them anything
and lay them out however you like within that directory.
game binary:
Is the file /usr/games/gargoyle in a standard installation.
Is the file /usr/local/games/gargoyle in a local installation.
game man page:
Is the file /usr/share/man/man6/gargoyle.6 in a standard installation.
(note, the filename may be gargoyle.6.gz or something rather than
gargoyle.6 depending on man configuration and page storage format)
is the file /usr/local/man/man6/gargoyle.6 in a local installation.
(note, the filename may be gargoyle.6.gz rather than gargoyle.6, as
above)
note: /usr/local/share/man/ is the same directory as /usr/local/man
(one or the other is a symlink - which one may vary from system to
system).
Files of architecture-independent static game data: This is data that
does not change as a result of playing the game. It specifically
*DOES NOT* include high score tables, savefiles, logs, etc. If your
game reads script files that determine game behavior or probabilities,
etc, when initializing, those script files are included. If your game
displays help text that's stored in files, the files belong here.
Go in a directory named /usr/share/games/gargoyle in a standard
installation.
Go in a directory named /usr/local/share/games/gargoyle in a local
installation.
Note: Under ordinary circumstances, attempts to write these locations
usually fail. The game or user running it is not likely to be allowed
to write in these directories, and even if they are, the partition on
which they reside is likely to be mounted readonly in server locations.
Note that /usr/share (and /usr/local/share) and its subdirectories
including the static game data and man pages may be on a drive mounted
by several different machines of different architectures which all run
the same version of the OS and "share" the installation data. If you
have data that makes sense on an i386 machine and doesn't make sense
on a SPARC machine, don't put it here.
Source code: Note that most standard game installers do not include
source code - usually it is packaged separately in another installer,
and sometimes it is not provided by the developer.
Goes in a directory named /usr/src/gargoyle in a standard
installation.
Goes in a directory named /usr/local/src/gargoyle in a local
installation.
Modifiable files including high score tables, game play logs,
savefiles, etc ...
Go in a directory named /var/games/gargoyle in a standard
installation.
Go in a directory named /var/local/games/gargoyle in a local
installation.
Configuration files: Site-wide "default" configuration file, if
singular, is the file /etc/gargoyle in both standard and local
installations.
Site-wide "default" configuration files, if there is more than one
file, all go in a directory named /etc/gargoyle in both standard and
local installations.
A per-player config file, if there's only one per player, is the file
.gargoyle in the user's home directory.
If there is more than one per-player config file, then all of them go
into a directory named '.gargoyle' in each player's home directory.
Note that per-player configuration files should not be created by the
installer. They should only be created when the player, having
actually invoked the game, makes a configuration change that differs
from the site-wide or default configuration. If non-players, or
players whose configuration is identical to the default or site-wide
configuration, have their own configuration files, it wastes disk
space.
Note that users' home directories are usually in /home/$username, but
the setup is site-specific, and some users (usually root at least)
don't use /home anyway. So don't rely on the directory named /home.
Use getenv("HOME") or getpwuid(geteuid())->pw_dir or whatever
equivalent you have on your system or in the libraries of your
preferred language to find the user's home directory. 999 times out
of a thousand it'll be in /home, but you never know.
Hope This Helps,
Bear
Björn Ritzl
> Based on FHS 2.3, which is online at http://www.pathname.com/fhs/ .
>
> This is my interpretation of that document as it pertains to games,
> which may or may not be the same as others' interpretation. If I've
> made any serious mistakes, please point them out.
<snip thorough research and description>
> Hope This Helps,
>
> Bear
>
Wow, Roguebasin this one Ray! I'm sure this would be of use to a lot of
roguelike developers.
/Bj�rn
Alex
> A legal game installer never does a local installation by
> default: 'local' directories are reserved specifically for the
> use of the site administrators. You may include an automated
> way to make a local installation, but it must never be called
> other than by the explicit and intentional command of a local
> site administrator. In particular, ordinary package
> installations, upgrades, downgrades, or removals must not affect
> a local installation.
I'm not sure what you mean with "legal game installer", but I think my
interpretation of the FHS is quite a bit different in this point. The
/usr hierarchy belongs to the "system", i.e. either the BSD variant or
the Linux distribution of your choice. Only the official software
management tools for your system, e.g. apt-get for Debian, yum for
Fedora or the ports system for FreeBSD, should install software there.
On the other hand, /usr/local is where the the admin can install
software that is not part of the system's official distribution. The
reason for the distinction, as I understand it, is that the system
provides for easy installation, upgrade and removal of software that is
in /usr, and manual installations there by the administrator might
interfere with the system's software management in undesirable ways.
Concerning the "legal game installer", I can think of four meanings for
that term:
(1) A software package intended for the official distribution of a BSD
variant or a Linux distribution, e.g. a .deb file that is distributed
through Debian. This will probably install into /usr, but such packages
are created by official maintainers who should know best where to place
their files.
(2) An unofficial software package for some software management tool.
Like (1), but not officially distributed with the system, e.g. a .deb
file that can be downloaded from the game's homepage and then installed
with dpkg. I'm not quite sure where this should be installed, but I
think I wouldn't mind such a package installing files into /usr.
(3) A source tarball, including a build system that can also install the
software, e.g. a project using automake. Since this software is built
and installed manually by the local admin, it is the very definition of
software that should go into /usr/local. In fact, /usr/local is also the
default prefix for automake (used e.g. in "./configure && make && make
install")
(4) Some form of executable installer. Since the installer is downloaded
and installed manually by the administrator, this too is software that
should not go into /usr. If it's a binary distribution that doesn't come
with source code, then it should probably not even install into
/usr/local but into /opt by default.
Finally, a note on user-specific installation. While the FHS says
nothing about the structure of home directories, there's something
called the "XDG Base Directory Specification" on freedesktop.org:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
The specification looks a bit rough and unfinished, but quite a few
desktop applications on my machine seem to use it, so it may be worth a
look for developers of software that should integrate into a desktop
environment.
Ray
> Ray wrote:
>> A legal game installer never does a local installation by
>> default: 'local' directories are reserved specifically for the
>> use of the site administrators....
> I think my
> interpretation of the FHS is quite a bit different in this point. The
> /usr hierarchy belongs to the "system", i.e. either the BSD variant or
> the Linux distribution of your choice. Only the official software
> management tools for your system, e.g. apt-get for Debian, yum for
> Fedora or the ports system for FreeBSD, should install software there.
Okay, I'll admit I'm not entirely sure on this point; I think it is clear
though that an "ordinary" installer in a linux distro (deb package or
whatever) should not use any of the "local" directories.
> On the other hand, /usr/local is where the the admin can install
> software that is not part of the system's official distribution. The
> reason for the distinction, as I understand it, is that the system
> provides for easy installation, upgrade and removal of software that is
> in /usr, and manual installations there by the administrator might
> interfere with the system's software management in undesirable ways.
True, but it's worse than that; automated package management tools
can also affect the admin-installed software in undesirable ways.
> Finally, a note on user-specific installation. While the FHS says
> nothing about the structure of home directories, there's something
> called the "XDG Base Directory Specification" on freedesktop.org:
>
> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
>
> The specification looks a bit rough and unfinished, but quite a few
> desktop applications on my machine seem to use it, so it may be worth a
> look for developers of software that should integrate into a desktop
> environment.
It looks like it would only be applicable to Xwindows applications,
not to all games.
Bear
Paul Donnelly
> Alex wrote:
>
>> Ray wrote:
>>> A legal game installer never does a local installation by
>>> default: 'local' directories are reserved specifically for the
>>> use of the site administrators....
>
>> I think my
>> interpretation of the FHS is quite a bit different in this point. The
>> /usr hierarchy belongs to the "system", i.e. either the BSD variant or
>> the Linux distribution of your choice. Only the official software
>> management tools for your system, e.g. apt-get for Debian, yum for
>> Fedora or the ports system for FreeBSD, should install software there.
>
> Okay, I'll admit I'm not entirely sure on this point; I think it is clear
> though that an "ordinary" installer in a linux distro (deb package or
> whatever) should not use any of the "local" directories.
I agree.
>> On the other hand, /usr/local is where the the admin can install
>> software that is not part of the system's official distribution. The
>> reason for the distinction, as I understand it, is that the system
>> provides for easy installation, upgrade and removal of software that is
>> in /usr, and manual installations there by the administrator might
>> interfere with the system's software management in undesirable ways.
>
> True, but it's worse than that; automated package management tools
> can also affect the admin-installed software in undesirable ways.
Isn't it the admin's responsibility to not screw things with
incompatible duplicate programs? Installing to /usr/local instead of
making a package is pretty sloppy anyway (assuming a system with a
package manager).
>> Finally, a note on user-specific installation. While the FHS says
>> nothing about the structure of home directories, there's something
>> called the "XDG Base Directory Specification" on freedesktop.org:
>>
>> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
>>
>> The specification looks a bit rough and unfinished, but quite a few
>> desktop applications on my machine seem to use it, so it may be worth a
>> look for developers of software that should integrate into a desktop
>> environment.
>
> It looks like it would only be applicable to Xwindows applications,
> not to all games.
In what way?
Gelatinous Mutant Coconut
game came in" approach, personally. It's really nice when I can just
unzip a download, open the file and double-click on an executable
right away. As for games distributed in source form, a simple makefile
that just produces an executable seem sufficient; users are generally
smart enough to know how put the executable where they want it and
make shortcuts to the file if they so desire.
Putting a lot of time into an game's installer is, in the vast
majority of cases, not going to make the game more fun.
Ray
> Ray <be...@sonic.net> writes:
>> It looks like it would only be applicable to Xwindows applications,
>> not to all games.
> In what way?
It's about Xwindows resources and Xwindows desktop management. I can't
find a single thing not Xwindows-related that this says anything about.
Bear
Paul Donnelly
It's describing a set of locations for files. I don't see any way that
this particular section is related to the X Window System. While
freedesktop.org is overall concerned with standards for X desktop
environments, this section is very applicable to any program.
Gerry Quinn
donn...@sbcglobal.net says...
This thread makes me think "Thank you, Bill Gates". MS have sometimes
trie to make rules about what you are supposed to do with regard to
installing stuff etc., but developers ignore them and they basically
accept that.
- Gerry Quinn
Alex
> This thread makes me think "Thank you, Bill Gates". MS have sometimes
> trie to make rules about what you are supposed to do with regard to
> installing stuff etc., but developers ignore them and they basically
> accept that.
Actually, I think the situation is quite similar on Windows and on
Linux. Both have some sort of convention of where files should be
installed, and neither really keep software installers from doing things
differently.
Having and using these conventions is a good thing IMO. The days where I
knew the name and purpose of every file on my system are long gone, so
at least having software and data in well-known locations helps a lot.
Some software packages may have good reasons not to follow the
conventions, and that is ok too. Unfortunately, I think that with most
software that installs into unusual locations, the reason is just the
developer's ignorance.
Paul Donnelly
Not having to deal with developers like that is one of the nicer things
about running Linux.
Sir_Lewk
> This thread makes me think "Thank you, Bill Gates". MS have sometimes
> trie to make rules about what you are supposed to do with regard to
> installing stuff etc., but developers ignore them and they basically
> accept that.
Developers not listening to Microsoft's advice concerning installers
is the main reason why getting people to use non-privileged accounts
in windows has been so hard for Microsoft to do. It is _highly_
suggested that any windows developer do the responsible thing follow
Microsoft's advice, and stop programming like it is still 1995.
This is one of the things that makes me think "Thank you, Bell Labs" ;)
Pender
<gelatinousmutantcoco...@gmail.com> wrote:
> Putting a lot of time into an game's installer is, in the vast
> majority of cases, not going to make the game more fun.
Yeah, this was my thought too. With my game Brogue, you just drag it
from the download folder to the Applications folder and play -- and
the first step isn't even necessary. It stores the high scores and
window size data in the user-specific Preferences file per the OS X
standard. I don't understand why a separate installer app should ever
be necessary for a roguelike game. Even if you have a number of
ancillary data files apart from the application as in Angband,
installation can consist of dragging a folder instead of a single file.
sreservoir
except, of course, that some people aren't playing gui roguelikes.
--
"Six by nine. Forty two."
"That's it. That's all there is."
"I always thought something was fundamentally wrong with the universe"
Ido Yehieli
>
> I don't understand why a separate installer app should ever
> be necessary for a roguelike game. Even if you have a number of
> ancillary data files apart from the application as in Angband,
> installation can consist of dragging a folder instead of a single file.
Expectation on the mac are not the same as expectations on windows (or
linux). Windows users for the most part expect to get an executable
file, run it, and have it do all the copying while putting a shortcut in
the start menu or on the desktop.
You can argue whether this is good or bad, but this is what most windows
users expect regardless of our opinion. For the mac I would just wrap
my game as a .dmg file and be over with it, since this is more or less
what mac users expect.
-Ido.
Krice
> Windows users for the most part expect to get an executable
> file, run it, and have it do all the copying while putting a
> shortcut in the start menu or on the desktop.
I don't expect or want an installer for a roguelike, and
many roguelikes don't use installers. If someone does want
an installer I would suggest to play something else than
roguelikes.
Ido Yehieli
Most != all.
Normally only power users prefer a zip file to an installer on windows.
-Ido.
Timo Pietilä
Usually this is the case, but with roguelikes I'm not so sure.
However for angband msi-installer file would be rather easy to do with
all of its good features.
Only problem is that savefile -directory needs to be accessible to
everyone, which is tiny security problem. Unless of course you separate
it from rest of the files and put it in users profile (where? In Local
Settings\Application data? or just Application Data? Or in My
Documents?). Also you might want to be able to edit edit-files, which
contains monsters, vaults, items etc.
Of course you could install it as per user-installation in my documents
instead of program files.
What way to prefer?
Using zip is quite straightforward in this.
Timo Pietil�
Jeff Lait
Users prefer a .exe instead of an installer or a .zip. I always hate
adding a whole extra "install" set of screens and stuff to go through.
Not to mention the ambiguity about how to delete it.
That said, what users really want is just to play it in the browser
and avoid the whole download stage entirely.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Gerry Quinn
b73f6f...@b2g2000yqi.googlegroups.com>, sir...@gmail.com says...
> On Dec 14, 9:07 am, Gerry Quinn <ger...@indigo.ie> wrote:
> > This thread makes me think "Thank you, Bill Gates". MS have sometimes
> > trie to make rules about what you are supposed to do with regard to
> > installing stuff etc., but developers ignore them and they basically
> > accept that.
>
> Developers not listening to Microsoft's advice concerning installers
> is the main reason why getting people to use non-privileged accounts
> in windows has been so hard for Microsoft to do. It is _highly_
> suggested that any windows developer do the responsible thing follow
> Microsoft's advice, and stop programming like it is still 1995.
Non-privileged accounts are an inconvenience to most PC users, so most
don't bother. But anyway, Windows installers generally allow users to
install programs in whichever mode they want. They don't insist on you
doing it one way or another.
Zipped roguelikes are fine too.
- Gerry Quinn
Gerry Quinn
60505e...@m33g2000pri.googlegroups.com>, pende...@gmail.com
says...
I agree, a zipped folder is fine for Windows also, and it's trivial for
the user to make a desktop shortcut. I wouldn't do it with most games,
but roguelike players are used to zips and possibly even prefer them.
However, there are also several free and easy-to-use programs out there
for making standard Windows installers, if you want to go that route.
If you are doing something other than a roguelike, I would recommend it
- most Windows users do not want to be messing with zip files.
- Gerry Quinn
Gerry Quinn
> On 12/20/2009 5:16 PM, Pender wrote:
> > On Dec 13, 6:53 pm, Gelatinous Mutant Coconut
> > <gelatinousmutantcoco...@gmail.com> wrote:
> >
> >> Putting a lot of time into an game's installer is, in the vast
> >> majority of cases, not going to make the game more fun.
> >
> > Yeah, this was my thought too. With my game Brogue, you just drag it
> > from the download folder to the Applications folder and play -- and
> > the first step isn't even necessary. It stores the high scores and
> > window size data in the user-specific Preferences file per the OS X
> > standard. I don't understand why a separate installer app should ever
> > be necessary for a roguelike game. Even if you have a number of
> > ancillary data files apart from the application as in Angband,
> > installation can consist of dragging a folder instead of a single file.
>
> except, of course, that some people aren't playing gui roguelikes.
Surely everyone has a GUI OS by now though?
- Gerry Quinn
Gerry Quinn
26g2000yqo.googlegroups.com>, torespon...@hotmail.com says...
> On Dec 21, 6:05 am, Ido Yehieli <ido.yehi...@chello.at> wrote:
> > Normally only power users prefer a zip file to an installer on windows.
I think roguelike users do, but they are an exception.
> Users prefer a .exe instead of an installer or a .zip. I always hate
> adding a whole extra "install" set of screens and stuff to go through.
> Not to mention the ambiguity about how to delete it.
Most installers build an uninstaller automatically.
> That said, what users really want is just to play it in the browser
> and avoid the whole download stage entirely.
You can come close to that using a standard .exe installer - they can
transparently install it from the web site.
- Gerry Quinn
Gerry Quinn
timo.p...@helsinki.fi says...
I install it in C:\Games\RPG. None of this privilege or Program Files
nonsense for me. I edit what I want when I want. (But I take care to
avoid downloading software that does that.)
- Gerry Quinn
Sherm Pendley
> Expectation on the mac are not the same as expectations on windows (or
> linux). Windows users for the most part expect to get an executable
> file, run it, and have it do all the copying while putting a shortcut
> in the start menu or on the desktop.
>
> You can argue whether this is good or bad, but this is what most
> windows users expect regardless of our opinion. For the mac I would
> just wrap my game as a .dmg file and be over with it, since this is
> more or less what mac users expect.
Exactly. When in Rome, do as the Romans do.
sherm--
Krice
> That said, what users really want is just to play it in the browser
I never play browser based games.
Matt_S
roguelikes right on my desktop.
sreservoir
surely some people don't like their specific roguelike's gui?
Gelatinous Mutant Coconut
> On 12/21/2009 10:54 AM, Gerry Quinn wrote:
> >> On 12/20/2009 5:16 PM, Pender wrote:
> >>> installation can consist of dragging a folder instead of a single file.
> >> except, of course, that some people aren't playing gui roguelikes.
> > Surely everyone has a GUI OS by now though?
> surely some people don't like their specific roguelike's gui?
I don't understand this line of conversation; whether or not the
roguelike's GUI interface is used is completely orthogonal to whether
or not the game is distributed as a folder or executable with no
installer. It isn't any more difficult for a terminal user to 'mv' the
directory or binary than it is for the GUI user to drag the folder or
executable.
Seebs
> I don't understand this line of conversation; whether or not the
> roguelike's GUI interface is used is completely orthogonal to whether
> or not the game is distributed as a folder or executable with no
> installer. It isn't any more difficult for a terminal user to 'mv' the
> directory or binary than it is for the GUI user to drag the folder or
> executable.
Good point. I don't think I actually care whether it's an application or
a directory or whatever.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Billy Bissette
$27...@news.chello.at:
I prefer zip files, but I am a power user.
Not all uninstalls do a proper clean-up. Garbage is often left in
the registry. Directories can be left. I've managed to get into
weird "half-uninstalled" situations under previous OSs. I don't
really know what the installer is doing. Sometimes I know the
installer is doing something that I don't want it to do. Not all
installers work entirely as advertised. As machines and OSs progress,
some installers start to break down. I'd rather just dodge all the
issues with a compressed file and a drag-and-drop operation.
When I have the option between a zip file and an installer exe, I
tend to pick the zip file. If your program's only real benefit from
an installer is to eliminate the drag-and-drop process, then maybe
you should consider offering a zip in combination with an exe.
J�rgen Lerch
On Mon, 21 Dec 2009 07:03:18 -0800 (PST), Jeff Lait wrote:
> Users prefer a .exe instead of an installer or a .zip. I always hate
Yes, setup.exe. ;-]
> That said, what users really want is just to play it in the browser
> and avoid the whole download stage entirely.
As you said ,,I hate'': No, they don't. I want things on my
computer, not on some slow server that'll be unreachable when
I want to play.
Also, only those users will want a browser game who are able
to get DSL and/or flatrates.
Ad Astra!
JuL
--
jyn...@gmx.de / L'�tat, c'est toi. (Moi)
J�rgen ,,JuL'' Lerch /
Timo Pietilä
That's my point. There is no "official" way to do this. If you do it MS
way, you install it in Program Files and user settings etc. goes into
your profile. That's obviously not how Angband is designed to work.
I use external drive for my installations, so that I can play same game
in several different computers.
Timo Pietil�
The Wanderer
> On 21.12.2009 18:02, Gerry Quinn wrote:
>
>> In article<hgnlpg$9j2$1...@oravannahka.helsinki.fi>,
>> timo.p...@helsinki.fi says...
>>> Only problem is that savefile -directory needs to be accessible
>>> to everyone, which is tiny security problem. Unless of course you
>>> separate it from rest of the files and put it in users profile
>>> (where? In Local Settings\Application data? or just Application
>>> Data? Or in My Documents?). Also you might want to be able to
>>> edit edit-files, which contains monsters, vaults, items etc.
>>>
>>> Of course you could install it as per user-installation in my
>>> documents instead of program files.
>>
>> I install it in C:\Games\RPG. None of this privilege or Program
>> Files nonsense for me. I edit what I want when I want. (But I
>> take care to avoid downloading software that does that.)
>
> That's my point. There is no "official" way to do this. If you do it
> MS way, you install it in Program Files and user settings etc. goes
> into your profile. That's obviously not how Angband is designed to
> work.
It is with per-user settings, rather than global settings; "Program
Files" then becomes analogous to /usr, and "your profile" becomes
analogous to "your home directory". Unless I'm misunderstanding what you
mean by "user settings, etc."?
> I use external drive for my installations, so that I can play same
> game in several different computers.
And I install to multiple paths, completely self-contained, so that I
can have multiple versions installed in parallel without interfering
with one another (e.g. for testing out new development versions). That's
harder with Angband than it possibly should be, but easier than it would
be for almost any Windows program.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
Gerry Quinn
wand...@fastmail.fm says...
> And I install to multiple paths, completely self-contained, so that I
> can have multiple versions installed in parallel without interfering
> with one another (e.g. for testing out new development versions). That's
> harder with Angband than it possibly should be, but easier than it would
> be for almost any Windows program.
It's easy to do that on Windows.
The only issue you might have is with programs that use the Registry to
store data, which will obviously be the same for all versions. But
this data is usually things like user preferences rather than save
files etc.
- Gerry Quinn
Jeff Lait
> Saluton!
>
> On Mon, 21 Dec 2009 07:03:18 -0800 (PST), Jeff Lait wrote:
> > Users prefer a .exe instead of an installer or a .zip. I always hate
>
> Yes, setup.exe. ;-]
Ah, a .exe that matches by name the last 500 .exes I download and
likely has the same InstallShield icon. What is more frustrating, it
is a use-once .exe. The thing I download isn't the thing I use to run
the game in the future. It is just what I run the *first* time.
Installers make sense when you have something truly big to install or
complicated to install. Even then, sign me up for Steam or Impulse
that handles that crap in the background for me and only bothers me
when the game is ready to play.
But for roguelikes? I think we are fooling ourselves if we think
there is any complexity worth of "installation".
I don't need to "install" pictures I download from the web, why should
I install roguelikes?
I really like what Macs do with .dmg files. Something simple you can
just drag about as you wish, that internally contains whatever
installation crap is needed, providing one consistent launch point.
> > That said, what users really want is just to play it in the browser
> > and avoid the whole download stage entirely.
>
> As you said ,,I hate'': No, they don't. I want things on my
> computer, not on some slow server that'll be unreachable when
> I want to play.
>
> Also, only those users will want a browser game who are able
> to get DSL and/or flatrates.
It is not that users "want a browser game". They don't care about
"browser vs local". It is that they just want to be able to play the
game immediately after discovering it, without task switching out,
without agreeing to security compromises, etc. When they discover it
is a great game, they may want to be able to play it locally or when
not connected to the internet, and *then* they may want to get a local
version.
There is a lot of friction in the whole download process that shaves
off would-be players.
(This all said, for games where the player must commit a certain
amount of effort to "get" the game it is advantageous to have extra
friction on installation. This sunk cost makes them more likely to
continue to commit the resources to get to the point where the game is
fun.)
The Wanderer
> In article <kO-dnegEtoOLVq3W...@giganews.com>,
> wand...@fastmail.fm says...
>
>> And I install to multiple paths, completely self-contained, so that
>> I can have multiple versions installed in parallel without
>> interfering with one another (e.g. for testing out new development
>> versions). That's harder with Angband than it possibly should be,
>> but easier than it would be for almost any Windows program.
>
> It's easy to do that on Windows.
Not for most programs I've seen, at least not without hacking either the
installer or the actual program itself. (Not all installers even provide
the option to choose an install location, although the vast majority do
nowadays.)
> The only issue you might have is with programs that use the Registry
> to store data, which will obviously be the same for all versions.
That's one of the big problems, yes, particularly considering that
virtually all Windows-only programs (and even some ports of
non-Windows-only software) make use of the Registry. It also exacerbates
the others, in that frequently even "install wherever you please"
software will create Registry entries specifying its install location...
> But this data is usually things like user preferences rather than
> save files etc.
And when those are incompatible between versions, or when you want to
test out changes in one install without affecting others, it becomes a
problem.
It's certainly possible to do self-contained (and potentially parallel)
installs under Windows; the entire Portable Apps collection is based
around doing exactly that. It's just not practical, for most programs,
to do it without modification.
Gerry Quinn
@b32g2000yqd.googlegroups.com>, torespon...@hotmail.com says...
> On Dec 21, 11:30 pm, "Jürgen Lerch" <jyn...@gmx.de> wrote:
> > Saluton!
> >
> > On Mon, 21 Dec 2009 07:03:18 -0800 (PST), Jeff Lait wrote:
> > > Users prefer a .exe instead of an installer or a .zip. I always hate
> >
> > Yes, setup.exe. ;-]
>
> Ah, a .exe that matches by name the last 500 .exes I download and
> likely has the same InstallShield icon. What is more frustrating, it
> is a use-once .exe. The thing I download isn't the thing I use to run
> the game in the future. It is just what I run the *first* time.
Unless it's large, you can run it from the browser. Most of them have
a distinctive name anyway, in my experience.
Then to run the game, you click on the desktop shortcut. Nice and
simple!
> Installers make sense when you have something truly big to install or
> complicated to install. Even then, sign me up for Steam or Impulse
> that handles that crap in the background for me and only bothers me
> when the game is ready to play.
>
> But for roguelikes? I think we are fooling ourselves if we think
> there is any complexity worth of "installation".
>
> I don't need to "install" pictures I download from the web, why should
> I install roguelikes?
It's just a convenience for users. Granted roguelike users often like
zip files, but most users don't.
> It is not that users "want a browser game". They don't care about
> "browser vs local". It is that they just want to be able to play the
> game immediately after discovering it, without task switching out,
> without agreeing to security compromises, etc. When they discover it
> is a great game, they may want to be able to play it locally or when
> not connected to the internet, and *then* they may want to get a local
> version.
>
> There is a lot of friction in the whole download process that shaves
> off would-be players.
>
> (This all said, for games where the player must commit a certain
> amount of effort to "get" the game it is advantageous to have extra
> friction on installation. This sunk cost makes them more likely to
> continue to commit the resources to get to the point where the game is
> fun.)
Interesting point. Still, I think the standard Windows install process
is pretty straightforward for most people. In principle, it's click to
download the installer, click to run it, press Okay a couple of times,
and click on the desktop icon to play.
I don't like Steam, it forgets my password and then won't run software
offline. And you have to run some software from within it which is
annoying.
- Gerry Quinn
Gerry Quinn
wand...@fastmail.fm says...
> On 12/22/2009 09:14 AM, Gerry Quinn wrote:
>
> > In article <kO-dnegEtoOLVq3W...@giganews.com>,
> > wand...@fastmail.fm says...
> >
> >> And I install to multiple paths, completely self-contained, so that
> >> I can have multiple versions installed in parallel without
> >> interfering with one another (e.g. for testing out new development
> >> versions). That's harder with Angband than it possibly should be,
> >> but easier than it would be for almost any Windows program.
> >
> > It's easy to do that on Windows.
>
> Not for most programs I've seen, at least not without hacking either the
> installer or the actual program itself. (Not all installers even provide
> the option to choose an install location, although the vast majority do
> nowadays.)
I've rarely seen any that doesn't, and I don't see any need for hacking
anything. You can nearly always choose what directory you want to
install in. Screensavers are sometimes an exception.
> > The only issue you might have is with programs that use the Registry
> > to store data, which will obviously be the same for all versions.
>
> That's one of the big problems, yes, particularly considering that
> virtually all Windows-only programs (and even some ports of
> non-Windows-only software) make use of the Registry. It also exacerbates
> the others, in that frequently even "install wherever you please"
> software will create Registry entries specifying its install location...
True, but this is mostly so that patchers etc. can find the program.
Granted a few of them store local working directories etc. which is a
bit silly.
> > But this data is usually things like user preferences rather than
> > save files etc.
>
> And when those are incompatible between versions, or when you want to
> test out changes in one install without affecting others, it becomes a
> problem.
Yes, but these things are rarely incompatible, nor do you usually need
to change them.
> It's certainly possible to do self-contained (and potentially parallel)
> installs under Windows; the entire Portable Apps collection is based
> around doing exactly that. It's just not practical, for most programs,
> to do it without modification.
I will admit I rarely see the need for more than one copy of an app -
but I don't recall being balked often when I wanted to do it. For
example, a couple of weeks ago I installed the game Astral Masters in
an old and new version, and had no problems, despite it using a
standard installer.
- Gerry Quinn
Ido Yehieli
> I don't need to "install" pictures I download from the web, why should
> I install roguelikes?
>
Because unlike most pictures, a game is something you will access more
than once (hopefully). Unless the whole game is one exe (that is also
putting its save files in a directory in c:/user/ido/whatever) I rather
just have an installer that puts all the files away and just gives me a
single desktop shortcut & start menu entry (you can even skip the start
menu, almost never use it anymore).
> It is not that users "want a browser game". They don't care about
> "browser vs local". It is that they just want to be able to play the
> game immediately after discovering it, without task switching out,
> without agreeing to security compromises, etc.
Speaking of which, webrl (http://code.google.com/p/webrl/) still waits
for you to make good use of its "engine" :)
-Ido.
Magnate
> Based on FHS 2.3, which is online at http://www.pathname.com/fhs/ .
>
> This is my interpretation of that document as it pertains to games,
> which may or may not be the same as others' interpretation. If I've
> made any serious mistakes, please point them out.
It's unfortunate that you started this long thread shortly after I spent
quite a long time making the angband build system FHS-compliant. Please see
trac.rephial.org for the latest changes.
I am confident that we've now got it right:
- architecture-independent data goes in /usr/share/angband - this is the
lib/xtra stuff (sound a graphics), along with help/ and file/
- configuration data goes in /etc/angband - this is the edit/ and pref/
directories, which can be changed on a system-wide basis
- variable data goes in /var/games/angband or in ~/.angband/Angband,
depending on the build type (setgid or private dirs). This is the save and
score directories.
All these defaults can be overridden with options to configure. The data/
and bone/ directories are no longer created.
- the user/ directory is always ~/.angband/Angband on POSIX systems,
regardless of build type. This is where your dumps and local pref files end
up.
HTH,
CC
Magnate
Ooops. I missed the copy to rgrd. My comments apply only to Angband, of
course.
CC