Definition: Users have their own profiles which stores their settings. When player starts the game first time, he is asked to create a profile. Subsequent starts then asks the player which profile he would like to use.
Implementation: All settings are stored internally in Settings/Param subsystem. All params are mapped to python under xenocide.param module, so param "audio_musicvolume" is found at python at "param.audio_musicvolume". As it's a python variable, it can be changed simply executing "param.audio_musicvolume = 0" (mutes the music) in the console.
The Settings/Param subsystem is modified so, that it allows adding human readable descriptions for every param. I'm thinking the following notation:
Settings::NewParam<float> audio_musicvolume("audio_musicvolume", 1.0, "Musicvolume. 0.0 is muted and 1.0 is highest level.");
User settings is stored into two files, which are placed under profiles/garo/ directory. These files are garo.cfg and garo.py. I'm using my profile name as an example here
The garo.cfg is actually a python file which just has .cfg extension instead of normal .py. This file contains all parameters, and their values in python notation, which relates to the profile. Example:
# audio_musicvolume (float variable): Musicvolume. 0.0 is muted and 1.0 is highest level. param.audio_musicvolume = 0.8
When user changes any setting via in-game menus, the garo.cfg is rewrited, so user can't edit this file directly, or his changes would be lost after he changes any setting via in-game menus. This is explained at the beginning of garo.cfg in comments.
It is easy to write the code which simply iterates over all params, writes the param comment among the param and its value itself into the garo.cfg file.
When a new user profile is first created, let's say a profile named "guyver", a directory called guyver is created under the profiles/ directory and guyver.cfg file is created into this directory with default values of the params.
Member Quake and it's revolutionary console? It didn't support turing state scripting, but it had aliases and it could run commands which were implemented inside the Quake engine (change weaopn, or say something to the teammates, for example). Experienced users created often complex keyboard mappings. My own quake script contained over 300 lines, complex aliases to select best available weapon, or toggle different keyboard mapping modes, for example. As we use Python, experienced users will be able to create very complex scripts to modify the user interface, keyboard mappings etc to suite their needs and even implement new features.
The point is, that the experienced users can create the garo.py file, which is executed after garo.cfg. They can use all benefits of the Python scripting to do whatever they want, so that they can customize their profile as much as they ever need to. All these scripts and python code can be placed into this file (garo.py).
Params which can not be set via in-game menus
We will propably have dozens or even hundrets of params, which can't be set via in-game menus. I don't mean that this is a problem, because there will be many params which are simply not so important that we should add an option to change them via in-game menus. Other reason is, that if we would allow changing every possible parameter via in-game menus, there would simply be way to many options which user could change and the menus would be cluttered.
As every parameter is writed into garo.cfg with its default value and its help text, the experienced users can examine the garo.cfg file and re-set the parameter in garo.py file. So the garo.cfg servers also as a dictionary to all values which can be changed.
User keyboard mappings
Currently the keyboard mappings/shortcuts are stored inside a xml file. I'm thinkign of two choises:
1) This file should be moved into the user profile directory.
2) Rewrite the keyboard shortcuts so that a keyboard mapping is binded with a python function. Example:
keyboard.bind("F8", gamestate.quicksave) keyboard.bind('F1', console.toggleConsole)These commands would be saved into garo.cfg among the param commands.
This gives us the ability to easily bind anything into a keyboard button (combination). When testing and developping, it is often easy to bind a python function into a button and then execute it without typing the command into the console. This also would allow experienced users to bind their custom python code into shortcuts.
And xml file would still be used to define what python functions can be binded via in-game menus and human readable explanations what they do. (Example: To bind quicksave into a button, the user would not see the raw function name "gamestate.quicksave' but an user friendly text "Quicksave")
About params which should not be changed
There will propably be need for params which can't be changed via python (they should be read-only) and also params which dont relate to user profile anyway. This proposition is not related directly to user profiles, but I explain it here anyway
We modify the Settings/Param subsystem further, so that it allows some attributes for every param. These would be: read only in python and no profile related. I was thinking of the following notation to express these attributes:
Settings::NewParam<float> current_gametime("current_gametime", 0, 'Current gametime in seconds since gamestart') .Settings::readonly() .Settings::noProfileRelated();If the readonly attribute is supplied, trying to assign a value into the variable in python would throw an exception. If noProfileRelated is supplied, saving the settigns would not include the variable into the garo.cfg file.
Guyver has also some ideas which I'm hoping he will explain to us. Any thoughts about this? Member that this is only a proposition =)
edit: Fixed some fine details about keyboard mapping and bolding.
Edited by Garo, 11 January 2006 - 04:24 AM.