The Five Basics of Being a Game Design Problem Solver

The most important thing I'm responsible for day-to-day is managing the following perpetual cycle of game design:

1. Listening to feedback from team members and players;

2. Deciding how or how not to integrate that feedback into the game;

3. Then validating those decisions by tracking how changes resonate with players.

By no means have I mastered this cycle. However, especially as the designer on the small team developing Highgrounds, I find that there are a small set of processes I can follow to more efficiently and respectfully work with the team to drive the design of our game forward. Here they are in no particular order.

1. Identify the Problem Before Finding a Solution. A lot of the feedback I encounter comes in the form of raw ideas or inspiration ("There should be a character who blocks lightning bolts!"). This feedback is often useless in actually helping to decide if the idea should make it into the game or not. To make a qualitative assessment, I always need to first understand what problem the design suggestion is trying to solve.

For example, behind the suggestion to allow characters to block lightning bolts may be a feeling that the lightning bolt ability is too powerful, making games against lightning bolt characters noncompetitive, and thus less fun. With the problem understood, it's much easier to evaluate if the solution proposed will help solve that problem or not. If the solution does not help or will causes other problems in the game elsewhere, you now at least have a basis to work from to easily look for alternative solutions that WILL address the issue. I also find it easier to have a dialogue with the person providing feedback as to why I agree or disagree. Now your feedback is directed at a common enemy ("the problem") instead of the merits of a team member's idea or design sensibility.

2. Give Rationale Along With Recommendations. On the flip side, when it's my turn to make design recommendations, I find it's important to explain the problems in the game I see along with why I believe the suggestion I'm making is the best solution to that problem. I often refer to this part of a design recommendation as the "rationale" for the change.

If I find myself giving feedback without much rationale, it's usually a telling sign that I have not fully thought through the actual issues with the current design, or that I may be suggesting a change that is unnecessary.

3. Keep Design Notes. Once a decision is made on how to proceed with a design change, I always recommend that the change, problem, and rationale be captured for reference later (a simple Google document shared with the whole team is usually enough). Why should you go to all this trouble? Inevitably, a change you make to the game now will reveal or create new problems in the design later. When it comes time to address those problems, it's extremely helpful to remember why the previous changes were made in the first place. Having your previous rationale on hand will help prevent you from making the same mistakes twice, and ensure that new changes will not reintroduce old problems.

4. Use "Listening Aids": I've been fortunate to have a number of great mentors over the course of my short career in games. A common habit between all of my mentors has been to bring a notebook or sketchpad to every meeting they attend. I've found this notepad serves a few important purposes in working through the cycle of design.

1. Most obviously, it allows design notes to be captured amid rapid conversation of problems and solutions.

2. It supports discussion of visual concepts better than the napkins, straws, and salt shakers that are typically available at meeting locations outside of work.

3. It provides important social cues about openness and listening. When you physically take note of what a team member is saying, it demonstrates to the other person that you are hearing and considering their ideas.

The notebook itself is not important, but making a conscious effort to "take note" of other's feedback is. Their perspective may not be relevant now, but extremely useful later. This applies when interacting outside of your immediate team as well. It's worth the effort to reply to your players on the forums, and respond to that misguided Publisher feedback that would be easier to ignore. Without doing the above, you run the risk of appearing unreasonable and longer term you will find yourself with less feedback from your team; feedback that could be critical to the success of your game down the road.

5. Play Your Game, Know Your Game. On small teams, it's typical to take on a lot of responsibility and wear many hats. When you have so much else to do, it gets harder and harder to justify spending time just playing your game. But I find it's critical to know your game well enough to understand how even the smallest changes will affect the high-level design. Even when you know where a problem lies in your game, it's easy to land on flawed rationale because you simply didn't know the full impact your suggested change would have.

In Highgrounds, there are now upwards of 140 characters with 2-4 unique abilities each, and I do my best to make sure I know each and every one of their strengths and weaknesses. The time you spend now playing and studying your game will pay off in the form of fewer new design problems to tackle later in development.

--

There are likely many other things to consider, but keeping these five basic ideas in mind can have a big impact on how often you and your team make the right change to your game.