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.