Dev Journal

There are so many steps that people usually don't see when it comes to game design. Here we take a look at (almost) every step it takes, soup to nuts (or, well, cards to dice I guess). As an example, I'm going to walk through a game that we've only ideated so far and haven't built, so you know what we'd do at every step to get this out into the world.

1. IDEATION

This is the part that honestly, almost everyone can do. And does! People constantly have ideas about stories that should be written, movies they'd like to see made, games they'd like to create and play. Ideation is important - it's the start of the process. But that's just it: the start. It's like saying, "I'm going to run a marathon." But - and it's a big "but" - that's all it is, the start. You haven't finished a marathon just by wanting to run one.

Example idea: A game where you are trapped in a haunted auction house, with all kinds of cursed items, and you have to bid on cursed items you'll gain.

2. GOALS

The concept of a game starts to give it shape. A "haunted auction house" gives you an image to play with. "Cursed items" start to allow you to picture elements. The next step - and often one people mix with the first step - is defining the goal. The goal determines what a player will want to achieve, which in turn allows you to figure out how they'll go about achieving it. Are they working together? Are they working against each other? Are they working against each other AND the game? Are they cooperating AND competing at the same time?

Example Goal: The big one: escape the auction house first. To do this, we'll define another goal: successfully bidding to avoid gaining cursed items (or really, to gain the cursed items you'd prefer rather than those you don't). The lowest bidder gains the item up for auction.

3. MECHANICS

In game design, a "mechanic" is the method by which something is done. Drawing a card is a mechanic. Playing a card, rolling dice, trading cards, flipping tokens, placing tokens, placing tiles, moving tiles, and on, and on. There are a LOT of mechanics, and they start to shape a lot about the game: how it's played, how tactile it is, how visual things are, how complex actions are. Too many mechanics can leave a player confused. The wrong mechanics can bring a game to a screeching halt, or make it so that players can't achieve their goals. Sometimes when building a game, you may end up needing to add or remove mechanics as you go. You just have to make sure it all works together.

Example Mechanics: For this game we'll have a few mechanics. First, we'll have the cursed items themselves. Each item gives the user a capability, but also gives them a specific curse that will curtail their actions. These may be 3d objects, or maybe (more likely) be represented by cards. Why cards? We can easily have the image of the object, and all the content we need (description, effects, etc.) on something that is fairly cheap to produce and can carry all the information. It's why cards are ubiqitous in games. In a game like clue where a lead pipe is simply a lead pipe - has no other attributes - then a 3D object works great. But when the object needs to have more information, cards are one of the best formats.

We'll also have the bidding mechanic: spending ghostly money to avoid gaining certain items, and we'll need something to track this, like a small board and tracker. We'll have a movement mechanic (in order to escape), and possibly some ability to perform other actions with the items.

4. GAME PLAY

We have our idea, we have the goals, and now we have some of the ways to achieve those goals. Now we need to start figuring out game play. This is where we start to figure out what the players will actually do and the order they'll do it in. Will there be individual turns or simultaneous? Will turns have phases? What will each turn consist of? Will there be something that happens every round of turns? We have two stages of the game (the Auction stage and the Escape stage) so will the turns have to be different for both?

Honestly, this is where it starts to get hard. To this point, we've just had ideas and expanded on them. Now we need to start structuring those ideas into what will become a playable game. And not only a playable game, but a game that is enjoyable to play! There's no real shortcut to this part. You have to lay out each step of your game and see how well it feeds into the next. It requires having an idea of the game setup and the components before you even have the components figured out. So you get into a bit of a "chicken and egg" scenario at times. It's these things that make this stage of game design so difficult.

Example Game Play: The game will be structured into two stages: an Auction stage and an Escape stage. The Auction stage will have items that are drawn in a random order (shuffled cards) and each bidder (player) writes down their bid on a piece of paper, hidden from each other. Bids are revealed in player order, and switches to the next player (clockwise) after each bid. The lowest bidder gains that cursed item. Items should have a max spend (the reverse of a real auction which tends to set starting prices) to prevent bidders from using up all their money too fast. If two bidders spend the same lowest amount, the first bidder in player order wins the bid and gets the item.

After the Auction stage we have the Escape stage. All players have their meeples placed in the Auction room. They need to work their way through the auction house while dealing with their curses. I picture a board with various traps and triggers along the way, and potentially multiple exit points. Players will be able to use some of their curses on other players (though not sure how yet). Players should not only to interact with each other but also with the game, so the game needs a way to interact with the players. We'll set up a "Demon's deck" for this purpose. This gives us another drawing mechanic, so we'll need to determine when those cards are drawn.

It's at this stage that we'll also need to figure out a set number cards and components for the game (and possibly for different player counts), so that fewer players gets fewer items to bid on. We'll also need to figure out how many players can play. Typically I start with 2-4 players as a base number. Then - based on board size, card counts, how long it takes to perform a turn, a round, a game stage, etc. - I adjust the number up or down in order to reach a desired game length.

5. INITIAL RULES

A lot of the process done during the Gameplay phase above gives us a rough structure for the game, the various components, the general design, and so on. But before we get to building stuff, we need to make sure that all of our ideas are consistent with one-another. So, it's time for our very first rulebook! I emphasize very first because there can (and most likely WILL) be literally be dozens of versions before you even get to version 1.0 of the game.

The rules will typically have the following sections (this obviously changes game to game):

• Story: a lot of games will have a background story to set the scene and place you into the world; think of it like a prologue to the game.
• Description & Objective: a summary of the game, your goals, and the primary mechanics used to achieve them.
• Components: a list of all the items in the game (useful to make sure nothing is missing).
• Setup: how the game is configured along with any adjustments for player counts, which components are used, where they need to be placed, examples of the layout, etc.
• Gameplay: a breakdown of the game's stages, turns within each stage, and actions within each turn. This is the section that has the actual "rules" of the game. It needs to cover the descriptions of each action and set the bounds (what is and isn't allowed), as well as give an undrestanding for all the components and how they're used throughout the gameplay. You will rewrite this section hundreds of times (not kidding). As you test, you'll encounter a lot of edge cases to adjust for, or scenarios that don't work with the actions you've allowed. Don't feel bad if a rule doesn't work; it's all part of the process.
• End Game Conditions: some games can have multiple ways to end (in this game, it may be possible no one wins), so we describe each scenario.
• References: there can be multiple reference sections, depending on how many different component types you have and the complexity of those components. But a good reference allows players to quickly find a specific component and understand any additional details or usage restrictions/abilities without having to reread the entire book.

6. INITIAL DESIGN

Who knew that the "design" part of game design didn't come first, or that it would take us this long to get to something we can actually see? Well, we're not nearly finished, my friends. Buckle up. Anyway, now that we have our idea (which gives us a vibe and theme), our goals, our mechanics, and our gameplay, we can start putting "pen to paper" so to speak. Based on the work we've done so far, we now have an idea of the different design elements we're going to need. We don't need to come up with everything at this stage; the idea isn't to have a finished, production ready product. We're going for MVP - minimum viable product. Some people just do bare minimum, with words written on pieces of paper. Others borrow items from games they already own (if you need lot of extra cubes, Terraforming Mars is a goldmine). Rather than just the outline, I prefer to have a mix of something visual that "sets the stage" and carries some of the theme, and then lesser-designed components that are placeholders but allow the game mechanics to work. This way when a player gets to the game for the first time they have a bit more runway to get into the idea and don't have to "theater of the mind" the entire thing.

Example Design: We know we need a game board, and a rather large one at that. Let's go with an 18" x 18" quad-fold board to start. I'm thinking isometric or top-down view for the various rooms and spaces; maybe a Clue-like board. At this point I'll make a rough map of the entire "building," laying out rooms, windows, etc. More like a building plan than a fully realized board. I know the players will need to move on the board, so we can do a grid system for movement spaces.

For items, we'll need cards. How many? What type? What will they do? Well, here's where we find out. Since the cards will be distributed among the players, we can figure how many cards we'll want each player to have on average and work backwards. If players will activate one curse per turn, I would like for their to be a minimum number of different turns, so that not all turns feel the same. For games with fewer players turns come up more often, so I'll aim for 3-4 different curses (on average). Which means I'll need potentially 12-16 different curse cards for a 4 player game. If we want more variability, we can increase this to 18 cards and not use them all. This allows us more cards to play with to get different curse effects. This might not be needed, but we can also bring down this count.

We'll design a "ghostly funds" tracker for each player. This will allow them to track their total spendable ghost money. Since they'll have several cursed item cards for their game, maybe this will be part of a game mat, with an area for tracking spending money and places for their curse cards? Something to consider.

Lastly, we talked about things the players can do; actions they can take. Maybe there's a second deck of cards that allows them to draw actions (the "Demon's deck" mentioned before). Game design is iterative, so it's okay to go back to the goals or mechanics and work our way back here when ready.

7. VIABILITY TESTING

Well, here we are: we have our rules, we have our game pieces. We've cut and drawn and arrange, and we're finally ready to play! Do yourself a favor and don't go running out the door screaming "Who wants to play my game???" It's possible that your game will work straight out of the gate. But it's more likely it will... not. Not that you should doubt your ability to make a working game. It's just that these things don't always go smoothly. So I like to start with just testing the gameplay by myself. Going through the various motions we've laid out in the game. This is usually where I'll discover the biggest issue with a game and whether it'll even work, or if I have to go back and change major mechanics.

You should be able to make it through all of the various stages of gameplay. If you feel the game hits your goals (the things you want to elicit from your players: satisfyingly crunchy, thinky, tricky, quirky, competitive, etc.), then you're ready to move on.

8. INTERNAL (CLOSED) TESTING

And we're STILL not done. Now that you know your game is, well, a game, it's time to bring others into the process. You should have a few trusted acquaintainces, friends, or family that you can play with first. These are people that should understand that this is an early prototype, with a long way to go before the final version. They should be able to see past the simplicity of components and be able to focus on the ideas and gameplay itself. They should also be people who you trust to give you honest feedback, and from whom you can stand the most harsh criticism. Not that they will be your toughest critics, but the tougher and more thorough they are, the easier things will be down the road when complete strangers get involved.

9. DESIGN REFINEMENT

At this point, you'll have played at least a dozen times or more, and will have gone back and forth to steps 2-6 (goals, mechanics, gameplay, initial rules, initial design), and made multiple adjustments. Now you should take a bit to refine your design elements based on your internal testing. This should include more of your theming and bring the game closer to your "vision," providing people with a better feel and vibe. Again, you're not looking to be finished with the design (far from it). But each element should be conveying what the end design should be perceived to be.

10. EXTENDED TESTING

Feeling good about your game? Awesome! Now let's break it. This is the step where you bring in a trusted outsider: someone(s) who hasn't yet played the game, and preferably another game designer, critical thinker, or well-verse board gamer. You can sometimes skip this step and go straight to step 13 (without your initial prototype and just use your initial design), but you'll get a better result if you can find people to break the game and if you can get your game spiel down before going public.

11. RULES REFINEMENT

After that extended testing feedback, it's time to clean up the rules. This is because you're gonna start open playtesting soon, where you want people to be able to reference the rules, and not just what's in your head. So it's time to really get a readable, semi-formatted rulebook going. Remove all the extraneous bits and chop away until you get a clean ruleset that you can guide players with.

12. PROTOTYPE 1

Sometimes this is just your initial design, but more often than not you'll want to have a cleaner product to present to people you don't know. Sleeve the cards, get some representative tokens, make sure you find dice that match. If you're printing cards, the card backs should have a thematic design. Basically, build what you can so that when the general public start to play, they don't have to think, "What will this game eventually be?"

13. OPEN TESTING

Finally. After months of development, we're here! We can start to bring in the general public and get feedback. We're still in the guiding phase of playtesting: sitting and playing or assisting the play. Your goal is to see where the issues and enjoyment lie. What do people like, don't like, what works, doesn't work, and how can you refine everything to make the entire thing a tighter game. All this feedback goes back into design and rulebook refinement, which goes into more extended testing, which may or may not adjust your initial prototype (replace individual components, card, etc.). Assuming everything continues to go well, we move on.

14. PROTOTYPE 2

While you may at this point have multiple prototypes, this is the next "big" one, where the rulebook is formatted based on the game and theme, components start to really match the end design, and it starts to look like a game you might have on a shelf. Often times this is when you also create your box for the design (if you haven't done one by now). That's because you're about to move into the hardest phase: blind playtesting.

15. BLIND PLAYTESTING

Here it is: the big time! Blind playtesting is where you have people you don't know pick up and play your game, with minimal to no interaction. They should be able to learn the game from the rulebook, set it up, play, and review their experience. Depending on the audience you're working with, you may want to answer minor questions, but for the most part you'll want to minimize interaction. At larger conferences where time is limited, helping the players go through setup and initial learning of the game is okay, but otherwise you'll want to be as hands-off with this part as possible. Feedback forms are your lifeline, and taking in info about their experiences, what they liked, what they wished was better... all of that will feed back into your refinement process for months.

The other reason why this is hard isn't just because the players have to do this on their own; it's that you have to find enough people to play! Taking the game to local game stores and running playtests; attending proto-spiels and playtest events; finding people who want to play something they have never seen or even heard of. It's very time consuming. But also, it can be very satisfying. When you have successful blind playtests, suddenly your game feels alive. You can picture someone buying it in a store, taking it home, learning it, and playing. Then teaching it to others, and on and on.

To be honest, I never feel like I can find enough blind playtesters, even after months of blind playtesting. At some point, you'll have to trust you've done all your due diligence, and move on. Otherwise you'll never publish.

16. DESIGN & RULE FINALIZING

Here we are: you've done your testing, gotten your feedback, made your adjustments, done more testing, rinse and repeat. Now you're no longer getting anything that changes game mechanics, the component design and graphics haven't changed in months, and you can lock down the final design elements and prepare for production. At this point, you HAVE a game. It's made, it's ready to play. And now you come to an important fork in the road: self publish, or shop it to a publisher? Both have their benefits and drawbacks, but as far as the game itself goes, you're pretty much there.

There's a lot more steps for both self publishing and finding a publisher (crowdfunding, soliciting, production, marketing, retail & sales, distribution deals, and revisions), but the game... the game is done. Your initial little dream has grown into a full-blown, multi-year obsession that makes your friends want to throw meeples at you. But as long as they're nice components, you'll just save them for your next game. :)