Game design mistakes 5: Your game idea sucks, part two (Game design vs. software development)

by Gil Hova

I’ve been reading a lot about software development, and there are a lot of new techniques out there that have some creepy parallels to board game design.

With the old-school “Waterfall” software development technique, the developers would get their requirements from the project stakehoders, and retreat into their offices or cubicles. Several months later, they emerged with the program.

A diagram of the Waterfall model

A diagram of the Waterfall model

You can imagine typical issues with this model. Maybe the stakeholders would catch glimpses of the project as it’s being put together, and maybe they can occasionally offer some input. But for the most part, the development process isn’t something they have control over. So if and when the software came up buggy and/or short of spec, they’d have to call a new project to fix the problems with the old project.

Newer methodologies have established themselves since then. These methodologies are more iterative than the Waterfall technique.

A diagram of the Iterative model

A diagram of the Iterative model

These processes emphasize constant communication between the project stakeholders and the developers. Every few weeks, the stakeholders get a version of the project that’s as functional as possible. They provide their input, and the developers include that input in the next version.

Board game designers: does this look familiar at all?

It turns out that software development and board game design are very similar. Just replace “project stakeholders” with “game players,” and you have a pretty good model of how the game design process goes. You come up with a playable version of the game, let it get torn apart by the playtesters, and adapt their feedback into the next version of the game.

So, how does this relate to how your game idea sucks?

Lots of game designers have an idea, and insist on sticking to that idea even after playtesters insist that the idea is holding back the game. Let’s say you have an idea for a wargame that includes dart-throwing as a combat resolution mechanism. Your playtesters love everything about the game except the dart-throwing.

So what do you do? Do you re-jigger the dart-throwing? Do you adapt the other mechanisms so the dart-throwing fits better?

New designers tend to stick to their original ideas. If their muses gave them this idea of a dart-throwing wargame, then dammit, that’s going to be what they put out.

But more seasoned designers will realize that if they removed the dart-throwing and replaced it with something the playtesters enjoyed, s/he would wind up with a fun game.

This sort of thing is impossible without the iterative technique. Most of the actual work in game design isn’t spent sketching ideas or backstory into a notebook. It’s spent getting the game on the table and seeing how it breaks. Then, after you figure out ways to fix those problems, you get it back out on the table and try to break it again.

Every time you sit down with your playtesters, listen to them. That’s not the same thing as “implement everything they say,” because sometimes they’ll suggest a radical change when a minor tweak will solve the same problem. But if a lot of playtesters complain about the same thing, look for the root cause of the problem they’re talking about, and try to solve it as simply and elegantly as possible.

One other thing: some designers put a lot of sweat into flavor text and backstory. Save yourself heartache: save flavor text and backstory to the very end of the game design process. If you spend a couple of weeks writing the history of a desert region where your game is set, and then realize it’s better set on a coastline, then you’ll have to redo the backstory. Instead, finish the game first and then write the backstory.

I have to tread carefully again here, because some designers are inspired by backstory, and they’ll work on a game’s narrative to help flesh out game mechanisms. If that’s how you work, then be careful about spending too much time on developing the game world instead of the game. People would rather play a fun abstract game than a dull but well-themed game.

If you design games as an excuse to write backstory, then you may want to consider putting the game aside and just writing a book. You may find it a more direct route to realizing your vision.

As a game designer, you have no obligation to your original idea. Remember: Your game idea sucks, but the finished game it will spawn is going to rule!

Your only obligation is to give people fun games to play. If playtesting leads you to a radical design change that would make the game significantly more fun, but would cut the game off from its original inspiration, do it! Make the change.

At worst, if you still feel obligated to the original idea, you can always start again, with what you learned last time. Maybe that dart-throwing wargame’s problem was the wargame part. Maybe you should split the design into two different games, a wargame and a lighter dart-throwing game with a war theme. Now you’re sticking to your original inspiration, and you have two exciting games you’re working on!