In this section we outline a framework for identifying, embedding and tracking Behavlets. Game components, design patterns and a fundamental model of psychology form a foundation for this framework; instantiated via notation for modelling that supports the coding of features in the game engine. The theoretical foundations relate to each other as shown schematically in Fig. 1, which is a flow chart for Behavlet extraction.
Top (theoretical): the method draws on comprehensive and detailed design patterns, paired to a personality/temperament model with mapped play/game characteristics.
Upper middle (analytical): the method considers the game in question as ‘ground truth’, and utilises structures from stage 1 to describe core play traits and game structure. Lower middle (applied): these gameplay features, which we term Behavlets, are codified as pseudo code, and integrated into or alongside the game for tracking.
Bottom (classify/predict): in our implementations of Behavlets, the adaptive phase involves predicting player actions from player models comprised of Behavlet features and classifying or reclassifying type based on accuracy of prediction.
The Behavlet approach is a way to model players based on variation of their dynamic gameplay behaviour. Behavlets comprise track-able player actions or sequences of actions, which provide insight into a deliberate decision making process. Behavlet profiles vary between players based on personality and may be dependent on other factors such as game type (hence the importance of an adaptive model). In this way the Behavlet model somewhat resembles a Hidden Markov Chain model. For example, in a computer game a player can usually move an avatar or some pieces. The way they move very often has qualifiers, such as fast/slow or cautious/aggressive movement, and these qualifiers can have a basis in player temperament which is not directly observable. To extract and characterise Behavlets, i.e. features codifying these behaviours, we start with the structural foundations of temperament theory and design patterns. These structures are refined to the specific case of the game, and the two structures are combined to give a lens through which the game is analysed, searching for feature descriptions. Identified features are given a working description in natural language. The working description is translated to a coded form; data is gathered, resulting in a Behavlet feature set; this set can be subjected to feature selection methods.
The entire process has four stages, containing respectively three, three, one and one modelling steps. The following description and flow chart, Fig. 2, outlines an iterative process for a game designer/developer (GD) and associated team:
Gameplay analysis and mapping
Game structure and context (leads to) \(\rightarrow \)
Game mechanics and dynamics \(\rightarrow \)
Game design patterns.
In this stage, GD should identify which game components deliver agency to the player, and thus are central to describing player behaviour. Further, GD must differentiate between game mechanics, the building blocks of game-play described by Constituative rules, and the dynamical operations of player–game interaction. Then design patterns specific to the game can be identified.
Traits of play behaviour \(\rightarrow \)
Traits versus patterns \(\rightarrow \)
Observation and Behavlets.
In this stage, GD specifies how behaviour would express itself. GD uses a list of descriptive terms for behaviour (given in Tables 2 and 3), to characterise how design patterns would turn into extended sequences of action selection. GD then observes the play of the game to develop Behavlet concepts.
For the informal Behavlet set from step 2, GD then defines pseudo-code and game engine encodings.
Feature set shape and select
GD performs feature selection to test individual Behavlet contributions and cull uninformative ones.
The process requires several theoretical contributions which follow in the next three sections. We define:
A simple method of game specification based on existing theories, centred on design patterns.
Behavioural traits of play based on temperament theory.
An approach for linking psychology to specification, and defining game play actions.
We make no contribution in the area of feature shaping/selection: many methods exist in the literature.
Gameplay analysis and mapping
In the first instance we need to understand a game’s design in more holistic manner; considering the game’s broader play, gaming, and cultural context. We propose an emphasis which draws upon three existing methods for modelling games and gameplay. The process is not strictly prescriptive which is why some domain expertise is important.
Game structure and context (descriptive focus)
In the first step, appropriate game components are chosen based on Björk and Holopainen (2005)’s model, shown below; these components help to define a game in terms of its whole context. They must satisfy the constraint relation provides agency: i.e. chosen components contain all game elements that enable the player to explore the possibility space of the game; all others are excluded. The set of sub-components chosen in Table 2 are a first approximation—any specific case requires reassessment.
Game mechanics and dynamics (analysis and design focus)
The second step further refines the lens on the game, by adopting in turn each of the core perspectives from Sect. 2.1: Mechanics/Constituative rules, and Dynamics/Operative rules. The goal is to clarify the scope of game components: to differentiate between the rules of the game and the dynamical operations of game-play. Mechanics can be expressed in terms of atoms of play (Cousins 2005); while Dynamics arise from an emergent process, which implies that they must be expressed only over several atoms: i.e. the scope is greater. Therefore, the scope of player and game actions must be defined, to distinguish those that can characterise player behaviours from more simple ones. The procedure for this is to identify, for any given action-oriented design pattern, the simplest possible atomic action sequence for the player, forming a loop based on Perception \(\rightarrow \) Analysis \(\rightarrow \) Decision \(\rightarrow \) Execution (PADE), with associated feedback coming from the game. This identified loop then enables discovery of more complex interactions, i.e. atoms versus molecules of play, which better serve to express temperament-driven behaviours.
Game design patterns (implementation focus)
Design patterns are specific, tried and tested, blueprints for implementation of facets of gameplay. We utilise game-specific design patterns following the methodology of Björk and Holopainen (2005), although strictly limited to the components and perspectives identified in steps one and two. Eleven pattern groups are provided in their method, from which we select the most relevant to list below (because there are over two hundred patterns, we do not list them individually here). These should be followed as listed, in order of importance to the expression of player behaviour, identifying patterns group by group.
Actions and Events Patterns
Game Design Patterns for Social Interaction
Game Design Patterns for Game Mastery and Balancing
Game Design Patterns for Game Elements
Game Design Patterns for Resource and Resource Management
Game Design Patterns for Information, Communication and Presentation
Game Design Patterns for Narrative Structures, Predictability, and Immersion Patterns
Game Design Patterns for Goals
Game Design Patterns for Goal Structures
Game Design Patterns for Game Session
Game Design Patterns for Meta Games, Replayability, and Learning Curves
A game can potentially be analysed and broken down using the above three stages in an iterative cycle, especially for a complex multimodal game: as each step is completed, insights into the game will grow, which will enable further specification at earlier steps. The outcome of analysis is gaining an understanding of a game, its design, play context and gameplay, so as to be able to be able to express the game in a detailed and practical manner.
We propose a further three-stage process to link the predispositions for action described by Temperament theory to the structural decomposition of gameplay elements as described above, e.g. patterns of game design described by Bjork and Holopainen (2006). These three stages facilitate the identification of Behavlet-type observable patterns of action, which are (as explained) like psychologically-grounded features of gameplay,
Traits of play behaviour
The relationship between the four archetypal skill sets of Temperament theory and the playing of games is shown below in Table 3, adapted from Bateman et al. (2011). The behaviour of these four player archetypes is marked by the abstract nouns given in the third column, which indicate how the play behaviour of each player type would be modified by that type’s preferences/tendencies. Given that type systems assume that every individual embodies each of its types to some degree, these behaviours are not to be taken as mutually exclusive. As mentioned above (Sect. 2.2), such behaviour is the key information on which to build our feature extraction method, going beyond the common verb-based description of gameplay; this behaviour serves to help target the search for descriptive patterns of play that can be coded as features.
Our method derives a list of high-level behavioural traits (from the ‘Behaves with...’ column), which can be expressed, either positively or negatively and to varying degrees, in most games and by most players. Play traits describe ways in which players explore the possibility space, reducing the uncertainty towards the game’s outcome. In this sense they are related to player types, which describe the way games can be enjoyed. Importantly, they are instantiated from a sequence of action selection choices, as these embody the mechanics of how the player explores the space/reduces uncertainty.
We are proposing a practical method to extract features, therefore we relate the behaviours more directly to play by providing synonymous terms which may be closer to the context of game play, easier to define in terms of the actions and reactions of play, and thus clearer for the practitioner/designer. All synonyms are given from Collins thesaurus. In Table 4, the ‘Applied Form’ denotes the term we prefer as best suited to the gaming context, and use throughout the test.
Our trait list thus comprises Caution, Thoroughness, Aggression, Decisiveness, Planning, Optimisation, Empathy, Fair Play, Resourcing, Speed and Control Skill. Separating these generic traits from game-specific features divides the space of reasoning about player behaviour into different levels of specificity and different focus areas in each game. This helps to build a method that is useful across a variety of game types.
Most games emphasise one or more of our traits, but few games force the player to adopt a particular style of playing; these traits therefore differ from the concept of a control scheme or modality. If a play style is forced by the game, then it is no use for distinguishing between players since all must play the same way.
Our high-level game-play traits were specified with regard to a concept of single-player, console-type play in contemporary games. Any game quantity not controlled or affected by players, whether or not it is recorded in metrics, should not be assigned to a trait. Since the emphasis is on ways that players express themselves in the game and how they interact with the mechanics of a game, their physical reactions (e.g. facial expression, galvanic skin response, other biometrics) were not considered (this issue was addressed in Cowley et al. 2014).
Traits versus patterns
Each of the Temperament theory archetypes also comes with a list of activities they are drawn to, given in column two in Table 3. This list acts as a guideline to relate behaviour traits to the game design patterns of Björk and Holopainen (2005), as exemplified in Table 5. Patterns are polymorphic templates for the design of potential transitions through the game’s possibility space, meaning they can be varied from instance to instance—e.g. the pattern ‘Limited Resources’ can imply quite different gameplay experiences from game to game, as for example the limited health and ammo in ‘survival horror’ games creates a strategic pressure, compared to the limited time for planning in ‘online shooter’ games, which creates time pressure. Thus patterns are the abstract expression of the behaviour defined by traits. Due to the large number of patterns, an extensive correlation with behaviour traits can only be done in the bounding context of a given game—but for reference, the example in Table 5 is expanded in Appendix E in Supplementary Material with seven pattern categories per preference, and over 600 associated patterns. This should supply the basis for any mapping of a computer game’s patterns to the archetypes.
The play patterns complement the traits in more complex games; they allow us to triangulate the meaning of a Behavlet by relating it to both a behaviour trait and a set of commonly-correlated features, i.e. a design pattern.
Observation and Behavlets
At the end of the third stage, we develop the set of Behavlet concepts, each relating to one or more trait-related play patterns. This has an observational component, working from the game analysis given above and searching for and registering distinct patterns of events. Observation can be done by watching game sessions, examining the game log, visualising game log data, etc. During observation, it will also be likely that a list of simpler ‘features’ of play are described. These can help when designing/coding Behavlets.
The intent of the player in performing each action sequence needs to be associated with a behaviour trait. The link between player intent and the expression of intent through player action should be as clear as possible, i.e. involve as little ambiguity as possible. Behavlets are thus subject to a condition, which we term the reasoning condition, defined as: the requirement that one must be able to reason over (or induce from) the raw game log data in order to derive a behavioural representation.
This condition implies that, without yet making exact logic statements, we need to consider whether it is possible to build a ‘constraint harness’ for each pattern. We define the term constraint harness as: a logic statement defined over the game engine variables which, when triggered, indicates the start of the relevant trait-related play pattern.
If it is clear that the pattern can be captured thus, an important question should be answered before including the Behavlet in the list: can it generate data? Alongside testing, this question depends on whether the constraint harness is internally consistent and feasible to run. If so, further effort should be given to characterizing the Behavlet. It should be given a short but descriptive name. One must decide if it is atomic or molecular, because play patterns reflective of traits will tend to be more complex than the atomic level.
Once defined, it is useful to consider whether the Behavlet relates to more traits than it was originally conceived for? This is likely to happen and even to generate highly correlated Behavlets, but that is acceptable and indicates good pattern coverage has been achieved.
Finally, for each observed Behavlet, a description of the observed pattern of play and associated trait is written in natural language. The goal here is to guide the algorithm development and coding that follow.
In this section we give guidelines for free coding of the Behavlets. Following the observational step, using a simple encoding scheme, we can generate a working representation of the actions that players can take, and the archetypal forms of behaviour that can shape those actions. Of course, coding the Behavlets depends largely on project-specific issues such as game engine language etc. Our scheme therefore only addresses how to turn the natural language into the appropriate algorithm to represent the Behavlet and capture the observed behaviour.
The basic algorithm, for a given Behavlet \(\beta \), is (for several simple examples, see Table 11):
To state this in plain English, iterating through the states from a raw data log file, the algorithm searches for constraint harness parameters to satisfy. These may take the form of one or many variables at some state, or at temporally distributed states. The constraint harness is a set of logic statements, and the parameters are simply numeric thresholds. The measurement function is likely to be a simple increment count, such that when the constraint is met, the variable for \(\beta \) is increased by one. So \(\beta \) represents a simple count of the number of times the play pattern has been performed. Or more complicated functions can be defined, such as a measurement of another set of state variables, separate to the constraint.
The procedure of algorithm specification involves deconstructing the Behavlet operation to the atomic level of state transitions. Once the state transitions required for the pattern are found, associated variables in a temporal pattern can be defined, and the constraint can be written, along with the measurement function.
Of course it is important to perform quality assurance during this procedure: to estimate the computability of the algorithm, its speed, and potential execution hazards (particularly when the constraint triggers on earlier states than the measurement function). These issues are simpler to handle when developing algorithms within the game engine, which will already provide the needed functionality for handling raw game log data.
Finally the algorithm description should be re-written using pseudo-code. The goal is to move toward an executable specification of the Behavlet, while still expressing concepts in terms of the player behaviour and not yet the engine code. As Dalbey says “the vocabulary used in the pseudo-code should be the vocabulary of the problem domain, not of the implementation domain” (Dalbey 2012). Dalbey also advises that the pseudo-code logic should operate at the level of a single loop or decision, so it can reflect the ‘atoms’ of gameplay already found and analysed in step 2 (Sect. 3.1.3). The pseudo-code should be simple and clear to read, and because the final coding of the Behavlets will be done in the language of the game engine, selecting a style close to natural language helps to avoid over-specification. Thus we suggest Structured English, a forerunner of the database query language SQL which should be familiar to many game designers (Davis 1983, p. 337).