gamedevlists-general

RE: [email] RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

True, but aside from the fact many games these days run into gigs of data,
what happens the first time you need to patch it or something similar? It
all gets messy very quickly.

My stance is that any game you ship should go out of its way to provide the
most user-friendly experience possible. From properly supporting things like
multi-monitor and alt+tab to implementing workarounds for known driver bugs
or issues. You can add as many things as you like into the requirements or
readme section, but insisting people are logged in as an admin or stating X
glitch is a driver issue and you should hassle an IHV to fix it isn't likely
to win you many fans.

It's also debatable just how savvy the average gamer or parent is with
computer matters, many people encountering a game which doesn't appear to
work will most likely simply take it back.

_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk








> -----Original Message-----
> From: Dan Thompson [mailto:da...@ar...] 
> Sent: 04 December 2003 21:37
> To: gam...@li...
> Subject: Re: [email] RE: [GD-General] A portable preferences library
> 
> 
> I'd say it stumbles, but doesn't *quite* fall down. Since 
> with Colin's scheme you can move games/apps around as 
> entities freely, you could (in theory), just move the whole 
> thing somewhere where little johhny *does* have access. 
> Actually the windows LUA compatibility stuff under XP does 
> this exact thing in the registry to anyone who tries to write 
> to HKLM - just copies it to HKCU and lets them do whatever 
> they want to it.
> 
> -Dan
> 
> ----- Original Message ----- 
> From: "Andrew Grant" <ag...@cl...>
> To: <gam...@li...>
> Sent: Thursday, December 04, 2003 1:14 PM
> Subject: [email] RE: [GD-General] A portable preferences library
> 
> 
> > >> I think multi-user systems is an antiquated concept.
> >
> > You're joking right?
> >
> > Also your scheme falls down the minute somebody without 
> write access 
> > to
> the
> > games folder attempts to play it. Something that's pretty 
> common these
> days
> > where Dad has to install the games little Johnny wants to 
> play on the
> family
> > PC. I'd be surprised if your approach makes it through QA of any 
> > publisher worth their salt.
> >
> > I agree the registry isn't the place to store the data, but 
> neither is 
> > the game install folder. Anything you need to save from 
> your game and 
> > that doesn't ask the user for a path should go into the whatever's 
> > returned by SHGetFolderLocation(.., CSIDL_APPDATA, ..);
> >
> >
> > _____________________________________
> > andrew grant | programmer | climax brighton ag...@cl... - 
> > www.climax.co.uk
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Colin Fahey [mailto:cp...@ea...]
> > > Sent: 04 December 2003 20:42
> > > To: gam...@li...
> > > Subject: Re: [GD-General] A portable preferences library
> > >
> > >
> > > 2003 December 4th
> > > Thursday
> > >
> > > I have used the following scheme for storing user 
> preferences for an 
> > > application:
> > >
> > > [1] A plain text file in the same directory as the executable,
> > >        with the extension *.txt rather than something else (like
> > >        *.ini);
> > >
> > > [2] The application, when launched, can determine the path of its
> > >       executable file, and thus the location of the corresponding
> > >       user preferences text file;
> > >
> > > [3] All aspects of reading the user preferences text file are
> > >       fault-tolerant; re-ordering, adding, removing fields will
> > >       have the least possible effect -- and field values are
> > >       similarly checked and clipped to sane limits.
> > >
> > > Security of the preferences is not an issue for my use of this 
> > > scheme.
> > >
> > > Benefits of this scheme:
> > >
> > >   [a] One can have many independent instances of the application
> > >         on a single machine, each with different preferences;
> > >
> > >   [b] The user can edit preferences if the application 
> malfunctions,
> > >         which is impossible in a scheme where the 
> application itself
> > >         is the only entity that can manipulate the 
> preferences file;
> > >
> > >   [c] Users can send or receive preferences files, or disucss
> > >         specific named settings, via e-mail or web pages;
> > >
> > >   [d] Settings in the preferences file can correspond to an
> > >         application's scripting system -- so that the preferences
> > >         file is nothing more than a batch of scripting commands
> > >         that can otherwise be entered at run-time in the
> > >         application itself (as in a console window for a video
> > >         game);
> > >
> > >   [e] Settings persist after clean install of operating system;
> > >
> > >   [f] Application and settings can be stored on a CD-ROM or
> > >         portable disk or flash-memory device, and one can
> > >         take it to someone else's computer and operate the
> > >         application without doing an "installation" or
> > >         polluting their computer with any files whatsoever;
> > >         (I bring my prototype applications to a friend's house
> > >         for demonstration on my keychain USB memory device,
> > >         and execute directly from the keychain!)
> > >
> > > Basically, I'm a strong believer of the settings following the 
> > > application around.  I think the old MacIntosh operating 
> system hid 
> > > a kind of directory system behind the application icon -- 
> with the 
> > > "resource fork" and "data fork", which was a pretty good idea 
> > > because it allowed data associated with a program to be 
> bound to the 
> > > program.  Thus, moving or copying the icon would assure that all 
> > > settings and data moved with it. It was a nice abstraction that 
> > > simplified the notion of "application" and reduced confusion when 
> > > moving it around.
> > >
> > > Maybe I'm hard-core, but I think everything an 
> application needs to 
> > > operate, short of the absolutely guaranteed resources of the 
> > > operating system, should be packaged with the application -- and 
> > > totally portable.  I should be able to run any application on 
> > > anyone's computer from my keychain memory device, without 
> adding any 
> > > files to their computer!
> > >
> > > I think multi-user systems is an antiquated concept.  But 
> if I must 
> > > support multiple users of a single application (as 
> opposed to each 
> > > user installing his or her own copy of the application), then 
> > > individual preferences files can be stored with the application. 
> > > "preferences_bob.txt", "preferences_joe.txt", etc.  Putting these 
> > > preferences anywhere else but with the application leads to
> > > potential pollution that might never go away.  Lots of
> > > irresponsible developers don't do a good job of
> > > un-installation -- or somehow the application disappears from
> > > the computer without un-install ever happening, leaving tons
> > > of scattered junk behind.
> > >
> > > I always thought the Windows registry was a disaster; it 
> encouraged 
> > > people to centralize critical information, and it has 
> been a source 
> > > of confusion and annoyance for users. Protecting the integrity of 
> > > this single trash heap is silly.
> > >
> > > Okay, I sympathize with the idea that putting everything in one 
> > > place somehow seems more organized.  I dislike the idea of things 
> > > being scattered around.  But I think it's perfectly good to put 
> > > things in self-contained bundles that do not rely on any 
> centralized 
> > > thing or on scattered things.  It's very clean.
> > >
> > > I think rather than pushing itself upon one's computer (like a 
> > > formal installation procedure), applications should be 
> passive and 
> > > the operating system should instead scan for applications upon
> > > boot-up. Thus, the "Start" menu is populated at boot time and
> > > is 100% in sync with available applications.  Applications
> > > can contain
> > > preferences about placement in the "Start" menu hierarchy,
> > > much like an application can propose its own icon.  The key
> > > is to eliminate the idea of "installation".
> > >
> > > Okay, some of these ideas are radical, but I just wanted 
> to share my 
> > > own thoughts about preferences files.
> > >
> > > --- Colin
> > >
> > > cp...@ea...
> > >
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program. Does 
> > > SourceForge.net help you be more productive?  Does it help you 
> > > create better code?  SHARE THE LOVE, and help us help YOU!  Click 
> > > Here: http://sourceforge.net/donate/ 
> > > _______________________________________________
> > > Gamedevlists-general mailing list 
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > Archives: 
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > >
> 
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program. Does 
> > SourceForge.net help you be more productive?  Does it help 
> you create 
> > better code?  SHARE THE LOVE, and help us help YOU!  Click Here: 
> > http://sourceforge.net/donate/ 
> > _______________________________________________
> > Gamedevlists-general mailing list 
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it 
> help you create better code?  SHARE THE LOVE, and help us 
> help YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Gamedevlists-general mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

RE: [email] RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

I was actually refering to having to patch multiple versions of a game, and
the fact many patch installers check the registry for the game location and
current version before doing anything.

I completely agree about the DLL and copy protection things though.



> -----Original Message-----
> From: Dan Thompson [mailto:da...@ar...] 
> Sent: 04 December 2003 22:18
> To: gam...@li...
> Subject: Re: [email] RE: [GD-General] A portable preferences library
> 
> 
> However, the analogy completely breaks down with patches, 
> because little johnny doesn't have write access in the 
> example. Since we are talking about preferences, anyway, for 
> this arguement I'll just say patching is done by admins. 
> Actually the copy on write method, while taking an obscene 
> amount of space, is the most transparent out of everything 
> I've seen, and even handles patching (yay). Of course it 
> would have to be OS level, then you get into arguements about 
> where it goes, etc.
> 
> Regarding the discussion about dlls and stuff in the windows 
> directory, I can't really convince myself its all MS's fault. 
> No one is forcing people to use the windows directory for 
> dlls, and if people would just use HKCU/Software/Company/Game 
> for keys, it wouldn't really be that bad. Its the <insert the 
> worst name you can call someone for your language here, and 
> make it plural> who write random stuff as a "copy protection" 
> who make life miserable.
> 
> Speaking of copy protection, I actually had to use the CD 
> crack in order to play Max Payne 2 - because the protection 
> meant to prevent such things kept the game from working! 
> Isn't that FUNNY!? *twitch*
> 
> -Dan
> 

Re: [email] RE: [GD-General] A portable preferences library

[Colin F. <cp...@ea...>]

2003 December 4th
Thursday

For what does one need administration rights?  To access the 
Registry and other protected directories!  Well, all of that is
unnecessary.

And as far as patching is concerned...  How do people acquire
patches today?  The application itself acquires its own patches!
I won't go in to the details of how an application can acquire
its own patches and somehow not interefere with the application
during the acquisition process, but I think it's pretty evident
that this is easy.

What huge binary "preference" might the user have?  Couldn't this
go in the application directory, too?

As far as my comment about multi-user systems being an antiquated
concept, I stand by it, but I need to qualify it.  I envision 
decentralizing all security and preferences; these things become
the responsibility of individual resources in cooperation with 
the operating system.  For example, you could set the "desktop"
to "Bob's" preferences, and access one of "Joe's" folders, and
launch a media player with "Jane's" preferences.  There is no
user logged in to the console, just a cloud of resources with 
various security mechanisms.

Right now it is possible for me to create a ZIP archive that is
protected by a password.  Even if a hacker compromises my computer
and gains access to the ZIP archive, it is pure junk to the hacker.
Just expand the idea to everything about the operating system and
all applications.

So a computer may have many users, but the idea of *being* a user
on a system and automatically gaining access to resources that 
you own is obsolete.  Too often the big gatekeeper (e.g., the 
Windows operating system) is compromised.  Security needs to 
be decentralized.

--- Colin

cp...@ea...

Re: [email] RE: [GD-General] A portable preferences library

[Dan T. <da...@ar...>]

> For what does one need administration rights?  To access the
> Registry and other protected directories!  Well, all of that is
> unnecessary.
Only HKLM and secured directories - which games shouldn't be dealing with
anyway. Same deal with any other OS. It'd be absurd for a game to require
root on a linux box to play, wouldn't it? Yet you should be able to put
games in /bin (I forget where it is under linux) or /Program Files and
expect them to play for all users. Doesn't work with preferences in the exe
directory.

> And as far as patching is concerned...  How do people acquire
> patches today?  The application itself acquires its own patches!
> I won't go in to the details of how an application can acquire
> its own patches and somehow not interefere with the application
> during the acquisition process, but I think it's pretty evident
> that this is easy.
Still doesn't address the need for write access, which is why I personally
shelved that thought.

> What huge binary "preference" might the user have?  Couldn't this
> go in the application directory, too?
>
> As far as my comment about multi-user systems being an antiquated
> concept, I stand by it, but I need to qualify it.  I envision
> decentralizing all security and preferences; these things become
> the responsibility of individual resources in cooperation with
> the operating system.  For example, you could set the "desktop"
> to "Bob's" preferences, and access one of "Joe's" folders, and
> launch a media player with "Jane's" preferences.  There is no
> user logged in to the console, just a cloud of resources with
> various security mechanisms.
Dear god, no. Maybe I'm misunderstanding you, but I'd be pretty irritated at
having to put a password at everything I do. Of course, you *could* get
around that by saving your password somewhere and having the OS do it for
you... that sounds familiar. Or you could be lazy (like people are) and just
use the same password for everything. Which we all know is very secure.

> Right now it is possible for me to create a ZIP archive that is
> protected by a password.  Even if a hacker compromises my computer
> and gains access to the ZIP archive, it is pure junk to the hacker.
> Just expand the idea to everything about the operating system and
> all applications.
So then you want every application to support a robust security system?

> So a computer may have many users, but the idea of *being* a user
> on a system and automatically gaining access to resources that
> you own is obsolete.  Too often the big gatekeeper (e.g., the
> Windows operating system) is compromised.  Security needs to
> be decentralized.
I don't pay a whole lot of attention (I'm behind a firewall, and I keep up
on updates), but generally I see *applications* getting compromised, then
the fact that they are running under Admin access causes problems. Since you
want the applications to run their own security, this problem is in no way
solved.

-Dan

>
> --- Colin
>
> cp...@ea...
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>

RE: [email] RE: [GD-General] A portable preferences library

[Ivan-Assen I. <as...@ha...>]

> What huge binary "preference" might the user have?  Couldn't this
> go in the application directory, too?

Many recent games, like Tony Hawk Underground, allow the user to
make a skin for his player from his own photo. This is binary, and
is relatively large (compared to the typical dozen of ints and strings
from the "options" dialog).

RE: [email] RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

> For what does one need administration rights?  To access the 
> Registry and other protected directories!  

One of which is c:\program files...

Of course you could install things to c:\unprotectedCrap but that rather
misses the point of being able to let your kid brother play with the PC and
be safe in the knowledge he isn't likely to fuck things up.

A lot of people use the auto update functions provided by games, a lot of
peple don't. I tend to be in the latter as I'd rather download such things
at work in the background and bung them on a CD instead of sitting at home
waiting for a game to update itself.

Andy



> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...] 
> Sent: 04 December 2003 22:47
> To: gam...@li...
> Subject: Re: [email] RE: [GD-General] A portable preferences library
> 
> 
> 
> 2003 December 4th
> Thursday
> 
> For what does one need administration rights?  To access the 
> Registry and other protected directories!  Well, all of that 
> is unnecessary.
> 
> And as far as patching is concerned...  How do people acquire 
> patches today?  The application itself acquires its own 
> patches! I won't go in to the details of how an application 
> can acquire its own patches and somehow not interefere with 
> the application during the acquisition process, but I think 
> it's pretty evident that this is easy.
> 
> What huge binary "preference" might the user have?  Couldn't 
> this go in the application directory, too?
> 
> As far as my comment about multi-user systems being an 
> antiquated concept, I stand by it, but I need to qualify it.  
> I envision 
> decentralizing all security and preferences; these things 
> become the responsibility of individual resources in cooperation with 
> the operating system.  For example, you could set the 
> "desktop" to "Bob's" preferences, and access one of "Joe's" 
> folders, and launch a media player with "Jane's" preferences. 
>  There is no user logged in to the console, just a cloud of 
> resources with 
> various security mechanisms.
> 
> Right now it is possible for me to create a ZIP archive that 
> is protected by a password.  Even if a hacker compromises my 
> computer and gains access to the ZIP archive, it is pure junk 
> to the hacker. Just expand the idea to everything about the 
> operating system and all applications.
> 
> So a computer may have many users, but the idea of *being* a 
> user on a system and automatically gaining access to resources that 
> you own is obsolete.  Too often the big gatekeeper (e.g., the 
> Windows operating system) is compromised.  Security needs to 
> be decentralized.
> 
> --- Colin
> 
> cp...@ea...
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program. 
> Does SourceForge.net help you be more productive?  Does it 
> help you create better code?  SHARE THE LOVE, and help us 
> help YOU!  Click Here: http://sourceforge.net/donate/ 
> _______________________________________________
> Gamedevlists-general mailing list 
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Re: [email] RE: [GD-General] A portable preferences library

[Colin F. <cp...@ea...>]

2003 December 4th
Thursday

> One of which is c:\program files...

Well, this is an example of "build it and they will come".
Microsoft set up an architecture (Registry and protected
directories) to encourage developers to put files in certain
places.  "Program Files", "My Documents", "My Music", 
"My [...]", etc... (Definitely a product of the "Me" 
generation!)  I don't buy in to it.

But keep reading...

> Of course you could install things to c:\unprotectedCrap but that rather
> misses the point of being able to let your kid brother play with the PC and
> be safe in the knowledge he isn't likely to fuck things up.

I admit that under the current version of Windows and Linux,
there might not be a cool way to prevent one's kid brother
or some malicious hacker from messing with the contents of
unprotected directories.

Basically, I think the operating system should protect all
directories and files independently -- and not by mere flags,
but by virtue of the encryption of the entities themselves.
So, the operating system can only control read and write 
access, not the security of the contents.  Compromising the
operating system only compromises the read and write access
to the disk drive, not any user data.

Given the current operation of Windows and Linux, I guess
one must decide what to do based on the "kid brother" scenario.

But consider this:  Even my USB memory device has its own 
password protection, independent of Windows.  I could go
further and encrypt each file stored on my keychain.
Why rely on Windows to enforce the security of drives?
How often have people been horrified to learn that their
disk drives have been "shared" over WiFi or cable modem?

I don't know how one could execute an application from an
encrypted ZIP archive, but if this problem were solved then
the only thing left to worry about is the archive being totally
deleted (something kid brother might do) or being randomly
corrupted, NOT HACKED, by someone with malicious intent.
All user preferences and patched files can be placed or
retrieved from the application archive by a login (decryption
key), but a hacker cannot cause any predictable change to 
the application or its data.

> A lot of people use the auto update functions provided by games, a lot of
> peple don't. I tend to be in the latter as I'd rather download such things
> at work in the background and bung them on a CD instead of sitting at home
> waiting for a game to update itself.

"Real Audio Player", "Macromedia Flash", many games, etc, detect 
their own updates.  Some games, like "Planetside", force the user to
wait for patches to download and take effect upon each login, as
necessary, because its a multiplayer game that requires everyone to
have the same client.  Frankly I dislike how frequently some 
applications are updated or are marked as obsolete.  In the case of
Real Networks products, I suspect the "update" is just a new bundle
of sponsored advertisements and links, and a new opportunity to 
change the End-User License Agreement to introduce a new level of
spying on the user.

I don't like my software depending on outside entities, and I guess
that's the fundamental philosophy behind my ideas.  I don't like 
chasing Microsoft's idea about how people should do things.  I don't
like applications that call home or need to do things with remote
servers to continue operating (unless that is the core purpose of
the application, like a web browser or a multiplayer game).  I don't
like application resources scattered around, or depending on outside
systems to protect the integrity of my own data.

On the subject of saved games or saved preferences...  I think putting
saved games in the application directory is a pretty easy convention
to follow for developers, and easy for end-users to absorb.  I think
the saved game directory should be easy to copy to an alternative 
location, or even merge contents with another saved-game directory
-- so a friend could send you a saved game that you simply copy to 
your own saved-game directory.

I agree with Brian; I want to be able to delete an application 
directory (or perhaps one day it will be an archive object) and 
have it gone -- without the operating system being involved in 
anything other than a file deletion operation.

On the subject of multiple instances of an application versus the
ability to double-click to open documents...  Okay, this feature
would require a list of file extensions and paths to associated
applications, which I assume is currently found in the Registry.
As it is now, one can double-click on a document that is not 
currently associated with an application and then browse for the
application -- or, one can right-click and choose a new application,
potentially with the same exact name (but different path) to 
open the file (or even change the application association for
future double-clicks of the file type).

As far as I'm concerned, this is not compromising my philosophy.
The window system is an application with its own "preferences",
such as what application to use to open a given file extension.
Microsoft may have used something called a Registry file for 
this purpose -- but I don't see why all other applications on 
the computer should be considered subordinate (in the sense of
"being part of") to the Microsoft window system application.
Application-specific data belongs with the application, not
with the window manager application.

In this age of removable media (USB memory devices, etc) and
other ways of transporting computing contexts from machine to 
machine, I don't want any machine to know anything about me.
Also, I don't want to depend on any machine for security.
I visited MIT's campus last month, and I thought it was really
cool that they had Linux terminals all over campus set up in
public spaces like ATM machines.  Of course it was Linux 
running locally and accessing some centralized network drive
for user preferences, but I envision being able to take 
preferences with you and use a terminal totally anonymously
and without any persisting data associated with you.
I think my little keychain "drive" is just the beginning of
the decentralization of information and security.

--- Colin

cp...@ea...

RE: [email] RE: [GD-General] A portable preferences library

[<ma...@ch...>]

On Thu, 4 Dec 2003, Andrew Grant wrote:

> > For what does one need administration rights?  To access the 
> > Registry and other protected directories!  
> 
> One of which is c:\program files...

Only for the english language versions of Windows.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
The irony is that Bill Gates claims to be making a stable operating system
and Linus Torvalds claims to be trying to take over the world.

                                        - Seen on Linux Kernel mailing list

Re: [email] RE: [GD-General] A portable preferences library

[Dan T. <da...@ar...>]

However, the analogy completely breaks down with patches, because little
johnny doesn't have write access in the example. Since we are talking about
preferences, anyway, for this arguement I'll just say patching is done by
admins. Actually the copy on write method, while taking an obscene amount of
space, is the most transparent out of everything I've seen, and even handles
patching (yay). Of course it would have to be OS level, then you get into
arguements about where it goes, etc.

Regarding the discussion about dlls and stuff in the windows directory, I
can't really convince myself its all MS's fault. No one is forcing people to
use the windows directory for dlls, and if people would just use
HKCU/Software/Company/Game for keys, it wouldn't really be that bad. Its the
<insert the worst name you can call someone for your language here, and make
it plural> who write random stuff as a "copy protection" who make life
miserable.

Speaking of copy protection, I actually had to use the CD crack in order to
play Max Payne 2 - because the protection meant to prevent such things kept
the game from working! Isn't that FUNNY!? *twitch*

-Dan

----- Original Message ----- 
From: "Andrew Grant" <ag...@cl...>
To: <gam...@li...>
Sent: Thursday, December 04, 2003 1:45 PM
Subject: RE: [email] RE: [GD-General] A portable preferences library


> True, but aside from the fact many games these days run into gigs of data,
> what happens the first time you need to patch it or something similar? It
> all gets messy very quickly.
>
> My stance is that any game you ship should go out of its way to provide
the
> most user-friendly experience possible. From properly supporting things
like
> multi-monitor and alt+tab to implementing workarounds for known driver
bugs
> or issues. You can add as many things as you like into the requirements or
> readme section, but insisting people are logged in as an admin or stating
X
> glitch is a driver issue and you should hassle an IHV to fix it isn't
likely
> to win you many fans.
>
> It's also debatable just how savvy the average gamer or parent is with
> computer matters, many people encountering a game which doesn't appear to
> work will most likely simply take it back.
>
> _____________________________________
> andrew grant | programmer | climax brighton
> ag...@cl... - www.climax.co.uk
>
>
>
>
>
>
>
>
> > -----Original Message-----
> > From: Dan Thompson [mailto:da...@ar...]
> > Sent: 04 December 2003 21:37
> > To: gam...@li...
> > Subject: Re: [email] RE: [GD-General] A portable preferences library
> >
> >
> > I'd say it stumbles, but doesn't *quite* fall down. Since
> > with Colin's scheme you can move games/apps around as
> > entities freely, you could (in theory), just move the whole
> > thing somewhere where little johhny *does* have access.
> > Actually the windows LUA compatibility stuff under XP does
> > this exact thing in the registry to anyone who tries to write
> > to HKLM - just copies it to HKCU and lets them do whatever
> > they want to it.
> >
> > -Dan
> >
> > ----- Original Message ----- 
> > From: "Andrew Grant" <ag...@cl...>
> > To: <gam...@li...>
> > Sent: Thursday, December 04, 2003 1:14 PM
> > Subject: [email] RE: [GD-General] A portable preferences library
> >
> >
> > > >> I think multi-user systems is an antiquated concept.
> > >
> > > You're joking right?
> > >
> > > Also your scheme falls down the minute somebody without
> > write access
> > > to
> > the
> > > games folder attempts to play it. Something that's pretty
> > common these
> > days
> > > where Dad has to install the games little Johnny wants to
> > play on the
> > family
> > > PC. I'd be surprised if your approach makes it through QA of any
> > > publisher worth their salt.
> > >
> > > I agree the registry isn't the place to store the data, but
> > neither is
> > > the game install folder. Anything you need to save from
> > your game and
> > > that doesn't ask the user for a path should go into the whatever's
> > > returned by SHGetFolderLocation(.., CSIDL_APPDATA, ..);
> > >
> > >
> > > _____________________________________
> > > andrew grant | programmer | climax brighton ag...@cl... -
> > > www.climax.co.uk
> > >
> > >
> > >
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Colin Fahey [mailto:cp...@ea...]
> > > > Sent: 04 December 2003 20:42
> > > > To: gam...@li...
> > > > Subject: Re: [GD-General] A portable preferences library
> > > >
> > > >
> > > > 2003 December 4th
> > > > Thursday
> > > >
> > > > I have used the following scheme for storing user
> > preferences for an
> > > > application:
> > > >
> > > > [1] A plain text file in the same directory as the executable,
> > > >        with the extension *.txt rather than something else (like
> > > >        *.ini);
> > > >
> > > > [2] The application, when launched, can determine the path of its
> > > >       executable file, and thus the location of the corresponding
> > > >       user preferences text file;
> > > >
> > > > [3] All aspects of reading the user preferences text file are
> > > >       fault-tolerant; re-ordering, adding, removing fields will
> > > >       have the least possible effect -- and field values are
> > > >       similarly checked and clipped to sane limits.
> > > >
> > > > Security of the preferences is not an issue for my use of this
> > > > scheme.
> > > >
> > > > Benefits of this scheme:
> > > >
> > > >   [a] One can have many independent instances of the application
> > > >         on a single machine, each with different preferences;
> > > >
> > > >   [b] The user can edit preferences if the application
> > malfunctions,
> > > >         which is impossible in a scheme where the
> > application itself
> > > >         is the only entity that can manipulate the
> > preferences file;
> > > >
> > > >   [c] Users can send or receive preferences files, or disucss
> > > >         specific named settings, via e-mail or web pages;
> > > >
> > > >   [d] Settings in the preferences file can correspond to an
> > > >         application's scripting system -- so that the preferences
> > > >         file is nothing more than a batch of scripting commands
> > > >         that can otherwise be entered at run-time in the
> > > >         application itself (as in a console window for a video
> > > >         game);
> > > >
> > > >   [e] Settings persist after clean install of operating system;
> > > >
> > > >   [f] Application and settings can be stored on a CD-ROM or
> > > >         portable disk or flash-memory device, and one can
> > > >         take it to someone else's computer and operate the
> > > >         application without doing an "installation" or
> > > >         polluting their computer with any files whatsoever;
> > > >         (I bring my prototype applications to a friend's house
> > > >         for demonstration on my keychain USB memory device,
> > > >         and execute directly from the keychain!)
> > > >
> > > > Basically, I'm a strong believer of the settings following the
> > > > application around.  I think the old MacIntosh operating
> > system hid
> > > > a kind of directory system behind the application icon -- 
> > with the
> > > > "resource fork" and "data fork", which was a pretty good idea
> > > > because it allowed data associated with a program to be
> > bound to the
> > > > program.  Thus, moving or copying the icon would assure that all
> > > > settings and data moved with it. It was a nice abstraction that
> > > > simplified the notion of "application" and reduced confusion when
> > > > moving it around.
> > > >
> > > > Maybe I'm hard-core, but I think everything an
> > application needs to
> > > > operate, short of the absolutely guaranteed resources of the
> > > > operating system, should be packaged with the application -- and
> > > > totally portable.  I should be able to run any application on
> > > > anyone's computer from my keychain memory device, without
> > adding any
> > > > files to their computer!
> > > >
> > > > I think multi-user systems is an antiquated concept.  But
> > if I must
> > > > support multiple users of a single application (as
> > opposed to each
> > > > user installing his or her own copy of the application), then
> > > > individual preferences files can be stored with the application.
> > > > "preferences_bob.txt", "preferences_joe.txt", etc.  Putting these
> > > > preferences anywhere else but with the application leads to
> > > > potential pollution that might never go away.  Lots of
> > > > irresponsible developers don't do a good job of
> > > > un-installation -- or somehow the application disappears from
> > > > the computer without un-install ever happening, leaving tons
> > > > of scattered junk behind.
> > > >
> > > > I always thought the Windows registry was a disaster; it
> > encouraged
> > > > people to centralize critical information, and it has
> > been a source
> > > > of confusion and annoyance for users. Protecting the integrity of
> > > > this single trash heap is silly.
> > > >
> > > > Okay, I sympathize with the idea that putting everything in one
> > > > place somehow seems more organized.  I dislike the idea of things
> > > > being scattered around.  But I think it's perfectly good to put
> > > > things in self-contained bundles that do not rely on any
> > centralized
> > > > thing or on scattered things.  It's very clean.
> > > >
> > > > I think rather than pushing itself upon one's computer (like a
> > > > formal installation procedure), applications should be
> > passive and
> > > > the operating system should instead scan for applications upon
> > > > boot-up. Thus, the "Start" menu is populated at boot time and
> > > > is 100% in sync with available applications.  Applications
> > > > can contain
> > > > preferences about placement in the "Start" menu hierarchy,
> > > > much like an application can propose its own icon.  The key
> > > > is to eliminate the idea of "installation".
> > > >
> > > > Okay, some of these ideas are radical, but I just wanted
> > to share my
> > > > own thoughts about preferences files.
> > > >
> > > > --- Colin
> > > >
> > > > cp...@ea...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: SF.net Giveback Program. Does
> > > > SourceForge.net help you be more productive?  Does it help you
> > > > create better code?  SHARE THE LOVE, and help us help YOU!  Click
> > > > Here: http://sourceforge.net/donate/
> > > > _______________________________________________
> > > > Gamedevlists-general mailing list
> > > > Gam...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > > >
> >
> > >
> > >
> > > -------------------------------------------------------
> > > This SF.net email is sponsored by: SF.net Giveback Program. Does
> > > SourceForge.net help you be more productive?  Does it help
> > you create
> > > better code?  SHARE THE LOVE, and help us help YOU!  Click Here:
> > > http://sourceforge.net/donate/
> > > _______________________________________________
> > > Gamedevlists-general mailing list
> > > Gam...@li...
> > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us
> > help YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
>