Progress, Regression, and Advancement

The Situation model is built on the notion that the game experience involves both the player and the game. The player, as represented by attributes, and the game, as represented by the available inputs and outputs.

As such, when using the Situation Model to define other aspects of design, it is important to keep both the player and the game involved.

In this article, we will begin to discuss multiple Situations. That is, how Situations flow from one to another.

The Result of a Situation often presents the user with a new Situation. Progress is what happens when a Result generates a new Situation that the player feels is moving further through the game. Specifically, the player gets the impression that the game is moving towards the player's own goals, whatever those might be. Regression is what happens when a player feels that the Result generated a Situation that is farther from the players goal.

In essence, Progress is the player's desire, while Regression is what the player wishes to avoid. Progress is positive, Regress is negative.

Advancement is a different concept. As the player plays the game, Knowledge and Experience are accumulated. Whether the player is Progressing or Regressing, these two attributes are always increasing. A player can learn from falling into a pit and dying. A player can learn from leaping over the pit and continuing on his way.

The specific sequence of Situations that a player plays through is that player's Advancement through the game. Advancement is always positive, in the sense that the player is always accumulating Knowledge and Experience.

Advancement is a far more useful design concept than either Progress or Regression. By studying how a player may advance through a particular game design, the designer is able to gleem some insights into what Knowledge or Experience a player may have deduced. On paper, the designer can map out a particular sequence of Advancement and determine if the player is reasonably able to handle a particular Situation at any point along that sequence. The question of, "How many lives would it take a player to get past obstacle X" is a question of Advancement, not Progress or Regress.

Complexity, Risk, and Challenge (WTP 3)

One of the powers of the Situation Model is to be able to accurately defined the concept of Challenge.

Really, it's fairly simple. First, let us divide the Situation into Domains, each named for the three actions that the player is capable of taking. So there is the Reason domain, the Ability domain, and the Comprehension domain.

But, before we can deal with Challenge itself, we need to define two other terms.

Let Risk be the relative potential for the player's actions in the Situation to produce negative consequences towards achieving the player's goal.

There are two degrees of Risk. One degree is the quality of the negative consequences. IE: how badly does it hurt the player to fail? The other degree is the quantity of the negative consequences. IE: how likely is the player to fail? How much of the Mapping Table is dedicated to paths that lead to failure rather than success? Or, put another way, how many Game Inputs are there that lead to success rather than failure?

Let us define the first degree to be Risk:Pain. The second degree will be Risk:Extent.

Risk, in either degree, is a fundamental quantity of a Situation. It is not affected by the player's skill set or body of accumulated wisdom. As such, it is not enough to be able to define what a Challenging Situation is. After all, what is hard when you first begin to play is not nearly as hard at the end.

Since the player's Reason, Ability, and Comprehension are all fixed by the Situation Model, only Knowledge and Experience can explain the changing nature of Challenge. So, now we introduce Complexity.

A Situation's Complexity is a descrition, for each domain as defined above, of the body of Knowledge and/or Experience needed to feed into the player's attributes to successfully deal with the Situation at hand. The more Knowledge and/or Experience, the greater the Complexity.

Complexity exists in each of the three domains, and it should be looked at separately for each.

Complexity in terms of Reason means that it requires pulling in disperate Knowledge in order to device a correct plan that will create the desired Result. The greater the body of Knowledge required to find a viable solution, the more Complex the task of using that Knowledge becomes.

However, reason has the honor of being the only domain fed by both Knowledge and Experience. So it gets a second pass. Reason must also estimate the likelihood of being able to execute the Player Input into Game Input, and the player's Experience informs this. However, greater Experience serves to decrease this form of Reason-based Complexity. Greater Experience means that the player is capable of doing more, providing more complex input, and doing so more accurately. Thus making more complex input easier for the player to achieve.

This also requires a degree of Risk analysis. The player must use the Knowledge of the Risks (which may not be complete, of course) to determine if the player's Experience is enough to be able to hit one of the correct solutions. Risk:Pain makes one wary of confronting the Situation at all (if the player has a choice), while Risk:Extent puts a stress on evaluating one's Experience for confonting the Situation.

Reason-based Complexity, therefore, has two degrees: Complexity:Reason:Knowledge and Complexity:Reason:Experience.

Ability-based Complexity is fed only by Experience. The decision of what to do has been made, and now it must be effected and transformed into Game Input. This Complexity represents the quantity of Experience one needs in order to properly manipulate the user interface to turn Player Input into Game Input. Or, in simpler terms, it represents how skilled a person must be at using the UI in order to command a particular Game Input. Thus, giving rise to Complexity:Ability.

Comprehension-based Complexity is fed only by prior Knowledge. Complexity in Comprehension means that it requires a large quantity of accumulated Knowledge to properly Comprehend a particular Result. The phrase "properly Comprehend", is intensionally nebulous.

Particularly of the Player Input that was used to produce this Result. From that, the player can actually reduce later Complexity (which we will discuss more later), by being able to apply previous victories in new Situations. Rather than later having to use Reason to cobble together some attempted solution, the player need only take an already proven solution and modify it for a new Situation. This proven solution, of course, is represented as Knowledge and/or Experience.

Which gives us Complexity:Comprehension.

So, what is Challenge? Well, quite simply, Challenge is any and all of these. A Situation is said to have a degree of Challenge when any of the 6 aforementioned degrees is involved to any significant extent.

Challenge therefore has 6 pimary degrees that a designer can theoretically adjust. Each of those degrees can be adjusted in a myriad of ways.

Risk of all forms provides the player with negative Results. The player does not (presumably) want negative results, so the player attempts to avoid them.

A high degree of Risk:Pain means that the player has a strong wish to avoid failure. It means that the player is going to be in a mental state of stress on the possibility of failure. Planning to avoid the pain is therefore very crucial; this degree plays towards the player's Reason and Comprehension, as well as Knowledge and Experience.

A high degree of Risk:Extent means that there are many pitfalls. The player must take extra care to provide the correct Game Input to select the right Result. This degree plays towards the player's Ability and Experience.

Complexity, of all forms, confounds the player. It makes the player's task harder by placing greater demands on the players attributes.

Complexity:Reason:Knowledge means that the player must use a great deal of accumulated Knowledge be successful in this Situation. Devising strategies is one example of this.

Complexity:Reason:Experience is all about stressing the player's accumulated skill at manipulating the user interface. The player must plan for his/her shortcomings if there are degrees of Experience that he/she is missing. The player may choose to play it safe rather than attempting a plan with a greater degree of Risk:Pain or Risk:Extent.

Complexity:Ability requires that the player be able to substantially manipulate the user interface. The player must have a great deal of prior experience in performing the actions that the player is being required to perform.

Complexity:Comprehension requires that the player gather large quantites of Knowledge from other Situations in order to be able to understand what is being presented by the game.

There are also 3 extra degrees of Challenge. And they are pretty obvious when you think about it. For a given Situation, there is a base "quantity" of Reason, Ability, and Comprehension that is required to be able to confront the Situation and/or learn from it. The more the Situation requires from the player in these domains, the more difficult the Situation (or later Situations in the case of Comprehension, due to lack of Knowledge and/or Experience) is. We will call these degrees of Challenge Difficulty:Reason, Difficulty:Ability, and Difficulty:Comprehension.

So, in total, there are 9 degrees of Challenge, each with a virtually infinite number of ways of being expressed to the player.

We will discuss how Challenge changes over the course of multiple Situations in later articles.

Knowledge Pathologies 1 (WTP 2)

Given our current model of game design, we now have a way to express certain disfunctions in games.

By disfunction, or pathology, I mean a place where the player's natural progression from one Situation to another is interrupted in a way that is either not called for by the game's design or could be considered significantly annoying to a player.

Given the Situation Model, we have an understanding that Knowledge is a fundamental part of the Interactive Loop. Indeed, it is Knowledge (and Experience) that makes this loop actually function, where each iteration builds upon the last. As such, when a pathology arises with regard to Knowledge, it can break the Interactive Loop.

Though the Situation Model is focused far more on the player than the game design, we will look at these pathologies from the point of view of the game designer; what the designer intends and/or expects.

In this article, I will examine pathologies surrounding Knowledge generation.

In the Comprehension phase of the Interactive Loop, the game's Result is processed by Comprehension, informed by prior Knowledge, to generate new Knowledge. A pathology can result in this phase from one of the following ways.

Vital information, information necessary for the player's later progression, may not be available. That is, the game's design did not actually provide a Result to the player that any form of Comprehension and prior Knowledge could transform into the appropriate Knowledge. This is more than a mere pathology: this is a clearly broken game.

Now, a game exhibiting this pathology isn't always technically unprogressable. If the game is progressible, what must happen is that the Reason phase needs to find a way to generate this Knowledge by taking a bold exploration of the known Player Inputs. In essence, in order to proceed, the player must try everything until something works. And the Knowledge of how to proceed is generated by inference; when progression occurs, the player understands that this was the correct answer.

A game example of this kind of pathology would be when a player is presented with a standard 10-key number pad and a locked door. The door is otherwise impassable, and the player knows that it requires an 8-digit password to proceed. The key piece of Knowledge that is missing is the password itself. If the game does not provide any Result where this password appears, then this pathology results. The player can proceed by trying all possible codes until one works.

Let us call this pathology Unfairness. I use this term because the game is not playing fair with the player; it has failed to provide certain Knowledge that it later expects the player to possess.

This pathology is often confused with a second Knowledge pathology. This one occurs when the game provides a Result that is intended by the designer to produce certain Knowledge, but for the player fails to do so. This can happen in one of two ways. In one way, it happens because the player simply isn't good enough at Comprehension to be able to follow the game's logical consequence from Result to Knowledge. The other is that the player doesn't have a certain piece of Knowledge to inform their Comprehension process in order to follow the logical consequence from Result to Knowledge.

The latter form is one of two things. It is either an expression of a prior Knowledge pathology, or the player has simply not yet encountered the Situation that is intended to provide the player with the specific Knowledge. So we will ignore this one for now, and focus on a lack of Comprehension.

This form of pathology is simply that the game expects too much out of this particular player. Perhaps the player is unsuited to playing this game. It is important to note, however, that it is easy to confused this pathology with Unfairness; in order for this one to apply, there must be some logical consequence that leads from Result to Knowledge. Even then, one might suggest that it is Unfair to expect too much in the way of Comprehension from a player; however, I consider it perfectly reasonable to have a game require a high degree of Comprehension from a player.

In general, a lack of Comprehension isn't really a pathology with the game; it's a problem with the player. The player is simply not suited to this particular game. Given the number-pad example, it could be the case that the 8-digit password was scattered and hidden about the game world, and the player simply didn't have the Comprehension to pick up on it.

To the player, there is no difference between these two forms of Unfairness. A wise player might use a FAQ to determine how the Knowledge was supposed to be deduced, and then judge whether the game was Unfair or if the player simply didn't have sufficient Comprehension to put it together. But, more often than not, the player will simply put it down to the game itself being the problem and leave it at that.

All of the above pathologies are what I call Negative Knowledge pathologies. This means they fundamentally arise from the player not actually Knowing something. But there is another kind of Comprehension Knowledge pathology that is equally, if not more, important: False Knowledge.

That is, the game provides a Result, and the Knowledge produced from Comprehending this result is inaccurate to what the game design actually is. The player has gained some Knowledge, but that False Knowledge will impede or degrade the player's progress.

The reasons that False Knowledge is often worse than Negative Knowledge are legion. First, it is much easier for the game designer to accidentally tell the player the wrong thing than it is to tell the player nothing about something. Second, it is often more difficult for the player to unlearn something than it was to learn it in the first place, particularly if the False Knowledge was bound in some way to real Knowledge. Third, a lack of Knowledge generally breeds failure; False Knowledge can more often perpetuate the cycle, breeding new False Knowledge from later iterations of the Interactive Loop.

False Knowledge can be very sneaky, and it can be very easy to create False Knowledge by accident. For example, if you have a game where performing an action will lead to a reward, but only rarely. And additionally, there is no other indication that the action will succeed or fail on a particular location without trying it, and there are huge numbers of places to try in the game. This is a strong setup for False Knowledge generation.

There is a very good chance that the player will learn that taking that action is totally meaningless. The player might try it in a few places, but since it is rare, it will more than likely fail in all cases. Thus, the player will learn that this action never does anything. This False Knowledge would become pathological if said action was later required in order to progress.

False Knowledge, much like Negative Knowledge, happens either from poor Comprehension, a Result that more reasonably leads to the False Knowledge than the real Knowledge, or from prior Knowledge that helps lead to the False Knowledge.

This kind of pathology is called Deception; the game is actively Deceiving the player, whether intentionally or not.

Deception is particularly dangerous because of the ease at which it can happen. A game designer must take special care when designing a game, so that False Knowledge is not readily generated. And the more the developer focuses on creating difficulty in the Comprehension stage of Situations, the more likely it is that False Knowledge will be generated.

Despite the dangers of Deception, it can often be corrected fairly easily. Given the above example, the most reasonable way to correct this is to make sure that the player encounters those places where the action will result in a positive outcome early on in the game. Or to outright tell the player and point the player in the direction of such a place where the action will work.

Now, if part of the difficulty (and potentially enjoyment) in the game is to actually discover this Knowledge on one's own, then the game still has the responsibility of providing appropriate clues as to the viability of this action. The action should have some realistic backing, such that it would seem viable just from the player's understanding of the workings of the real world. There can also be certain subtle indicators that one might want to try using the ability in certain locations.

There are a myriad number of ways of suggesting the viability of the action; the key thing to remember is that there should be something that lets the player know that it will work. And the most effective way is for the player to experience it working him/her self. All the game needs to do is hint the player to a location where it will work.

What's the Point? (WTP 1)

So, I've created a fairly interesting model of a game (the Situation Model), one that can be applied to games on virtually any scale. It can be applied to virtually any kind of game, and probably some things you don't think of as games.

(Let's assume you buy all of that, as I haven't actually proven or even demonstrated it yet)

Yay for me. So I can apply them to games. Big deal, right?

Scientific models aren't useful in and of themselves. Their usefulness is when they can actually predict something of value (or of potential value. Or even just something).

As such, the key to how truly valuable this model is will be in what it can actually tell us about a game. Can it explain why one game works and another one doesn't? Can it actually tell us what effective games and non-effective games are?

To me, the most important thing to get out of any Theory of Design is a way to objectively assess a game's design. To be able to say where a game is functional or not just by an examination of its structure. And, because functionality is person-specific, such a theory needs to be able to at least potentially address what kind of people will find a design functional and what kind won't.

That's part of the reason I'm not going to (yet) attempt to justify the theory by showing how it applies to actual games. Instead, I'm going to examine the theory itself, explain certain pathologies and functionalities that it indicates are possible, and then show that there are games that exhibit these pathologies and/or functionalities. I will, in essence, examine the theory in a vacuum and then show that it does predict certain things about games.

Maybe after that, I'll see about showing how well it applies to games in general.