I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game. To that end, I'm going to go through the development process to release a game. Here is the transcript from the fifteenth episode on making paper versions of your game first:
Welcome to another Adventure Mechanics side quest. I'm Chandler. I have been getting swamped by the overwhelming nature of Cartogratour lately. In an attempt to still make forward progress, I have been trying to break down the game into all the smaller mini games that will make up the bigger game as a whole. Even that's has proven to be a problem for me, though. I keep getting stuck in the development swamp, not sure if the game I am making is even fun. So, I'm going to try something different with the mini game I'm currently working on: I'm going to make a paper version of the game and try it out before spending time committing it to code. In this side quest, I want to talk about prototyping your digital game on the table first.
So, what does that mean? If it's a puzzle game, that means building and testing them using tokens and board game pieces before you put them to screen. In some other cases, you may be able to proof out the game using just a deck of cards. For one game jam, the team I worked with did exactly that. We pulled out a set of playing cards and made a game using those cards and a couple of tokens. It was fun to play in person, too! The rest of the jam, everyone had a better idea of what the game was supposed to be because we sat down and hashed out all the details beforehand. In the end, the trash talk from the table didn't get included for the AI we put in, but the core was still there. Not having trash talk, along with poor instructions, made the digital version confusing and feel kinda flat, but it was amazing to play test the game on night one of the jam. I'll put a link to what we made in the show notes, but that experience turned me onto this methodology for testing game concepts.
What games can be prototyped like this? It turns out a lot. If you haven't seen how the original Super Mario Bros was developed, each level was plotted out on graph paper and checked against the constraints before they could be coded into the game. Everyone had a chance to look at it, see where it wasn't going to be fun, and adjust parts to be able to fit into the tiny amount of memory on the original Nintendo Entertainment System. By the time they were play testing the game, the team had confidence that each map was going to at least keep the flow of the game, if not be fun. Keep in mind that at the time, they didn't have the same type of tools that we have today. Committing to code wasn't as fast as mocking up a pre-fab and pushing it to the scene. It took more effort to put it in, so making sure it was the way you wanted was more important.
Another, probably more obvious, example is Civilization. The Civilization series centers around the 4x genre; Explore, Expand, Exploit, and Exterminate. This obviously lends itself to converting to tabletop, since the game that it is famously named after started there. New game mechanics can be tested and refined in a night of gaming, instead of waiting for weeks to have features implemented. Moreover, developers can set up a specific situation to really test a scenario over snacks. No one is spending huge amounts of time doing a rudimentary implementation of a game before seeing if it's fun. It also allows for rapid iterations to see if any tweaks are necessary as you adjust rules to better match the game loop you want the player to experience.
One other, possibly less obvious, reason to make a tabletop version of what you're building is to see if it's engaging. As Mark Darrah of BioWare fame mentioned in his talk, Will it be FUN?, it can be used to test seemingly inappropriate types of mechanics, such as real time melee combat in an adventure game. At the end of the day, whatever you end up with for your combat system, you'll have to come up with a model, or some other way to represent it. If that combat can be represented in some way, it can be represented on the table. It doesn't necessarily have to exactly be represented on the table, either. If your combat relies on percentage, you can use two d10 to represent that, or use opposing card draws from a deck of cards. Whatever you can use to get the same expected feel with a given mechanic will work. The point isn't to make a full blown tabletop version of your game, but rather to only test to see how engaging it is, or can be. At the end of the exercise, you should expect to set aside what you build and start work on implementing it digitally.
So, why do this at all? Well if I haven't convinced you that there is value in examining games, or even single mechanics, before implementing them, I suppose that's your perogative. Planning out something and getting iterations in when it's relatively cheap will make your game not only better, but also faster to finish. If you are on a tight budget, or have extremely limited time, spending some time on a table version of things will make your vision more clear earlier in the project. And that's the point. I'm not advocating that making a tabletop version of you game will be the magic bullet you need to get you game done. Far from that. It's only a tool to explore what you want to make, and maybe expose a flaw in it early. Like all tools in your toolbox, it's up to you to make use of them, or not.
Now that I've convinced you of at least the value of tabletopping your game, let me talk about how I'm applying this to Cartogratour. I am currently working on the gardening portion of Cartogratour. I plan on planting and harvesting being a story point in the game, so I need to have it be engaging. I examined gardening and farming that a few other casual games, especially ones with a larger focus on story telling, but none of the minigames on farming were really what I was looking for. I decided to take a mechanic from one of the tabletop games I play with family. In the game Patchwork, each player is trying to build out their quilt using pieces from the center to make their blanket with as many buttons and as few holes as possible in order to win. For my take on gardening, I wanted to evoke the feel of getting into your garden and really planning it out, making sure that each plant is getting it's proper framing and can really shine in context. I didn't see any real incentive for aesthetic consideration in any casual slice-of-life game, so I want to bring that in using the quilt building mechanic in Patchwork. Instead of building up the quilt, however, you're building up a garden bed. Each plant will have it's own requirement, and each garden bed will have it's own conditions, including shading and types of soil. All these considerations will determine the ultimate value of the garden.
That sounds ideal to mock up on the tabletop, doesn't it? In my initial test, I'm setting up a static version of the garden plot and trying a few different plants, with different layouts. For the layout of each plant, I'm envisioning that each will be something similar to a tetrimino. You know, the tetris pieces. This will force the player to make less than optimal choices and enable a sort of high score for a given garden. I'm not quite sure how shading will be visualized, but I am going to start with a card that is drawn to give a quadrant that is shaded on the plot to start off with. My initial plan for scoring is to score each plant in it's ideal conditions, matching the soil types, along with shade requirement. If there are any blank spots in the garden, that will be some sort of point penalty. Once I have all of these mocked up on paper and play test it a couple of times, I should be able to see if the game is engaging. I'll let you know the results in a follow up episode.
But, that's enough about tabletop testing your game. As always, if you have suggestions, observations, or any other thoughts on this, leave a comment or reach out to me on Twitter. My handle is @jcsirron. This has been another Adventure Mechanics Side Quest. I'll talk to you next time.
