So you’re designing a new mechanic for your game, you’ve avoided the temptation to jump on the first idea that comes to mind, and you’ve got a few different ideas for it. They all seem like they could work, but you’re not sure which one is the best, or if they’d even be fun when you actually played them.

Maybe you’ve been there before, or maybe not, but it’s where I found myself last week. I decided to give paper prototyping a try for the first time as it seemed like it might give me a good idea of which of my ideas I should stick with.

Paper prototyping is just what it sounds like – a prototype of a game or a mechanic that uses paper, cards, dice, plastic figures or whatever else to test and iterate on a design as fast as possible. It lets you do the work of fleshing out a design and playing with the results without needing to spend days or weeks coding a new feature.

So why would I do this?

I wanted to implement a mission system for Chaintanks that would break up the game into chunks that would take a few minutes each to play. I had two ideas for how to do this and I decided to make a paper prototype of one of them. The idea was interesting, but I wasn’t sure if it would be fun when I actually implemented it, and I knew it would be very difficult to balance.

In this design, players would be given 24 hours to spend completing missions. They’d select one of three missions with different properties like difficulty, reward, and the number of hours it would take. They would fight a battle that would take a few minutes, then continue finishing missions until they’d used up all of their time. Finally, they’d fight a boss which would end the game.

Pixels to paper

Some parts of this design translated really well into paper and some didn’t. The missions could easily be represented by cards with the various properties on them and split into three decks the player draws from each turn. The battles on the other hand couldn’t be represented on paper, and trying to hack the game to simulate the battles would take too much time to code and play.

I decided to use a simple formula to determine how strong the mission is and have the player roll a D20 against that strength. If the player failed the roll they’d be increasingly penalized depending on how low they rolled. I did this to simulate a player playing the game poorly and losing big chunks of their tank.

My goal was to test out just the card system and nothing else. It’s a bit unfortunate that the gameplay has to be simulated by dice rolls since player skill generally isn’t so random. Even still, the random element did take away the skill I’d have at Chaintanks as the developer and put me more in the shoes of an average player.

I started the prototype thinking it would take almost no time at all, but even without having to code a new feature it still took longer than I expected. I had to create around 30 different cards that would create interesting risk vs reward choices while still being balanced against all the others. That alone took a couple hours of plugging numbers into a spreadsheet before I was even ready to make the cards.

Creating the cards didn’t take much time, but after I’d played the game a few times, I wound up changing the numbers on almost all of them. That took almost as long as creating them in the first place! An hour here or there might not sound like a lot, but since I’m doing this in my off hours while working full time, even an hour is a fair investment of time.

The results?

By the time I was done I had gone through three revisions of the game and tested each one at least a few times. The first version wasn’t a lot of fun, but I was able to get some good insights into why that was and refine it. By the time I got to the third prototype I was making some pretty interesting choices and having fun trying to get the best score possible.

I’ve decided to implement the idea in the game, but the paper prototype will probably still be useful in the future. Playing through a full game of Chaintanks will probably take around 30 minutes, but playing the paper version takes only 5 or 10 minutes. Once I have this feature implemented, I’ll still be able to use the paper prototype to balance and improve the missions without spending hours on play testing.

The hardest thing to balance when I implement missions will be the difficulty rating. In the paper prototype, creating a difficulty rating that offers an element of risk versus reward was easy. Replicating this in Chaintanks will be harder though. As I mentioned in a previous blog, the game has problems in the late game. I think I’ve fixed these issues, but it’s possible they might pop up again now that the game will last a lot longer.

Keeping the game balanced and fun isn’t going to be an easy task, but I’m looking forward to growing my skills as a game designer no matter the outcome. This prototype did take a fair amount of time, but I’m glad to have experimented with a new feature before committing to it rather than repeating the mistakes I made with Alpha Strike.