How Game Designers Solved These 11 Problems

The coolest feature in Gears of War is, definitely, the active reload. Here's how it works: every time you reload your gun, you're invited to play a tiny mini-game. A cursor swipes along a line and you can hit reload again to try and win a prize. Land here, and you'll reload super fast. Land here, and you'll also get a weapon boost - like, more powerful bullets. But land anywhere else and your gun will jam. It's a great feature - adding tension, skill, and flourish to one of the most basic actions in shooters. But, it also left Epic with a problem. You see, in playtesting, the devs found that advanced players were nailing that perfect reload, constantly giving them better bullets and, thus, an advantage over the enemies. So they had to rebalance all the foes, making them more resistant.

But, beginner players often ignored the active reload entirely. So they didn't get that weapon buff - and were now fighting these overpowered bad guys with weak bullets. Agh! So much of game design is about solving problems like this. You come up with an idea - and then find out that it's flawed in some way. It's unbalanced. It's confusing. It's not leading to the gameplay you intended. Or it's clashing with some other feature in the game. And, as a designer, you can often find yourself going around in circles to find the right solution.

Surely there's a better way? Well, in this episode, let's look at how the best game creators go about solving problems in their design - to give us some take home tips for fixing future issues. Oh, and I'll also let you know how Epic fixed the active reload. The solution is... pretty ingenious. I'm Mark Brown, and this is Game Maker's Toolkit.

So, before we start coming up with solutions... we need to make sure that we've accurately identified the problem. During the development of Dying Light, the game's director had an issue: weapons break too fast, and so he told the designers to increase their durability. But, lead designer Maciej 'Matt' Binkowski didn't want to fiddle with that stat because it might mess up the game's economy. So, instead, he dug deeper, asked more questions, and got to the real problem - players could only kill a few zombies before their weapon broke. So, to fix this, the designer didn't touch weapon durability at all, but instead lowered the health points of the enemies. It solved the problem, and basic combat felt better too.

Binkowski suggests designers step back and figure out the root cause of the problem, before trying to solve the issue that's been reported. We also need to make sure that everyone is on the same page about the problem. Just before Astroneer left Early Access, the designers wanted to improve the game's crafting system - but had very different ideas about the issue. One designer thought it was too simple, and so wanted to add more machines and resource chains. Another actually thought it was already too complicated, with fiddly, unintuitive processes.

This, naturally, led to disagreements - but it was only when they stepped back and really broke the problem down, that they realised they were talking about two completely different issues. One was looking at the shallow gameplay loop, from a wide-angle systems perspective. The other was looking at the operation of complex machines, through the lens of moment-to-moment interactions. Now, seeing eye-to-eye, they could solve the underlying problem, and fix both issues at once. Those fiddly machines could be overhauled, and then used to expand the simple crafting loop to create a more interesting economy.

Okay, so hopefully we now know what the real problem is. So how do we fix it? Well, here are some best practices from across the industry.

Approach one - quickly iterate through possible solutions. When Blizzard was making Diablo 3, they wanted to fix a problem from the previous game: potion spamming. Players would often just guzzle endless potions during combat - and so enemies needed to do massive one-shot hits to have any chance of actually killing the player. Unfortunately, Blizzard didn't really know how to solve this thorny issue - so, they just tried a bunch of ideas.

How about - potions become less effective if you drink them in quick succession? Slap a build together and... that didn't work - if a potion only heals for 25%, players would just chug four of them. Okay, how about you automatically heal - but only if enemies are unaware of your presence. Make a build and... no good. Enemy awareness just wasn't obvious enough. Alright, let's simplify the rule: if three seconds pass without you taking damage, you start to heal. Build the game and... didn't work. Players would run away from fights, acting passive and defensive.

That's the opposite of what Blizzard wanted - players should be aggressive. Ah! But, that did point to the solution: make enemies randomly drop crystal balls filled with health, when you kill them. This removes potion spamming, it's simple to understand, and it makes players act aggressively. Job done. This approach is all about trying stuff and using the results to guide your way to the solution. Like, that first solution with the diluted potions, designer Wyatt Cheng says "we weren't totally thrilled with this solution as we were putting it in, but we did it anyway. We knew that even though this might not be a solution that we're willing to ship with, it was something that was going to teach us a lot more about the problem".

Approach two - identify the levers In a fascinating GDC talk about game balance, Bungie's Jaime Griesemer explains how his team fixed the sniper rifle in Halo 3. You see, the rifle was broken: players were able to acquire long-range targets too quickly between shots - and, they could also use the sniper rifle in close quarters for massive damage. It was overpowered. Fixing an issue like this means first identifying which levers can be pulled - and which ones can't.

For Griesemer, you can't shorten the range of a sniper rifle. And you can't nerf its damage, reduce its accuracy, or stop it doing insta-kill headshots, either. Those factors all define the sniper rifle - you can't change those stats without breaking the very identity of the weapon. So by removing those options, it became clear what can be changed. Stats like the number of shots in the clip. The length of the reload. The time it takes to zoom in. The time between shots.

Whether you can do insta-kill headshots outside of the scope. And the maximum ammo you can carry. The right call was changing the time between shots. It stopped players from instantly acquiring and shooting a target after each bullet, and it made it much less effective in close quarters now you can't spam the trigger. In the end, it was enough to increase the time from 0.5 seconds, to 0.7 seconds. By figuring out what can and can't be changed, you can better focus your attention on potential solutions. However - this must be done carefully. Sometimes the target really is that thing you've convinced yourself cannot be changed. As always, be prepared to kill your darlings.

Approach three - make big changes Okay, so I just talked about a change of 0.2 seconds - a pretty small change that had a big impact on the game. But sometimes, you want to swing for the fences. Less than a month before the first Civilization was released, Sid Meier realised that the game had pacing issues. So he decided to solve the problem by reducing the size of the map. Not by a few tiles. Or a few percentage points. He cut that sucker in half. And this worked wonders - the game moved faster, felt snappier, and it better captured that true Civ feeling of relentless forward progress.

We've already talked about iterating on a problem - but development time is limited, so if you're only ever changing things by tiny amounts - a 5% nerf here, a 6% buff there - you may never get to the right answer. Or you'll find out too late that your solution would never have worked. Meier's advice is to "double it, or cut it in half". With such dramatic changes, you'll very quickly see if the change has an effect - and if you go too far, you can always drop back down to readjust. Talking about that Civ map, Meier says "if I’d been afraid to deviate too severely from what we already had, I never would have gotten to the right size in time before the game shipped".

Approach four - flip it on its head In Shovel Knight, Yacht Club wanted to put an interesting twist on saving your progress. They wanted a system where players could risk skipping a checkpoint, in order to get a reward. So they made a checkpoint that you have to pay to use. If you want, you can skip it and save the cash - but at the risk of losing more progress when you die. But this system didn't really work. It was complicated to use and visually unintuitive. And, worse still, it had a big balance problem: novice players, who needed the checkpoints the most, were also least likely to have the funds to save their game. No good.

So the solution was to flip the concept upside down. Instead of paying money to save your game... what if you get paid if you don't save? So now, saving is automatic - removing that complexity. And it's free - so novice players never lose out. But it also has that spicy twist of risk and reward - cocky platforming experts can intentionally break the checkpoint to make more money. Sometimes you're close to the right solution, but you just need to reverse the formula.

Approach five - find the solution elsewhere So when Naughty Dog was working on the UI for The Last of Us, they initially let Joel upgrade his weapons at any point, from a tab in the inventory UI. But that created problems - it added complexity to the minimalist interface, some players missed the option entirely, and because players could upgrade whenever they wanted, they'd typically just upgrade as soon as they could afford something. Whatever was cheapest.

Now the developers could have iterated on this UI design for ages, moving the upgrade button to different screens or changing how it was communicated to the player. But the ultimate solution was to pull upgrading out of the UI entirely. Now, the game has upgrade benches. These are specific points in the world where you can modify your weapon, meaning you might not have a chance to upgrade for an hour or two. This ensured that players actually engaged with the system. And because they had more resources saved up, they were able to boost the weapons they enjoyed using the most - not just the cheapest. They also spent more time assessing all the options, and made plans for the next upgrade bench.

Remember that games are a massive web of interconnected systems - so sometimes you can fix a problem in one area, by actually making a change somewhere else.

Approach six - solve multiple issues at once During the madcap multiplayer sessions of New Super Mario Bros. Wii, the designers found it annoying to die - and then have to wait until the end of the level, or a checkpoint, to come back to life. So they needed a fix. The first idea was that knocked-out players could randomly spawn inside question mark blocks. Which is pretty cute. But they kept going until they found a better solution: players would come back in a bubble, and their team mates have to pop it to get them back into the game.

This didn't just solve the original problem. It also helped fix another one - sometimes, novice players get to a tricky bit that they can’t tackle. So, now, they can intentionally put themselves in a bubble, let the better players make progress, and then pop back out when it's safe. This one feature made dying more fun, and also let players dictate their own difficulty. Mario's daddy, Shigeru Miyamoto, has that classic quote - "A good idea is something that does not solve just one single problem, but rather can solve multiple problems at once." So, sometimes, it's best to wait for a solution that also has other benefits for the game.

Approach seven - study player behaviour Okay, let's finally get back to that Gears of War story. So, remember - Epic had to boost the health points of enemies, because advanced players kept doing perfect reloads and getting a damage boost. But this screwed over beginner players who ignored the system entirely and were now getting wiped out by these amped up bad guys. But Epic noticed another difference between these two player types. Top shooter players rarely finish a clip - they reload before they're out. But novices would typically shoot until the clip is empty, and let the game automatically reload. So this offered up a solution.

The devs secretly boosted the power of the last few bullets in a clip. Dubbed them "magic bullets". And so - on the whole - only novice players would get this buff, giving them a similar advantage to the expert players with their perfect reloads. Most of the problems in game design are derived from watching how players interact with the game. So why not that use that same approach in order to find the solution?

Okay, so now we have a solution, we can implement it. But there's still a few more challenges ahead. The first is second-order effects. In Rainbow Six Siege, Ubisoft knew that it needed to fix its overpowered shotgun. So they nerfed it - and it had the intended effect. The shotgun was no longer outperforming the other weapons. But it also had a knock-on effect: because the shotgun is a great defensive weapon, this nerf made it much harder for defenders to win against attackers. They just couldn't hold them back.

Fixing a problem in one place can create another problem elsewhere. Designers should be aware of how different systems might interlink, and be smart about avoiding these issues. Or, perhaps, figure out how to solve these new problems. The solution for Siege was to reduce the time limit on rounds. Because defenders automatically win if time runs out, this made that side more likely to succeed, bringing the balance back in line.

Another challenge is finding the resources to implement those changes. Late in development of Prey, Arkane's designers realised they needed more monster variety on the space station - but they didn't really have the time, artists, or AI programmers to make anything new. So the designers found a creative solution: the poltergeist. This enemy is invisible and attacks by throwing nearby physics objects. It needed dramatically fewer resources than the other foes in the game.

Prey's designer Ricardo Bare says "good designers understand how to solve problems within the constraints that they have", and adds that the poltergeist actually ended up being one of his favourite enemies in the game. A lot of game design issues crop up late in development - or even after the game has gone live. So sometimes the best solution is just the one that you can actually achieve with the time and resources available.

And finally, you need to test if the solution actually has the desired effect, by going back to those playtesters, or getting fresh eyes. Halo's Jaime Griesemer recommends that you don't tell your playtesters how you fixed the issue as that can bias their experience. Just see if the problem has been resolved. If not - well, hopefully, like in the case of Diablo 3's rapid iteration, this helped you figure out what the actual problem is, and you can reframe the question and start again.

As I've been discovering myself, game design is all about solving problems. Very few ideas survive first contact with players. And so the best game designers aren't those who can come up with good ideas - they're the ones who can also figure out good solutions to problems. This video was absolutely packed with stories of clever developers solving game design problems. It's like, my favourite genre. There were loads more that I couldn't fit in, so if you're a GMTK Patron on the Bonus Video tier, you can now check out a special tie-in video with even more stories.

Oh, and what about if your game has already been released and then you start getting criticism? Well, then you should check out this video to find out how to handle negative player feedback. See you soon.