RE: [GD-General] A portable preferences library

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

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