Tabletopping your game

        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.

Momentum

     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 this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from the twelfth episode on momentum and how to keep it going for a project:

Welcome to the adventure mechanics side quest and it's me, Chandler. With the holidays in the rear view mirror, I've come up against this unenviable situation: I've been officially working on CartograTour for over a year. Sure, I haven't worked on it as much as if it was my day job, but I still haven't gotten nearly enough of it done. I've taken a look at my version control history, and, I've got to say: it's a sorry sight. There are periods of manic pushes coupled with rather large swaths of... Well, nothing. Some of those lulls were due to personal issues, but most were due to lack of inspiration. I had trouble refining the main gameplay loop in my head for quite some time. I have only recently come up with other things for the player to do that fit diegetically. With those last pieces in place, I think I have a relatively good foundation to start executing on the game. Artwork continues to be a struggle for me and sound design hasn't even come up, yet. That being said, those things aren't something I had to focus on quite yet. But now the project is now to the point where coming up with ideas is finally ending and it's time for me to look at something I haven't really done for a game: production. For today's side quest I'm going to talk about production and keeping momentum going on a project.


Now, I know I just did a side quest on motivation and you may wonder why I'm talking about momentum. They're roughly similar in terms of goals and results, so why focus on something so close to it? Well, honestly, it's because of the difference between the two: motivation is about starting, momentum is about continuing. That is one step closer to the end product, after all. More importantly, that's what you need for production. All of it is in service of that end goal; getting the game out the door and into your hands. Motivation is the micro issue every day, momentum is the issue for every update. I'm not going to be obtuse and say it's a macro issue, but it is certainly an issue. Without momentum, you can easily get stuck in "the swamps" of game design. And, oh boy, you do not want to get stuck there. Trust me.


First, let me clarify what "the swamps" of game design actually are. They are the time between first prototype and final polishing. That time where you're not quite sure the design is actually fun. You're in production, yes, but you're not done with tooling up, yet. These are times where momentum is absolutely sucked from you. The swamps may be short, or they may take a long time. Bioware programmer and producer Mark Darrah somewhat loathingly describes the end of the swamps as "Bioware Magic." This is that magic point where productivity shoots through the roof and the roadmap to finish the game finally hits something more realistic than finishing a decade from now. Now, to be clear, that typing point is also a sign of crunch in a team and I highly recommend listening to his reasoning why you shouldn't use the term "Bioware Magic" at all, but that's not really why I brought it up. It's more so because of that time before suddenly becoming more productive. The times where you're struggling to find the fun in the game, to get the real core of what the game you are developing should be. Time in the swamp can be short, or it can be years. How can you avoid, or at the very least minimize it? Keeping momentum.


Keeping momentum going in your project is rough. If you need any proof, take a look at any dev log for an eventually abandoned game on YouTube. Solo devs spend a year (or more?) on a single project, only to end up abandoning it later. They may lose motivation, they may have a life event that prevents them from developing further. Whatever the reason, though, their game is left only visible in dev log videos, a stark reminder of what could have been. Now, some of these games were appropriately abandoned, others, not so much. One thing that is common to most of the projects I see is that the developer tends to spend more time producing the dev log updates than actually working on their project. That’s certainly not true with all projects, but enough of them want to talk about their game and produce “sizzle reels” over actually getting the game done. After all, time spent on producing other things can take away from the project itself. Sometimes you need to walk away from it and come back with a fresh mind, but if you’re working on a consumable related to the game that isn’t in service to the end goal, you really are taking away from it. *cough* I’m looking at you, Chandler… *cough*


So, how can you avoid that fate and keep on track? Well, in perfect honesty, I’m probably not a good role model to look at. That doesn’t mean that I don’t know what's necessary to get a project done, though. Small wins are key. They are the things that you look back at and point at that you completed, or are really proud of. That doesn't mean amazing artwork or a really appropriate soundtrack or sound effect, either. It's making the main menu, the options screen, all the small things that make a game complete. Sure, there may be some days where you look back at what you've worked on and not really be able to point at anything, but you need to keep those days to a minimum. Even if it's a tiny improvement, completing that one feature or even tweaking it to feel better will keep momentum going. In the game forum I'm part of, we have a saying, "no zero weeks." The real quote is, "no zero days," but most of the forum goers have day jobs and family and can't necessarily work on our game designs every day, hence why we changed it to weeks. The point still stands, though. If you want to get a game done, you need to put in the time to finish it. It will never get done if you don't put in the time. And for me, at least, that means having small wins every time I sit down to work on Cartogratour. That little bit of dopamine keeps me wanting to come back to work on it.


That's not to say that's the only way to keep momentum. Another way to keep momentum is to have some form of accountability. It may be something you announce publicly, or to yourself, but having accountability will force you to have someone, or some time to be done with your game. I know I literally just railed against devs that did it and quit, but dev journals can be one method of making yourself accountable. I personally don't find them to be really motivating, since your accountability is more nebulous than having a friend that can take you to task when you're not done when you say you were supposed to be. A public dev journal does provide some sort of accountability, though. If that's going to be enough for you to get your game done, do it. Personally, I need something more to keep myself on task, though. As I said earlier, I am part of a game development forum. Part of that is updating everyone on what you've done over the last week. It's not a whole lot more, but having to say that you haven't gotten much, or anything, done on your project does give a tiny bit of a guilt trip to keep making progress on it. So far, that has actually kept me working on a game design longer than when I didn't have the forum for accountability. Having to update a group on a regular interval is what helps me the most in terms of keeping accountability.


Whatever you use to keep accountability, make sure that you're not losing the end goal of having it in the first place: Getting the game out the door is the first priority. If you no longer are getting value from one form of accountability, jettison it. If the accountability isn't helping you get closer to your goal, change it's form or ditch it entirely. Accountability is only as good a motivator as you allow it to be. If that accountability changes to something else and becomes another hobby or whatever, make sure to find a replacement. Most importantly, if you don't get motivation from the accountability, don't spend time trying to conjure it. Switch to a different strategy that works for you.


On that note, one last way to keep momentum is to make a timeline, or set a short term goal for what needs to get done. In more formal company environments, I would be advocating for scrum or sprints. In this case, I'm advocating to chunking out the work into as small of pieces as possible to get the game done. It's not sexy, or even interesting for that matter, but it works. Small pieces are just easier to finish over getting something huge done. That ties into my first method, go for the small wins. Having small pieces planned out can prepare for just that situation. I may not like mixing work and my hobby, but this is genuinely one thing I have pulled from my professional life into my personal life that helps me. The important thing is to not plan out everything in such detail that you feel like it's "just executing" on it to finish the game. Things change in design and when they do, you'll be throwing away that effort that you put into the later parts of the plan that are no longer relevant. And that's just wasting effort that can be put towards the game itself. So, plan in smaller chunks and get those parts done. Then repeat that cycle as many times as needed. And if you find yourself getting overwhelmed by the pieces you've made, it's a good sign that you aren't done breaking apart your work. I'm currently in the throes of doing exactly this to Cartogratour. I'll make another update for that when I'm done planning it out, though.


That's about all that I have for this side quest. Hopefully you find it entertaining, if not enlightening. As always, if you have any questions, ideas or comments, reach out to me on Twitter. My handle is @jcsirron. I will talk to you next time.