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 smoothe 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.

beta 1

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.

beta 2

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.

Published on March 20, 2010 at 11:45 pm  Leave a Comment  

The URI to TrackBack this entry is:

RSS feed for comments on this post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s