This is a copy-and-paste of my current thoughts on the process of writing IF. I’m not an expert in this, but I put this out there for what it’s worth.
It’s kind-of a data dump, which is not the best online form; I’ll divide it by topic when I have a bit of time.
There are plenty of people who have better insight than I do in writing superlative IF; but this is the first attempt I’m aware of to define, fairly rigorously, the general case, and to give due attention to every part of the general case. So, for example, I discuss gates in some detail, which isn’t something I’ve seen discussed elsewhere.
It’s written as a ‘formula’ with the standard understanding, that IF authors should write the kinds of games they want. This is a manual on how to fly a plane: it doesn’t tell you where to go or what maneuvers to execute.
The basic idea behind this strategy for making IF is that every move you make as an IF author should raise the value of the game for your players.
First, outline the story. Games without a story tend to do poorly; stories appear to be necessary for a well-designed IF. (1 week.)
Second, design the game flow. (1-2 weeks.)
Third, program the game. (1-2 months.)
Finally, refine the play of the game. (Three months.)
Make the story
To make the story:
*Decide what emotional signal to send.
*Decide what message (or moral) you want to send, if any.
*Decide what change in circumstances best conveys that emotion.
*Decide what character best conveys it.
*Define the STATUS QUO as the first circumstance. This should have some problem, or conflict, built in to it.
*Define the SOLUTION as the final circumstance.
The story is:
The player has a chance to explore the STATUS QUO, examining the problem therein. Keep in mind that although this is an “exploration,” it is *dynamic* — it is a series of interactive events which figure the problem in the status quo, and implicitly argue that it is not sustainable. 30 min.
The player has a choice to challenge or not challenge the status quo. 15 min.
If the player challenged it, the status quo fights back! If he didn’t, it rewards him. 30 min.
If the player is fighting the status quo, he has the opportunity to defeat it. If he didn’t, he must now surrender to the original problem or be destroyed. “Destruction” here means death, losing the cardinalship, being voted off the junior league team, or whatever. 15 min.
This makes for an hour-and-a-half game, which is about the length of a movie. Probably, you’ll go over budget here and there, and your player will waste more time than you expected trying to do something weird that never occurred to you, making for a two-hour Comp entry.
a small situation
In the status quo, there is a problem. The problem is important: it is emotionally significant in a way that captures the player’s attention. It must also be believable. Therefore, you should go for the least improbable situation you can think of that would convey the problem.
And this is an important rule of drama: the smaller a situation is, the more interesting it is. A story about a fourteen year old who is considering going for her first kiss will probably be met with more interest than one about saving the Universe from forces of cosmic evil.
You can also overlay differences of scale. For example, consider a story about a fourteen year old who must save the Universe to get her first kiss; or save it somehow *with* her first kiss — perhaps a parable on not chickening out; or indeed, choose between saving the Universe and kissing someone she’s had a crush on *all summer*. But in all of these cases, it is the little story that drives the interest.
Now, in this small situation, you have a big problem. You must introduce this problem quickly in a way that makes the player feel it. Then, you must develop it in a way that makes the player understand and feel it more. This happens during the “exploration” phase of the game.
You do this by establishing rules about consequences. Anything that convinces the player that a certain consequence will follow a certain PC behavior can be used to establish the central problem of the status quo. NPCs can make predictions, issuing advice, warnings, or threats. The PC can get miniature versions of the problem situation, with small preliminary efforts at making solutions causing small versions of the problem situation to arise: trying to leave the grounds of the mental hospital leads to disciplinary action; trying to reason with one’s wife sparks a fight; going to the police backfires. Finally, you can establish the central problem by simply informing the player of it in the game’s narrative voice, either having the game directly inform “you,” the player, or having the PC think it through “out loud.”
Creating the problem situation around the status quo means creating two sets of rules. We can call these the carrot and the stick.
The carrot is the reward the status quo offers the PC for “correct” behavior. If the PC complies with the pressures of the status quo, this is his reward. However, it must be an inadequate reward. Otherwise, you are writing a game where nothing will happen, and that’s not a story. There’s no conflict.
So, the carrot is rotten: the outcome of going with the status quo is unacceptable. (Alternatively, you could create a story where the status quo is good but *threatened* somehow. The PC’s job is then to *maintain* it. But that’s comparatively boring, and follows basically the same logic anyway.)
The stick is the punishment the status quo offers the PC for “incorrect” behavior. If the PC fights the status quo, this is how the status quo will fight back. It must be an apparently formidable punishment. Otherwise, you are writing a preachy game with cheap, easy heroism.
When the carrot is unacceptably rotten and the stick is intimidatingly painful, you have put the PC in a bind. That’s narrative conflict.
If a bind were the only thing we offered the player, then that’s a downer of a story. We also should offer the player a *real* reward that, unlike the rotten carrot that the status quo offers, is actually wholesome and attractive. It should be both — pleasurable and good for the PC.
This can be backgrounded. Usually heros in modern stories act heroic not for profit, but to escape some bind — to prevent some kind of calamity. Sometimes authors go too far with this: the romantic hero/ine shows no interest in the love interest until having vanquishing the villian, at which point the love interest throws him/her-self at the hero/ine.
There are other similar developments we know from stock fiction: after thwarting the alien invasion, the intrepid alien busters seize the flying saucer, which allows humanity to pirate the alien technology. And so on.
You can make the reward the goal. This just means the PC explicitly acknowledges the desirability of the reward, and the reward can’t be used as a zinger at the end.
In a bad ending, of course, the PC is deprived of the reward, and instead given the rotten carrot of the status quo. And this should be conspicuous deprivation, underlining the fact that the player screwed up.
With the carrot-stick contingencies laid out through the exploration section, the player ought now to understand thoroughly the stakes and the nature of choice about to confront him.
Therefore, when he is confronted with the choice, he ought to have developed an attitude toward the topic that tells him what the likely consequences will be. Also he should know which choice will give him a chance to win his goal, and which represents an abandonment of that goal.
The choice must happen in a particular situation, and a particular moment. This should be the moment of greatest tension — everything in the game has been leading up to the sense that This Is It, and everything that follows will have to do with the ramifications of this choice.
This happens halfway through the story. Usually, this isn’t done in IF. Instead, the choice is put at the end, and the consequence follows immediately. That’s not good storytelling: it’s lame. It’s lame like the lameness of CYOAs. It’s especially lame when one choice is followed by Instant Death and the other by Glorious Happiness.
An IF shouldn’t be a series of puzzles you play to get to a one-choice CYOA.
Instead, watching the consequences develop out of the decision will cause the player great joy. This will be the second half of your game.
The choice itself is a gate. (see the section on gates, below) In general, the most impressive to players will be a choice which is clearly marked out as a choice by the storytelling, but that has the same form as the other gates in your game. So, if you use a lot of simulator gates, then making the choice a simulator gate will be the most impressive. If you use a lot of NPC gates, making it an NPC gate will.
However you make the choice gate, the player must clearly understand through the storytelling that this is an important moment in the game, and that he is choosing between the carrot and the stick of the status quo.
In traditional fiction, we have a character faced with Terrible Consequences if they don’t get something right. The probelm with IF in this regard is that you need to be able to put your money where your mouth is. If you set up terrible consequences, or a meaningful choice, then you need to be able to follow through if the player demands it.
This is really two problems: The problem of variety — the development that goes into putting together alternate story lines — and the problem of agency — making sure your reader doesn’t do something game-ending or calamitous without understanding what he’s doing.
the problem of variety
After the central narrative choice of the game, you need to have two different story lines. So if you’re writing a game that has two options in the central narrative conflict, it appears you have to write 1.5 games. Because you have two central-to-endpoint sections.
Luckily, you can cheat. Set up your story so that the choice has immediate effects that the player plays through, but then have the two story lines merge. Program in occasional reminders — NPCs respond to the player differently; he has different items; perhaps program an alternate scene.
Computers have memory. Use that memory to have the story lines again diverge a scene or two before the end of the game. If the player has chosen “correctly,” that choice now makes the game happily winnable. If he has chosen wrongly, the happy (or happiest) ending is no longer available.
avoiding and using cliches
There is no general advice to be given here, so this is a brief section to give you some food for thought. In moving from your general story-logic, which is emotional logic, to particular settings and situations, think on how much variety you can build in while staying true to your story logic.
Consider including a variety of settings:
Indoor and outdoor
Weird places people shouldn’t go
Also consider a variety of scenes:
Dealing with the very rich
With the very poor
With the very popular
With criminals or police
With people who have normal jobs
With people who have very peculiar jobs
And consider paradoxical situations:
Having to arrest a cop
Or rob a criminal
Or disobey a king
Or collect an overdue account from a rich man
Or give spiritual counseling to an atheist
Finally, try to create vibrant conflicts on various levels:
conflicts in goals
conflicts in strategy
conflicts in what the story is about
conflicts of ideas
conflicts of ideals
Think of the genre of the story you are telling.
Consider the different stories you’ve read or watched on the screen that are similar in setting, in situation, or in genre. Ask yourself: what are the kinds of things that are done in these stories?
Make a list.
Those are your audience expectations. You can surprise your audience by starting to talk about something that looks like it would be on that list, and then doing something different, or the opposite.
The less said about symbolism, the better. Here I’ll avoid talking about the profound and stick to the practical — anything that gives your story meaning by representing something other than itself is symbolic.
There are two very different strategies.
The first is to convey some message (for example about the relationship between the individual and society) by as many means as you can. So, if you’re telling a story whose premise is that the relationship between a group and a single person is always bullier-bullied, and that story takes place in a car dealership, then you’ll want to show that in every relationship:
* between the car salesman and his coworkers
* between his boss and his work force
* between a customer and the customer’s family
* between the secretary and everyone else
For a good popular version of this strategy, rent _The Wrath of Khan_ and notice how every particular character is given a version of the _Kobayashi Maru_ scenario. All of them are confronted with their own mortality.
The second strategy is to use a symbol in as many different ways as possible. In _Wrath of Khan_, every character responds to the confrontation with their mortality differently. In _Notorious_, alcohol is not given one role — it’s not just a poison that the main character is using to destroy herself — but it is given *many* roles.
Doing this makes your storytelling richer.
The first symbolic strategy is well-enough known. It’s the way critics generally talk about stories, because multiplying examples of an interpretation strengthens their case for that interpretation. But the second is really the one that makes for interesting storytelling.
(It’s generally interesting to both repeat and vary a pattern, in many ways that aren’t obvious.)
There’s no formula for symbolic literacy; you just have to work at it.
Good game flow is an essential part of creating a good game. This section is about the logic of game flow and some advice on using that logic to create a good game. It is about tactics.
The earlier sections were about storytelling. Good storytelling makes your players care about your game. Good game flow makes your game playable.
The most obvious rule of playability is that the user is able to control the game properly. For example, if your player is talking to an NPC and is given the prompt:
(You can say yes, lie and say no, or change the topic.)
and the player types LIE, only to get:
You lie down on the floor.
then that breaks the player’s involvement in the game. This is perhaps the worse case, where the game engine actively misunderstands the player’s command (after suggesting it). It is also bad when the player cannot, even after multiple attempts, make the game understand reasonable framings of commands.
Prevent this kind of problem by improving your programming ability, by telling the player what to type (e.g., “You can SAY YES, lie and SAY NO, or CHANGE THE TOPIC.”), and by beta-testing.
Besides giving the parser due attention, the rules in creating good game flow are:
* Allow the player to ESCAPE the game.
* Allow the player to REPLAY the game, with multiple endings.
* Understand the plot.
* Understand the purpose of every moment.
* Don’t write difficult puzzles, or if you do make them escapable.
* Use non-puzzle gates to structure your game flow.
* Give the player a clear sense of his position in time.
Allow the player to ESCAPE the game.
The player should be allowed to end his involvement in the game. In general, he should not be trapped by the game-logic; any situation ought to be escapable, except for the one scene where you are writing about the PC being physically and emotionally trapped.
So, a player should be able to escape any particular puzzle and return to the main story-line, to have it trundle along to completion, and he should be able to escape the game as a whole. This allows him to pace his involvement in the game, so that if he becomes irritated with it he has an elegant way of ending his involvement. That way he does not need to feel resentful to you for coercing him into playing a game that is not to his taste.
A -> B -> C -> D -> Ending | | | | V V V V --- (escape) -----> alternate ending
The means of escape could be anything; the PC could get on a bus and leave the state; or call the cops; or so on. It should make sense in the game and make sense to a person who does not want to keep playing; it will not reward the player emotionally as does the end, but it should not punish him, either.
In the previous section, we talked about the importance of escape: if a player does not like your game, give him an opportunity to end the game gracefully, and thereby minimize the damage he will do to your Comp score.
Conversely, if the player feels committed to the game and plays through it all, but then does not like the outcome, you also have a problem. The solution to this is to allow the player to reach alternate endings that convey different emotions.
Also, this allows a player who enjoys the game to continue playing after the end. Therefore, the game experience is structured like an accordion, expanding to the level of interest of the player.
One ending is sufficient. Two endings which represent diverse alternative emotional signals is good. Three is plenty. More than that probably exceeds the point of dimminishing returns.
The emotions of the endings should be *foreshadowed*, or “hinted.” The player must know where he’s going. He must not feel he’s making all the right heroic decisions and have that lead him to an ending where the PC is impoverished and treated with contempt; nor should a player who feels he’s acting villainously be showered with riches and praise. Not unless you set this up as part of your dramatic effect.
The player must be given clear emotional signals about how he will be directing the plot. He must understand the kind of move he is making (although not necessarily the moral universe of the work). This information should unfold to the player in the first 30 minutes of the work, when you are setting up the status quo and the PC’s goal.
MAKE THE MOST ENJOYABLE PLOT LINE EASILY AVAILABLE. The fact is that most people will not bother to replay your game. Therefore, you *must* make the most enjoyable ending the most likely one for a player to arrive at.
It doesn’t need to be the most *satisfying* — if you have the ability to write an enjoyable ending that makes the player want to reload and play again, that’s great. But the one ending that most makes the player think, “Wow, that was a cool game,” should be the one he is most likely to arrive at.
Otherwise you have squandered your best writing and storytelling on the minority of your players.
Plot is the chain of events, linked by cause and effect, that create your story.
For these purposes, you must consider how the PC’s actions, the player’s decisions, and outside (game) forces transform one moment into the next.
Plot is the experience of the player going through the game flow. Game flow is the succession of plot-nodes, and how they are programmed to lead one into the other. Game flow is progress through the structure of plot.
A moment in the story is a plot node. It’s a set of game-states which the user can fluidly switch amongst, *reversibly*. If you can move south, and then back north, and the game is in the same state as if you had never moved, you’ve stayed in the same moment.
(In a sense, this is never true, because the move counter is always going forward, and therefore the player can never truly recover an old game state, except by UNDO. But let’s not go there.)
Moments are connected to each other by gates: unreversible moves. You generally use gating to drive the plot forward.
Within a moment, the player explores. The usual practice is to make the gates puzzles, the solution to which ends one moment and begins the next. Therefore, the exploration the player does within a moment *must* inform him where the game is: what puzzle he must pay attention to and how he will solve it.
In very dull games, one moment is nearly identical to the next: we solve puzzles to open doors to get into an unadorned one-room shed, for example, wherein we find a single item that will allow us to solve some other puzzle.
So, there are two different issues here: the puzzle can be interesting or boring, and the moment can be interesting or boring. What, then, are the characteristics of boring or interesting moments?
Boring moments have too little happening. There is only one focus of attention, easily understood. They are the same as previous moments, or they have only one difference from previous moments: they have the same map, the same items, the same (or nearly similar) goals, and the same characters — and those characters are doing the same things and have the same attitudes, are in the same states and have the same conversations as before.
Now, the more boring a moment is — the less it stimulates the player; the more similar it is to previous moments — the less exploration the player will need to do and the easier you must make the gate to pass on to the next moment.
The more interesting a moment is, the newer it will be and therefore the more exploration the player will need to do. Therefore, the more difficult the gate to the next moment can be.
Every moment in the game must have a specific purpose. It should pace the plot properly, moving the story more slowly when the player is collecting information and moving the story more quickly when the player must act on his information. It should have an identifiable emotional signal, and likewise be paced by the difficulty or ease of the gate to suit the complexity and change of that emotion.
Usually, puzzles are used in IF to control game-flow: they are gates from one moment to the next, and moments are sequenced to move the player steadily toward the end of the game.
Puzzles are dangerous game design. They lock the game from moving forward, freezing the player in one moment (which, however interesting, will eventually become boring) and they do not, by their nature, explain to the player what he must do to unlock the game.
Look at this rationally: Any puzzle has a probability of being noticed, and of being understood, and of being solved. Normally, all three of those must happen for the player to pass through the gate to the next moment and solve the game.
Now, let’s say a normal puzzle has high ratings for all of these: 95%. The probability that the player will solve this puzzle in what you consider a reasonable time is then 95% * 95% * 95% = 86%. That means 14% of your players won’t solve it on time, or won’t solve it at all.
But, it gets worse: A normal game might comprise five of these puzzles. Now the math tells us that 46% of your players will go through all the puzzles without getting stuck and needing to go to the hints. More than half won’t be able to play the game through in a timely way without help.
Now, every time the player goes to the hint file, that decreases the value of your game a little. In contrast, players can still quite enjoy games that they consider easy.
If you still want to put puzzles in your game, there are several ways to overcome this problem:
MAKE PUZZLES EASY. In general, difficult puzzles do not raise game value for players more than easy puzzles do; and no puzzle that sends the player to the walkthrough raises game value.
MAKE FAILURE INSTRUCTIVE. Programming a puzzle that can be solved is one thing; but for a puzzle to be well-specified, it should do interesting things even when the user tries out a wrong solution. And those interesting things should be instructive, nudging the player toward the correct solution.
MAKE PUZZLES REDUNDANT. If you have a locked room the player must get into, give the player two ways to open the door and a window he can jimmy open. Thus, the player has three ways of getting into the room and is less likely to get stuck.
MAKE PUZZLES OPTIONAL. If the player can escape the puzzle and still solve the game, forgoing the benefit of solving the puzzle, then even if the player gets stuck on the puzzle, it won’t seriously damage the game’s value in his eyes.
USE TIMERS. If the player doesn’t succeed in moving the plot forward after a certain amount of time, the game moves itself forward — by whatever means you can think of writing in.
MAKE AUTOHINTS. Link object descriptions to timers, so that the game gives the player more and more direction the longer he is stuck in a moment.
And, of course…
CREATE A HELP SYSTEM. Include a walkthrough, a hint (or think) command, and a help section.
The alternative to writing puzzles is to write gates that are self-evidently one-way transitions out of the current moment, and which the player can very easily solve after doing enough exploration.
These usualy preceed endings or cut-scenes. For example:
>get in car
Do you want to drive home? (Type yes or no.)
Please type ‘yes’ if you want to go home, and ‘no’ if you want to stay here.
[Usually, a cut-scene would follow, perhaps ending with the player in his own house.]
CYOA gates are usually used just before a big transition to a new scene, or in a major plot decision. The check (Are you sure you want to–?) is standard.
These are like puzzles, but they aren’t difficult. When the player arranges the simulator-objects in a certain way — pours the gasoline into the gas tank, gets in the car, starts the engine, and drives off — then the game transitions to the next moment.
What’s the difference between a simulator gate and a puzzle?
If the above situation were a puzzle, the gas can would be hidden in the sock drawer, the gas pump would be broken, and the PC would need to find the right knife to cut the garden hose to improvise a siphon. (And half your players would write you complaining: “This puzzle sucked!”)
In contrast, in a simulator gate, the gas can is full and is sitting in the garage and the keys are in your pocket, which is mentioned when you try to start the car. So the player still needs to make the decision to do something, and go through some steps to make it happen, but wouldn’t need to jump through hoops to make it happen.
Movement gates are a specific kind of simulator gate. Sometimes the game will transition to a new moment when the PC leaves one area for another. That’s a simulator gate that’s triggered by movement: a movement gate.
Conversation gates, and NPC gates generally, are also commonly used: you need to give the bus driver your ticket, or reach agreement on some certain point in a conversation. Then the NPC takes you to a new location, or does something to alter the state in the current location.
Not often used, but they do move the story along: after the player has been in the moment a certain length of time, or a certain length of time after the PC hits a trigger, the game transitions to the next moment.
These are usually used in the negative — you must do something *before* the timer runs out. It’s called then a “timed puzzle.” But there’s no reason you can’t do it in the positive.
Be aware that people may criticize this for not being interactive enough. But in general, timer gates are still used rarely enough that the player probably won’t understand what is moving the game forward, which will be refreshing.
GATES IN COMBINATION
You can combine these gate elements to suit your game: if the player doesn’t ask the NPC for a ticket after a certain number of turns the NPC brings it up; or so on.
Give the player a firm understanding of where he is in time. This means a lot of things.
At the most basic level, make a score so that the player can track how much of the game he has left to play. Or, if you want to make an unscored game, write the game so that the player has a clear understanding of the endpoint and his relation to it.
In general, game flow must be restricted. The player cannot have too wide a playing field, or there’s no structure to his experience of the game in time. Players don’t like that. On the other hand, players seem very forgiving of a gauntlet structure, where there is only one obstacle-strewn path through the game (a structure I personally dislike).
A narrow structure that does not permit wandering over too-broad a territory allows the player to look back over his experience of the game and have a clear understanding of his timeline and how he got to be in his present location.
A wide map *can* do quite well, if there are significant events the player can mentally fix in time. But if there is a broad area to explore, and no significant events happen while he explores it — there are no changes to the map, the characters, or the PC — then the player will sort his experience of the game spatially.
If the player sorts his experience of the game primarily spatially, he won’t experience the game as a narrative. Narratives happen in time. Therefore, giving the player a wide range of exploration with relatively few state-changing events is bad design.
And indeed, a map that uses one-way location connectors to herd the player along seems to successfully “fake” the player into sorting his experience of the game temporally and not spatially, and therefore into understanding the game as a narrative: even if nothing is particularly happening.
Besides the player’s experience of the past, the player must be able to structure his experience of the future temporally. So, it is very important that the player have a fixed goal in mind during most of the game. And, equally, it is important that the player be able to place himself in relation to that goal, and have a “next step” available to him at any moment that allows him to progress toward that goal.
It is not important that all go according to the player’s plan. In fact, you will often want to have things work out contrary to his expectations. And he may not know how to *implement* his next step. But he must not feel lost in the narrative; not unless it is a deliberate part of the dramatic effect, for example to put him in sympathy with a PC who is lost.
So: orient the player to the past with a series of significant game-changing events which have happened behind him, and to the future with a clear goal and a likely plan as to how to get there.
A red herring is something that appears to be important, but isn’t. There are two reasons for using them in games: to make solving puzzles more difficult by distracting the player from what’s really important; and for artistic reasons.
The rule of thumb in the IF community is that a game can have one red herring.
DISTRACTING THE PLAYER. A red herring might *appear* to be the solution to something, causing the player to bend all his efforts to make that solution work, and preventing him from stepping back and looking for an alternate solution. This is perhaps the most evil use.
ARTISTIC PURPOSES. Sometimes people just don’t like it that a game is set up to encourage the player to collect a bunch of miscellaneous objects from the environment, carry them around, and use them in peculiar ways.
For example, we can easily envision a game in which the player must collect a cheese grater, a doily, some turtle wax, an extension cord, and an over-ripe cantaloupe, and put each to its proper use during the game to close the para-dimensional gate and send Cthulhu back to his resting place.
In order to allay the criticism that a person who was worried about Cthulhu coming through a paradimensional gate would *not* go around collecting this strange assortment of stuff, the game-programmer might add a spatula to the carryable inventory. That way, when the player puts Cthulhu to rest and rescues his girlfriend, she can ask, “Why in the world are you carrying a spatula around?”
The purpose, in other words, is to broaden out the frame and imply a world beyond the immediate game situation.
–In the example above, the real problem is that the PC isn’t motivated to collect these things, which is solved through good puzzle design.
Agency is understanding what you’re doing in the game. It is the converse of the CYOA trick of asking you to make a choice where the ramifications of the choice are unforeseeable.
You *must* have agency around the plot-controlling actions of your game. Even if you offer your player no *choice*, the player should understand what he is doing. And if you are creating a game in which the character has no agency, you need to signal that clearly, for example by having the character comment on it.
Now, that’s basic agency. There’s another kind of agency possible, which I’m calling ‘depth agency.’ This is conspicuous agency given over something that does not control the game flow.
In this case, the player is basically given a big red herring that he has agency over. He can control the red herring and make it do various different, interesting things. But the red herring has no impact on the game.
So, it’s not a red herring in that it’s meant to distract the player from the crucial focus of the game. Rather, it’s an artistic red herring, meant to broaden out the scope of the game.
In effect, in building depth agency in to your game, you are creating a toy. But you don’t want to make it obvious that it has no effect on the game. The advantage of this is simply that it creates depth: just as the text descriptions go beyond what is strictly necessary to lead the player through the game because it creates depth.
refine the play
Playability is the primary criteria that informs players’ opinions of your game. You make a game highly playable through testing.
* Alpha-test: play the game yourself, and work out the kinks. Then give it to your friends to play while you look over their shoulder. Take notes.
* Beta-test: sign up people online to beta-test your game. Have them make transcripts and take notes about what is giving them trouble.
* Refine your game, and then BETA-TEST AGAIN, with a new crowd of beta-testers. Repeat.
Now, in general, your early beta-testers are more likely to spot trouble than your later ones. And beta-testers are a scarce resource — you won’t get too many.
So, let’s say you have five people volunteer for beta-testing. Here’s how you distribute the game to them:
You pick *one* and ask him to beta-test. Then you fix your game to smooth over the problems he found.
After you’ve done that, you send it to your second beta-tester. And then you fix the problems she has spotted.
Now, if it’s looking pretty good, and you think you have all the bugs worked out, you send it to your final three beta-testers.
You can see how it would waste the second beta-tester to have her beta-test in the same round as the first one. Most of the troubles they spot will be the same. Beta-testers have limited patience, and more importantly, they can only objectively view your game for so long.
When you’re certain the bugs they find won’t overlap, you distribute it to multiple beta-testers. (Unless you have an unlimited supply; then you don’t need to ration them.)
If you have a very large and complex game, you may want to submit to multiple testers the first time, assuming they’ll find different bugs.
You can’t recycle beta-testers; not really. When you send the game back to them, they start to feel too much like contributors; now they *like* your game, not for good reasons — not because it’s well made — but because they had a hand in making it happen.
In alpha testing, you should spell-check your transcripts. You may think this is the least of your worries, but the fact is that beta testers will soon stop tracking errors that they see many times. You get tester fatigue. The point of alpha testing is to catch as many errors yourself as you can, so that your beta testers focus more on what’s important and what you can’t catch yourself.
In your first round of beta testing, you are looking for problems of any kind. You’re especially worried about game-breakers, of course, but all problems must be dealt with.
Besides all this, you want to ask your beta testers some basic questions.
1. Did you like the game? If this were a Comp entry, what would you give it?
It is *very* important to ask this question, because without it you don’t have an accurate understanding of what shape your game is in. You have a collection of feedback, but no overall evaluation.
2. How into it did you get? On a scale from 1 (worst) to 10 (best), how would you rate the immersiveness?
3. How well put-together did you think the puzzles were? On a scale from 1 (worst) to 10 (best), how would you rate them?
4. How easy or difficult was it for you to get the computer to do what you wanted? On a scale from 1 (worst) to 10 (best), how would you rate it?
Based on the survey I did for Comp 09, your game’s final score should be within a point of this formula:
60 % Immersiveness + 20 % Puzzle + 20 % Playability
*Very* creative games will get a one or one and a half point boost; very derivative games will get a one point penalty.
With the above information, you ought to be able to use your revision time more effectively. If people rated immersiveness low, find out why and fix that as a priority. After that, fix your puzzles or playability depending on which is lower and easier to raise. In the event of a tie, I would focus on playability, on the theory that boosting the player’s control of the game will help them solve the puzzles.
Again, use the immersiveness-puzzle-playability survey to see where you should focus your revision time.
This is the last round of beta-testing you’ll do, probably. So:
Whenever you make a change that isn’t trivial — any alteration to major text, to game logic, or so on — WRITE IT DOWN.
Then, re-alpha test the game yourself, going through your list, to ensure you have corrected the error and that you haven’t introduced a new bug.
Find someone to test it one last time. Just to be sure.