Playtesting 101: Finding the Purpose
Playtesting 101: Finding the Purpose

Published

This is part 1 in a series on how to playtest games (click through to parts 2 3 4 5 6).

It may sound ridiculously simple, but the first step of playtesting your game is to figure out why you’re testing your game. It’s surprisingly important to work out the nuances of the ‘why’, which will affect who, when and how you structure the rest of the process.

In this post, I’ll be going over why you need to find the purpose of the test and some common testing goals at different stages of development.

There are three reasons that finding out the ‘why’ is important:

  • You can’t test for everything every time you test;
  • If you know what you’re testing, you know who you should be asking what about your game; and
  • You know what feedback to disregard, file away and/or come back to at a later time

The last of these is possibly the most important: if you get some feedback about the graphics of your game at a point where graphics really don’t matter to you, it’s vital that you set it aside and only consider it once you’re actually creating the graphics. If you haven’t specifically stated what the purpose of the test is, there’s a great temptation to go and ‘fix’ everything that people come up with, leading to premature development of features you shouldn’t be developing yet.

It shouldn’t be surprising, therefore, that your playtesting purpose will change as development progresses. Early tests are usually exploratory in nature, some aspects you might be testing are:

  • Concept testing (is the basic game concept fun? what exactly makes it fun?)
  • Game Mode testing (which game modes should we have? Does multiplayer work here?)
  • Level format testing (is this what a level should be?)
  • Teaching Discovery (what do we have to teach the player to make them an effective player? Is there a preferred method for doing this?)

Once you’re a bit further on, you’ll be wanting to start refining your game. This is where you’ll find testing purposes like:

  • Level design refinement (is this level fun? are there any dull parts?)
  • Mechanics Tweaking (would it be better if gravity were a little stronger?)
  • Bug Discovery (can they break the game? how?)
  • Teaching Testing (does the game teach properly, and at the right pace?)
  • Graphics and Sound Tests (is there enough whiz, bang and pop? are you conveying the right information to the player through the graphics and sound?)

Late on in the development, there’s a temptation to test for everything, as, well, you need everything to be right. However, it’s just as important to realise that you’re probably not in a position to change your basic game concept late in development as it is to realise that graphics and sound are probably not that important for your first test.

Of course, this all depends on the game you’re making, and the lists above are far from exhaustive (if there’s any glaring omissions, please let me know and I’ll update them).

That’s it for now. Next time, we’ll be looking at who and where you should test.

In this series