How To Playtest An "Idea"

Table of contents

No heading

No headings in the article.

Playtesting in game design is generally regarded as a way of running through different iterations of a game to track engagement, identify bugs, and gain a sense of “game feel.” It is typically conducted in a technical sense, such as “playing x levels” or “spawning x enemies” to see how the game handles interactions and how the player feels about them. Being able to properly test games is a key step to success as it helps games lean into their strengths while correcting their weaknesses. The issue though, is that this occurs in the mid to late stages of development while features are still being built and polished.

If we want to identify what works well in a game during the earlier stages of development, then we need to figure out how to playtest an idea. It sounds silly because an idea is intangible - something we can never physically navigate or directly hand to testers. With testing being a critical part of feedback though, the challenge is worth pursuing so that we can make the most informed game design choices before investing more time and energy.

So, how can we playtest an idea? This is where we bust out a fun list, a “top x ways…” list, if you will! Here they are:

  1. Scenario-Building
  2. Listen Outside The Box
  3. Make It Physical
  4. Rotate Ideas

Let’s dive in!


Scenario Building

This strategy involves the famous question that every game developer loves to ask - “what if?” We inherently love to ask this question because it gives us a way to expand ideas while still keeping them connected. For playtesting then, we shape this question to better understand the nuanced behaviors of our ideas. Let’s say that we pitch an idea for a size-based inventory system where an inventory holds a certain number of slots and different items will take up a different amount of slots. To playtest we may ask…

  • What if the player wants to swap the placement of items with different sizes?
  • What if the player is continually left with a single empty slot?
  • What if the player wants to organize items based on size?
  • What if an NPC wants to give the player an item?

These questions continue until every situation has been exhaustively identified. You will never anticipate every scenario unfortunately until the idea is brought to life, but many of those design headaches can be caught upfront. If the questions are somewhat answered, then your idea is likely solid and just needs some refinement. Conversely, if all the questions are left with no easy solution, then a completely new idea may be needed.


Listen Outside The Box

Leading off the previous strategy, there is no way to identify every potential scenario. As individuals, we have limited insight into the pros and cons of our ideas. It is easy to get attached to them initially and ignore some of the underlying flaws. To help avoid this, we can turn to other people for feedback. Ideally, these are people who are not close to you and are not necessarily full-fledged game designers. Finding online forums such as Reddit to gather feedback is a great way to meet these kinds of people.

In a concise, organized manner, lay out the idea to these people whether it is the central premise of the game or a specific subsystem/feature. A great way to get people to respond is to present ideas as a choice. Continuing the inventory example, you could propose two ideas, such as a sized-based inventory system versus a weight-based one. By phrasing it as “which idea do you prefer,” you will find that people are naturally inclined to respond because they feel their choice is the best one. It gives direction for how people can respond and allows you to narrow down ideas.


Make It Physical

Nope, this does not mean go straight into prototyping or full-fledged coding! Instead, we want to add physicality to our ideas and arrange them to see how they are interconnected. One great way to do this is to put ideas on separate Post-It notes and place them on the wall. Ideas that are closely related should be grouped together. Then, as you discuss how each idea relates to one another, you can move them around the wall. This allows you to see if any connections between ideas are impacted by new ones.

For example, we may have a bunch of ideas surrounding a statistics system. Then, we introduce separate ideas for quests that rely on tracked data as well as an achievement system. By laying them out physically, we can see how both the questing and the achievement subsystems both rely on a strong statistics system. In this, we can reevaluate how the statistics system can be set up to handle operations with multiple parts of the game at once.


Rotate Ideas

Similar to the physical strategy, we can also use substitution as a way of playtesting ideas. When coming up with an idea, start making small variations to it and saving those as separate ideas. Then, when trying to sequentially line up different systems that all interact with one another, start swapping ideas with each small variation to see which one fits best. Here is an example:

Finish Quest > Earn Reward > Add Item to Inventory

In this example, we would have different ideas for rewarding the player:

  • Display above character’s head
  • Float towards player (magnet)
  • Straight to hotbar
  • Drag over from pop-up single slot inventory

All of these involve earning rewards, but they feature different ways of accomplishing that same task. We can walk through this specific case and rotate between the various “middle” ideas to see which path is the most engaging.


TL;DR

Playtesting does not have to be reserved until the game is fully developed! Experiment with playtesting your initial ideas to iron out potential problems and nail down the vision for your game before drawing a single piece of artwork or typing a single line of code. Your future self will thank you!