Tackling Hard (really hard) Design Problems
by Brice Morrison
Computer Scientists have an official definition of a problem that is “Hard”. Some problems, regardless of your intelligence, the computing power you have, or the algorithms you can come up with, are mathematically Harder than other problems. They are fundamentally different in nature from simpler problems. In Hard Problems the solution, even though no one knows what the solution is yet, can already be predicted to be very complicated and costly.
Game Designers also often run into what I like to call Hard Design Problems. These problems seem to come up with some regularity, they share similar attributes each time, and they’re scary. Namely:
When designing a feature, level, or part of your game, you realize the design you were planning won’t work out as you had imagined. At all.
Every design answer that you can immediately think of as a response won’t work.
You realize that either no one has done this in games before, or people have tried and it turned out to be a poor game experience.
At first, you have no idea how to proceed. You’re out of ideas, and the few ideas that you do have seem to all be bad ones or disqualify themselves in some other way. You have fallen down a rabbit hole.
Hard Design Problems are scary for a designer. You break out into a sweat, fearing that you’ve already tumbled past the point of no return and your only solution will be to either deliver a sub-par game experience or scrap the whole project. Your mind starts racing, questioning your design judgement. You think “There has to be something I’m missing,” but after two hours of discussion with teammates or alone in your office looking at the whiteboard, you have made no progress. Instead, those two hours have only served to help you truly understand how deep the rabbit hole goes.
If you haven’t encountered a Hard Design Problem in your design career yet, you will.
I’ve been there. In one game I was working on, I had designed (what I thought) was a dialog system that would allow players to get to know the personality of a computer-generated character. Ideally the design would allow for interesting dialog without the developers having to author specific content. You could walk up to a non-player-character and have your conversation, with the experience that you were “getting to know them”. Prototypes had been mocked up and playtested, and everything seemed ready to go.
However, after plotting out the character generator, I soon realized that this was a Hard Design Problem. If the text was generated then it would quickly become stale to the player. And if I scrambled the text or made it random, then it didn’t feel like a conversation at all, it felt like some kind of matching game.
I searched for an out. I looked at the game, fleshed out the next few sequences, and saw how it was going to go, unhappy with the results. After doing some research into how other games handled dialog systems, I saw that no one had successfully attempted what I was trying to do. I felt like I had designed myself into a corner.
When you run into a Hard Problem, it doesn’t feel like a great experience. But Hard Design Problems are where heroes are made, where Designers can show their true skills, coming up with ideas that have never been implemented before in a game. It takes guts, and it takes perseverance, but it can be done. Hard Design Problems are what separate Pro Designers from the hobbyists.
So how do you tackle a Hard Design Problem? There are many ways, but one method has consistently helped me and many teammates work through a problem. Though it may sound simplistic at first, you’ll be amazed at what you can tackle one step at a time.
First, Understand the Problem
Often, this is the longest step; you need to find out exactly what this problem is and explore it completely to wrap your head around how it works.
Hard Design Problems can sneak up on you. Things are going perfectly well, you’re working on your space attack game, driving your ship around and shooting other ships, nothing innovative. When suddenly you see the flaw, and so you try to design around it in a way that still provides that player experience you want. The first step usually takes care of 90% of design issues. But in a design rabbit hole, this does not solve the problem. It may even exacerbate the problem.
Once you realize you’re in, at this point you need to explore it. Talk through the gameplay experience. Understand exactly what is wrong, and why it isn’t working. Make some paper prototypes, draw some demos on the whiteboard, or hack a program together and play. Try as many variations as you can think of and make sure that you absolutely understand what is going on, and the steps that are leading to the result you don’t want. Look at other games and see how they have handled (or failed to handle) similar problems.
In my conversation prototype, I tried to understand the design in several ways. I progammed a quick prototype that would allow me to play through multiple iterations of the game quickly. I also mapped out the player flow on the board, seeing what they were thinking, (“First, read all the dialog options. Second, try to guess which is the right one.”). Finally, I looked at other games and how they handled dialog, from branching trees, to ELIZA, to Heavy Rain and Mass Effect.
Don’t take this section lightly; you should be spending quite a long time noodling and thinking the issue over. The point of this stage is to make sure that before you go any further, you know how deep in you are already. The worst thing that can happen in a Hard Design Problem is to think you’ve solved it and continue forward on your game, only to run into the same Hard Design Problem again because you didn’t fully grasp the issue that was in front of you.
Second, List all the Possible Solutions
This is the fun part. Once you understand the design as much as you can, it’s time to start coming up with solutions. But not just one solution, you need to map out each possible solution so that you can THEN go back and pick out the best one. This is still a brainstorming stage.
For my dialog problem, I listed off each solution one by one. I could turn the dialog options from text into icons, like “Anger” and “Humor”, and have the player pick those to get the NPC’s personality. I could author the dialog myself. I could make branching trees that were randomly generated. Or I could get rid of dialog in the game.
Note, particularly from that last one, that EVERY solution must be considered, even ones that you know you aren’t going to pick, or ones that are impossible given the circumstances (time, content generation, etc). Why? Because picking all the solutions, even the bad ones, will help to further map out the problem and let you understand how deep it goes.
With each of these solutions, don’t write them on a board and move on. Flesh out what it would really mean to implement that solution. How would the rest of the game be affected? How long would it take you? Quantify each solution clearly so you can get ready to make a decision.
Third, Pick the Best Solution
Once you’ve mapped out all the solutions, it’s time to decide. Look at all the solutions, every possible solution, and take heart that if you have done the first two steps correctly, then this is all that you can do. You have to play with the poker hand that you’re dealt with, and this is your hand. You have done your homework and now it’s just time to pick one.
For my dialog system, I eventually came up with a system that would allow both text, variety, and mapping personalities on each characters. After nights of long work, I was really proud of it. I won’t go into detail here, but you guys might see it in a future game I’ll release.
Make sure that when you leave the Hard Design Problem, it is truly finished. Don’t leave any loose ends or anything to chance. Every possible answer, no matter how stupid, should have been seriously considered before being discarded. These explorations and decisions are what make great games and great designers.
Don’t Be Afraid!
Hard Design Problems are inevitable, but failed designs are not. Put on your thinking cap, sit down with your notepad, and prepare for one of the best lessons that you can get in making games. Tackling tough problems is the best way to learn and grow.（source:thegameprodigy）