RE: [email] RE: [GD-General] A portable preferences library
Brought to you by:
vexxed72
Menu
▾
▴
RE: [email] RE: [GD-General] A portable preferences library
|
From: Andrew G. <ag...@cl...> - 2003-12-04 21:45:09
|
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 > |
