Never skip playtesting.

Greetings game devs!

Sorry about the long delay between posts but I have been crazy busy between work, side projects, mentoring people, and a few interesting opportunities that have come up. Opportunities to playtest different games! Games I can’t talk about because of NDA’s but it was interesting to see how different teams, whether indie or AAA.

Why playtest?

So you’re making a game! Spent days, weeks, maybe even months creating mechanics, control schemes, levels, fine tuning balance and crafting the world’s story. Perhaps you’ve even managed to play through everything you and your team have created without finding a single bug! Why would you ever waste valuable dev time on playtests?

That’s how I used to think. Then I realized I had tunnel vision and missed about ten different fires.

It happens to everyone, especially when working creative projects. That’s why it’s important to bring in a fresh pair of eyes every so often to catch what you haven’t. These fresh eyes have no idea how your game works, the controls, or what bugs to avoid, and they will stumble blindly through your game and figure things out for themselves, or with some minor prompting from the test runner if the tutorial isn’t implemented.

As these testers play your game it will become clear what works and what doesn’t. A system that seems entirely simple and intuitive to you as a designer or a member of the dev team may as well be Greek to your testers. Controls that looked good on paper and dev tests make players want to stop playing, and maybe your well thought out story is lacking in characters or tension compared to the gameplay.

Playtesting will reveal all of this and so much more. Whether you test with friends and family, random strangers at an event, or your target audience.

Reaver was the game where I found out just how important playtesting was. We thought our control scheme was on point, our combat system simple and intuitive, and we had miraculously created a bug free game. This illusion was destroyed upon playtesting.

It turned out that players couldn’t aim while using their jetpack like we wanted them to do. We had to break convention and move the jump button to a trigger. We wanted to push players towards a more aggressive playstyle where they healed through finisher moves on stunned enemies. Turns out players had no idea they could stun or finish enemies. And boy did we ever find a ton of bugs.

It was an enlightening and humbling experience that ultimately lead to a much better final product.

How would you set up a playtest?

So now you want to set up a playtest. Where do you start?

Like with anything else, make a plan. Decide what the purpose of this playtest is. What are you looking for feedback on right this moment? Controls, Combat, Narrative? A specific level or system? What questions do you have for your testers? Write those questions down and make sure they are focused.  You don’t want to waste your time and your testers certainly don’t want theirs wasted.

I have personally found that between five and ten is a good number when going out to events when grabbing random people. It’s quick and painless for both you and your testers once the playing part is done. If you’re working as part of a bigger team working with a more dedicated playtest session, then you can ask more questions depending on the playtest group’s size. Usually I find these take around an hour or so of discussion.

Where would you perform a playtest?

That depends! If you’re in a big studio or budget you probably have your own place to host these things! If you’re an indie dev, that’s going to be up to you to figure out. Look around your community, there might be indie dev events you had no idea about. People love to check out what everyone’s working on and help each other out. Just make sure to talk to the organizers first. Put up some fliers, or pick up some ads online and invite people to the library, rent out a place, or invite them to your home if you like. And if you really want to catch people’s attention, strap a laptop to your chest with a controller and see how many people you can get.

While you’re at it, if you have cards, fliers, or anything you can give out to people interested in keeping touch with your team and project, these places are great for handing those out.

One last thing!

If you have a particularly large playtest or you are aware that you have potential show stopper bugs, make sure to implement a debug menu. Something that will let you skip to different points in the game if something goes horribly wrong. Can’t stress enough how many times I’ve seen playtests be saved by this.

Take notes!

Probably the most important thing to do during the playtest rather than afterwards when you’re asking players questions. This is why I recommend a pair of people run these. One to help out the playtesters whenever needed, the other to watch and write things down.

This way you can write down if players had trouble with the controls when trying to do X, they struggled through this part of the game because Y, or if they just really didn’t like your characters for any reasons they may let slip out.

Now, in the big studio playtesting sessions I’ve been to, they have recordings for that. Camera on your face, audio recordings, recordings of your play session and every button you pressed, nudged and accidentally hit in a panic. It was kind of creepy the first time I went to one of these but I understand why they do all of that, especially in a room with ten different testers and only two people to run the show. This way they have an idea of how the testers feel throughout the session and then compare that with their questions later on.

One playtest I was part of recently involved a level where the only boss in the entire game had a particularly obnoxious difficulty curve that was inconsistent with the rest of the game. That was pretty easy to see on my body language for anyone that watched the recording. Turns out, after talking with my fellow playtesters, I wasn’t the only one who struggled with that boss. Only two other testers made it through and it took considerably more effort than the devs wanted. A concern they had but weren’t sure about until they ran this playtest.

Create an action plan.

So now you’ve run your test, have your notes written up and survey’s filled out. What’s the next step?

Break down that information into actionable data with which to move forward. Are your controls and systems working? Is anything difficult to understand, clunky, or need any kind of fixing? Write down the steps that you and your dev team need to take in order to make the necessary corrections to your project. Break those down into tickets and assign them accordingly to your team.

But not every single piece of feedback you get from playtesters will be good information.

Sometimes you will have a game that focuses on tactical decision making with branching paths and a tester will say they don’t think the game needs as many choices as it has. Is this feedback valid when the point of your game is to give players the means to tackle problems as they see fit? Outliers like this and feedback that ultimately goes against your high-concept or design pillars aren’t really useful information.

But what if it’s multiple people bringing up this same issue and these testers are also part of the audience you’re aiming for? Then there might be a problem that needs more looking into. Conveyance of these choices might not be strong enough. Risk vs reward might need balancing. Maybe the way the player gains access to these choices needs more looking into.

Take the time to break down this feedback into something you and your team can work with.

Thank you so much for reading another of my posts!
Sorry it took so long and that it wasn’t about Death Stranding or Jedi Knight: Fallen order like I planned originally. It has been a hectic last few weeks and I am reconsidering this whole weekly blog post business because of it. I’ll definitely keep posting as often as I can though.

Until next time! Have a nice day.

Add a Comment

Your email address will not be published. Required fields are marked *