How Game Designers Solved These 11 Problems

Summary

The video presents game design as an ongoing process of identifying problems, testing solutions, and checking for unintended consequences. Its examples offer these practical lessons:

• Find the root cause before changing a feature. In Dying Light, players said weapons broke too quickly. Rather than changing weapon durability and risking the game’s economy, the team lowered zombie health so players could defeat more enemies before a weapon broke.
• Make sure everyone agrees on what the problem is. During Astroneer’s development, designers disagreed about whether crafting was too simple or too complicated. They realized they were talking about different things: the overall gameplay loop and the moment-to-moment operation of machines. Addressing both made the system more engaging and easier to use.
• Iterate to learn. For Diablo III, Blizzard tried several ways to prevent players from spamming healing potions. Testing imperfect ideas helped reveal what mattered: players should be encouraged to fight aggressively. The eventual solution was for enemies to drop health when killed.
• Identify which design “levers” can change without damaging a feature’s identity. In Halo 3, Bungie preserved the sniper rifle’s defining traits—such as its range and powerful headshots—and instead increased the delay between shots from 0.5 to 0.7 seconds.
• Try dramatic changes, not only small tweaks. Near the release of the first Civilization, Sid Meier cut the map size in half to improve pacing. His advice: double a value or cut it in half to quickly see whether a change makes a meaningful difference.
• Reverse the premise if the current solution isn’t working. Shovel Knight originally charged players to use checkpoints. Yacht Club Games flipped the idea: saving became automatic and free, while breaking a checkpoint became a risky way to earn money.
• Look for a fix outside the system where the problem appears. The Last of Us moved weapon upgrades out of the inventory menu and into upgrade benches in the world. This made the feature easier to notice and encouraged players to plan upgrades around the resources they had.
• Prefer solutions that address more than one problem. In New Super Mario Bros. Wii, defeated players returned in bubbles that teammates could pop. This made waiting after death less frustrating and let less experienced players sit out difficult sections until it was safe to rejoin.
• Use observed player behavior to shape a solution. In Gears of War, experts often reloaded before emptying a magazine, while beginners tended to fire until it was empty. Epic secretly strengthened the final bullets in a clip, giving beginners a helpful boost without changing the active-reload system.
• Watch for second-order effects. In Rainbow Six Siege, reducing the power of an overperforming shotgun also weakened defenders. Ubisoft shortened round timers so defenders could win by running out the clock more often, restoring balance.
• Design within real constraints. Late in Prey’s development, the team needed another enemy but lacked time and resources for a conventional one. The poltergeist—an invisible foe that attacks with nearby physics objects—provided variety with fewer development demands.
• Test the result with players. Return to playtesters, or use fresh eyes, to see whether the original problem is actually solved. Avoid explaining the change beforehand, since that might bias their reactions. If the fix fails, use what was learned to redefine the problem and try again.

Featured People and Development Teams

People: Mark Brown, Maciej “Matt” Binkowski, Wyatt Cheng, Jaime Griesemer, Sid Meier, Shigeru Miyamoto, and Ricardo Bare.

Teams and studios: Epic Games, Blizzard, Bungie, Yacht Club Games, Naughty Dog, Nintendo, Ubisoft, and Arkane.

Games discussed: Gears of War, Dying Light, Astroneer, Diablo III, Halo 3, Civilization, Shovel Knight, The Last of Us, *New Super Mario