Playtesting Tips & Tricks – Ebolt Game Design

Playtesting is a valuable tool in a designer’s arsenal throughout any game project. Being able to test your assumptions and designs with relevant testers in a specific setting can mean the difference between failure and success. But how do you maximize the effectiveness of this potentially costly tool?

Playtesting does NOT mean bug hunting

It is important to emphasize that quality assurance (QA) or “bug hunting” is not what playtesting is for. Sure, you can find issues (bugs) in your game during playtesting, but it is not the goal. A very stable version of the game is needed for playtesting to be effective. If you find lots of bugs during playtesting, the playtest results should be ignored entirely as the feedback is 100% tainted by those issues.

If you ask someone what they think of the driving characteristics of a new Ferrari, do you think their feedback will be useful if the car had a flat tire during the test lap?

Finding issues/bugs effectively can be done via other processes, which we’ll talk about in a different blog. But for now it is very important to keep playtesting and QA-testing separate.

So what is playtesting then?

Simply put is that playtesting is used to confirm specific design assumptions with relevant testers.

The word specific is very important here. If I would ask 20 random gamers to play Zelda and ask them “do you like this game”, I’d get a lot of different answers but none of them would be actionable or even measurable without a lot of extra specific playtesting. Some would hate the combat, some would love the world, others would hate the story, some would love the beautiful trees. So what do you then do with that information? It’s interesting, but not very useful…

So before any playtest you have to clearly define the questions you would like answered. Unfortunately, this is also the hardest part in playtesting to get right…

Examples of actionable and measurable playtest questions:

How long does it take a new player to complete the single-player story?
Do new players actively use the mechanics taught to them after the tutorials?
Which areas do players get ‘stuck’ in and lose motivation?

Each of these questions are measurable in both observation and data, plus they test an assumption. Let’s say you designed the game to, on average, take 20 hours to complete. If new players then complete it in 12 hours on average, there might be a problem.

Who are “relevant testers”?

You need to pinpoint your relevant audience as specifically as possible:

What age are you targeting?
Kids? Men? Fans of Harry Potter? Footy maniacs?
What kind of games do they like?
What type of gamer are they?
How much experience in your type of game do they need?
How many hours do they game a week?

If you get a highly experienced shooter maniac to test if your tutorials work, the results will be skewed, as there is a high probability that person already knew the mechanic you teach in said tutorials. Playtesting with a relevant audience is paramount.

The unfortunate truth is that anybody involved in the development process of a game is by definition a horrible playtester. Co-workers are biased by their own knowledge of the game, their personal opinions of the process and much more. Use your development team for bug hunting, not playtesting.

Playtesters also have limited uses, depending on what assumption you are playtesting. If you want to test the assumption that your opening tutorial teaches the basic gameplay mechanics effectively, you cannot test that assumption with people who have played the game for 20 hours. Seems obvious but you wouldn’t believe how many times I’ve seen this go wrong.

When do you playtest what?

Again, you cannot find out if your Ferrari is fast around the circuit if the bodywork of the car is only half installed. Before they can test the entire car on a racetrack they do testing with subparts first – They do a wind tunnel test in just the spoiler, etc. Same applies for games.

Early in a project you want to playtest on a much smaller scale. If your game is primarily about shooting, build the systems and content needed for just shooting to near final quality and playtest that first. Lots of studios make the mistake of also building other secondary systems parallel to their (untested) core mechanics, making it very costly when they need to change later on. Focus on your core first; once that is nailed, move onto other systems.

The later in the project you get, the more ‘game-wide’ the questions you playtest can become. You move from “do players understand the healing mechanic” onto “can they complete the entire game in under 10 hours”. Your assumptions get larger the later you playtest.

Want to make a Playtest plan for your game? Book a 1on1 session!