Interactive fiction equation

drt.gif (46685 bytes)

Interactive fiction equation

10 January 2007

For awhile now, I've been trying to identify a fundamental "equation" that can represent many (or most?) of the design problems found when creating a virtual world. This article is my latest attempt. It focuses on the tradeoff between story and choice.

The prescient-author thought-experiment

Like Maxwell's demon, I'll begin my discussion with an incredibly improbable / impossible thought-experiment.

Imagine that an author is creating an interactive fiction title. The author can see the future, happens to know exactly what choices a specific player will make long before the IF title has even been started. This prescience saves the author a lot of time and work because the author only has to write a piece of linear fiction.

Because the author has (potentially) years to design and implement the game (which ends up being just a story), the game can even include movie-quality eye candy.

Once the title is completed, the chosen player is placed in front of the computer, given a mouse and keyboard, and chooses away. However, all the player's choices are effectively ignored during "gameplay" because the author knew exactly what they would be before hand, and programmed them in. Regardless, the player walks away from the "game" vowing that it's the best one that he's ever played (assuming that the author is any good).

Let me start "the equation" here.

E(c) = f(author's skill, eye candy)

In English, the player's enjoyment of the game's choice, E(c), resulting from a given choice, c, (and its subsequent story/experience) is a function of:

The author's skill, an incredibly vague parameter.
The amount of eye candy (and money) used for the game.

The "game-master behind the curtain" thought-experiment

Prescient authors are hard to come by. However, face-to-face RPG game masters (or "dungeon masters") are more common.

Instead of a prescient author creating a movie ahead of time, imagine a game master sitting at the other end of a network and acting as the IF title's brains. This game master is, of course, incredibly skilled, and can parse the player's inputs so blindingly fast that the player thinks they're interacting directly with a computer. Furthermore, the game master can create new content in the blink of an eye.

Even if the game-master's authoring skill and eye-candy ability are the same as the prescient author's, the player's experience won't be as good:

The game master doesn't know what the player will do ahead of time. The game master can guess, which is important, but the GM only really knows what has happened in the past.

Related to knowing what the player will do, I'll point out that the enjoyment factor for an entire game is greater than (or less than) the sum of the enjoyment resulting from each individual choice. This creates an "enjoyment synergy" element that can't be ignored.
Real-time restraints affect enjoyment. The game master doesn't have years to make decisions about what will happen. For example: NPCs might not be as well fleshed out as they could be if the GM had time to prepare.
The game master may not be able to create published tie-ins, such as books or movies that the player would have read/seen before playing. Such tie-ins give players a better sense of the world, and what the game is about.
Although technically not game-master specific, other players affect the enjoyment of a choice, both positively and negatively. (I'm mentioning this here because game-masters usually GM for a group of players.)

Thus, E(c) is added to:

E(c) = f(author's skill, eye candy, knowing what the player will do ahead of time, enjoyment synergy, real-time restraints, published tie-ins, other players)

Outsourcing the game-master with AI

Game masters are expensive, being paid at least minimum wage. Therefore, the bean counters will get rid of them, replacing game masters with immigrant AI labour. AI gets paid very little and doesn't require benefits or holidays.

Unfortunately, contemporary AI has plenty of flaws compared to a game-master:

AI doesn't "understand" the player's psychology, so it can't tailor an experience to a specific player, based on subtle inputs from the player. Of course, the AI could always ask directly, "Do you prefer combat or puzzles?", but it's not quite the same. Nor can the AI tell if the player is having fun; face recognition isn't good enough.
Contemporary AI isn't very good at simulating NPCs, other than NPCs that instantly and blindly attack.
AI doesn't know as much about the real world's "physics" as a real game master.
AI doesn't know enough about the world, and is especially lacking in its understanding of Human culture and behaviour.
Contemporary AI can't create compelling content.
Contemporary AI can't create a compelling story.
AI won't understand all the player's inputs, especially if typed commands or NPC conversations are involved. (I'll discuss this later and won't include it in E(c).)
Etcetera. This list is practically endless.

E(c) is expanded once again:

E(c) = f(author's skill, eye candy, ..., a compelling story, etcetera)

E(c) rules of thumb

To look at E(c) another way, the following factors affect E(c):

A live game master is better than (most) pre-programmed quests/stories.
Pre-programmed quests/stories are (usually) better than procedurally-generated content.
Eye candy (and money, in general) increases E(c)... or in terms of text IF/MUDs, good writing improves E(c).

You can't do that!

Unfortunately, not every action that a player chooses to undertake can actually be acted upon. Character limitations aside, players encounter the following problems:

They venture into areas of the world where there's no content, "You can't go there!"
The world's physics can't handle their requested action. For example: They may wish to take apart a sweater and use its thread the knit a hat, "I don't know how to do that!"
The world's physics can handle the action, but players can't figure out how to tell the computer to do that. This is the "guess the verb" problem common to text IF and MUDs, "I don't understand!"
The player isn't allowed the action because it might adversely affect other players, such as PvP, "You can't do that!"
The action is prevented because it might break major or minor quests, "You can't do that!"
Although the player thinks they are making a choice, the action isn't really a choice. For example: The player is asked to choose between door A and door B, but both doors lead directly to the same room. While false choices may fool some of the players some of the time, they'll annoy most of the players most of the time.

This is an important part of "the equation":

P(y|d) = f(no content, world's physics, guess the verb, adversely affect other players, break major or minor quests, not really a choice)

In English, the probability of encountering a "You can't do that!" (or similar) situation, y, given a decision, d, is a function of how much content there is, how robust the world's physics are, etc.

Just to clarify, players will also be told, "You can't do that!" when they try have their human character (or pig) fly, try to walk through walls, or leap tall buildings in a single bound. This sort of failure isn't an issue for P(y|d) as long as players accept it as part of the reality of the world.

The annoyance factor

When players choose an action that isn't allowed, they get frustrated and annoyed, and they don't enjoy the game as much.

How annoyed a player gets depends on a few factors:

If the player thinks the game should handle the action/choice they will be more annoyed. Personally, I get really annoyed when WASD-based games don't allow me to jump. I expect such behaviour to be standard.
Players are more forgiving if they know why the choice didn't work. If the game explains to the player that they can't kill the king because the king's death will ruin their game later on, they'll be much more understanding.
Inconsistent behaviour is more frustrating. If a player's character can chop down one tree, why can't it chop down others?
If a player thinks that a decision is important, but they're not allowed to make the choice they want, they'll get frustrated. For example: A player may just experimentally try to pick a leaf off a tree. If they aren't allowed to do this, they won't be too offended. However, if they are given a quest to acquire a leaf but aren't allowed to pick one from a tree, they will be mightily annoyed. (I'm not including this in A(c'), but in another term later.)

The annoyance factor produces another term:

A(c') = f(expect game to handle choice, why the choice didn't work)

In English, the annoyance factor, A(), given a failed choice, c', is a function of the player's expectation that the game should handle the choice, etc.

P(y|d)A(c') rules of thumb

To look at P(Y|d)A(c') another way, the following factors affect P(Y|d)A(c'):

A live game master is better than (most) procedurally-generated content.
Procedurally-generated content is (usually) better than pre-programmed quests/stories.
Spending more development resources reduces P(Y|d)A(c') (which is good).

First pass at the equation

My first pass at the "interactive fiction equation" is:

E = Sd (E(c) - P(y|d) A(c')) I(d) P(d)

In English, the player's overall enjoyment of the interactive-fiction title is the sum, over all decisions, d, of the enjoyment from the individual choice that's finally accepted, E(c), minus the probability of the player's choice being invalid times the annoyance that results.

Both the choice-specific enjoyment and annoyance are scaled by I(d), which is a function that indicates how important the player views a decision. (See the "leaf picking" example above.) The are also scaled by P(d), which is the probability that the player will encounter the decision. Thus, the more branches in the game, the lower the probability that the player will encounter the specific decision.

The equation is busted

From the start, let me emphasise that the equation is busted. It's only an approximation. Here are some of the more obvious flaws:

As I stated earlier, E(c) are related. E is greater than the sum of its parts, and the order of events, often out of the author's hands, significantly affects E(c).
The equation assumes that players encounter a "You can't do that!" choice at most one time for a specific decision. Realistically, there will be times when the several of the player's choices in a row will be invalid. I could write these probabilities into the equation, but it would end up making the equation look heinously complex.
Games provide feedback after every choice, during which time players cannot make other choices. Sometimes this is as short as a beep, but often it's a lengthy cutscene. One reason players dislike cutscenes is because they can't make choices during the cutscene.

One way for the equation to handle long cutscenes is to treat them as a series of decisions where the player keeps getting "You can't do that!" responses from the computer if they try to do anything other than what's shown in the cutscene.

An easier way is to add a fudge factor, A(c, t), which is how annoyed the player is that they have to sit through cutscene from choice-c, for time, t.
Choice is one means, along with eye candy, to improve a player's immersion. Thus, every choice a player makes improves their enjoyment of the experience. To account for this, I've added a constant, ki, to the term. The constant is, of course, player specific. Some players find choices more immersive than others.
E(c), P(y|d), A(c'), I(d), and P(d) are all affected by the player. Most notably, some players are attracted to higher E(c), while others have higher A(c') and are more annoyed by "You can't do that!" messages.

The less-busted equation is:

E = Sd ( E(c) - P(y|d) A(c') - A(c, t) + ki ) I(d) P(d)

Interpreting the equation

The obvious use for the equation is to maximise E for all (paying) players, limited by the funds and technology that the interactive fiction title has available. This means:

Maximising E(c) when I(d) or P(d) are large. In English, put the most effort into content that's both seen by the most players, and considered important by players.
Minimising P(y|d) or A(c') when I(d) or P(d) are large. Make sure that important decisions, or ones that players are exposed to a lot, are populated with choices that players are likely to choose. If a player's first choice isn't available, make sure they understand why.
Minimising A(c, t) when I(d) or P(d) are large. Make sure that a cutscene resulting from an important/common decision doesn't annoy players.
Maximising I(d) and P(d) when E(c) is large, or minimising them when P(y|d), A(c') or A(c, t) are large. Don't make parts of the game that can't be simulated well (aka: good choice coverage) important or common parts of the game.

Some specific conclusions about E(c), how enjoyable the consequences of a choice are:

An IF title can have a low eye-candy budget if it overcompensates in other E(c) components, or vice versa.
A game targeted at a niche market can have a lower E(c) if the niche market allows for more accurate prediction of players' choices, and a lower P(y|d).
Enjoyment is, of course, player specific. A game's advertising and first fifteen minutes of play should be designed to attract players that will find the game enjoyable, and weed out those that won't.

About P(y|d), players getting "You can't do that!" messages:

Using story-like techniques, convince the player that they only want to make choices that are understood by the IF title. If the IF title is about combat, players shouldn't even think about trying to defeat the evil overlord in a sewing contest.
Train the player to only want to make certain choices. In FPSs, players are trained early on that all they can do is run, jump, and shoot. Sewing is not an option. Even text IF titles train players to expect certain commands.
Provide lists of acceptable choices, where possible. This will eliminate the "guess the verb" problem.
When designing the game, pretend that you just sat through the opening cut scene. What do you want to do next? What's your second choice? Hypothesising that you've done those and the game has responded, what's next? Predict what the player will want to do, not based on the prescribed story, but based on the player's experience so far; always remember, players don't know how the story is supposed to turn out.

Corollary: If the predicted choices lead away from the story, the best solution is to design preceding events so that players want to make choices that enable the story. The worst is to force players into a choice they don't want to make.

Corollary: Because of the cascading nature of choices, the first fifteen minutes of play defines your entire game. You can guide players towards the story later on, but it's difficult to change the initial trajectory.
Games reduce the number of "You can't go there!" messages, which increase P(y|d), by providing a buffer area around required locations. For example: Even though a single street might be needed to hold a general store and restaurant, adding a few more streets of scenic houses allows players to wander a short ways off the core content. (This is equivalent to the "wide valley".).
Keep track of what players try to do (but fail at) during beta and enable the more common choices.
If a decision-point can't give players the choices they want, most likely for story reasons, then the remaining choices had better have a really high pay-off in E(c) to counteract the player's frustration and not being able to use their choice.
Games should pre-select players whose choices are likely to be similar. For example: Don't advertise a puzzle game in a FPS magazine! More subtly, players from different cultures might make different types of choices given the same decisions.

Corollary: A game should weed out inappropriate players in the first 15 minutes of play. If the game is about puzzle solving, but a player's first reaction is to start killing everything in sight, recommend to the player that he tries another game.

About A(c'), players being annoyed by "You can't do that!" messages:

If a choice won't work because it would break a quest, tell the player.
Provide lists of acceptable choices, where possible. This will reduce the player's annoyance when they can't do what they want.
If a player expects a choice to work, they will be more annoyed when it doesn't, and vice versa.
If a choice isn't handled by the world's physics, figure out what the player is trying to do an suggest an alternative. Example: If the player types, "Challenge the evil overlord to a sewing contest," a response of "Sorry, the emperor don't sew, but he might accept a sword-fight," is much better than "I don't understand."

About A(c, t), players being annoyed by long cut scenes:

If a cutscene is long, make sure that it's written so that players don't have the urge to "break in the middle" and change the direction of the cutscene.
If a cutscene is long, it had better have a good E(c).

About ki, immersion from choice:

ki is player specific. Some people are willing to tradeoff a lousy overall experience just to have freedom of choice. As a general rule, these people are gamers; they accept low E(c) and high P(y|d) A(c) because of their high personal ki.

Most people are not game players; they have a low ki. They spend their time watching/reading stories (with high E(c)), or in the real world (with high E(c) and low P(y|d)A(c)). If an IF title wishes to attract them, it should have high E(c) and low P(y|d) A(c).

About I(d), decisions that the player perceives as important:

Put more development effort into decisions that players will find important.

Corollary: Make sure that decisions that are expensive to implement are "hyped" by the game so that players find them important. For example: If a development team is going to spend $10M creating an animation of the Titanic sinking, the should put the animation at the end of the game (so the sinking can be hyped), and make sure that players expect (and want?) the Titanic to sink.
Important decisions should show a menu of choices so that players don't run into the "You can't do that!" problem at a moment that they are intensely interested in making a choice.

About P(d), common decisions:

Put more development effort into decisions that all players are guaranteed to see, such as the beginning decisions when players haven't scattered to the winds. In later sections of the game, a decision may only be encountered by a small percentage of players, so the development effort should be reduced.

Corollary: If a decision is expensive to develop, make sure that players encounter it!
Commonly-encountered decisions should either have well-known choices, or a menu of choices. This ensures that a single player won't be getting "You can't do that!" all the time, and/or that the bulk of the players won't get "You can't do that!" for a decision that all of them will encounter.