The Best Way to Succeed is to Fail

For the past several weeks we’ve been prototyping different ideas for a new mobile game. Taking the time to “find the fun” through experimental prototyping is one of those Game Development 101 strategies that everybody agrees is a good idea and yet few teams actually have the leeway to implement. Very often the schedule is written to assume the game will be fun after a few tests and therefore the team can move into production quickly. Instead, what happens too frequently is that the arbitrary schedule forces teams to switch gears before the core bits of fun have been identified, thus complicating the production process (which isn’t really production but just a more expensive extension of prototyping) and sometimes damning the game to mediocrity.

At Robot Invader our development process is driven by a simple mantra: never compromise on quality. If we can’t execute the idea we have at the quality we require, we will simplify it or cut it. There’s almost never a good reason to ship something that is half-assed.

So, with our quality-focused mantra in one hand and our sense of enlightened professionalism in the other, we optimistically dove into prototyping our new game idea. The initial concept for the game looked good on paper, but, as we should have anticipated, actually implementing the damn thing revealed a lot of flaws. First and foremost, our design called for the user to touch objects in the environment as a character moves through the scene. As soon as we knocked together a basic prototype of this mechanic, the core idea upon which we intended to rest the entire game, we found it was basically unplayable: the moving character required a moving camera, and manipulating moving objects on the screen, even when they move slowly, is difficult and frustrating.

Cue doubt and apprehension. Our sense of enlightened professionalism called in sick that week. We had an idea, and we made it, and guess what? It wasn’t good enough. Our mantra for quality requires us to change it or throw it out, so we did.

With a couple of changes we had something playable. We locked the camera in place, changed the level design to use one screen worth of real estate, and shuffled the other components of our initial concept around until it worked. And actually, it worked pretty well. Within a few days we had a bunch of levels, each with different mechanics, each of which might make their way into a final game. It was encouraging progress because we were able to make levels that were extremely difficult without being arbitrary or unfair. I think the mark of a good game design is one that can scale up in difficulty without relying on changes to the core rule set, and with our tweaks this design certainly stood up to that test.

At first we felt good. We were back on track with a few minor edits to the original formula. But as we worked forward with the prototyping, our excitement waned. The design was solid, and we could make a whole game out of it. And it would be a fun, if somewhat quaint puzzle game. But it wasn’t going to be a big breakout success. It was a little underwhelming.

As we started to prototype the art pipeline we realized that we’d made a trade-off without even realizing it. By simplifying our game concept to work around flaws in the original design we’d cut the teeth out of our art. With a static camera the scenes that Mike was building became flat and boring. There’s nothing wrong with 2D games, but we have a specific style in mind that doesn’t work well with a flat perspective. Though it would be wrong to make the game design subservient to art requirements, trading art quality for design hacks is also not acceptable. It’s a compromise, and quality is the loser. A better game design would work in tandem with the art, not against it.

So we changed gears again. Went back to the drawing board, resurrected some ideas that had landed on the cutting room floor during our previous experiments. And this time, it’s clicked. The design was easy to prototype and is more fun to play after only a day or two of work than our previous attempts. It works with the art style, and in fact has opened up many avenues that we didn’t previously consider. The camera is moving, the interface is simple, and it’s able to draw upon game design precedent without losing its personality.

There are still many questions we haven’t answered. Our experimental prototyping work will continue until we can show how the design will scale across an entire game. It’s possible that we’ll find some flaw in this new approach, but I don’t think it’s likely. The white-box prototypes are fun, there’s a great deal of flexibility inherent in the idea, and it’s going to look awesome. We’re excited again, and glad we didn’t settle for a mediocre idea. Making the game as good as it can possibly be will require our noses to become intimately familiar with the company grindstone, but the path forward is clear.

Of course, when we have more to share you’ll hear about it here first.

One Response to The Best Way to Succeed is to Fail

Is your team in the game design stage and you are prototyping portions of the design to see if you are going to get the quality you want? And if you don’t get that quality, making changes to the design? In other words seeing if you have a good game design? Or you have a game design completed and you are making changes to get the quality you are looking for like playability, performance, visual appeal, etc. by optimizing your code or changing the artwork to not slow down frame rates or use too much memory? Just trying to learn from some experts. 🙂

Search for:

About Robot Invader

We warped our brains watching '50s monster movies in glorious black and white. Now we're making video games for your phone, tablet, or virtual reality headset.