gamedevlists-general — List for discussing general game development issues

Re: [GD-General] A portable preferences library

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

2003 December 7th
Sunday

> I understand the need in a multiplayer game to keep people from cheating, 
> but I do not understand at all the opposition many game developers have to 
> single player games having editors.  It's not you against the players, it's 
> okay if he wins even if it isn't the way you intended.

I totally agree.

I also think that making it impossible to save the game state at arbitrary
times and places (which should almost always be technologically possible
without some wacky paradox) is just annoying.

For some people the game just isn't fun with the stock rules.  I gave up
playing Oni, and almost gave up before finishing GTA3, because of lengthly
missions that I would fail at almost the last moment -- only to be forced
to start from the very beginning again!  Imagine reading a novel, and on
page 200 you encounter an unfamiliar word that forces you to start reading
the novel from the very beginning.  After a while you would begin to hate
seeing the same stupid stuff over and over again, just to catch brief 
glimpses of the worthy challenges before being sent back to the beginning.

Funny anecdote:  I remember a guy who played Half-Life in "god mode" from
beginning to end.  His character was totally invulnerable -- but he'd 
still very carefully avoid threats and he'd get freaked out when his 
character was attacked by enemies.  This was shocking to me, because it
required convincing oneself that taking damageless damage was really bad.
But I realize that me and my desire to save games at arbitrary points is
just another "safety net" in a continuum of comfortable risk.

There are a few "one-shot kill" games, like Rogue Spear and maybe America's
Army.  If one's character is shot once (or, sometimes, twice), that player
must sit out the rest of the multiplayer match.  (Rogue Spear did allow 
the first few dead characters to assume control of any living non-player
characters remaining in the team's squad, but just consider the general
high stakes of games of this nature.)  Anyhow, for some people the high
stakes are obviously a thrill.  For some, no game is worth playing unless
the reward is fantastic (like being the only survivor in a one-shot kill
match).  A state lottery might have a pot of $100 million, and clearly
lots of people like the nature of that kind of "game" (crazy odds but
huge reward), but that same scenario can be a big turn-off for others.

Anyhow, I like the idea of tuning the rules and "laws of nature" in a
game, because it is just like adjusting the bass and treble on a 
stereo.  There is no good or bad way to play a game any more than
adjusting the sound of music to increase listening pleasure could be
considered "cheating".

If people want bragging rights (e.g., "I defeated the Britney Spears
Mech with my Paris Hilton Pokemon at the Pepsi-n*Sync MTV beach house."),
then the Educational Testing Service will have to offer standardized 
testing in video games, with standard equipment, because anyone who
*wants* to cheat in any single-player game on any system will find a way.
That would be awesome: sending colleges official video game scores.
Of course ETS would charge $4 for each addional score report, and your
bad video game scores would haunt you for five years!  There'd be 
video game prep courses, private tutors, and pressure from parents to
not flunk video games.  Every now and then there'd be the guy who 
got a perfect score, going on to play video games at the school of 
his choice -- probably going on to do something really video game-y
for society some day...

To summarize, I think that the observation that "It's not [game
developers] against the players [...]" is really great, because I
suspect a lot of development teams don't actually explicitly 
consider their relationship with players in this regard.  Maybe 
some developers vaguely think enforcing game conditions will permit
a standard that will make the game a meaningful basis of comparing
people (just like a standardized test), but I wonder how the team
would vote if the matter was raised explicitly at a meeting.

I think that simple observation could very well change the 
unspoken attitude of developers toward their anonymous end-users.
I think it could very well be a good core principle to remind
everyone of at, say, monthly milestone meetings, or whatever.
Well, it seems important to me, anyhow, now that I've seen the
idea spelled out.

--- Colin

cp...@ea...

RE: [GD-General] A portable preferences library

[Ken P. <ke...@dr...>]

>I dislike usage of CSIDL_PERSONAL (My Documents) because saved games and
>preferences are obviously *not* documents, but should still be able to
>roam with my profile.

Define "document".  Save games document my progress within the game.  Prefs 
files document my preferences.  Would a Word file still be a document if 
you didn't have a reader for it?


>5- Data format.
>For preferences and anything the user may want to edit 'by hand': XML
>rulez ! :)))
>For application specific data / saved games, I guess proprietary
>encrypted formats are still the way to go (to avoid at much those
>littles pesky saved game editors).

What a useless waste of time.  Whatever you design, they will crack.  And 
if some user at home edits his save games to make the game a little easier 
for themselves, who cares?  The time spent encrypting your save games in 
your proprietary format could be better spent polishing the game itself.

I understand the need in a multiplayer game to keep people from cheating, 
but I do not understand at all the opposition many game developers have to 
single player games having editors.  It's not you against the players, it's 
okay if he wins even if it isn't the way you intended.

Re: [GD-General] A portable preferences library

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

2003 December 6th
Saturday

I am satisfied with the idea that different applications will
require different schemes to store data, such as user preferences.

Nothing stops me from running an application from my keychain USB
memory device and having it store my user preferences there.
I can have as many versions of the application as I want, 
even identical versions, coexisting on my keychain USB memory
device, each with its own set of persisting data and preferences
for any number of "users" (which has nothing to do with the 
total number of users on any given host machine).  I can remove
the keychain USB memory device from a computer without leaving
any residual trace of the application, and I can attach to a
new machine without any installation procedure.

All of that existing flexibility suits me just fine.

I understand that other applications benefit from the window 
manager or file explorer knowing about them.  Some applications
will be less transient than the scenario I descibe above.

There will be applications that all users of a multi-user 
system (in the conventional sense) are likely to want to use,
and I can recognize the benefit of "scattering" preferences
to the persistent stores associated with each user.  In some
cases this facilitates user "roaming" to other machines.
(However, consider the fact that my keychain USB memory
device can "roam" to any machine with a USB port, regardless
of network connectivity and some domain controller to share
data about me.)

I'm not sure if I agree with the objection that multiple
installations of an application (including games), one per 
user, is necessarily bad!  One user might choose to mod the
game or apply patches...

I agree that acquiring patches and storing them on a CD-ROM
so one doesn't have to risk not being able to download them 
in the future (when the game company goes out of business ;-))
or the inconvenience of downloading in the future, is a 
good option.

Briefly, about the DivX codec or the DirectX version example...
I want to say that the product shouldn't ship when it requires
something the target operating system doesn't have by default,
but I know that's a little extreme.

Also, I'm not sure "XML rulez".  It's hard to beat the convenience
and simplicity of a text file that resembles an *.INI file.
Text editors are commonplace, but I've never really considered
using an XML editor (something that handles the tags transparently).
I'm not saying XML is bad, but I guess the idea of using an XML
editor as spontaneously and easily as, say, Notepad for really 
plain text files, is an idea that I haven't considered yet.

I want to make a comment regarding all of my posts on this subject:
I admit to irresponsible, superficial consideration of this issue;
soooo, if you haven't already, disregard everything I have said! :-)

--- Colin

cp...@ea...

RE: [GD-General] A portable preferences library

[Nicolas R. <nic...@fr...>]

Hi !

Just to add my 2 cents about that very touchy subject:

1- Admin installation (and DLLs or Shared Extensions).

- I don't want to "re-" implement my DivX codec in my game, and
therefore I'm using the system's one. But I can't be sure the system is
already having it installed. If not, I do install the "official" one.
And the only place for system-wide shared code is... in system. I think
that's the main reason for many games to require the "admin" login
during installation.
- I *could* install the codec right next to app, but this won't be
patched, correctly if the user is installing a newer version.
- Another example is the DirectX dependency. If your app is using DX9b,
you *need* to install it (10% users only knowing what DX is), and you
*must* be admin for that.
- Any inter-dependency through pieces of codes should be handled by the
system, and therefore, uninstalling be handled by the system as well (to
check those inter-dependencies). Alas, AFAIK, there is *no* system
handling code dependency correctly (and completely).
- Reason for DLLs (or shared extension) is essentially code separation.
If one day during your development you find that a reference is missing
in the DLL (or shared extension), it means that somewhere, code release
process was broken (or misused) [or it may be due to @#!#@=E9 compiler
'missing' code changes].

BTW, though being the only user on my machine, I am certainly not an
admin on it (though still having debugging rights :) ). And I can't
count the number of downloaded viruses (or simply f..... Ad programs)
that failed to spoil my system that way. To continue on this thought:
never found a single unix geek who was "using" their system under the
root login (they were always using the 'su' for temporary admin
purpose).


2- Multiple-instances & Auto-update.

I really think it is nonsense to install the same application n times on
the same machine.

- I know hard disk space is cheap (even cheaper than raw CD-R now), but
you cannot say someone, hey, buy more disk so another user can launch
me. Note that a possiblity is given with "current directory" setting
(available through the shortcut). But it is leading to another problem
when an unknown new user is launching the thing (creating a new
directory, updating the shortcut...).
- You don't want to patch the same application multiple times. Even less
if each instance is sharing data with other instances (which would yield
to complete mess, not saying that you may have 8472 different shortcuts,
and you cannot tell a user to change the path in them) !
- You don't want to spend those 10 minutes installs from CDs 'n' times.
[if you are not copying data from CD, it means you won't be able to
patch those data].

- Automated update. Sincerely, I never ever used a game auto-update
feature. Why ? Because I prefer to store the update installer somewhere
accessible for my next "re-install" (an re-patch :) ). Plus, if the game
is installed multiple-times (on multiple-machines), I don't want to
download that update 'n' times [especially knowing how fast is servers
access when new updates are available]. Of course, I'm not a low-end
user, but still do know some low-end (very low end trust me ! :) ) users
who are doing the exact same thing [though storing updates on the
desktop].


3- Multiple-Users / Multiple-Machines.

I think it is wrong to think that a machine will be used by a single
user. Especially knowing how easy user selection is on XP-Home edition.
Even very low-end users are using the feature (not even knowing they are
'loging' into something :) ).

The same thing has to be said with small home networks. They tend to be
quite common (especially with all those WiFi network bundles now) and so
easy to manage (as long as you are not under unix :)) )


4- Data locations.

- There are at least 4 major data locations needed for an app (not sure
all games need those, but...).
a- Machine specific (non-portable) data (data relating to machine's
hardware and setup, like binary-code).
b- Application specific (portable) data (usually game content).
c- User/Machine specific data (data relating to user's preferences based
on machine's hardware: D3D, OpenGL, resolution, EAX, ...)
d- User/Application specific data (key bindings, colors, skins, names,
network games, saved games).

(a !=3D b) (and c !=3D d) because of portability issues.
(c !=3D d) because of roaming profiles (same preferences on all =
machines)
!
(a !=3D c) because a user may prefer lower resolution for higher FPS,
while another one may prefer best visual quality, though choices are
based on hardware.
(b !=3D d) because of ... User Preferences ! :)

On windows:
(a) =3D (Application directory)/"WhatYouWant", could be HKLM (but it
prevents shared-network-drive installations).
(b) =3D (CSIDL_COMMON_APPDATA)/"YourCompany"/"WhatYouWant"
(c) =3D (CSIDL_LOCAL_APPDATA)/"YourCompany"/"WhatYouWant", could be =
HKCU.
(d) =3D (CSIDL_APPDATA)/"YourCompany"/"WhatYouWant"

I dislike usage of CSIDL_PERSONAL (My Documents) because saved games and
preferences are obviously *not* documents, but should still be able to
roam with my profile.

I'm not sure what would be the correct locations on other systems.


5- Data format.
For preferences and anything the user may want to edit 'by hand': XML
rulez ! :)))
For application specific data / saved games, I guess proprietary
encrypted formats are still the way to go (to avoid at much those
littles pesky saved game editors).


Nicolas

RE: [GD-General] A portable preferences library

[Mat N. \(BUNGIE\) <mat...@mi...>]

Wouldn't it be easier to add the ability for the user to import/export
preferences? (Along with the requisite documentation.)

MSN

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Tom Spilman
Sent: Friday, December 05, 2003 11:31 AM
To: gam...@li...
Subject: RE: [GD-General] A portable preferences library=20

> -----Original Message-----
> Behalf Of J C Lawrence

> > Maybe I'm hard-core, but I think everything an application needs to=20
> > operate, short of the absolutely guaranteed resources of=20
> the operating=20
> > system, should be packaged with the application -- and totally=20
> > portable.
>=20
> In the case of user preferences this violates the model of=20
> segmented access rights and patterns as it requires that=20
> users have write access to the installation point the=20
> application.

	Maybe one that wants to maintain application controlled config
selection ala BF1942 for instance, yet not violate the write access of
non-admin accounts should use SHGetFolderLocation( CSIDL_COMMON_APPDATA
), CSIDL_COMMON_DOCUMENTS, or whatever is equivalent to 'C:\Documents
and Settings\All Users\' in other OSs. =20

	Tom


=09



-------------------------------------------------------
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=3D557

Re: [GD-General] A portable preferences library

[Parveen K. <pk...@al...>]

On Fri, 5 Dec 2003 14:28:06 +0200 gam...@li...
wrote:

> 

> I believe Microsoft are working on something like "zero-install" games,

> where the CD is just popped into the drive, and the game uses part of the

> HDD for caching - but doesn't rely on it being preserved across runs,

> similar to what games use the Xbox HDD.



Sounds similiar to the Gentoo LiveCDs.	Having America's Army, UT2k3, and
RtCW:ET on bootable CDs are a god-send when you're bored out of your skull
and away from your own machine.



www.gentoo.org

www.gentoogames.com

RE: [GD-General] A portable preferences library

[Tom S. <to...@pi...>]

> -----Original Message-----
> Behalf Of J C Lawrence

> > 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.
> 
> In the case of user preferences this violates the model of 
> segmented access rights and patterns as it requires that 
> users have write access to the installation point the 
> application.

	Maybe one that wants to maintain application controlled config
selection ala BF1942 for instance, yet not violate the write access of
non-admin accounts should use SHGetFolderLocation( CSIDL_COMMON_APPDATA
), CSIDL_COMMON_DOCUMENTS, or whatever is equivalent to 'C:\Documents
and Settings\All Users\' in other OSs.  

	Tom


	

RE: [GD-General] XML parsers (was: A portable preferences library)

[Tom S. <to...@pi...>]

> > And indeed, to get game-quality optimisations, I'll have to 
> write my 
> > own micro XML parser so we can stop using Xerces

> Xerces? We decided against using a validating parser,
> and are happily using expat.

	If your looking for a very small fast XML parser CMarkup (
http://www.firstobject.com/dn_markup.htm ) is it.  Download the eval zip
which contains all the source... It's just one header and source file
which is under 1600 lines all together.  It has 3 different flavors...
MFC, STL, and one that wraps MSXML.DLL.  The thing is so simple that you
can easily 'find and replace all' your own string class if necessary.
It also uses EDOM ( http://www.firstobject.com/dn_edom.htm ) which makes
querying the parser for data dead simple.

	If you can't tell I had a very good experience with it.
Definitely check it out.

	Tom

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

[Andras B. <bn...@ma...>]

How about using delayed dll loading together with SetDllDirectory??


andras


Friday, December 5, 2003, 12:19:08 AM, Jeff Laing wrote:

> Because when push comes to shove, Windows is *still* just DOS - it still
> requires a PATH environment variable of ";" seperated directory names to
> search - in fact, with the latest versions of Windows, Microsoft is
> disparaging the idea of putting your DLL's into the system directory, but
> they don't give adequate documentation or support of the API's required to
> insert directories into the search path.

RE: [GD-General] A portable preferences library

[Simon S. <red...@ho...>]

>Anyhow, you are of course free to do whatever you want, but my advice to
>anyone thinking of releasing a PC game in the future would be to follow the
>recommended approach and install all per-user options in the correnct
>location. Even if everyone using a PC has a single login then the worse 
>that
>happens is their saves are stored with all similar data and can easily be
>backed up.

The only "Correct" thing to do on the Windows platform is what the logo spec 
says: http://www.microsoft.com/winlogo/software/default.mspx (spec is 
downloadable from http://go.microsoft.com/fwlink/?LinkId=9775 , Main 
sections of interest here are 2.0: Install/Remove, and 3.0: Data and 
Settings Management.)

_________________________________________________________________
Hot chart ringtones and polyphonics. Go to  
http://ninemsn.com.au/mobilemania/default.asp

Re: [GD-General] A portable preferences library

[J C L. <cl...@ka...>]

On Thu, 4 Dec 2003 22:47:06 -0500 
Brian Hook <ho...@py...> wrote:

> Originally I was thinking it would be a binary file format, strictly
> because I wanted the ability to serialize raw binary data "just in
> case".  Now you could make a valid argument that you could always
> convert to text, i.e. 3.14 becomes "3.14", but maybe you don't want to
> suffer a data conversion loss or something, I dunno.

I wouldn't use a configuration system that didn't use flat text files,
but then I'm religious in that regard.

> foo=3D129ABC55

I ended up electing to use a leading typing string that identified the
encoding of the rest of the value.  As such I had decimal, hex, a
variety of true/false forms, quoted strings, and ${value} substitution.
With the exception of the latter, which I did for pure geek value, they
all turned out to be absurdly useful.

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Re: [GD-General] A portable preferences library

[J C L. <cl...@ka...>]

On Thu, 4 Dec 2003 21:08:37 -0600
Garett Bass <gt...@st...> wrote:

> So, I'm guessing that the multi-user advantages of the registry-stored
> preferences are likely used only by an elite few with some serious IT
> skills.  Another example of 99% in, 1% out.  I'm partial to 1942's
> handy built-in multiple profiles dialog.  I suppose you could always
> use a single registry key to set a default profile for each
> system-level user.

Mozilla has a rather nice multi-user same account setup.  I've seen
quite a few non-technical homes setup with Mozilla and separate user
configurations.  It also has a rather decent divide between system level
configuration and defaults and per-user overrides.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

RE: [GD-General] XML parsers (was: A portable preferences library)

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

> Once all this is in place, it is our intent to replace the
> XML editors with an editing tool specific to the language,
> which then removes the need for the validation. At which
> time we will replace Xerces with a home-grown parser.
> 
> So far it has worked out extremely well - much better than
> I had anticipated.

By the way, we have very good initial impressions from using
InfoPath (the new member of the Microsoft Office suite) as a
custom editor for XML files. It lets you very easily create a
designer-friendly interface, and add validation against a schema,
or even custom validation rules via JScript. It's perfect for
things that require nothing more than standard UI widgets,
like conversations.

If you have a significant amount of structured data that is not
graphical in your game data, and you think you spend far too much
time on writing UI code, definitely check it out.

RE: [GD-General] XML parsers (was: A portable preferences library)

[Richard S. <Ric...@ei...>]

> > And indeed, to get game-quality optimisations, I'll have to
> > write my own micro XML parser so we can stop using Xerces
> Xerces? We decided against using a validating parser,
> and are happily using expat.=20

The fully validating parser is there as a launch pad, really.
The provided parser and tools allows us to get off the ground
quickly and easily, the validation forces us to produce a
well specced formal grammar (XML schema, in this case). The
schema can also then be used by editors to provide good quality
language validation.

Once all this is in place, it is our intent to replace the
XML editors with an editing tool specific to the language,
which then removes the need for the validation. At which
time we will replace Xerces with a home-grown parser.

So far it has worked out extremely well - much better than
I had anticipated.


> We have around 1500 XMLs in a game
> installation. We don't have tests for how long it takes to=20
> load them all,
> because they most of them are loaded on demand, but in normal=20
> gaming sessions
> (load the game and play 30-40 minutes) profiles showed that
> total time spent inside expat was < 500 ms.

Ah, I think we'll have less XML files, but much of our overhead
will be coming from processing the rules out from the parsed
XML and binding XML data content to game functionality. Also
in a given gametick, these rules may need to be run many hundreds
of times, using different data in each case. We have a fallback=20
plan in case this overhead is too much (given there is no real
alternative) is to retranslate the XML automagically into C++.
Actually, it might be easy enough to do this that I'll do it
anyway - it can't hurt and it would be an interesting exercise.

Rich

[GD-General] XML parsers (was: A portable preferences library)

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

> And indeed, to get game-quality optimisations, I'll have to
> write my own micro XML parser so we can stop using Xerces

Xerces? We decided against using a validating parser,
and are happily using expat. We have around 1500 XMLs in a game
installation. We don't have tests for how long it takes to load them all,
because they most of them are loaded on demand, but in normal gaming sessions
(load the game and play 30-40 minutes) profiles showed that
total time spent inside expat was < 500 ms.

RE: [GD-General] A portable preferences library

[Richard S. <Ric...@ei...>]

Ivan-Assen said:
> If you are really opposed to using XML - after all, why would=20
> a "simple"
> preferences library need a big bad XML parser (answer: you'll=20
> likely need
> an XML parser in the game anyway...), you can play the=20
> revolutionary by using YAML:
>=20
> http://www.yaml.org

Looks like an alternative, except currently there does not seem
to be a C++ parser for it, or, perhaps more importantly[0], no
support tools. Certainly churning out a language spec for SCite
(or editor of choice) would be simple enough, but comparing this
to the enormous resources available to the XML user leaves it
with a long way to go. Which is fine by me as I'm 80% of the
way through implementing a complex data and rule based system
in C++ using XML as the interim data format and would hate to
find a better alternative at this late stage :*)

Rich

[0] Only because non-validating parsers for this kind of language
are not too hard to produce[1]
[1] And indeed, to get game-quality optimisations, I'll have to
write my own micro XML parser so we can stop using Xerces

RE: [GD-General] A portable preferences library

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

On Thu, 4 Dec 2003, Garett Bass wrote:

> // Andrew grant wrote in response to Colin Fahey:
> //
> // I'd be surprised if your approach makes it through
> // QA of any publisher worth their salt.
> 
> 	Colin's approach is exactly what is used by Quake, Quake2, Quake3,
> Half-Life, and by the transitive property, Counter-Strike.  Another popular
> game using this technique is Battlefield 1942.

Under Linux at least, q3 uses ~/.q3a/ to store things in. 

~ == $HOME btw.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
We can argue this until the cows come home, but let's agree to compromise.
If you're right, you can say "told you so". If I'm right, I can say... well,
whatever Bill allows me to say. Fair enough?
                   - /. comment by Rogerborg on 2002.07.02 on MS Palladium

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: [GD-General] A portable preferences library

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

> Okay, so back to the actual file format....
> 
> Originally I was thinking it would be a binary file format, strictly 
> because I wanted the ability to serialize raw binary data "just in 
> case".  Now you could make a valid argument that you could always 
> convert to text, i.e. 3.14 becomes "3.14", but maybe you 
> don't want to 
> suffer a data conversion loss or something, I dunno.
> 
> Point being that I'd rather not dictate policy if I don't have to.
> 
> So instead of doing a UUEncode, I could do an inefficient translation 
> to ASCII by simply converting directly to ASCII.  It would double in 
> size if I used hex, but it would still be editable in a text editor.
> 
> So if you need to write out 0x12 0x9A 0xBC 0x55 to the key "foo" then 
> the file foo.pref would have:
> 
> foo=129ABC55
> 
> Not efficient, but it works.

If you are really opposed to using XML - after all, why would a "simple"
preferences library need a big bad XML parser (answer: you'll likely need
an XML parser in the game anyway...), you can play the revolutionary by
using YAML:

http://www.yaml.org

quote from the site:

YAML(tm) (rhymes with "camel") is a straightforward machine parsable data serialization format designed for human readability and
interaction with scripting languages such as Perl and Python. YAML is optimized for data serialization, configuration settings, log
files, Internet messaging and filtering. YAML(tm) is a balance of the following design goals: 

YAML documents are very readable by humans. 
YAML interacts well with scripting languages. 
YAML uses host languages' native data structures. 
YAML has a consistent information model. 
YAML enables stream-based processing. 
YAML is expressive and extensible. 
YAML is easy to implement. 

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: [GD-General] A portable preferences library

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

> 	About three years ago I remember speaking to some DX guy about a
> standard they were working on for PC game installs.  Something about
> using a fixed percentage of the drive for game installs and it
> automatically managing it.  Anyone remember anything about that or was
> that a crunch mode delusion?

I believe Microsoft are working on something like "zero-install" games, where
the CD is just popped into the drive, and the game uses part of the HDD for
caching - but doesn't rely on it being preserved across runs, similar to what 
games use the Xbox HDD. 

RE: [GD-General] A portable preferences library

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

And hey, Doom also stored it's config file in the game directory so that's
another mass seller which counters my opinion!

But for arguments sake lets get rid of all those games released before the
year 2000 when your average PC came with 98/SE/ME... which leaves BF1942.
I'm not sure what relevance it being a popular online game has, while it's a
fantastic game I don't think it's sales were anything remarkable.

Anyhow, as someone pointed out there are games out there which require admin
privileges to play but more and more are switching to using the correct
location for this sort of thing. Unless you haven't looked lately then XP
now comes packaged with pretty much any PC and Microsoft are really pushing
the muti-user angle since it's the first OS targetted at the home market
which has good support for this. People who think they know better might
disagree with this usage scenario, but when Microsoft pushes an aspect or
usage pattern it more often than not becomes adopted (I used to hate 'My
Documents' when it was first introduced, but I use it now).

Anyhow, you are of course free to do whatever you want, but my advice to
anyone thinking of releasing a PC game in the future would be to follow the
recommended approach and install all per-user options in the correnct
location. Even if everyone using a PC has a single login then the worse that
happens is their saves are stored with all similar data and can easily be
backed up.

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








> -----Original Message-----
> From: Garett Bass [mailto:gt...@st...] 
> Sent: 05 December 2003 03:09
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> // Andrew grant wrote in response to Colin Fahey:
> //
> // I'd be surprised if your approach makes it through
> // QA of any publisher worth their salt.
> 
> 	Colin's approach is exactly what is used by Quake, 
> Quake2, Quake3, Half-Life, and by the transitive property, 
> Counter-Strike.  Another popular game using this technique is 
> Battlefield 1942.
> 
> 	Personally, I find Colin's suggestion to be a perfectly 
> acceptable means of managing preferences for a game.  I 
> particularly like the ability to keep a variety of preference 
> files onhand.  More than one per user can be handy if you are 
> experimenting with some scripted input behavior in your spare 
> time but don't want to lose your competition config.
> 
> 	Now, I'm not sure this is true, but I've heard that 
> Counter-Strike is currently the most popular online FPS, and 
> that 1942 is second most popular. And yet you exclude 
> Activision and EA from your set of all "publishers worth their salt".
> 
> // Something that's pretty common these days where
> // Dad has to install the games little Johnny wants
> // to play on the family PC.
> 
> 	Ok, this makes me feel a little dumb.  I've been trying 
> to set up a restricted access user on a Win2k box at work, 
> and no matter what I disallow, I still can't figure out how 
> to prevent the user from installing stupid crap from the internet.
> 
> 	Somehow I doubt there are many fathers who are running 
> serious system-level multi-user setups at home.  More likely 
> everyone just uses the same login and shares the same 
> clutter.  Sure, it's still multi-user, as in "used by 
> multiple people", but not at the registry level.
> 
> 	So, I'm guessing that the multi-user advantages of the 
> registry-stored preferences are likely used only by an elite 
> few with some serious IT skills.  Another example of 99% in, 
> 1% out.  I'm partial to 1942's handy built-in multiple 
> profiles dialog.  I suppose you could always use a single 
> registry key to set a default profile for each system-level user.
> 
> 	Apologies in advance for the rants.
> 
> Curious,
> Garett
> 
> 

Re: [GD-General] A portable preferences library

[J C L. <cl...@ka...>]

On Thu, 4 Dec 2003 12:42:12 -0800 
Colin Fahey <cp...@ea...> wrote:

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

Windows allows this as well under NTFS ala extended attributes, tho it
is not commonly used.  Linux allows extended attributes under Ext[23]fs
but not ReiserFS or XFS IIRC.

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

In the case of user preferences this violates the model of segmented
access rights and patterns as it requires that users have write access
to the installation point the application.  Stackable filesystems are
one way around this, but are extremely unlikely to be widely deployed.
Logical view based filesystems are a possible address if you insist on
the model, but that's even further out.

> I should be able to run any application on anyone's computer from my
> keychain memory device, without adding any files to their computer!

Limited execution environments, be it capability systems, trusted
computing, or execution models will be and often already are the first
hurdles there.  If the OS physically won't allow execution of a file
which is not on a pre-configured trusted device...

> I think multi-user systems is an antiquated concept.  

<shrug> And yet they are becoming more common.

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

Which in turn requires write access to the installation location.  Not a
winner.

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

There are two disparate concepts: removing access/configuration data
from a user, and removing the entire application from a system.  They
are different and disjoint.  Removing an application from a system in no
means that each user's configuration data must also be removed (well,
not unless you want some extremely unhappy users).  

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

Quibble: My desktop boots perhaps twice a year if that...

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

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

[Tom S. <to...@pi...>]

> -----Original Message-----
> Behalf Of Jeff Laing

> I'm surprised that no-one has said "use XML format please" - 
> its not that painful, given that you'll have a fairly limited 
> schema to implement.

	...and that would most likely be followed by use Lua. =)

	Tom

RE: [GD-General] A portable preferences library

[Garett B. <gt...@st...>]

//// I wrote:
////
//// So, I'm guessing that the multi-user advantages
//// of the registry-stored preferences are likely
//// used only by an elite few with some serious
//// IT skills.

// Brian Hook wrote:
//
// this is true, but it's still there.  Even if it's
// just 1% of users, if your game sells 200K units,
// that's 2000 users that will run into problems
// with your game.

Actually, I'm suggesting that those 2000 users are the only ones who will
benefit from registry-based user-specific profiles, whereas a system like
that in 1942 lets you choose one of many profiles no matter which user you
are.

If you are planning to write your registry prefs into HKLU, then you are
choosing to cause trouble for someone who suddenly wonders where their prefs
went after they switch from their admin account to their user account.  This
is a problem that using the registry can cause.  I, agree with Colin Fahey:

// The window system is an application with its own
// "preferences".  Microsoft...used [the] Registry...
// for this purpose.
// Application-specific data belongs with the
// application, not with the window manager
// application.

I just don't see how the Registry is in any way an analogue of a memory card
or application bundle.  Just the opposite, it is an increasingly obscure
database bloated with junk data that is very difficult to give a thorough
spring cleaning.

Regards,
Garett