Photo: fra.ps
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.
This is a great article. I don’t think you can overstate the importance of really understanding the problem. I’ve had several problems, game design and otherwise, come back and bite me because I thought I had solved them, and didn’t really understand them.
Also, I’ve been trying to come up with a new approach to dialog. I’m eager to see how you solved the problem.
I’ve had this Hard problem thing happen to me many times. One example is a side scrolling action game I was making. I wanted the game to function a little more intelligently than previous action games. I wanted the enemies to put up a decent fight and have decent AI as well. That wasn’t so hard. I also wanted them to have multiple hit points 1 for head, middle and low. And likewise the player could attack with high, middle and low attacks. It all worked out in my head.
However a problem arose that I hadn’t considered. Because I designed my game around using slopes and cliff faces in order to break up the flat plane it made fighting enemies with multiple hit points cumbersome. If you hit the enemy that was below you while you were on a cliff face with a low attack it would obviously hit the higher hitbox. And vice versa you could hit an enemy’s low point with a high attack.
This to me was unacceptable. I designed the game to make clear distinction between High, Middle and Low attacks and I didn’t want to break that illusion as I feared it would confuse players.
So knowing I was in trouble I went and researched all the 2D side scrolling action games that were like mine. My first look was into fighting games. While looking through Street Fighter, MVC2, Guilty Gear etc I quickly realized that the fighting takes place on a flat plane with no inclines, declines, or cliffs this is why High, Mid, and Low attacks work so well I figured. So with that knowledge I understood that I was fighting an uphill battle.
The next game in my study was Odin’s Sphere and Demon Blade Muramasa. These games are the framework around what I would love to accomplish but I always felt combat was severely lacking because enemies are stupid.
Anyway in both Odin’s Sphere and Muramasa(more so Odin’s Sphere)flat planes are used for fighting. And when there are cliffs and other obstacles in Muramasa it doesn’t suffer the same problems as me because the enemies have only one hitbox.
After studying many more games including Super Smash Bros and Castlevania SOTN I knew I was trying something that hasn’t been done exactly how I was trying.
The solutions I figured could work are as follows
1. I could take all slopes and short cliffs out of the game. However I felt this would be a bit monotonous even if I made it inside a factory or something where slopes and such are rare. This could definitely work.
2. I could realign the player’s and enemies rotations so even if they are on a slope the line up right. Low attacks hit low mid hits mid etc… However this would limit my slope angles. No 45 degree staircases because even with rotation one character is going to be much higher or lower.
3. NO COMBAT TAKES PLACE ON, NEAR OR AROUND SLOPES,SHORT CLIFFS OR ANY OTHER ANGLE CHANGING OBSTACLE. This seems like the ideal situation. I could have simple enemies, machinery and flying enemies with ONE hitbox that appear in angle variety areas that can take advantage of the surroundings.
And with areas that have flat planes I can focus on the meat of the intelligent combat with other humanoid creatures.
4. Take away what makes it unique and have every enemy have only one hitbox and take away the players ability to attack high, mid or low. I really didn’t want to try this but it was always on the table. If I did do that I would have to find some other way to make it unique this in turn would motivate me to finish the game as opposed to making a clone of something and getting bored.
(Oh man sorry for writing a novel)
Another Hard problem I ran into (this will be short lol) is I was trying to make a mockup DS game using Multimedia fusion. The look I was going for was big expressive characters and bright colors. 1 character would be on the top screen and another would be on the bottom. It would use a static camera and be a platformer. They would work together to solve the levels puzzles.
However I didn’t take into account that because there are 2 screens the size of the levels would be dictated by the size that could fit onto ones monitor without distortion. Because I’m a nice guy I don’t design my games to only work in 1920×1200. So the vertical limit of my screens would have to be something like 600-800 pixels.
The reason it would need to be so big is because there is only a certain amount of puzzle creation that can take place in one single area. And because the more space I had the more expressive I could make the characters. Also because it’s a platformer the amount of space is limited to left and right movement along with jumping.
Anyway I had to fine tune the movement physics just right so you wouldn’t move to slow or too fast and be able to walk from one end of the screen to the next in 2 seconds. Possible solutions are below
1. Discard the idea for big cute expressive characters instead use small characters with less expression. Something like 16×16 or maybe 32×32 however thats pushing it if I use DS screen resolution.
2. Increase the screen size which in turn allows me more expressive characters and as another result increase the level to level workload. I think this will be the best solution if I can strike a compromise between character size and Screen/level size.
3. Make the game 8 directional (kinda like Lolo) which would allow me more space and no need to worry about gravity or vertical physics.
a. If I chose 8 directional movement I would still have to make a compromise between characters size and screen/level size.
b.yadayadayadyada this is getting too long.
This is just an example of 2 Hard problems I’ve encountered and just how much torture it can put one through.
Currently I am still working on both games albeit a lot less.
I hate HARD PROBLEMS.
What’s the best way to prevent Hard problems?
(Once again sorry for the novel)
There is no way to prevent Hard problems.
Asking “How can I avoid Hard Design Problems?” is like asking a programmer “How do you avoid implementing tough programming problems?” or an artist, “How do you avoid having to draw things that you aren’t really good at drawing?” It’s necessary to get better at your craft. Going through Hard Designs is absolutely necessary to becoming a great designer.
Of course, you could always just copy other games entirely and never innovating. Then you’d avoid Hard Problems. :-)
Good article. I liked the solution to hard problems that you gave.
I do have one thing to say, that’s not especially relevant. I don’t understand one thing. Game designers hire professional artists to make the sprites of a game. They hire professional musicians for the music, etc. However, a lot of them just come up with the game story and dialogue themselves. Why not hire a professional writer? That way movie directors’ll need another insult for bad movies instead of “it looks like a videogame”
Pingback: The Most Underappreciated Job in Game Design | The Game Prodigy
“I won’t go into detail here, but you guys might see it in a future game I’ll release. :-)”
Oh what a horrible tease :)
Do you have an example of an actual solution to a hard design problem?
In Super Mario Galaxy, I’m certain that many design discussions were focused around the camera issue of what happens when the player runs on to the underside of a surface. The options:
- Flip the camera upside down (disorienting)
- Flip the controls backwards depending on what side he’s on(Mario would be stuck turning around and around in the same place as the player holds the same direction; bad)
- Remap the old controls to the new orientation (the controls are now backwards; up makes Mario go down, and down makes Mario go up)
I’m certain they tried all of these and decided none of them worked. At first this looks like all the options, but there was one they didn’t try. And that’s the control/camera solution they went with, and you almost never notice it because it works so well. You can see what they finally did by checking out the game.
(I thought I’d end on another horrible tease :)
There are of course hundreds of other hard design problems. Getting Sims to eat, sleep, and take care of themselves on their own in Sims 3. Giving the feeling that the player needs to run frantically into the battlefield in Call of Duty without actually being able to kill the player. Getting the player to feel like pressing “A” to assassinate a guard in Uncharted is fun, as opposed to relying on some kind of minigame. These were all very tough but were all solved.
Thanks for the comment!
Pingback: How Smart Designers Prep With Game Research | The Game Prodigy