Game Design Tips - Part 3 - Playtesting blog - TheManWhoFlewAway

Welcome to the third in my series of game design tips. In part 2 I focused on prototyping so for part 3 I'll talk about the related process of playtesting. This post is a more generic and expanded version of the one I posted for Observatorium last year.

What is playtesting?

Playtesting is the process of letting other play your game before release. The point of playtesting is to highlight (1) design flaws and (2) major bugs in your game. The process of discovering and fixing these issues should strengthen your product.

When should you start playtesting?

As early as possible! Deciding on what to playtest in the first instance ties in nicely with the topic of prototyping: try to separate your 'design' from your 'wrapper' and produce a small demo that underlines what is new/interesting about your game. Playtesting is all about getting feedback to help direct your efforts so focusing on what's unique will get you off to a good start. Aim for 5-10 minutes of play.

How often should you playtest?

Playtesting should occur at all stages of development. Important milestones such as first playable, vertical slice, alpha etc. are particularly important but it's useful to perform regular playtests - such as fortnightly or monthly - to ensure you're thinking of others as well as yourself at all times. Don't be scared to arrange a playtest if you're stuck on the design of a certain feature: playtests are like experiments that provide useful feedback which fuels future development.

Consider your Target Audience

It's useful to keep your target audience in mind once you start bringing others on board. Keep a note of the name, age and gaming experience of each tester and refer to this when considering what feedback you will/won't address. Addressing all feedback can sometimes be as counter-productive as addressing no feedback whatsoever: trust your instincts and look for trends.

Suggested Phases for Playtesting

Below is a suggested approach to playtesting: the idea being to start small and branch out with each stage - adding more people to the test pool and improving the quality of feedback you'll receive. You can however choose to playtest in any way you like: just be sure to consider the approach that's right for your game.

(1) Test Yourself

This may seem counter-productive but before getting anyone else on board you should test it yourself. It's hard to analyse your game impartially being so close to development but some things you can look out for at this stage are:

• Aim - does the demo have a goal? Does it provide enough of a challenge or is there an adequate progression in place? If not, subsequent tests may not be very useful to you right now.
• Showstoppers - anything that seems like a major bug will hamper subsequent playtests and shift the focus from playability to stability. Prioritise glaring bugs that are easily reproduced and fix them. Infrequent critical bugs or any minor issues can wait
• Tutorials - ask yourself if you have trained the player adequately for the challenges they face. If not - add more details: you're already thinking about design improvements for first time players!

You don't want to spend too long on this phase as you should be testing your game daily as you add new features. This stage is about making sure you're ready for the next step...

(2) Test with Friends

Next, ask close friends to play your game and watch them as they do it. Chances are you will have missed alot of major issues in phase (1) and will need to go back. The point however is to get people outside the development team to play your game and get a useful list of feedback to help you focus. From this point on you'll want to start taking notes and refraining from interacting where possible. The approach I often use is:

• Observation - let your friend play the game and observe them silently
• Vocalisation - ask your friend to vocalize their thoughts as they play as much or as little as they like. This gives an insight into their thought process and how they are interpreting the game. Believe it or not what you see them doing and what they tell you they're trying to do may be completely different (!)
• Notes - make a note of any playability issues they encounter: this will depend on your game design but some examples of things you'll want to look out for are (1) clarity - do they understand the concept, menus and gameplay? (2) flow - are they experiencing the game as you intended? (3) fun - are they enjoying the experience as you intended?

Make a note of bugs but flag them as such - again, you can deal with these later. Do not start the playtest by explaining your game to them: you want them to come at this cold to gauge the usefulness of your prompts.

If your friend gets stuck don't abandon the test (though for all intensive purposes your game is most definitely not ready for market right now) - let them sweat it out for a while. If they still can't progress I find it useful to ask them what they think they're trying to do rather than to help them immediately. The need to ask this question and the response they give you will pave a path towards a solution.

I find it useful to keep a pool of friends close to the development cycle and send them regular builds. Asking your friends to record their playthrough is very useful but If you're unable to observe them it's still useful to ask (1) did you get stuck anywhere? (2) was there anything you didn't understand? etc.

(3) Test with Friends of Friends

Why friends of friends? You'll want to test with someone who isn't worried about hurting your feelings. These tests will also take a bit longer to organize and you'll want to use them wisely so I would suggest fixing as many issues from phase (2) as possible before moving on.

This process is very similar to (2) but you should treat it as much more formal. Imagine these people are part of your target audience. At the end of the playtest, it's useful to have Q+A about the session and anything you're trying to quantify or improve. Some example questions:

• How useful did you find the tutorials?
• How intuitive did you find the controls?
• How helpful did you find the in-game readouts?
• When would you have stopped playing the game and why?
• Was there anything that could have been explained better?
• General thoughts on gameplay?
• General thoughts on story?
• How intuitive did you find the menus?
• Any other comments/suggestions?

This is not a definitive list and you could ask some of these questions at phase (2) also. The point of Q+A is to open a forum for feedback and get an insight into problems/suggestions you may not have even considered yet. Take all feedback into account and consider what changes you could make to improve your game most.

(4) Test with the Public

The final phase is to test with a broad community: either through releasing a demo online or by attending an indie game event. Being able to directly observe your testers or viewing a video of their gameplay session is infinitely more useful than trying to interpret comments on a forum but don't be afraid to ask follow up questions if you don't understand someone's response to a particular section but refrain from interfering with their playthrough.

This phase should be considered hands-off: the core goal is to get a large volume of testers to play your game and expose new issues or underline old issues you haven't quite fixed yet. Be available to fix/bypass any show-stoppers of course but don't interfere too much. Take notes - as always - and feed this back into your development cycle.

Playtesting vs Quality Assurance (QA)

Playtesting should not be confused with QA. Although the QA team is very important, the QA process usually happens at the end of the development cycle. Do consider first-time feedback from the QA team but bear in mind that feedback on deeply-embedded design issues will be harder to address the closer you are to release.

Staying Focused

This seems like a lot of work - and it is - but the point of playtesting is to prevent design issues from snowballing. Some other points to consider:

• Keep your original goals in mind and how you can tweak your design to achieve them
• Playtest important milestones - first playable, vertical slice and alpha are especially important
• Substantial changes to existing mechanics or adding new ones requires more playtesting
• People unfamiliar with your game are more valuable than previous testers
• Try not to go round in circles - every fix should move the game forward
• Try to look for trends - these are undoubtedly the "must fix" items
• Try to prioritise feedback before proceeding and set reasonable goals for addressing it
• Don't hide behind fancy art/sound in early demos - you want to expose design flaws
• Be wary of the audience you are targeting: don't try to make a ‘game for everyone'
• Quality assurance should not be the sole stage where playtesting occurs
• Stay positive - take every page of feedback as a sign your game needs more time

Benefits of Playtesting

The benefits of playtesting are similar to benefits of prototyping:

(1) Identifying/Removing Risks - early playtesting can save you time and money and de-risk the later stages of your development cycle. Code is time consuming so you'll want to reduce coder workload where possible. Art and audio are low risk and can change right up until release. Design however feeds into code/art decisions and should be locked down as early as possible. Design issues will propagate the longer they are ignored.

(2) Confidence in your Product - playtesting can give you confidence in what is/isn't working. You may be overly worrying about how you've designed a certain feature but playtesting may reassure you that the chosen implementation is actually the right one; playtesters may instead draw your attention to another area you thought was flawless.

(3) Improving your Experience - every time you perform a playtest with someone new you will undoubtedly see them react to your game in a way you did not anticipate. How you choose to react to such feedback will pave a path towards improving the experience for other first time players. Once you've performed enough playtests and reacted to enough feedback in a positive manner you'll find it less painful to watch subsequent tests.

Conclusion

That's it for part three of my game design tips. I hope this [lengthy] ramble has been useful to you. If you have any thoughts or feedback - or if there's any topic you'd like me to cover - then let me know.

I'm on twitter at @manwhoflewaway

Thanks for reading and good luck with your projects!

Clive Lawrence,

The Man Who Flew Away

Follow Observatorium development here on Indie DB