Discovery of Preferences, part II
- Personalizer code: fail-proof design.
In designing discovery and reuse of preferences we strived for
a system that can fall back gracefully to a simpler scheme if the
intelligent algorithms fail.
First, if Personalizer data files has been removed from the computer by
brute force, every game using Personalizer as configuration backend
will fall back to using the traditional approach to configuration
(although in this case, removing the centralized preferences memory
will certainly require reconfigurations.) More specifically, there will
be one configuration profile for every game stored in the game's directory.
This profile will be customizable as usual, and, as soon as Personalizer
is back up again, it will be automatically integrated into the preferences
memory.
Second, profile matching is generally a one-time operation;
once a suitable profile has been selected, it is marked as such for
the game and will be further reused without much hassle.
Third, if profile matching fails completely, Personalizer will
automatically create the default profile for the game from the metadata
provided by the game developers. This default profile, either customized
or left alone by the gamer, will serve for reuse in future games
on the same computer.
Previous Slide: Discovery of Preferences, part I Next Slide: Personalizer Summary
|
 |
Presentation Slides |
 |
|
 1. Problem Statement
2. Worst Kind of Lies
3. Need for Nomenclature
4. Configuration Linguistics, part I
5. Configuration Linguistics, part II
6. Persistent Preferences Memory
7. Discovery of Preferences, part I
8. Discovery of Preferences, part II
9. Personalizer Summary
More information is available...
|
