How Game Designers Solved These 11 Problems

The coolest feature in Gears of War is the active reload. Every time the player reloads a gun, the game invites them into a tiny timing challenge. A cursor sweeps across a line, and the player can hit reload again to try for a prize. Hit one part of the bar and the reload happens faster. Hit the best part and the weapon also gets a boost, such as more powerful bullets. Miss the timing and the gun jams.

It is a great feature because it adds tension, skill, and flourish to one of the most ordinary actions in a shooter. But it also left Epic with a design problem. In playtests, advanced players were hitting the perfect reload constantly. That gave them stronger bullets and a clear advantage over enemies, so the team rebalanced those enemies to make them more resistant.

Beginner players often ignored active reload entirely. They did not get the weapon boost, but they were now fighting tougher enemies with weaker bullets. A feature that made experts feel powerful had accidentally made the game harsher for newcomers.

So much of game design is about problems like this. A designer comes up with an idea, then discovers that it is unbalanced, confusing, pushing players toward the wrong behaviour, or clashing with another system. The hard part is not only having good ideas. It is learning how to find good solutions when those ideas meet real players.

Before proposing solutions, the team has to identify the problem accurately. During development of Dying Light, the game director reported that weapons broke too quickly and asked the designers to increase durability. Lead designer Maciej "Matt" Binkowski did not want to adjust that stat immediately, because changing weapon durability could disrupt the game's economy.

Instead, he dug into what the complaint really meant. The issue was not the number on the weapon. It was that players could only kill a few zombies before a weapon broke. The fix was to lower enemy health rather than increase weapon durability. That solved the reported problem and made basic combat feel better too.

The lesson is simple but easy to skip: step back and find the root cause before solving the symptom that was first reported. If the real problem is "the player cannot kill enough zombies before the weapon breaks", then several systems can be adjusted. If the problem is framed only as "weapon durability is too low", the design space becomes much smaller.

Teams also need to agree on what problem they are discussing. Just before Astroneer left Early Access, the designers wanted to improve the crafting system, but they had very different ideas about what was wrong. One designer thought the system was too simple and wanted more machines and resource chains. Another thought it was already too complicated, with processes that felt fiddly and unintuitive.

Those positions seemed opposed, so the conversation naturally created friction. But when the team broke the problem down, they realised the designers were talking about two different issues. One was looking at the shallow gameplay loop from a wide systems perspective. The other was looking at complex machine operation through moment-to-moment interaction.

Once the team saw those as separate problems, both could be addressed together. The fiddly machines could be overhauled, then used to expand the simple crafting loop into a more interesting economy. The disagreement was not solved by choosing one complaint over the other. It was solved by naming the two layers clearly enough that they could both be improved.

When Blizzard was making Diablo 3, the team wanted to fix a problem from Diablo 2: potion spamming. Players could drink endless potions during combat, which meant enemies needed huge one-shot attacks to threaten them. Blizzard did not know the right answer at first, so the team tried a range of builds.

One idea made potions less effective if players drank them in quick succession. That did not work, because if a potion healed for only 25 percent, players could drink four of them. Another idea gave the player automatic healing only when enemies were unaware of them, but enemy awareness was not obvious enough. A simpler version started healing after three seconds without damage, but that made players run away from fights and act defensively.

That failure pointed toward the real solution. Enemies would randomly drop health globes when killed. The new rule removed potion spamming, was easy to understand, and pushed players to act aggressively, which matched the combat Blizzard wanted.

This kind of iteration uses failed solutions as information. Designer Wyatt Cheng has said the team knew one early potion idea might not be shippable, but built it anyway because it would teach them more about the problem. A prototype does not have to be the answer. Sometimes its job is to reveal why the answer needs to be different.

In a GDC talk about game balance, Bungie's Jaime Griesemer explained how the team fixed the sniper rifle in Halo 3. The rifle was overpowered because players could acquire long-range targets too quickly between shots, and they could also use it in close quarters for massive damage.

Solving that meant identifying which design levers could be pulled and which ones could not. Griesemer argued that the team could not shorten the range of a sniper rifle. It also could not reduce its damage, remove accuracy, or stop instant-kill headshots. Those properties defined the weapon. Change them and the sniper rifle would lose its identity.

Removing those options made the useful levers clearer: shots in the clip, reload length, zoom-in time, time between shots, whether headshots worked outside the scope, and maximum carried ammo. The right adjustment was the time between shots. Increasing it from 0.5 seconds to 0.7 seconds stopped players from instantly reacquiring and shooting targets after each bullet, while also making the rifle less effective as a close-range trigger-spamming weapon.

Finding the levers focuses attention. It helps the designer separate the feature's identity from the numbers around it. But this has to be done carefully. Sometimes the thing a team has declared untouchable is exactly the thing that needs to change.

The Halo sniper fix was a small change with a large effect, but some design problems need a much bigger swing. Less than a month before the first Civilization shipped, Sid Meier realised that the game had pacing issues. His solution was to reduce the size of the map.

He did not trim a few tiles or shave off a small percentage. He cut the map in half. That dramatic change made the game move faster, feel snappier, and better capture the relentless forward progress that gives Civilization its shape.

Development time is limited. If every balance pass changes values by tiny amounts, the team may never reach the answer, or may discover too late that the chosen direction was never going to work. Meier's advice was to double it or cut it in half. A dramatic change quickly shows whether the adjustment has the right effect. If it goes too far, the designer can pull it back.

In Shovel Knight, Yacht Club wanted a save system with a risk-and-reward twist. The first version made checkpoints cost money. Players could pay to save, or skip the checkpoint and keep the cash while risking more progress if they died.

The system had problems. It was complicated to use, visually unintuitive, and badly balanced for novices. The players who most needed checkpoints were also least likely to have enough money to buy them.

The solution was to flip the concept upside down. Instead of paying money to save, what if players got paid for choosing not to save? Checkpoints became automatic and free, removing the complexity and protecting novice players. Expert players could still break a checkpoint on purpose to earn more money and take on extra risk.

Sometimes a design is close to working, but the reward and cost are pointing in the wrong directions. Reversing the formula can preserve the exciting part while removing the friction that made the first version fail.

When Naughty Dog was working on The Last of Us, Joel could initially upgrade weapons at any point from a tab in the inventory UI. That created several problems. The minimalist interface became more complex, some players missed the option entirely, and many players upgraded as soon as they could afford anything, usually choosing whatever was cheapest.

The team could have kept iterating on the interface: a different button, another screen, a clearer label, a stronger tutorial prompt. Instead, the solution was to remove upgrading from the inventory UI and put it into the world.

The game introduced upgrade benches: specific places where the player could modify weapons. Because benches were separated by long stretches of play, players had more resources saved up by the time they reached one. They spent more time comparing options, boosting weapons they liked, and planning for the next bench.

Games are webs of connected systems. A problem in one area is sometimes best solved by changing another area entirely. The fix for a UI problem might be level pacing. The fix for a resource problem might be enemy health. The first framing is not always where the answer lives.

During multiplayer sessions in New Super Mario Bros. Wii, the designers found it annoying when a player died and had to wait until the end of the level or a checkpoint to return. The first idea was that knocked-out players could randomly respawn inside question-mark blocks. It was charming, but the team kept looking.

The stronger solution was the bubble. A knocked-out player returns in a floating bubble, and a teammate can pop it to bring them back into the level. That solved the original problem by letting players rejoin quickly.

It also solved another issue. When novice players reached a section they could not handle, they could put themselves in a bubble, let stronger players make progress, and then return when it was safe. One feature made dying less frustrating and gave players a way to manage difficulty for themselves.

Shigeru Miyamoto's well-known design principle applies here: a good idea can solve more than one problem at once. That does not mean every solution needs to be clever in several directions, but it is worth waiting for a fix that makes the whole game healthier rather than merely patching one complaint.

The Gears of War active reload problem eventually came back to player behaviour. Epic had boosted enemy health because advanced players were getting perfect reloads and earning a damage boost. But that punished beginner players who ignored the system and were now facing tougher enemies without stronger bullets.

The team noticed another difference between those groups. Top shooter players rarely finish a clip. They reload before they run out. Novices usually keep firing until the clip is empty and the game reloads automatically.

That observation created the answer. Epic secretly boosted the power of the last few bullets in a clip, which the team called magic bullets. In practice, novice players were much more likely to receive that buff, giving them an advantage similar to the expert player's perfect reload without forcing them to master the active reload system immediately.

Many design problems are discovered by watching how players interact with the game. The same observation can also reveal the solution. The point is not only to gather complaints, but to notice the habits, timings, omissions, and workarounds that separate one kind of player from another.

Once a solution is implemented, the design work is not finished. One challenge is second-order effects: the changes that appear elsewhere because systems are connected. In Rainbow Six Siege, Ubisoft needed to fix an overpowered shotgun. The team nerfed it, and the shotgun stopped outperforming other weapons.

But the change also made it much harder for defenders to win against attackers, because the shotgun had been an important defensive tool. A weapon fix had become a side-balance problem. The solution was to reduce the time limit on rounds. Because defenders win when time runs out, the shorter round timer helped bring the two sides back into balance.

A fix can be correct locally and still damage the wider game. Designers need to ask what else depends on the thing being changed, which playstyles or roles are being weakened, and whether the new imbalance needs a second adjustment somewhere else.

Another challenge is finding a solution the team can actually build. Late in development on Prey, Arkane's designers realised the space station needed more monster variety, but the team did not have enough time, artists, or AI programmers to create a fully new creature in the usual way.

The solution was the poltergeist. This enemy is invisible and attacks by throwing nearby physics objects. Because the creature did not need the same visible body, animation load, or AI complexity as other enemies, it required dramatically fewer resources than a more traditional foe.

Designer Ricardo Bare has argued that good designers understand how to solve problems within the constraints they have. Many design issues appear late in development, or after a game is live, when the perfect solution is no longer available. In those moments, the best answer may be the one that delivers the design need without pretending the team has unlimited time or staff.

Finally, the team has to test whether the solution actually solved the problem. That means going back to playtesters or bringing in fresh eyes. Jaime Griesemer recommends not telling playtesters how the issue was fixed, because that knowledge can bias their experience. The useful question is whether the problem has disappeared in play, not whether people approve of the designer's explanation.

If the fix does not work, the failed attempt may still be useful. Like Diablo 3's potion prototypes, it can reveal that the team was solving the wrong version of the problem, or that the question needs to be reframed. A bad solution can still move the design forward if it teaches the team where the real issue is.

Game design is all about solving problems. Very few ideas survive first contact with players exactly as imagined. A feature may look elegant in a design document and still become unfair, unclear, dull, exploitable, too expensive, or damaging to another system once people actually play.

The best designers are not only the people who come up with strong ideas. They are the people who can diagnose what went wrong, align the team around the real issue, try solutions quickly, choose the right levers, make bold changes when needed, flip broken concepts, move the fix to another system, solve several problems at once, watch player behaviour, respect constraints, and test whether the result truly works.

That is what ties these 11 problems together. Each solution begins by treating the design as a living system instead of a single isolated feature. The right answer is the one that makes the game work better for the player, even when it arrives from an unexpected place.