Playtesting your game is one of the best ways to improve the quality of your game by focusing on real-world player behaviour and discovering what players actually think about specific elements of your game. Not only can playtesting enable a better end product for your game through real feedback from players, but it can also help to scope your project by understanding what your players want – and enjoy – to place more emphasis on those elements. Despite the benefits of playtesting, it is sometimes difficult to make playtesting a priority when there are so many other things that need to be considered. Many times, playtesting is either an afterthought or done at the end of development, with little time left to make changes and improve the experience that players will be engaging with. Hopefully, this article will put you on the path towards evangelizing playtesting within your own team, to be the trailblazer for this change.
While this is a fairly broad question, it makes sense to want to know what exactly makes playtesting worthwhile and why it is important to discuss within your team. While every team will have a plethora of expert opinions based on years of experience, it’s extremely important to know what your players want, as they are the ones who will be playing, investing in, and enjoying your game. Playtests are a great way to “get reliable attitudinal data [how players subjectively feel about the game] from people”[1] in regards to an overall experience over a play session, or on much granular instances or elements such as a specific mechanic. Tied with an iterative design implementation of constant improvement, re-testing those same pieces of your game can showcase the “effects that specific changes to the game have on users’ enjoyment”[2]. Even if your specific company prefers quantitative[3] over qualitative data[4] in regards to playtests, there’s a way to implement that strategy within your workflow to improve the quality of your product[5]. Playtesting can also involve more folks than just the designers; it can be important for other departments to see and understand what players are doing and saying about the game to work on improving their own parts – consider programmers or artists that are tangentially involved and would benefit from feedback[6]. Having “repeated playtesting and tuning [...] throughout development”[7], and especially implementing that process early on in the development cycle, can have profound financial benefits, as it is generally less expensive to test and adjust often, as opposed to pay overtime and hire additional staff to crunch at the last moment.
An interesting new approach to releasing games enables some companies to opt for soft launches for products, where developers can publish a nearly-there prototype for players to gain early access to and receive feedback. This new opportunity for feedback from real people is at the heart of a change in the way that development is done, namely by moving away from the typical waterfall – one step is worked on, completed, shipped, then move on to another step – cycle, towards an agile and iterative lifecycle. The waterfall standard is exemplified by McAllister and White (2010), highlighting multiple case studies of both large and small developers utilizing this method, while also relaying its rigidity and typical need for crunch to follow the strict deadlines for parts of the process[8]. Not only does an agile process with playtesting allow for flexibility in how the development occurs – working on smaller steps in a much larger cycle of iteration, such as tuning a mechanic while also working on the larger world in your game – but this new style of development can drastically improve the workflow and end product of your game. For the reasons above, moving towards an agile development strategy with soft launches is a worthwhile conversation to have to highlight the considerable improvements the process can lend to your team.
When aiming to include playtesting in your game design process, it is important to consider the separate roles that playtesting and quality assurance (QA) fulfill. Many on your team may believe that they are doing playtests through a QA process, or that there is no need for playtesting because of QA. To deepen the understanding of this fundamental difference, it is important to explain what benefits QA and playtesting offer as their own individual affairs. QA, in general, occurs at the end of a design process – whether it be level design, mechanic designing, and so on – and is focused on discovering bugs that may have been missed previously[9]. This step is synonymous with alpha testing[10] and tends to be a thorough step in a waterfall-style process. In this way, QA is usually considered the bug-squashers, a step in the process that removes game-breaking bugs and generally looks to polish the experience by making sure nothing is out of place. This type of quality assurance work is typically spearheaded by the engineering department to find those compatibility issues[11]. Contrast this with playtesting, which is meant to be an iterative process that designers “[perform] throughout the entire design process”[12], continually working towards improving the game’s design each step of the way. While QA is an important part to consider – think of all the skips and bugs that are exploited in the speedrunning community that weren't found in time by QA teams – playtesting improves your game throughout the process by getting external, real world feedback from potential players of your game.
Not only is playtesting a great way to understand how players will actually play your games, it allows your team to improve almost every aspect based on the feedback you receive. This means your game will be better off after playtesting than it was before, and sometimes that improvement is quite substantial. For example, Outer Wilds (developed by Mobius Digital) is a wildly successful puzzle adventure game released in 2019. Because of the nature of the game’s mechanics and narrative style, it had to “place a lot of trust in the players”[13]. This also meant getting feedback from players about how to appease both an audience excited about a space exploration game, and an audience that was after a puzzle game[14]. Thus, by Mobius Digital’s own admission, playtesting became a “key part of the design process”[15] to ensure that they were hitting the mark as they developed their game. Their own blog highlights the importance of playtesting, and of catering these playtests to issues they are facing, to add value to the product from the perspective of players – and even confirming the designer’s ideas in many cases.
Another prominent example of where playtesting has radically improved a game in development is Dragon Age: Inquisition (BioWare). While the development process of the game was rife with its own challenges aside from playtesting, interestingly they had other Electronic Arts (owner of BioWare) employees take home a build of the game to get their feedback. Two main issues needed to be addressed: a confusing narrative and boring battles[1], which had slipped past the developers of the game. Through further playtesting, the developers received quantitative feedback that highlighted the need for change, and in turn actually increased morale within the team to work to improve their product[2].
With this article, we hope you now have information that will empower you to speak about playtesting with your team, the benefits it offers, and its ability to shape the way that your game can be viewed both externally and internally. If you’d like, check out all of the services PlaytestCloud has to offer for your game, such as surveys, concept testing, and playtesting, all offered remotely for your convenience.