Spoof of Concept [1/10]

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.