Rapid Prototyping vs. Reckless Prototyping: How the Sausage is Made

It's been a while since I wrote a long "how the sausage is made" post about the process of game design. Here's one! (tldr; There are big changes coming to Belle of the Ball, but they're for the greater good.)

If I'm known for anything, it's probably that I shoot off game ideas at the drop of a hat. Of course, game ideas are very different than solid games. While working on Belle of the Ball, I resisted my natural urge to make drastic changes as a result of a bad playtests. I tried to stay patient, making small changes, and testing them out with several different groups in rapid succession. Here's what I've learned over the past year.


1: Base Changes on Feedback

Designing a proper game takes a lot of time for playtests, review, refinement, editing, and testing again. (I'm not talking about publishing here, just the design.) In January 2012, I decided I'd design a fully polished and working card game with Belle of the Ball's theme before the end of the year. I began with Prototype A and now it's finally approaching a final form in Prototype N in November.

If you're keeping track, that's 14 distinct prototypes in 11 months. You can track the changes to the project here. As you can see, it's a lot of incremental changes that, in the aggregate, make the game pretty different from beginning to end. When local playtesters sit down to play Belle, they joke about "So, is this completely different, too?" (Ironic, considering that those incremental changes pretty conservative when compared to my usual habits.)

Each playtest did offer very good insights. These led to changes to rules, card presentation, basic strategies, and point balances. All those changes were based on feedback and evidence. Still, after Prototype M, it felt like I was designing in circles. Some groups were coming back with feedback saying the game was great, others that they were lost and had no clear direction for their strategy.

The most discomforting feedback was hearing people had fun, despite problems with the mechanics. That meant I had something good lurking underneath my poor game design, but I somehow hadn't found it yet. Oy.

This led me to making small changes to address complaints while keeping anything that was getting good praise. I was so afraid of throwing out the baby with the bathwater that I only tossed out a teaspoon of bathwater at a time. (Okay, weird analogy. Moving on.)


2: Incremental Changes Can Lead to the Wrong Conclusions

Case in point. For several of the most recent prototypes, players had basic actions listed on cards in their collection. These are things, like "draw a card" and "play a card." When you group cards together, you can do all the actions in that group in one turn. However, you only score points if the suits on those cards match each other, so you have to decide whether a group will be mainly a tactical advantage or a long-term strategic advantage. A pretty nice gimmick.

There were other cards whose actions are rare, but powerful, like "steal a card from an opponent" or "steal a group from an opponent." If a player got these cards early in the game, he could steal an opponent's most basic functionality and cripple them for the whole game. Because other parts of the game were getting such good feedback, I only made the smallest possible changes to address these concerns.

That brings us to a playtest a few weeks ago where I debuted a slightly tweaked version of Prototype M. The only major change was that basic action cards were unstealable. This backfired terribly. Without a take-that option, the ability to steal cards felt pretty useless in the early game. It became obvious that the other elements of the game weren't sturdy enough to support early play. This particular test went through about six rounds until the testers finally admitted that they just had no idea what they were supposed to be doing.

I called off the rest of the game and we went on to play games that were actually fun. I went home frustrated and confused. All those months of design, all the changes, and the game still fell totally flat with the gamers I most respected.


3: Sometimes You Need Drastic Solutions

I've been here before. Back when I was designing Do: Pilgrims of the Flying Temple I was still a novice at story games. I began the project with certain assumptions about what a story game was supposed to have: Assumptions like "Stats" and "Character Creation."

In pursuing those assumptions, my earliest drafts of Do featured an elaborate procedural part of the game where players tell small stories about how their characters first got into trouble and rescued each other. It was a lovely little experience and it got lots of good feedback, but it took so much creative energy and time that each playtest never got to the actual game. I must have gone through five or six sessions were we never got passed character creation.

Playtest time is precious. You never know when you'll get another opportunity to bring this group of generous people together. And, indeed, they loved character creation. Heck, I wanted the game to have a fun character creation experience, but that was built on the assumption that a story game had to have character creation at all. I eventually realized interesting character creation wasn't as interesting as removing character creation altogether. (Mind you, this is mainly the case for Do, not judgment on other story games.)

I stripped out that whole part of the game. Roughly 40,000 words went to the trash. What little character creation remained was distilled down to two questions: How do you help people? How do you get into trouble? This takes less than five minutes and mainly serves as an elevator pitch for the actual gameplay experience. I was finally able to test and refine the actual game itself.

The earliest playtesters sometimes ask if I'll release the character creation procedure as a separate product. I might, but I'm in no real rush. It was mainly a hack of Spirit of the Century's character creation.


Changes to Belle of the Ball

Here's what I realized about that awkward Belle playtest. As I removed a clear short-term goal ("steal the other guy's basic actions"), the rest of the game didn't present any other short-term goals or even a long-term strategy. This was the root cause of the analysis paralysis problem present since the earliest prototypes. I was so distracted by pursuing the group-action gimmick that I couldn't see the core problem until then.

So I woke up the next morning with a very different vision in mind. Though the fancy party theme remains, the gameplay is offers very different options in any given turn. I scribbled down some notes and tested it over breakfast with my wife, then later that week with co-workers and friends. This led to further refinements over the following weeks and I'm happy to say it's actually a fully functional and fun game.

Prototype N is going to have the most fundamental changes to gameplay since the earliest prototypes. I lifted some pay-to-pick mechanics from games like Smallworld, No Thanks, and Manhattan Project. I also added conveyor belt line of cards, much like the line of cards in Guillotine. But just because the changes are big, doesn't mean they're reckless nor does it mean Prototypes A–M were a waste. All that time was spent in the service of creating a better game at the end of the process.

If you have been following the design process this year, you may regret that some of your favorite features have been lost along the way. That's the risk of transparent design. I appreciate your trust and I hope you'll enjoy where Belle ends up.

Boy, I do hope my process will be a little bit more efficient in the future though.