Designing a Game on Paper Before Committing To It

4 years ago by Jon Topielski (@jontopielski)

Share this post:

Over the last two weeks, I worked on a deckbuilding game called Ghost Roulette for Major Jam: Isolation. I designed the game on paper first and played it as a paper game before taking the time to convert it into a video game.

I decided I wanted to make a deckbuilding game that uses some kind of "roulette" mechanic for the jam. For the first time I thought it would be interesting if I designed the game to a somewhat significant extent first before implementing any of it, as opposed to doing design and implementation at the same time. Since this was going to be a deckbuilding game and I had playing cards and chips, I thought it would be a good experiment.

So, I busted out the pen and paper and the poker set and got to work.

My game involves having enemies place their chips before you but you having the ability to use cards to remove enemy chips or manipulate the board in your favor. So I sat there and gave myself chips and cards which represented different abilities. I manually placed the enemy chips each turn and created a gameplay loop for the game. Very early on I could tweak things like card count or starting chips or card definitions. There were major changes to the game during this initial design process.

Above you can see my makeshift "roulette" numbers 1-12 with red/black/even/odd squares. I placed chips onto these squares to represent bets. I used playing cards to represent both the cards in my hand as well as the wheel itself by drawing from a random pile of cards representing 0 -> 12.

Here you can see some of my notes for rules and different card definitions jotted down.

After playing my own game for about 2 days, I found myself starting to actually enjoy the game. I looked forward to playing my own game even though it was with poker chips and paper. It was at this point that I realized the game concept was solid enough to actually implement. So I set a minimum viable product goal of getting the game playable to the first boss fight and then expanding from there.

If my game hadn't been that much fun and I wasn't able to find interesting gameplay, I probably would have just scrapped it and moved on. I think this is one of the benefits of working in this way.

Another benefit of testing the core gameplay idea first before implementation is that the implementation part can be scoped more accurately. Since I know exactly what the systems are going to look like and for what scale they will operate, I can design those systems in that way from the beginning, rather than hacking them together to get a playable MVP and then refactoring them to a larger scale.

This was an interesting experiment and I believe it led to a more straightforward development process. I designed the game, then knew exactly what I was implementing. It was never unclear what the end result would be, which never left me confused about what the game was at the core. I would call it a focused or inspired development process.

Obviously not every game can be played physically like this but maybe the idea can be extended to just making sure a game is fun at its core with nothing else before committing to developing it. Not only does it help confirm if the game is worth working on but defining the game parts and what will be required to implement them up front will smooth the development process down the road and hopefully lead to fewer major design changes (and thus less refactoring).

Thanks for the read! The rest of this devlog will just be screenshots of the game as it came to be in the span of roughly 7-10 days.