FingerTips Personalizer, The Framework Design

In Personalizer, the value of an option is not an authority beyond exception; instead, we say that options define gamer's preferences for certain aspects of gameplay. In particular, if a profile contains an option that the game does not implement, this option can be safely ignored. If the game does not support a specific option value, it can either round the value to the closest valid value or use the default instead. The most notable difference of Personalizer options is that some options (or, to be precise, option types) allow setting a value that holds several preferences in the order of decreasing favor. For an example, consider option 'Language' that specifies the preferred language of a person. In the traditional approach, you select a language from a predefined list using the game's setup screens. You do that manually and only have the choices the game developers provide. Personalizer states that a gamer can define 'Language' as a list of values, such as 'Spanish Russian English', and, if the game has a selection of languages to offer, it must interpret the list and select the first language down the list that is available. If Spanish is available, it would become the first choice. If not, consider Russian. Otherwise, just go with English (or, finally, the default language, whatever that is.)

Binding associates one or more controls with a certain in-game action. This is so in the traditional model and even more so in Personalizer. However, in some cases it may be convenient or desirable to supply an action argument in order to modify the action's behavior. Action arguments are used to pass additional parameters in bindings. However, action arguments are not governed by definitions of actions as present in the library; instead, they are stored in the special Arg tag (see Section 5.4, “Preferences Tagging” for more information.)

Game development hasn't always been sensitive to localization needs. There are fine examples of games implementing multilingual interface, but there are also games that are only localizable through reverse engineering. As time passes, more games will incorporate the localizable approach and, as the result, multilingual interfaces will become a commodity. Personalizer is designed for localization in the sense that it does not stand in the way of localization. Like so many programming languages, it requires from the developer to use English for names of library entities (the matching algorithms won't work otherwise), but it says nothing about the interface language. Which means, you can make games that are Personalizer-aware and localizable.

FingerTips Personalizer Framework's Application Programming Interface automatically creates backup copies of important framework files (such as preferences memory, library data, and so on). These backups are known as snapshots.

Snapshots serve to restore preferences memory and the supporting files if corrupted due to an external factor such as hard disk crash or a virus attack. Snapshots are stored in the Snapshots Folder, with names formatted as creation timestamps, YYYY.MM.DD.HH.mm.ss. No two snapshots can be written within one second's span, so, if a snapshot exists already, the system will create the new snapshot one second further 'in the future'.

The Application Programming Interface will create snapshots when performing operations that change preferences memory files or the supporting infrastructure significantly. Initially, every snapshot is considered valid, but an external factor can damage the snapshot files, so the system automatically checks all snapshots for validity before reusing them.

The system automatically removes invalid snapshots older than one month and also stores only 5 most recent valid snapshots.

	Note
	The preferences memory persists and remains valid even in the event of direct deletion of the game files.

Personalizer profiles are portable. The gamer can extract preferences for a certain game and reuse them on another system or share them with friends. Reusing preferences previously extracted is known as integration. Implementation of portable profiles has been moved to the next release of Personalizer.

An extracted profile is an XML document (independent of a Personalizer installation) that contains the actual preferences plus any related information required to integrate the profile back into a Personalizer installation.

Personalizer development team reviews released games and game demos in order to maintain the coverage database. For every game, coverage database contains records for all options and bindings that game manifests, with every configuration item either mapped to an existing core library definition or marked as uncovered.

Uncovered configuration items from many games are linked through special group identifiers. Items in every group refer to concepts and entities that are semantically identical for all games of a genre. Put simply, items in a group describe the same thing, although the terms and approaches used may differ. When a group gains significant weight (the number of items in the group exceeds a predefined normalized threshold), our task is to assign an appropriate name and structure to that configuration entity and design a corresponding core library definition. Then all the items from the group are marked as covered and linked to than new core library item.

The main goal of the coverage to library design excercise is to keep the core libraries in good shape. By good shape we mean reflecting 90 plus per cent of existing configuration items common to many games. This way, profile matching has sense and the developers never have to create too many custom library definitions.

Library definitons serve as building blocks for profiles. If a profile references an in-game action, the action must exist in the library of actions. If a profile sets an option, the option must exist in the library of options.

Definitions provided by the FingerTips Personalizer Framework development initiative are known as core definitions, while definitions provided by game developers are known as custom definitions.

Definitions for in-game actions, both core and custom, are stored in the actions library.

Definitions for options, either core or custom, are stored in the options library. Definitions for option types, either core or custom, are stored in the option types library.

In the library of actions, every action's definition includes the following information:

Because the overall number of action definitions is formidable and the game developer generally uses under 10% of all possible actions, Personalizer attaches mandatory class attribute to all definitions. The following action classes currently exist:

In the library of options, every option's definition includes the following information:

Because the overall number of option definitions is formidable and the game developer generally uses under 10% of all possible options, Personalizer attaches mandatory class attribute to all definitions. Option classes follow the traditional division found in many games:

The developer will know to look into Graphics in order to locate the option controlling screen resolution.

Option class Personality is probably new for mainstream games. It is intended for options that identify (with user's consent) personal information that may be used for physical and psychological profiling of gameplay. Information such as sex, age, habits can make a game's content more appealing to player, while accessibility options describing possible gamer's impairments can make accessible games aware of the situation.

Every existing option must assume only those values that are mentioned in the option's definition. See Section 4.5, “Option Type Definition” for more information on how option types referred to from option definitions restrict the ranges of possible values.

In the library of options, every option definition references an option type that restricts the range of possible values for that option. The library of option types complements the library of options and stores definitions of option types. In particular, there are a number of built-in option types that model the most common option controls.

Personalizer options are the well known name/value pairs, where a name serves as a reference to a library definition, and the corresponding value must be valid according to that definition. Every option mentioned in a profile must exist in the library of options as either a core option defition or a custom option definition.

Besides the multivalue quirk of Personalizer options (Chapter 2, Little Differences), there are several peculiarities related to retrieving values of options.

Default Values. The game has to have a value for an option, one way or another. If the value is not in the selected profile and not in any of the inherited profiles, and there are no alternatives, FingerTips Personalizer Framework's Application Programming Interface will return the default value specified by the game developer.

Valid Values. Certain option types list many possible option values. Take 'Core.Language', for instance. The option 'Language' can list all languages that 'Core.Languages' defines as a space-separated list. This is perfectly valid in Personalizer as a way to express value priorities. However, the game usually does not have an interface all that multilingual. In real life, three languages are common, five languages are rare. That's it. When a game encounters an option value it is not ready to encounter, unexpected things may happen. To avoid such situations, Personalizer lets the developer specify the values that are considered valid for an option. Seeing this restriction, FingerTips Personalizer Framework's Application Programming Interface will filter out unlisted values when retrieving the option.

Grades. A grade is a game option with a fixed number of possible values that represent different levels of something. Personalizer uses option type 'Percentage' (values 0 through 100) to model slider controls and grades.

In "Half-Life 2", the developers chose to describe difficulty variations with words like 'Easy', 'Normal', and 'Hard'. On the other hand, developers of "Max Payne" chose to describe difficulty variations with words like 'Fugitive', 'Hard-Boiled', and 'Dead On Arrival'. Personalizer only knows that Difficulty has type Percentage, so 'Easy', 'Normal', and 'Hard' map to 0, 50, and 100. 'Fugitive, 'Hard-Boiled', and 'Dead On Arrival' again map to 0, 50, and 100. No matter what wording the developers use, Personalizer always measures difficulty in per cent. It does not have to know that 'Normal' from "Half-Life 2" and 'Hard-Boiled' from "Max Payne" refer to the same difficulty level.

Now, consider what happens when two games use different number of variations for 'Difficulty'. There are 'Easy', 'Normal', and 'Hard' from "Half-Life 2". And, there are 'Very Easy', 'Easy', 'Medium', 'Hard', 'Very Hard' from "AquaNox 2: Revelation". Because game developers create grades to reflect such marks on a continuous axis, Personalizer knows that values must be preprocessed. If a game requests the value of 'Difficulty', Personalizer rounds this value to the lesser of the closest marks. For this example:

Another common use of grades is modeling of slider controls with steps larger than one per cent, such as 10-step or 20-step sliders.

To learn about the order in which Personalizer applies defaults, filters, and grades, refer to ???.

A Personalizer binding is an association between an in-game action and one or more controls. A control is a sum of inputs provided by hardware controllers. Keyboards, mice, and joysticks can all contribute. An in-game action is simply any action initiated by the game player after the game launches.

Personalizer does not limit the number of bindings for any given action as well as the number of controls in a binding.

A sequence is a set of option assignments and action calls executed successively. As with bindings, execution of a sequence starts when the gamer invokes an associated control. You can think of sequences as a simple scripting mechanism.

A sequence must have at least one associated control, an (optional) title, and must contain at lease one action call or option assignment.

Controls for sequences work exactly the same way as for individual bindings. In fact, you can also think of a sequence as a single higher order action bound to a control.

Action Calls. An action call executes a single in-game action. Action call has the same properties as action in a binding: action name and action argument. The sequence context adds a couple of extra attributes: action execution flow and duration.

There are two possible execution flows for an action call: Standard (the default) and Spawn. The Standard variant says: "Wait until this action fully executes, then proceed to execute subsequent sequence elements." The Spawn variant says: "Execute this action in parallel with subsequent sequence elements."

Spawned actions are similar to background processes working concurrently with foreground tasks. Game players routinely invoke many actions in parallel, so this concept must be already familiar to them, although implicitly.

The second attribute unique to action calls is duration. Duration tells the sequence interpreter for how long the action must be executed (if the action's semantics allows for prolonged execution.) Personalizer suggest to measure duration in milliseconds. Alternatively, the interpreting game can measure duration in game- or hardware-specific ticks.

Option Assignments. Option assignment in a sequence is no different from an option assignment in a profile. It is presumed that option assignments are executed in zero time.

Personalizer allows game developers to attach arbitrary tags (name/value pairs) to most structures in preferences memory. Specifically, to profiles, options, bindings, controls, sequences, and sequence elements. Tags can serve as source of additional information. For example, when a game has found a suitable profile among the profiles from preferences memory, it can tag the profile as Selected="Yes". Next time the game starts, it can search for a profile tagged Selected="Yes" and initialize itself with information from that profile, if found. (This is done automatically by the API.)

When the developer sets tags programmatically, FingerTips Personalizer Framework's Application Programming Interface prefixes tag names with the game's unique origin string, so there is no possibility for misinterpreting tags (this also means that tags are not reusable in other games.)

Another natural application for tags are multi-player configurations where a single profile must contain preferences for two or more players who either take turns or play the game simultaneously. By tagging options and bindings with tags like Player="One", Player="Two", and so on, the game can store settings for many players in a single profile and be able to discriminate between the settings for different players.

While a Personalizer-aware game is still in development, certain preparations must be made. The developer creates Personalizer-related metadata that is loaded into FingerTips Personalizer Framework's Application Programming Interface memory space at run-time. This game-specific metadata includes the following information:

FingerTips Personalizer Framework was designed to keep the existing exteriors of the configuration process, so the setup screens for Personalizer-aware games will remain much the same. However, there are several important points that we must make.

Profile Management. For different reasons, many games do not include profile management. As a configuration component Personalizer already implements a full-featured system of profile management, so bringing operations such as creating, removing, modifying, and selecting profiles to the setup screens should be a breeze for game developers.

Configuration Stress Reduction. Personalizer makes possible automated discovery of preferences and tries to ensure that the discovered preferences are suitable for the game in question. To verify that the settings are right, the person intending to play the game still has to browse the setup screens, right? Simply because many games do not include tutorials, and awareness of the in-game actions available is key to playing.

The game developer can help by rearranging configurable items on the setup screens and/or marking the items visually using colors or icons. The idea is to partition items automatically derived from the persistent preferences memory and items for which the game had to use its own defaults. First, the gamer immediately sees configuration items that require immediate attention and, probably, reconfiguration. Second, the gamer can skim over the rest of the items with intent of understanding what actions and options are available. This approach is 50 to 80 per cent faster than verifying and tuning every available control separately.

Conflicting Controls. There are several ways for a game to react to conflicting controls for in-game actions. First, when the gamer assigns a control that is already in use, the game clears the control for the action that previously had it assign and remaps the control to the current action. Second, the game can inform the gamer that the control is in use and refuse to assign it. Third, the game assigns the control and marks both items using the control - either using color or icon. Personalizer suggests the third approach with possible additional quirk: the items participating in the conflict must not only be marked, they should also "bubble" to the top of the list and remain visible to the gamer.

Why keeping the conflict from automatic resolution is better? Because with high probability the binding that owned the control previously is one of the bindings automatically derived from preferences memory, and these, as far as Personalizer goes, are stable. Stable bindings are more likely to keep controls. However, there is margin for error, so it is up to the gamer to make the final decision.

During installation, a Personalizer-aware game must launch the redistributable core installer. This is a required action. The installer will install or update Personalizer on-disk files as necessary and provide base for further operations.

During uninstallation, the game must not launch the installer for any reason or explicitly uninstall Personalizer on-disk files. The preferences memory persists over life spans of individual games.

The initialization algorithm is as follows:

It is perfectly safe to uninstall Personalizer Redistributable Core when the game uninstalls because the Redistributable Core packages is structured in such fashion that it leaves behind the DLL and the persistent preferences memory.

Internally, names of in-game actions and options are strings without embedded spaces. This was a conscious design choice. However, an option such as '{http://softwarespecies.com/GameDev/ExtremeSuperTetris/V1.9}MultifigureHints' is unacceptable for setup screens. The names of library options and actions must be unmangled before displaying. This involves removing the origin prefix and inserting spaces at certain points.

The Application Programming Interface inserts a space after a capital letter, if the letter does not preceed and does not follow another capital.

The hypothetical core option's name 'MouseHorizontalSpeed' is converted to 'Mouse Horizontal Speed'. The hypothetical custom option's name '{http://softwarespecies.com/GameDev/SuperMegaTetris/V1.19}MultifigureHints' is converted to 'Multifigure Hints', and so on.

Personalizer offers an alternative naming scheme where you can indicate need for spacing using dots. For example, a name such as 'MultifigureH.ints' will be converted into 'MultifigureH ints'.

The purpose of profile matching is to rank profiles that may be suitable for the game in the order of decreasing weights. A profile's weight is the sum of points awarded to the profile for options and actions that match options and actions the game implements.

For every profile in preferences memory, Profile Matcher performs as follows.