Recently, I gave a talk at a panel during AndoCon 2014 on board game design. There were a lot of great questions during the panel, and some of them were on topics I’ve already covered previously on this website. There were also a few great questions, that I haven’t shared my thoughts and experiences on, so I thought I’d answer one of those today. The question asked of me was on prototyping. It ended up being a multipart question that covered a few key points. The first being what’s the best way to make your game look good during a prototype?
I love this question because I’ve approached this several ways in the past, and I see designers approach it in a number of ways as well. The best approach is to have your game look as good as it is done. What do I mean by that? Basically, if the game is new, and has barely been play tested, then it visually should look pretty rough, and be made from unimpressive components. In that way, if the game is nearly done, then it should have great visuals, and nice pieces to reflect its state of completeness. This may seem counter intuitive. Why not have a game look great early on? Honestly I see a decent number of developers have wonderful pieces, for early drafts of their games.
Let me tell you a quick story. When I first got back into game design I decided to share a game I had designed with a local gaming circle. I decided I wanted to show them what I knew would become a great game, so I wrote the rules in great detail, created wonderful art, and even imported little glass vials and filled them with glitter to use as a game pieces. The game was gorgeous, and so the first time I took it to the board game store where I wanted to play test it all I had to do was open the box, and people flooded over to see my work. Let’s just say the game was nowhere near ready to have other people play. I in fact only took it to the store to buy deck protectors for it, and I wanted the cards with me to test. I was trying to keep the game a secret till I tested it a few times. I was talked into trying it the next day, and it went poorly. It didn’t go poorly for the reasons you might expect. Don’t get me wrong the game wasn’t ready, but that was only half of it. The real trouble was everyone could see the huge amount of effort I put into the project, and that made it really hard to get real feedback about the game. It wasn’t until a year later, and long after I scraped the project, that I finally found out details about what people thought.
Seeing that so many hours were lost making the game look good I decided I needed a way to get my ideas on the table faster. I also needed to get people’s expectations in line with the current state of the project. If the game was a rough draft, so were the visuals. With that in mind I eventually came up with my rapid prototype system. It started as an experiment. Get a bunch of cheap blank white cards on Amazon, grab a pen, and other bits, and see if I can design a game from idea to a finished playable game in under two hours. On my first try I had a game ready to play in just barely that time. It played, well, OK. It wasn’t great, but I had come up with an idea, and made a playable game in a very short amount of time. I later tried it again, and had a game ready in an hour, and it was honestly a better game. However, the goal wasn’t to make a good game, or a great game, but just prove that functional prototypes didn’t need to take countless hours.
Since that time most every game I work on uses some variation of the rapid prototyping system, and I found as a great side effect people give me more open and useful feedback. It also ironically seems to be that rapidly making games seems to improve their quality. Several of the games I’ve designed using this system barely change from their first draft to their final draft.
The real question people have for me is what is the rapid prototyping system? And that is a great question. I meant to answer it during the panel, but we moved onto another topic, so I’ll answer that in next post.