Raph Koster, in his book A Theory of Fun, describes games as "puzzles to solve, just like everything else we encounter in life" (Koster, 2005, p. 34s). Puzzles and games alike are built on the foundation of their game mechanics; the mechanisms and functions that individuals use to engage a game and its environment with the ultimate goal of completing the game and finding the puzzle's solution. A good game can attribute its appeal and success with players to its well-designed, usable and effective game mechanics.
However, in the design of game mechanics, one crucial construct can often be overlooked in that individuals engage in different kinds of cognitive behavior when completing different kinds of activities and tasks. At their core human beings are "furious pattern matchers" (Reason, 1990, p. 66), and through daily life seek out the structure in all manners of activities, including playing games. In games, these structures and patterns take the form of game mechanics, and if a player is presented with a mechanic and is unable to process and understand its function in the overall structure of a game, they can get frustrated and give up (Koster, 2005, p. 25). As game mechanics today incorporate a wide variety of task and activities in the form of puzzles and obstacles to be overcome, they usually require different types of behavior and action from a player to complete them.
The issue with human cognition being left out of the design process arises in the development of the mechanics designed for use in completing a game's puzzles and obstacles. If a game's mechanisms are too easy to grasp, the game may "grow boring when they fail to unfold new niceties in the puzzles they present" (Koster, 2005, p. 42); if they are too difficult or complex, it may lead to player frustration. This leads to the question, is there a way of including a method of examining player cognitive performance and errors in the design and modification of game mechanics?
Skills, Rules and Knowledge Framework, a method which measures cognitive behavior and assists in determining what causes human errors, may be of potential use in the design and modification of game mechanics. In the first section of this paper both SRK framework and the types of human error will be detailed, along with examples of how SRK Framework has been applied since its initial development. The second section will focus on the definition and categorization of game mechanics, followed by a proposed application of SRK Framework to each category of game mechanic. Finally, implications for combining SRK framework with game design will be discussed with suggestions for future use.
The Skills, Rules and Knowledge Framework (or SRK taxonomy as it is sometimes called) is a method of measuring human cognitive performance and determining at what cognitive level particular tasks and activities are being performed. Developed by Jens Rasmussen, it defines behavior across three separate levels: Skills, rules and knowledge-based. It also provides information on the kinds of human cognition conducted at each stage.
Skills-based behavior is an activity or task that for the individual undertaking it, is a routine behavior. The task or activity is completed using "smooth, automated, and highly integrated patterns of behavior" (Rasmussen, 1987, p. 292), without the individual putting a significant amount of awareness or consciousness into the task or activity; it can be considered almost instinctual in nature. A fairly common example of a skill-based behavior would be riding a bicycle or driving a car. These are tasks that experienced individuals can accomplish without focusing too clearly on what they are actually doing. Instead, during a skill-based behavior, an individual's senses are focused on subconsciously keeping them oriented and informing them of changes in the environment (Rasmussen, 1987, p. 293) one's internal processes as to the progress of the Skills-based behavior, such as watching for road obstructions while driving a vehicle or riding a bike.
Mistakes at the Skill-based behavior level can occur on two different levels, overattention and inattention. Overattention is an interruption "of an action sequence at a time when control is best left to the automatic 'pilot'" (Reason, 1990, p. 73). An individual focuses too heavily on their progress and how they are trying to complete a task, resulting in errors or mistakes during the process. A Guitar Hero player may have difficulty in hitting the correct buttons on the controller to properly match up to the chords of a song if they are focusing specifically on the placement of their fingers on the controller rather than the act of playing the guitar itself. Inattention is related to an omission or interruption of a step in a skill-based behavior. Opening an email account to check for new messages but then closing it before reading any of them is an example of an omission mistake in a skill based behavior; receiving a phone call during the process of checking's one email account and then closing the email account once the phone call is over without reading any new messages is an example of an interruption.
Rules-based behavior is similar to Skills-based, in which the actions being taken to complete the task at hand are still, for the most part, commonplace to an experienced individual. However, there are additional checks and routines built in along with more cognitive and conscious effort placed on completing a task or action. Rules-based behavior is guided by a "stored rule or procedure...derived empirically during previous occasions, communications from other person's know-how as instruction" (Rasmussen, 1987, p.293) or through previous successes in problem solving and planning. While driving a car may be skill-based behavior for experienced individuals, other driving actions such as merging lanes or stopping at traffic lights fall under Rules-based behavior due to the additional cognitive and conscious effort required to successfully complete them.
Rule-based mistakes occur when an individual's stored rules are either sufficient to complete a task or solve a problem, but are misapplied and used incorrectly. It may also occur when the stored rule is actually insufficient or inadequate to assist in completion of an activity, but an attempt is still made to use it. An experienced individual, having dealt with a particular situation several times, may rely on their current set of rules that have allowed for that individual to achieve an acceptable outcome in the past- such as double checking mirrors when merging with traffic on a busy highway. The more and more successful traffic merges using that rule will lead to that rule becoming stronger, and the "stronger the rule, the less it will require in the way of situational correspondence" (Reason, 1990, p. 77) for that rule will be used. A mistake using a strong rule can occur when that rule is used incorrectly; an internally developed rule of double-checking one's mirrors before merging into traffic could lead to the failure of that task if applied at the wrong time or if distances between other vehicles on the road are misgauged while the mirrors are being checked.
The application of bad rules occurs when the rules being used to complete a task are inadequate to successfully complete that task, or the particular rule being implemented is inadvisable to the situation at hand. As an example of a rule being inadvisable, imagine the 'check engine' light of an individual's personal vehicle is active when they first turn on the ignition. If they turn the vehicle off, and then on again to see if the indicator goes away, and if it does, they assume the vehicle is perfect working order, that individual may potentially be making an inadvisable rule-based error. The problem that set off the 'check engine' light in the first instance may not have been resolved by the restart, even though the indicator itself is no longer active. Such a rule-based behavior isn't necessarily wrong in the sense that it "generally achieves its objective, though it may violate established codes or operating procedures" (Reason, 1990, p. 84), it's just not recommendable because of the potential to cause more problems.
Knowledge-based behavior occurs primarily when the activity being engaged in is a task an individual has never engaged in before. The individual has exhausted all of their options and problem-solving routines at the Skills or Rules-based level, and therefore has to use "slow, sequential, laborious and resource-limited conscious processing" (Reason, 1990, p. 57). In other words, the individual has to (either mentally or physically) research and experiment to find the best way to complete a task or achieve a particular goal. While an experienced individual may be able to operate a car with little effort and then navigate that car through traffic, if they have never undergone a road trip travelling cross country before, they would have to engage in conscious planning in order to successfully travel from point A to B. A goal would have to be established, based on the analysis of the environment and any objectives the individual may have, they would also need to develop a plan, either through trial and error in a physical sense, or more conceptually through understanding an environment's functional properties in addition to predicted outcomes of the plan being formulated (Rasmussen, 1987, p. 293). The same concept can be applied to experienced video game players; an individual that has been dedicated to playing games under the first-person shooter genre, and are unfamiliar with any kind of massively multiplayer online role playing game, would engage in knowledge based behavior in order to understand that game's systems and architecture.
Knowledge-based mistakes are somewhat more difficult to predict than either rules or knowledge based errors, particularly due to the fact that it involves solving a problem or completing a task an individual has little to no experience in handling as "uncharted territory" (Reason, 1990, p. 58). Usually errors at the knowledge-based level are centered on how an individual interprets the problem or task facing them. A type of knowledge-based error is the concept of 'out of sight, out of mind', in which an individual will use "only information which is readily available...to evaluate the situation" (Embrey, 2003 p. 8) when completing an unfamiliar task or trying to solve a problem. An example can be found in a 1978 study of how individuals can troubleshoot problems using 'fault trees' (an organized representation of the various explanations for a situation, usually in the form of a diagram). Fischoff et al (1978) gave their subjects an example scenario of a vehicle failing to start, presenting them with various versions of a fault tree diagram depicting all the potential reasons for why the vehicle might be malfunctioning. The subjects were instructed to examine the diagrams and judge them on if they considered all of the possible explanations for the hypothetical vehicle's issue. One of the more unique results of the study found was that subjects often overlooked the removal of branches in the various versions of the fault tree diagrams used, some of which had exclusions of very likely potential explanations such as 'battery failure' or 'ignition failure'. One of the possible reasons given was that subjects may have been ignorant; "there is no way to consider something that one has never heard of and that is not mentioned" (Fischoff, et al., p. 343). As both experienced mechanics and college students were interviewed, it's quite possible that many subjects committed a knowledge-based error because they relied primarily on the information they were given as to the hypothetical failure of a car, instead of considering additional factors which may have also been a cause.
Since its introduction, SRK Framework has been used by several different industries as a method in which to measure human cognitive level and to assist in determining both how errors occur and measure human performance. It has also been used as a basis for the development of new work models and user interfaces with the goals of decreasing errors and increasing performance.
Primarily, it has been used by Rasmussen in regards to the potential design and development of new interface systems. In his article "Skills, Rules, and Knowledge; Signals, Signs, and Symbols, and Other Distinctions in Human Performance Models" (1987), Rasmussen discussed the basics of the SRK Framework and the information processing characteristics of each level. In skill-based behaviors, collected information takes shape in the form of signals, or raw information in the form of "direct physical time-space data" (Rasmussen, 1987, p. 294). Signals assist in ensuring that the automated patterns of behavior that take place on a skill-based level, such as riding a bike, progress smoothly, by providing information about the environment. Signs refer to information perceived at the rule-based level, and serve to "activate or modify predetermined actions or manipulations" (Rasmussen, 1987, p.294), as rule-based behavior is commonly guided by procedures that have worked for an individual before. However, signs are limited to the selection or modification of rules controlling a rule-based process; they don't provide for problem-solving, rule development or the performance tasks at a knowledge-based level. Symbols, on the other hand, accomplish this as information perceived at the knowledge-based level; as "abstract constructs related to and defined by a formal structure of relations and processes" (Rasmussen, 1987, p.295), they are used in the problem solving and mental reasoning processes done when encountering an unfamiliar situation. In regards to interface design, Rasmussen proposes that a cognitive model based off of the SRK Taxonomy and how individuals process information through signals, signs and symbols would be beneficial to the development of new interface systems, as such a model would allow for the matching of performance categories to situation types (Rasmussen, 1987, p.296). The method in which information is presented from a complex system's interface needs to be designed in accordance with the tasks needed to be performed by a user, and what cognitive level those tasks may fall on.
Research into the development of interfaces and cognitively beneficial systems has also further expanded with Rasmussen's collaboration with Kim Vicente in regards to Ecological Interface Design (EID), a "theoretical framework for interface design for complex human-machine systems" (Rasmussen & Vicente, 1992, p. 589). Rasmussen's SRK Taxonomy was as a standard for describing the methods in which people process information, with the levels of the SRK being split into two separate groups. The first of which is analytical problem solving and knowledge-based behavior. The second group is centered on perceptual processing, where skills and rules-based behavior are included. The authors put forth that users of a system built for a complex work domain will have extensive experience and training, and that interface design for complex systems is highly specific into what information an application needs to convey and what it needs to be able to accomplish (Rasmussen & Vicente, 1992, p. 595). Therefore, individuals operating a complex work domain system will engage in skill and rules-based behavior based on their familiarity with the system, and to design interfaces with the goal of taking advantage of an experienced individuals perceptual processing would be beneficial. Analytical problem solving under knowledge-based behaviors can be implemented to deal with problems or events that occur outside of the complex work domain system and are not confined to "specific conditions (e.g., frequently encountered scenarios)" (Rasmussen & Vicente, 1992, p. 599). EID focuses on designing interfaces to boost an experienced individual's ability to complete familiar tasks efficiently at the skills and rules-based level while still maintaining the applicability of knowledge-based behavior should a situation require it.
SRK Framework has also been used in studies around several different types of industries to determine common errors and human performance. A two-stage study conducted of the aircraft maintenance industry by Hobbs and Williamson (2002) was based off of the hypothesis that a better understanding of the cognitive processing and work routines commonly employed by mechanics and workers in the field of aircraft repair and maintenance will lead to reduced risks to injury and maintenance errors. Using real-time observations of maintenance workers and mechanics, Hobbs and Williamson sought to determine the most common types of errors and accidents that could occur during a normal work day using SRK Framework. Participants were asked by observers at set intervals throughout a work day to briefly describe the activity they were working on, and then rate it according to a familiarity scale:
How would you rate the task you are doing right now?
The individual survey plus the observer's findings resulted in an approximation of what level on the SRK framework the particular activity lay, and if it possibly included behaviors from more than one SRK category. Additional interviews with participants about previous accidents and maintenance errors were also completed as the second stage of the study, breaking down each incident into three separate categories; behavioral, environmental, or equipment related (Williamson & Hobbs, 2002, p. 297). Overall, the information gathered allowed Hobbs and Williamson to determine the percentage of time committed to commonly completed tasks that were carried out on a day to day basis versus a monthly or yearly basis. This also led to their findings that those primarily rule-based and knowledge-based behaviors employed by the average maintenance mechanics could result in "more than twice as many rule-based errors and nearly three times as many knowledge-based errors as skill-based errors" (Williamson & Hobbs, 2002, p. 304). SRK Framework was helpful in this study in showing that focusing on reducing errors that may arise at the rule-based and knowledge-based level may help reduce accidents and incidents in the aircraft maintenance industry, as they appear to have been more common than skill-based errors.
Similar studies on human error and accidents in workplace environments have also been conducted, with the goal of using SRK Taxonomy as a basis for further models of error-type classification or for proposing organizational improvements. Saurin et al. developed an algorithm (in the form of a detailed flow chart) for classifying the errors and incidents encountered by front-line workers in industrial settings, using SRK Framework as its core concept (Saurin et al., 2008). Two field studies were conducted, one at an oil distribution plant, the other at a manufacturing facility that produced heavy machinery. Information on approximately 40 incidents out of a few hundred documented were gathered and summarized, before being evaluated using the SRK-based algorithm. The data collected suggested that the algorithm could be useful in the development and implementation of specific safety management strategies in an effort to reduce accidents and errors. The SRK Taxonomy could also be used potentially in the development of safety regulations made in response to certain kinds of errors, as "preventive measures will...have different emphasis whether they are focusing skill, rule or knowledge- based failures" (Saurin et al., 2008).
Overall, the SRK framework has certainly proven to be a versatile tool, however; like any method of measuring human performance it also has its drawbacks, especially regarding its implementation. One obvious issue with the use of SRK taxonomy is the apparent ease of assigning particular levels of cognition contained within the framework to specific activities, without thoroughly supporting the assignment with evidence or hypotheses as to why. Defining the act of typing on a keyboard as a skill based activity without clarifying the criteria used to make that determination, or not providing examples/studies as to why that activity could be classified that way will put the method at risk for a construct validity threat.
A good example of an assumption lacking support could be found in one of the previous studies mentioned. A small study by Bracco et al. (2008) used SRK Taxonomy as a basis for maintaining resilience in a system of operation. Citing a need for a more proactive organizational system with a focus on safety, Bracco et al. proposed a cognitively resilient model that would "dynamically maintain the circulation in the SRK framework", (Bracco et al., 2008) enabling operators to operate within rules-based behaviors by avoiding automatic, skill-based behaviors when possible. These proposed Skill-based behaviors in the proposed resilience model are best initially passed over in favor of developing rules and knowledge based behavior, which offer more experience and versatility that could possibly be shared with team members. The study conducted by Bracco and their colleagues on emergency room operations (2008) to support their proposal, while giving an example of how SRK Framework can be used to develop new organizational policies for a non-industrial field such as medical care; their study was limited to a single emergency room in a small Italian hospital with a staff of about 5 individuals (1 doctor, 3 nurses and one assistant). Only one emergency room case was observed, regarding the admittance of a 43-year-old Moroccan male with chest pain following a visit to a local police station regarding a fight (Bracco et al., 2008). Each step and the actions taken by the hospital staff are detailed out in their analysis; from the patient's admittance to the ER, to several echocardiograms, physical examinations (which revealed lesions) and blood tests and finally the unusual diagnosis of 'thoracic trauma' and transfer to an intensive care unit (Bracco et al., 2008). The actions of the staff are then broken down into different SRK categories:
The stretcher-bearers' description and the superficial decision of the hospital assistant contributed to set the SRK profile of the team at the S level, entering a cognitive tunnel that led them to treat this as a routine case... Nobody, including the doctor, moved from their cognitive level at the S stage, since they did not recognize either the ECG or the blood data as signs of an infarction, which required a move to the R level... (Bracco et al., 2008)
Bracco et al. felt that the hospital staff for the most part reacted at a skill-based level, only moving up to a rules-based level only when medical tests showed that the patient's case was not routine. However, if a researcher is using SRK taxonomy to measure human behavior and performance, additional observations, such as the ones conducted in Hobbs and Williamson's aircraft maintenance study (2002) which involved two separate airlines and at least four times as many participants, are needed to support the categorization of the actions and behaviors observed. While an explanation was offered that the activities of the hospital staff were at the skills-based level due to how "it was quite common to see Moroccans with lesions due to brawls" (Bracco et al, 2008, p. 6) in that particular ER unit, that must be the explanation for the actions of the hospital staff. Yet, since no additional cases are included in the study, the weight of that argument and Bracco et al.'s proposed organizational policies is lessened.
To summarize, if SRK Framework is going to be used as a method of measuring cognitive behavior, multiple examples or a larger study than the one conducted by Bracco et al. is needed for better support. Also, more clearly defined guidelines as to how one is determining an observed behavior would fall into what level of the SRK Taxonomy is needed.
When we play games, typically we are engaging with a system that allows us to interact with the game. Even the simplest of games like "rock, paper, scissors" has a structure and pattern to it in the form of a game mechanic, and the incredibly complex games found on the market today undoubtedly contain similar complex systems comprising of multitudes of functions and mechanisms for the player to use. However, an issue arises as to what exactly constitutes a game mechanic. Lacking from the game industry is what could be described as a solid, "unified definition of game mechanics that gives... a practical base upon which to build" (Cook, 2006, p. 1) and design games. Currently, there are various definitions that offer similar, but varying explanations as to what a game mechanic is; in order to best determine how SRK Framework can be applied to game design; some clarification of what defines a game mechanic is needed.
Lundgren and Björk (2003) offer the definition that a game mechanic is a simple construct that specifically covers a single type of interaction within the larger rule system present within a game, or is a much larger collection of game mechanics that follow similar constructs under the watch of a primary mechanic. In this sense, the rule system of a game may have multiple game mechanics, covering either a general or specific aspect of the game. An example of this would be a trading mechanic in a strategy game; the aspect of that mechanic would be that players can possibly trade with each other during a game. More specific mechanics would cover the specifics of what, when, and how players can trade, (Lundgren and Björk, 2003). Sid Meier's Civilization IV follows along this game mechanic definition; players are able to trade resources with each other or AI-controlled players, the act of trade representing the general mechanic/collection, and then various mechanics control what can be traded at what time. Specific mechanics within the general mechanic of trade in the game control exchanging of resources, technology, cities, and units amongst players; this can be done provided certain requirements are met. A player wishing to trade maps of the game world with other players need to have a specific technology to do so, and in order to trade in-game resources, players must have trade routes established with each other (Firaxis Games, 2005). A game mechanic is more or less a rule of the game and based on how a player interacts with the game rules.
Similar definitions, such as game designer Daniel Cook's definition of game mechanics being "rule based systems / simulations that facilitate and encourage a user to explore and learn the properties of their possibility space through the use of feedback mechanisms" (Cook, 2006, p. 1) continue on with the discussion of game mechanics being a rule or set of rules in regards to the game environment, but also considers the player's relationship with the mechanics as well. First, a player performs an action in the game environment. This in turn causes an effect within that environment, providing the player with feedback as to the results of the initial action. Using that feedback, the player can then perform another action to cause another effect and in turn gain more feedback, and so on and so forth. The key aspect of Cook's offered definition of a game mechanic is that exploration of the game environment through action and feedback is a primary requirement in order for a game to be considered a game. Cook provides an example:
I can put a black box on the table with a hidden button. Unbeknownst to a potential user, pressing the button enough times and the black box will spew out a thousand shiny silver coins. This is not a game. This is a bizarre gizmo. (Cook, 2006, p. 3)
Under Cook's definition, three criteria need to be fulfilled in order for a game mechanic to be considered a game mechanic. First, a mechanic needs to instruct the player as to what actions to take, enable the player to ability to clearly see the impact they have on the game environment, and provide information as to the possible end result of their interactions. A "system that encourages learning through strong feedback mechanisms" (Cook, 2006 p. 4) and meets those three requirements can be considered a game with developed game mechanics.
Sicart (2008) in his article "Defining Game Mechanics" offered a formal definition of game mechanics, based off an examination of previous and current research into both game mechanics and game design: "Game mechanics are methods invoked by agents, designed for interaction with the game state" (Sicart, 2008, p. 5). In breaking down this definition, methods are the behaviors, actions and functions available within the constraints of a game environment to the 'agents' , which are any involved parties in the game; a human player, an AI or a part of the computer system can be considered agents that can interact with mechanisms present within the game. Sicart states that in including AI/Computer systems under the umbrella of being 'agents', it helps provide information to the stability of the game system as a whole; if the actions of an AI controlled character aren't bound to the constraints of the game world just as a player's actions and behaviors are, it may cause instability in the game's other mechanics. The same can be said in the case of the AI having access to actions or behaviors unavailable to the player (Sicart, 2008) and considerations aren't taken to ensure that the AI-only actions do not disrupt the overall game system.
For the purposes of this thesis, Sicart's (2008) definition of game mechanics will be used in comparison to Rasmussen's SRK Framework, with some modifications made in regards to focusing on human players as the agents in the definition, and taking into account their cognitive behavior. The measurement of AI players and computer systems is unfortunately beyond the scope of this thesis. Lundgren and Björk's (2003) division of how there are general and specific types of mechanisms present in a game environment will also be used in conjunction with terms of dividing types of game mechanisms into three separate categories: core, primary and secondary game mechanics.
In game design literature, game mechanics are often categorized without a clear description of which concept of game mechanics is being used (Sicart, 2008). Most game mechanics can be described as "usually just a function...given a certain input" (Sigman, 2009) to create a certain result, but given how common versus how rare a game mechanic can be in a game environment, and how multiple game mechanics can be used to achieve the same end state, or the actions/behaviors available in a mechanism, it is necessary to draw lines between certain types of mechanics so as to differentiate between their place and influence over a game environment. Following along with Sicart's (2008) definition of game mechanics, for the most part game mechanics can be split into three separate categories.
Core mechanics are mechanisms that are repeatedly used throughout a game environment by an agent in order to complete an overall objective of the game or achieve an "end-game state" (Sicart, 2008). In essence, these can be described as basic, commonly available mechanics; moving forward, backward, and left to right in a first person shooter such as in Infinity Ward's Modern Warfare 2 can be considered a core mechanic because without movement the player cannot accomplish any of the goals of the game's single or multiplayer campaigns. The same could be said for looking around and jumping, which are additional actions that can and sometimes need to be repeatedly used in MW2 (2009) to accomplish goals and achieve an end-game state. Other examples of core mechanics could include the gathering of resources in a real-time strategy game; a common aspect of the genre, this action in conjunction with other mechanics (described below) gives players the means in which to defeat opponents or complete objectives through spending those resources.
Primary mechanics can be understood as core mechanics that can be directly applied to solving challenges that lead to the desired end state. They are "readily available, explained in the early stages of the game, and consistent throughout the game experience" (Sicart, 2008, p. 10). Like core mechanics, primary mechanics are always available to the player, but usually with the exception of a basic requirement (or requirements) being met first. In order to fire a weapon and attack opponents, a primary mechanic in Modern Warfare 2, a player must first have one equipped in order to engage in this action (Infinity Ward, 2009). Some primary mechanics may also require the use of core mechanics at the same time; Electronic Arts' survival-horror game Dead Space, for the Xbox 360, Playstation 3 and PC, has an example of a game mechanic that includes this type of prerequisite. In the game, the player (as engineer Isaac Clarke) is faced with the task of defeating a variety of undead monstrosities called 'necromorphs', who can only be killed by using "strategic dismemberment" (Pellet, 2008) to remove the limbs of attacking enemies (EA Redwood Shores, 2008). The player can use the commonly available core mechanics of looking and aiming in the game, and provided, they have a weapon equipped, also use the primary mechanics of dismembering to defeat enemy necromorphs in order to progress and complete objectives (and therefore the game).
Secondary game mechanics are any kind of mechanism that can "ease the player's interactions with the game towards reaching the end state" (Sicart, 2008, p. 10), but aren't necessarily needed or are only available during certain points within the game environment. They may also only be available for use in conjunction with primary game mechanics. While aiming and firing weapons at opponents is considered to be a primary mechanic in Modern Warfare 2 (2009), the player also has access to a short-range melee attack (using a combat knife) for use in dispatching enemies. The knife and its corresponding melee-attack could be considered a secondary mechanic as it is not required of players to use it solely for reaching an end-game state, and can be used in combination with the primary shooting mechanic of the game. And since it's a melee attack, only in certain circumstances, i.e., a close quarter's battle, can the knife be used to attack enemies. Dead Space (2008) also has a similar secondary mechanic available to the player; Melee-attacks can be performed to push enemies back or to injure them, however the melee option falls short of enabling the player to destroy attacking enemies as efficiently as does the primary mechanic of using weapons. The option is available to the player, but fits the criteria of being a secondary mechanic since it "cannot be used exclusively to solve the main challenges" (Sicart, 2008, p. 10) of Dead Space. In addition, several games in the Role Playing Game genre have multiple examples of secondary mechanics; in both Blizzard North's popular action-RPG Diablo II (200) and more recent post-apocalyptic-themed Fallout 3 (Bethesda Game Studios, 2008), there are secondary mechanics in the form of optional 'side-quests' outside of the main story objectives of the game either presented alongside the main objectives or needing to be 'found' by the player. Players are not required to complete side-missions in order to reach an end-game state, but in doing so, can earn rewards through the form of RPG standards such as unique items or additional experience. This allows the player to use optional quests as secondary mechanics to assist them in their interactions with the main objectives of the game, but not requiring it of them.
Currently, most varieties of games on the market today try to include multiple game mechanics from all three categories within their design. However, given the complexity of games on the market today versus games developed one or two decades ago, it could be argued that the concepts of core, primary and secondary mechanics are no longer sufficient enough to contain all of the potentially definable game mechanics. Several of the best-rated games of 2009, such as Modern Warfare 2, Braid or Empire: Total War (Dietz, 2009) all include game mechanics that could potentially fall beyond the three categories discussed previously, and the vast number of mechanics used in games with expansive game worlds such as Fallout 3 or Grand Theft Auto IV could lend weight to the argument that some constructs of game mechanics are useless (Sicart, 2008). More detailed analysis of this concept is needed but is outside the scope of this thesis.
Initially, given the previous definitions of game mechanics and the examples provided for each one, it may appear easy to apply SRK Framework to the different categories of game mechanics and separate them into separate levels of cognitive behavior. However, there are several criteria that should be used first to determine at what level in the SRK taxonomy a game mechanic would fall in. These criteria are meant to assist in avoiding the pitfalls discussed earlier in regards to the SRK-related study conducted by Bracco et al. (2008).
How commonly the game mechanic is used (or meant to be used) within the game should be a major consideration in the placement of the game, given how an individual may become more and more experienced at a game mechanic the more times they use it; as stated before in the discussion on SRK framework, and in particularly rule-based behavior; often the more time an individual is successful in using a specific action or behavior to complete an activity, the more likely they are to use that action again (Reason, 1990). Secondly, the kind of tasks/activities being undertaken in the game mechanic needs to be taken into account, as there are significant differences between tasks that can be completed using a skill-based behavior versus those that require a rules-based or knowledge-based behavior. Finally, whether the game mechanic in question is a core mechanic essential to game play or a secondary mechanic that is available to the player but not necessarily needed or required for use by the player also needs to be factored in.
Starting off with skill-based behavior, both core game mechanics and primary game mechanics may fall under this category, albeit in the case of primary game mechanics, there are some conditions that should be met first. As stated before, skill-based behavior often refers to the "smooth execution of highly practiced" actions (Embrey, 2003) and are nearly automatic and pre-programmed due to the little amount of conscious effort put into the behavior. Core game mechanics, as commonly repeatable actions available throughout the entire game (Sicart, 2008), can be considered on the skill-based behavior side of the SRK Framework; simple actions common in a game such as movement, looking around, jumping, are simple in nature and only require basic input from the player.
Some primary mechanics also fall under this category as well, depending on the actions required to complete them and frequency of their availability; Players have the ability to aim down a weapon's sights in Modern Warfare 2, provided they have a weapon equipped (Infinity Ward, 2009), and this action requires two basic inputs from the player to accomplish. In the default control scheme for the Xbox 360 version of MW2, players hold down the left trigger to aim down the sights of their equipped weapon and then use the right analog stick to aim at specific areas around the game environment. Since looking around and aiming is a very common activity in MW2 and only require basic input from the player to be accomplished, it best fits the description of being a skill-based behavior.
Figure 1 - SRK Framework and the proposed application to the categories of game mechanics.
Rules-based behavior on the SRK framework would encompass the majority of primary game mechanics. As rule-based behavior is composed of processes in the form of a "stored rule or procedure" (Rasmussen, 1987) commonly used to complete an activity, primary game mechanics are also commonly used by players to complete tasks or objectives in a game environment. Furthermore in the use of primary mechanics, players usually have to meet or follow some form of basic requirement (such as having an item/weapon equipped, using a core mechanic like movement in conjunction with the primary mechanic, etc), resulting in the player conducting more active reviewing of their input; this is also something done in rules-based behaviors in the form of "feedback correction" (Rasmussen, 1987) and more conscious reviewing of one's performance. Some secondary game mechanics, provided some prerequisites are met first, may also fall under this category. Secondary mechanics are meant to be non-vital, optional, or with limited availability throughout the game but still may have similar attributes to primary mechanics; meeting similar basic requirements in a secondary mechanic present only within a small section of the game environment same type of internal review found in rules-based behavior as is in primary.
The aforementioned Dead Space (2008) mechanic of "strategic dismemberment" is an example of primary game mechanics fitting under the level of rule-based behavior; when encountering enemy characters, players need to aim specifically for their enemy's limbs, appendages or tentacles in order to remove them from the game-state. The typical player goes through the step-by-step process of arming their weapon, aiming at one of their target's limbs or weak-points, firing the weapon until that limb is removed, and then repeating the process until their target is destroyed. Feedback is then provided to the player in terms of the enemy reactions. Through successful hits with an equipped weapon, players can "slow most bipedal enemies down by aiming for their legs" (Segers, 2008, p. 2) or disable them completely. By consciously reviewing their progress, players are able to adjust their processes when engaging with an enemy to ensure that the task of destroying them can be completed successfully. Some similar secondary mechanics in Dead Space also fit under rule-based behavior; the player has to man a fixed gun position through two different sequences spread out through the progress of the game. These sequences are secondary as they are limited to only those two separate occasions; the player has to shoot down incoming asteroids in the first sequence to prevent their ship from being damaged and/or destroyed and goes through the similar processes of aiming at targets and then firing to complete this activity. The player is able to enact feedback correction (Rasmussen, 1987) based on information they receive from the game environment; for example, along with head's up display giving information on the player's health, too many asteroid hits and the player's location begins to take damage and catch on fire.
The knowledge level in the SRK framework best covers secondary game mechanics, as knowledge-based behavior centers around an individual's lack of familiarity in completing a particular activity, or the exhaustion of all options/behaviors at the skills or rules-based level (Reason, 1990) needing the involvement of set goals as well as research in order to successfully complete an unfamiliar activity. Secondary mechanics, being non-vital, optional actions available to the player, more than likely fit under this category because engaging in secondary mechanics is more or less voluntary. It is less likely that a player will necessarily engage in them unless they feel it would be of benefit to their overall progress within the game's environment.
Looking back to side-quests in RPGs as secondary mechanics, there are multiple optional missions present in Fallout 3 that the player must engage in active problem solving and planning using knowledge based behavior. As an example, Oasis, an "amazingly fertile, verdant dot hidden among the desolation" (Hodgson, 2008, p. 193) of the game environment, is a location that has a side-quest available to the player that yields several different kinds of rewards based on the actions the player takes during the quest. However, to locate Oasis in the first place, the player has to engage in knowledge-based behaviors through problem solving and planning. The whole act of finding and completing the Oasis quest only occurs once in the entire game, requiring the task of locating the area, which in turn requires planning and research in order to accomplish like the vast majority of locations in Fallout 3 Oasis does not start out marked on the player's map. If a player wants to complete this side quest, they have to go through the following steps: They must first set the goal of finding the whereabouts of Oasis, and then start to research how to reach that destination. In-game, this can either be accomplished through communication with certain non-player characters, actively searching through each map grid in Fallout 3's game environment until finding Oasis, or through an encounter with a hostile non-playable character called the Drifter carrying the coordinates at a separate location (Hodgson, 2008).
With the previous examples of how SRK taxonomy can be applied to classifying current existing game mechanics into separate categories of cognitive behavior; we can now examine the potential of using SRK framework in the overall design of game mechanics during their development.
All core mechanics, as always commonly available methods for a player to engage with the game environment (Sicart, 2008), shouldn't need more than a skill-based behavior to operate. As the first and foremost mechanisms used by the player, core mechanics should only represent a minor obstacle for players to overcome initially for the purpose of establishing their place in the use of later, more complex puzzles or obstacles later on. If a player is engaging core mechanics at a rule-based or knowledge based level, it may indicate that the player is having trouble in deciphering the pattern inherent within its function, which in itself indicates that the core mechanic may belong in a different category or needs to be simplified. As skill-based behaviors center on activities and tasks that are engaged at an individual's automated, instinctual cognitive level, so should a game's core mechanics require basic input and have simple controls. And while there is the concern that if core mechanics and their patterns are too easy to grasp, it may lead to player boredom, this can be considered an acceptable risk, especially with the implementation of primary and secondary mechanics as a player learns the patterns of game's core mechanics," more novelty is needed to make a game attractive" (Koster, 2005, p. 39), and this can be done through primary and secondary mechanics.
Primary mechanics should be based around rules-based behavior, but also include the potential to be engaged at a skill-based level depending on the types of tasks and activities built into the function. As discussed before, Modern Warfare 2's (2009) primary mechanic of aiming and shooting can fall under a skill-based behavior due to the basic input required of the player in regards to performing this activity. Similarly designed primary mechanics can follow the same suite. More detailed primary mechanics like Dead Space's (2008) dismemberment mechanic can be built around rules-based behavior, as the pattern of the mechanic has some basic requirements to meet, one of which is for the player to be more cognitively aware of their performance in using that mechanic, i.e. scoring successful hits against an enemy's weak points. Furthermore, primary mechanics should rarely be engaged at the knowledge-based level beyond the first few times the player uses that mechanic to engage with game environment. Like core mechanics, if a player is still using the "slow, sequential, laborious and resource-limited conscious processing" (Reason, 1990, p. 57) of knowledge-based behavior for a primary mechanic even after several times of trying to use it, at which point a player normally would have developed their own stored rules and procedures (Rasmussen, 1987, p. 293), it may be an indicator there is an issue with the way the mechanic is designed or in the way information about the primary mechanic is being conveyed to the player.
Secondary mechanics may be a little more difficult to design using the SRK taxonomy as a guide, as again, they are usually optional, non-vital or limited in their use and placement in the game environment. Designing secondary mechanics like Modern Warfare 2's knife/melee attack can follow rules-based behavior similar to how primary mechanics do; the player would use a procedure derived through previous experience as stated by Rasmussen (1987) and Reason (1999) in engaging with the secondary mechanic, it just would not occur as often during the player's progress as it would with a primary. The amount of use the secondary mechanic may get should be taken into account as well. More complex secondary mechanics, with the example of RPG side-quests like the Oasis mission example from Fallout 3 (2008), could benefit from their uncommonness; the assumption can be made that players interested in pursuing secondary game mechanics will engage in knowledge-based behavior in order to comprehend them in the first place, and then follow through with planning, goal setting and research in order to complete them or use them to achieve an end-game state.
As potentially useful as SRK Framework may be to categorization and modification of game mechanics, however, it is not without several limitations that affect its use. Since SRK Framework was not developed with the manner in which the game industry produces games, several points need to be considered in its use.
Primarily, SRK framework is more efficient at identifying where mistakes and problems are occurring in a system or environment that has previously been established. The studies previously conducted by Hobbs and Williamson (2002), and Saurin et al. (2008) have all used SRK framework in their studies to retroactively determine areas in which improvements could be made to increase human efficiency or reduce human errors, but in the context of examining procedures and methods already in place. SRK Framework is less efficient at proactively finding issues or areas where mistakes will be made.
In the design and modification of game mechanics, SRK Framework would be limited to the window of time during a game's production rather than after the game has been completed and its mechanics finalized. Post-release adjustments made to a game's mechanics run the risk of causing confusion or frustration in the player; switching the primary mechanics of a large scale game such as Fallout 3 may even go so far as to 'break' the game and lead to players dropping their interest.
Within the constraints of a game's production cycle, specifically the pre-production and quality assurance phases, SRK framework would be best applicable to assist in assessing game mechanics. As it's more efficient in retroactively finding issues then proactively, SRK Framework can be used to review the first iterations or prototypes of a game mechanic or feature to point out errors or potential problem areas to address with later iterations. Once the mechanics progress beyond the drawing board, however, SRK Framework isn't applicable until actual implementation testing of game mechanics involving players using the game. During play-testing, SRK Framework can be brought back in to develop observational and interview methods (Not unlike the study conducted by Hobbs and Williamson (2002)) to assess player interaction with the game and its mechanics.
To summarize, SRK framework, as a method of measuring human cognitive behavior and determining errors, has been of benefit to other industries present today in finding problem areas affecting performance. Many current industries have used it to assess their processes and procedures in an effort to reduce the possibilities of human errors, as well as increase efficiency.
In its application to game design, SRK Framework can be used by designers to develop and modify game mechanics to best fit the types of cognitive behavior the player would engage in when using those mechanisms in a game. In adjusting game mechanics using SRK, it may provide solutions to the common issues of player boredom and frustration through categorization of how individuals complete tasks. It may also provide information on how to best adjust a game mechanic's difficulty, so that it remains within the boundaries of being understandable, but not too easy to grasp so as to lead to player boredom, and challenging, but not so difficult so as to lead to player frustration.
For more research into the applications of SRK Framework to game design, a more solidified and formal definition of what game mechanics are will be required. In addition, a detailed and formal categorization of the differing types of game mechanics will assist designers in using SRK Framework to assess the functions of a game's mechanisms in comparison to the differing levels of human cognitive as well as ensuring their patterns are being effectively communicated to their players.
You can contact the author of this piece at [email protected].
Bethesda Game Studios. (2008). Fallout 3 (Version 18.104.22.168) [Computer Software]. Rockville, Maryland: Bethesda Softworks.
Blizzard North. (2000). Diablo II (Version 1.12a) [Computer Software]. San Mateo, California: Blizzard Entertainment.
Bracco, F., Gianatti, R., & Pisano, L. (2008). Cognitive Resilience in Emergency Room Operations. Retrieved October 31st, 2009 from https://www.resilience-/engineering.org/RE3/papers/
Cook, D. (2006). What are game mechanics? lostgarden.com. Retrieved on December 11th, 2010, from https://lostgarden.com/2006/10/what-are-game-mechanics.html
Dietz, J. (2009). The Best Games of 2009. Metacritic. Retrieved January 20th, 2010, from https://features.metacritic.com/features/2009/the-best-games-of-2009/
EA Redwood Shores. (2008). Dead Space [Software]. Redwood City, California: Electronic Arts.
Embrey, D. (2003). Understanding Human Behavior and Error. Retrieved January 7,
2010, from https://www.humanreliability.com/articles/Understanding%20Human%20Behaviour%20and%20Error.pdf
Firaxis Games. (2005) Side Meier's Civilization 4 (Version 1.74) [Computer Software]. Sparks, Maryland: 2K Games.
Fischoff, b. Slovic, P., Derby, & Lichtenstein S. (1978) Fault Trees: Sensitivity of Estimated Failure Probabilities to Problem Representation. Journal of Experimental Psychology; Human Perception and Performance, 4, p 330-344.
Hobbs, A., & Williamson, A. (2002). Skills, rules, and knowledge in aircraft maintenance: errors in context. Ergonomics, 45, 290-308.
Hodgson, D. (2008). Official Game Guide: Fallout 3. Roseville, CA: Prima Games.
Infinity Ward. (2009). Call of Duty: Modern Warfare 2 (Version 1.07) [Software]. Encino, California: Activision.
Koster, R. (2005). A Theory of Fun for Game Design. Scottsdale, Arizona: Paraglyph Press.
Lundgren, S. & Björk, S. (2003). Game Mechanics: Describing Computer-Augmented Games in Terms of Interaction. Terms of Interaction. Proceedings of TIDSE 2003. Retrieved December 11th, 2009 from https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.5147
Pellet, M. (2008) Dead Space (Review). Xbox World 360 UK. Retrieved December 29th, 2009, from https://www.gamesradar.com/xbox360/dead-space/review/dead-space/a-2008101413721934082/g-20070924145143734032
Rasmussen, J. (1987). Skills, Rules, and Knowledge; Signals, Signs, and Symbols, and Other Distinctions in Human Performance Models. In A. Sage (Eds.), System Design for Human Interaction (291-300). New York, NY: IEEE Press.
Rasmussen, J., & Vicente, K. J. (1992). Ecological Interface Design: Theoretical Foundations. IEEE Transactions on Systems, Man, and Cybernetics, 22, 589-606.
Reason, J. (1990). Performance levels and error types. Human Error (pp. 53-96). New York: Cambridge University Press.
Saurin, T.A., Guimaraes, L. B. M., Costella, M. F., & Ballardin, L. (2008) An algorithm for classifying error types of front-line workers based on the SRK framework. International Journal of Industrial Ergonomics. Retrieved on January 2nd, 2010 from https://www.producao.ufrgs.br/arquivos/disciplinas/103_in_press_human_error_ijie_2008.pdf
Sicart, M. (2008). Defining Game Mechanics. Game Studies, 8, retrieved on December 11th, 2009 from https://gamestudies.org/0802/articles/sicart
Sigman, T. (2009). Anatomy of a Game Mechanic. Gamasutra. Retrieved December 11th, 2009 from https://www.gamasutra.com/view/feature/4091/anatomy_of_a_game_mechanic.php
Segers, A. (2008). The GameSpot guide to Dead Space. GameSpot Game Guides. Retrieved on December 29th, 2009 from https://www.gamespot.com/features/6200144/index.html?tag=gameguide;header
I'd like to thank my thesis committee; Malyn Segarra, Shawn Stafford, and Adams Greenwood-Erickson, for all of their help and assistance with writing and editing this paper.