Get the latest Education e-news
 
  • Playtesting is Sovereign, Part 1

    [08.10.10]
    - Lewis Pulsipher
  •  Whether you're working on video games or you're designing tabletop games as a way of learning game design, constant playtesting to improve the game is the major path to success.

    The biggest factor in the playability, the successful gameplay, of a game is not the quality of the ideas, nor the strength of conception, nor the marketing skill, nor the skill of artists or programmers. It's the quality and quantity of playtesting and the resulting improvements in the game. In the end, if enough people in your target market play the game and enjoy it, then it's "good"; if they don't, then it isn't! While a poor game may sell well thanks to marketing and other factors, ideally you want to create a good game to give you the best overall chance of success.

    The number of inexperienced people who think they've successfully designed a game, yet haven't playtested it at all, is remarkable. Playtesting is playing the game to find out how it can be improved, and then improving it to try again. The process is both incremental-a little at a time-and iterative, again and again. The playtesting stage is the start of successful design, not the end.

    Let's clarify something. I am talking about playtesting to improve gameplay, not testing to squash programming bugs. Some people call the former "fun testing" and the latter "bug testing". Bug testing is often what video game makers mean when they talk about "testing", and this testing takes place late in the development cycle, when the gameplay and appearance are set in stone (because it's too late to make big changes). This testing (misleadingly called "Quality Assurance") is aimed at making sure the game works the way it is supposed to, not at whether the way it's supposed to work is good or not.

    "Bug testing" essentially does not exist in tabletop games, although it is important (and often forgotten) to test the production version of a game, as converting the prototype into the published version can introduce its own set of problems. (A small example: the boxes on the Population Track on the 2006 Britannia board are inconveniently small; this new version of the board evidently was not actually tested. They are larger on the 2008 printing.)

    The "natural" way to design a game, as used in tabletop games, was long unused in the video game industry, but is coming back into custom. A playable prototype is produced as soon as possible. It is played, revised, played, revised, played, revised, seemingly forever, until a stable "good game" has been produced.

    The lead designer/programmer of Unreal Tournament III, Steve Polge, described how important it was for Epic to be able to playtest within a month of starting, and constantly thereafter. (See the video with the UT3 Ultimate Edition.) Epic's Gears of War 2 was playtested something like forty thousand hours (that's the equivalent of 20 people working a normal schedule for an entire year). For Civilization IV Firaxis used a team of only 7 or 8 people to make a working prototype as early as possible, then played it constantly throughout the production process. They then added many more to the team for production artwork and polishing. (See their 2006 GDC presentation, available in video form with the Civilization IV Game of the Year edition).

    The "wannabe" designer's assumption that the first prototype will be just fine as it is, before it's even played, is a product of both ignorance and the tendency to oversimplify the role of game design. If you think that a good idea makes a game, you might be excused for thinking the prototype will be "just fine". In fact, the idea is just a starting point.

    People in other fields of art and entertainment revise their work often, even if they don't test it on others. Beethoven had notebooks filled with musical ideas and revisions of his work. He actually completed four versions of the overture for his sole opera -- Leonora 1, Leonora 2, Leonora 3, and Fidelio, the one finally used. You can hear the improvements when you listen. I prefer Leonora 3, but this mini-symphony was too monumental to be used as an overture to an opera, so the composer tried another tack for Fidelio. He matched the work to his goals and requirements, something every game designer needs to do, especially when employed to make a particular game.

    Ideally, a game designer has the time to do this with every game, but this example is extreme even for Beethoven, and would be extreme for a game designer, to finish three versions of the same general work before settling on a fourth. The difference from games is that Beethoven was producing a passive kind of art, something to be presented to the audience when done rather than to be tested with an audience. Because games are interactive, the only way to modify them sensibly is to ask the "users" what they think and feel.

    When you design a game, you try to see in your "mind's eye" how the game is going to work, but until you play it, you simply cannot know what is going to work and what is not. The first few times you play, many things will change (provided, of course, that you're willing to make changes, which is a major characteristic of a game designer).

    Granted more experienced designers can foresee more weaknesses and eliminate them before reaching the prototype stage. But every designer, regardless of experience, is likely to change the game significantly when it begins to be played.

    What you absolutely cannot do is convince yourself that whatever you like is what other people will like, that the way you play is the way other people will play. You are not your audience, you are not typical (or you wouldn't be designing games), you are too close to the game: you cannot rely on yourself.

    There is no substitute for extensive playtesting. Your initial prototype is almost certainly going to stink. Get used to it.

Comments

comments powered by Disqus