Blog

Play testing is an extremely important part of game development as it provides the team with a plethora of information. Like anything, though play testing can be broken down and split up into specific areas of focus that aim to answer specific questions or test certain features. The most important aspects of play testing, in my opinion are the who, the what, and the how.

• Who are the testers?
• What is the purpose of the test?
• How should the test be conducted?

Members of the development team often make the worst testers due to their inside knowledge of how the game works and what’s expected of the player. Instead, it’s best to use a variety of testers that aren’t directly involved with the development process. Use casual gamers and expert gamers to help maintain proper balance. Use those with a high attention to detail to help spot hard to find bugs, glitches, and visual inconsistencies. Make use of completionists to help find specific issues with objectives, narratives, mechanics, and features. Take the time to bring fresh players into the mix to get a new take on things. The key is to have as many perspectives on your game as possible.

When setting up a play testing session it’s best to have defined goals, a set purpose, and even specific questions you want answered before jumping into things. Most importantly you’re collecting data but you need to determine what kind of data you’re going to focus on. Is this play testing session for feature testing, gameplay flow, or mechanic testing? Have a plan and make use of a variety of tools such as tracking software and questionnaires. Write up a testing document that will guide the testing procedure and illustrate the team’s plan for carrying out the sessions and gathering the appropriate data. Essentially, figure out exactly what you want to learn from your play testers.

Finally, and perhaps most importantly is how you should conduct your play tests; guidelines and the dos and don’ts of play testing. Observe but do not interfere. Set up but do not guide. Pay attention to what the players are doing and how they’re doing it. Gauge their reactions and emotions. Pay attention to what they miss and where they get stuck, how they die, where things happen, etc. When observing a play tester you’re taking into account every detail of their experience, what exactly they’re feeling, how they’re interacting and reacting with / to encounters / situations, and how they’re playing the game. Last but not least, aid the play testers by setting up a method for logging player input and whatever other specific information you wish to gather.

Oh, for those of you wondering when when it’s best to play test, the answer is immediately. The second you have a working prototype of a mechanic, feature, or gameplay sequence start play testing. Starting early will help you avoid running into issues further down the line. If you’ve crafted content or have even begun to delve into specific design elements before testing your mechanics and figuring out if you’ve got a fun, exciting concept you run the risk of having to scrap everything and start from scratch. Be sure to start testing early on, gathering feedback and adjusting your design / plan accordingly. You’ll regret it if you don’t!

Note that quality assurance testing differs greatly from play testing as it’s focused almost wholly on crash, bug, and glitch reporting. Play testing focuses more on gameplay and the player’s experience while quality assurance testing focuses more on polishing the game and ironing out all the kinks / bugs (as much as possible). Both are extremely useful tools when developing a game as they provide useful feedback that is necessary for designing and creating a successful and solidly constructed game.

I’ve been going through all of the things I’ve worked on and stumbled across the first UDK level I ever built. It’s simple, follows a video tutorial to get started, and has limited functionality but it’s a great look at where I started and what I was able to create. Here are a few high resolution images from inside the map.