3 min read

Spoof of Concept [1/10]

Part 1 of 10: Design to Succeed

Part 1 of 10: Design to Succeed [previous parts]


There is a difference between good gameplay and gameplay that appears good from a specific standpoint.


One project I worked on was an otherwise generic action game that also allowed the player to perform a number of cool and unique moves. Their coolness was twofold: it looked great when you performed them, and your enemies reacted to them in ways that looked awesome. Think of a very spectacular explosion that sends your victims on really nasty trajectories, like fancy fireworks made of flesh and blood. That project was very cool in this fashion, if you're into this kind of things.

Our prototyping focused on finding new ways for the player to be cool using those moves, and new cool ways for enemies to react to player actions. Our goal was to make prototypes as cool as possible, in order to showcase the full potential of our mechanic.

Playtesters loved it.

Publisher loved it.

Somehow, even the receptionist loved it.

But only after we had pointed the potential of the mechanic out to them, because they never could find the fun on their own. That is not to say there was no tutorial. It was there, but it showed the functionality, not the fun.

Even after people were shown the content and enjoyed it, they would slowly forget about it as they kept playing. We had to keep reminding them about it. This isn’t really something you can do to actual players. They would feel like they were forever stuck in a tutorial level.

The flaw of our mechanic was fairly obvious: regardless of how cool it looked, it was redundant. Once players had learned the basic moves, there was no incentive for them to explore the advanced ones, and there was in fact no way for them to know there were many advanced tricks to discover. A good tutorial could tell you about the buttons, but not about all the possible combinations.

Obvious or not, we didn’t learn about it until it was too late, because our prototypes were only designed to look at where the mechanic succeeded. We never honestly asked ourselves if it had any flaws.

Our approach was anti-scientific in nature. In order to move your hypothesis into the realm of verifiable results, you need to provide a way to disprove it. "Scientific proof" occurs when experiment fails to fail, so to speak.

Should we focus on ways to prove our idea wrong, we would quickly discover how limited the applicability of unique player moves was. Then we would either find ways to make them more useful, or ditch the entire mechanic and do a cutscene instead.

We never tried, because the idea of proving ourselves wrong was counter-intuitive. It felt like sabotaging our own work, whereas it was, in fact, the best way to make it better. Pushing the mechanic to its limits would improve it in the process, but the process itself would challenge our self-confidence.


Lesson Learned: Design To Fail. Make prototypes that attempt to shoot your own idea down.

Latest Jobs


Chicago, Illinois

Build a Rocket Boy Games

Edinburgh, Scotland
Lead Animation Programmer

Windwalk Games

Austin, Texas
Game Designer

Sucker Punch Productions

Bellevue, Washington
Campaign Director
More Jobs   


Register for a
Subscribe to
Follow us

Game Developer Account

Game Developer Newsletter


Register for a

Game Developer Account

Gain full access to resources (events, white paper, webinars, reports, etc)
Single sign-on to all Informa products

Subscribe to

Game Developer Newsletter

Get daily Game Developer top stories every morning straight into your inbox

Follow us


Follow us @gamedevdotcom to stay up-to-date with the latest news & insider information about events & more