Don't make this assumption about your players (Developing 10)

The plan seemed straightforward: take the levels from the previous development push, bundle them into a demo, put the demo on a Steam Deck, fly to San Francisco, and hand it to people at the Game Developers Conference.

Then, with one week to go before the flight, the demo went to one especially important playtester. He did not enjoy it. He found the game frustrating and tedious, and he gave up before the demo was over.

That painful session exposed a huge and common mistake about difficulty. The game had not simply become too hard. It had been designed around an assumption that had never been properly tested: that players would solve things quickly, understand the mechanics immediately, and need extra complexity to stay interested.

Before that moment, the demo already looked substantial. A puzzle matrix had helped generate about 26 levels. Those levels became an hour-long demo with three worlds, two magnets, and a long list of mechanics: color-changing panels, laser beams, moving platforms, wheeled boxes, spinning switches, and more.

Early testers found bugs, exploits, annoyances, and inconsistencies. Then Patrick Traynor, the designer of Patrick's Parabox, played through the game and shared a two-hour recording. That recording was nerve-racking to open because it showed someone evaluating the game in real time, with no advance clue about whether he liked it.

On the whole, he did like it. He laughed, smiled, complimented the puzzles, and saw potential in the magnet-platformer idea. His criticism was also useful. The game needed to communicate what the player could not do inside each puzzle. If a gap was too wide to jump, it should be obviously too wide. If a door closed too quickly to pass through, it should snap shut immediately.

He also gave one large piece of advice: simplify the levels, even if that made the game easier. That advice would soon prove to be exactly right.

With two weeks left before the conference, the demo was overhauled. Levels that did not work were removed. One relied too heavily on reflexes to be a good puzzle. Another had an exploit that was hard to fix. A pure platforming level was tried as a change of pace, but mixed feedback put it on the cutting room floor.

New puzzles filled the gaps. Mechanics became more readable. Linked buttons gained icons. A strange magnet sensor became a pulley panel that pressed a button when the rope hit the bottom. Simple green buttons became chunkier Frankenstein-style switches. A lock-and-key interaction gained a satisfying animation. The pause menu and title screen were polished. A prototype dialogue system was added to suggest where the story might go.

The demo looked much better, but the underlying difficulty assumption was still there. The game had been cleaned up around a problem instead of confronting it directly.

The crucial playtest came from the developer's dad. He was frustrated, annoyed, and found many levels overly complicated and tedious. In several cases, he simply handed the controller back and asked someone else to do the level for him.

As painful as that was, it made the design mistake suddenly obvious. A level would often begin as a simple layout that tested one clean interaction. But then the designer would imagine players solving it instantly, deciding the game was too easy, becoming bored, and judging the whole project as worthless.

So the level would gain extra steps. It would gain traps where one wrong move forced a reset. It would gain red herrings and extra elements that obscured the real solution. The result was not a better puzzle. It was messy, convoluted, frustrating, and tedious to play.

The design had been focused so much on making the levels hard that it had forgotten to make them fun.

The important question was whether the assumption was true. Would players really solve the cleaner version instantly? Or had the extra complexity been solving a problem that did not exist?

One level showed the issue clearly. In the original version, players had to use two magnets to flip two switches at the same time, lift two drill bits, make a laser hit an orb, and open a door. The underlying puzzle was good, but it was buried under so much extra procedure that even describing it felt tedious.

The level was remade around clarity, elegance, and simplicity. It used one magnet, fewer mechanics, a much smaller space, and a cleaner setup. There was no time left to run a full round of testing before the trip, so the new build went straight onto the Steam Deck.

At the conference, the answer arrived quickly. Players did not immediately blast through the simplified puzzles. They got stuck for a minute or two, understood the trick, and had the wide-eyed aha moment the game had been chasing. The frustration and confusion were gone, but the challenge survived.

The conference feedback was strong. People said the demo felt like a real game. Some refused to give the Steam Deck back until they had finished it. Making the game easier had been the right move, and in some places the game still had not gone far enough.

One remaining level was still too fiddly. More importantly, several basic mechanics had never been properly taught. Players stumbled over actions such as using the magnet to ride up to a higher platform or changing a magnet's polarity from far away.

Those actions felt obvious to the designer because the designer had lived inside the game for months, knew every solution, and had written the rules. A first-time player has none of that context. They do not know which moves are possible, which objects matter, which ideas are intentional, or which interactions are supposed to be puzzle solutions.

That is the central lesson: always challenge assumptions about your players. Do not assume they will find the game too easy. Do not assume they already understand the mechanics. Do not tune around the knowledge, skill, and familiarity that only the designer has.

Thinking like a new player is a skill, and it can be trained. Shigeru Miyamoto has reportedly told new designers to try playing with their left and right hands switched on the controller, as a way to simulate unfamiliarity. That is an extreme version of a useful principle: look for ways to experience the game without all of your practiced habits.

The best method is still to watch other people play. If possible, sit in the same room. Nothing is more humbling, or more useful, than seeing someone fail to understand a mechanic that seemed completely obvious during development.

It also helps to test with people across a range of skill levels. Young playtesters can be especially revealing, though their spoken feedback may be generous enough to be biased. The important part is often not what testers say after playing, but what they do while playing.

Target audience matters too. A major part of the difficulty problem came from worrying that expert puzzle players, the sort of people who complete Stephen's Sausage Roll or Baba Is You, would think the game was simple and dumb. But those players were not the target audience. The game was meant to reach a broader group: people who might enjoy gentler puzzle adventures such as Toki Tori, BoxBoy!, Inside, Limbo, and Portal.

A clear target audience keeps design choices grounded. A very hard game can still offer assist modes. A very easy game can add optional harder content or post-game challenges. But the core experience should be tuned for the people the game is actually trying to serve.

Finally, do not be afraid to start a level from scratch. Level design involves discovery, and a first draft often accumulates fluff while the designer is still figuring out what the level is about.

Once the core idea has been found, rebuilding the level with that knowledge can produce something far more elegant and coherent. The first version is not wasted; it is the messy route to understanding what the level should have been.

That same revision logic is obvious in writing, where a script might go through five or six drafts before anyone sees the finished piece. Level design deserves the same patience. The first draft finds the idea. The next draft should present that idea clearly enough for a real player to enjoy it.

The next job, then, was to step back and build a demo around even more basic concepts, then put that demo in front of people from the real target audience. That is the healthier loop: test assumptions, simplify the design, teach what players actually need, and make challenge come from understanding rather than friction.