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