Featured Blog

Design 101: Playtesting

Playtesting seems simple. Don't you just play the game and see what happens?



Hi, welcome back to Design 101. Last time we talked about How to Balance Your Games. Today we're going to be talking about the foundation of every great game design process: Platesting. Many new designers assume that playtesting is simple. Don't you just play the game and see what happens? There’s a lot to get into, so let’s get started.



The Power of Playtesting


Games are complicated. Really complicated. You take intricate systems of interlocking parts and then add the human factor. Theory and thought experiments simply aren’t sufficient for predicting systems this complex. Many designers support moving to an initial playtest as fast as possible. I’m one of them.


Theory can give you a strong foundation, especially when it’s using solid principles based on demonstrated psychological tests (which are basically science’s version of playtesting). But actually seeing the game in action is going to be a better picture than all your theoretical models. It’s the real thing.


So how do you run a productive playtest? Like everything, it depends on what your goal is. In my experience, I’ve found there are five different stages that each have specific goals.



Stage 1 - Concept Testing



In the earliest stages of a game’s design, you want to quickly test if your core concept is fun. This is often easy to do even in an incomplete form.


I’ve previously mentioned an experimental project where I used an auction system to avoid having to find balanced costs for every card in the game. Instead, players would bid on cards as they were drawn - setting the prices they felt were worth paying. This would free up my team to design anything we liked, without worrying about how hard it would be to balance. After all, the difficulty of figuring out the right cost of the card would be the core element of the gameplay.


But before we started making cards, we needed to test if this gameplay would actually be fun. As a proof of concept, I modded the rules of Magic: the Gathering. Replacing drawing cards from your deck with a mechanic where players bid on cards presented at auction, we were able to start testing the core concept in the same day it had been conceived. Obviously, Magic wasn't designed with this concept in mind. Even so. players would go through the core experience of figuring out the right price to bid for each card.


The result? It ended up being so much fun that I’d go on to develop the modded game into a Unique MTG format. By finding these issues early in the Concept Testing stage, you can create your core mechanics to avoid the problems in the first place.


Stage 2 - Scattershot Testing



How would you solve child malnutrition? Better figure it out fast, because you’ve been dropped into Vietnam with that mission. You have a minimal staff and even smaller budget. Oh, and you’ve only got six months to make a difference.

This sounds like a desperate pitch for a reality TV show, but it’s the situation that Jerry Sternin found himself in when he was working for Save the Children back in 1990. The list of the problems communities faced was staggering. Poor water sanitation, government roadblocks, rampant poverty, lack of education… The list went on and on.

Here’s what he did. Instead of trying to solve these impossible problems, Sternin sought out the bright spots in this dark situation. He looked to see if any kids in these horrible circumstances somehow weren’t suffering from malnutrition. Was it possible that some kids, despite all these problems, were actually doing alright?


The answer turned out to be, “Yes”. Some poor families had well-nourished children. So... What were they doing?


The community soon identified the common practices that led to these bright spots. It involved different feeding practices, as well as a different diet not previously thought appropriate for children. You can read all about the story in the excellent book Switch. The Heathe brothers really know what they’re doing.


So do we. Instead of hunting for the answers to your game’s giant problems, it’s far better to focus on those small moments when the game is going great. Don’t try to solve problems. Replicate successes. Clone the bright spots.


This obviously applies to all playtesting. However, you can accelerate the process with the Scattershot technique. A Scattershot Test is helpful early in an iteration cycle. It also runs directly counter to the instincts of many designers.


It makes sense to try and make your first build as close to the final experience as possible. If you know that a certain faction is only going to have a single unique mechanic, to give it a strong identity, your impulse is going to be to try and design the best mechanic possible and test that one. You might come up with tons of possibilities during the planning phase, but you’ll be tempted to only implement the best one during the playtest.


This is a mistake.


It’s pretty hard to look for bright spots when you can only examine one type of family in the village. A Scattershot Test involves putting in a whole bunch of different mechanics into that faction all at once. While the final mechanic might be intended to show up on 20 different cards, try five mechanics that each show up on four different cards. Then you can figure out which of the mechanics were the brightest spots in gameplay. This is still possible even if your genre doesn't allow cramming in this much diverse content into a single test (such as puzzle games). You can rapidly prototype the mechanics through a procession of bare-bones tests before trying to refine any one of them.


The next test you’ll narrow the mechanics. Once you have your final contender you’ll end up doing the same thing with the ways you implement the mechanic. If you're designing 10 different enemies that will use the mechanic, focus on designing them so they explore the mechanic in different ways. If 8 out of those 10 of those enemies are terrible, but the last 2 are great, you might have an awesome mechanic on your hands. You just need to figure out if you can copy the successful ideas across the other 8.


Scattershot Tests do have a drawback: they usually involve a massive amount of complexity. It’s often hard for players to learn a single mechanic, much less five different ones. Scattershot Tests require heavily enfranchised players that already understand the rest of the game on a deep level.


If your game has yet to be released, this normally means that that you’ll be doing all your Scattershot Tests internally. This is usually a good idea in any case, as playtesters often hate seeing content they like get cut. This is especially true if it gets cut for a reason hat doesn’t affect that playtester's fun, such as the mechanic being too hard for players to learn.


Stage 3 - Experience Testing



Experience Tests are the next stage. Once you’ve settled on your game’s bright spots you can design something closer to the real game experience. The game your playtesters play now, mechanically at least (art assets and other peripheries may be non-existent), will be close to what they’d be playing in the final version.

Now you’re looking at your game more holistically. Scattershot Tests can be successful even if none of the games played in the test were fun. That’s because your goal there is often to find the best versions of different pieces of the game. You’re looking for the most fun abilities, the most interesting characters, the most exciting mechanics. Experience Testing is figuring out how the player experience feels when all these different pieces fit together.

It probably won’t go well. Think of your game like a machine. Each each system, each ability, each item, each enemy, these are all parts that make up the gameplay experience. If your parts are out of alignment, working against each other or are out of balance - then the machine is going to provide a poor user experience.

Naturally, things will likely need to be changed. However, your goal here isn’t to gather constructive feedback or suggestions. Your goal is to figure out what your players are feeling as they play.

Game design is like chemistry. You’re trying to produce a specific chemical reaction in your players’ brains. Naturally you need to know if the experience being produced is in line with your design goal. Experience testing is designed solely to tell you this, without the benefit of brain scanning equipment.

There are several tools you can use here. The best feedback tends to come in real time, allowing you to figure out which parts of your game are causing which reactions. If you’re working on a digital title, getting your playtesters to record Let’s Play videos at this stage is a great tool. Ask them to talk through their thought process while playing. Ask them to include a window showing their webcam feed so that you can watch their reactions. Setting this up is really easy and often free. OBS is easy to use, while YouTube offers a way to set videos as unlisted so only those with the links can find them.

Unfortunately, talking through your internal thoughts isn’t something that comes naturally. Even people that are good at it often obscure their real reactions. If your game allows it, and a surprising number do, you should have players test in pairs. I don’t mean two players on different computers, I mean two players in front of the same computer. Yes, even if the game is single player. This technique was used by the developers of Myst to great effect. You can hear all about it, and other gems of insight, from the GDC Postmortem.


Try sitting two players in front of Dark Souls and you’ll see players discussing where to go and what to do. They’ll ask questions of each other with regard to the interface and react much more audibly when things happen. A strategy game is even better, as players try to figure out what the best move is.

While there have been many solo Let’s Plays of Five Nights at Freddy’s, the Rooster Teeth Video is the one I keep coming back to. Watch the pair's transformation as they start by letting their minds wander and mock t

Latest Jobs

Sucker Punch Productions

Bellevue, Washington
Combat Designer

Xbox Graphics

Redmond, Washington
Senior Software Engineer: GPU Compilers

Insomniac Games

Burbank, California
Systems Designer

Deep Silver Volition

Champaign, Illinois
Senior Environment Artist
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more