Developing a Tabletop Game

0. Introduction

Hello everyone! My name is Cliff Kamarga and I'm a video game designer. Many years ago, I came back to the tabletop scene after a long hiatus and decided to create my first tabletop game. In 2013, I created my first card game, Sellswords, which was picked up by Level99Games and released in 2014.

Several people have then asked me questions regarding my development process and how I got it published. So I thought it would be a good idea to write about it and share both my knowledge and experience with everyone. I hope that some people will find this useful.

Below are the topics I'll be covering. Feel free to simply skip to the one most relevant to you.

     1. Conceiving an Idea

     2. Designing the Game

     3. Prototyping

     4. Playtesting

     5. Creating the Rulebook

     6. Approaching Publishers

     7. Conclusion

Before you continue reading, please note that I won’t be going into great detail for each topic as that would make this post far too long. So I will be keeping things relatively short.

1. Conceiving an Idea

So, what kind of game should you make? Well, there are a few ways for you to approach this part of the development process and it starts by asking yourself "what is the purpose of my game?"

     a. Do you want to give players an experience?

     b. Are you filling a hole in the market?

     c. Are you modifying an existing game?

     d. Are you showcasing a new or interesting mechanic?

a. Do you want to give players an experience? This approach is about using theme as the core idea for your game. Will your game be about an epic fantasy adventure? Or how about exploring and colonizing the galaxy?

Whatever theme you decide to use as the core idea for your game, just be aware of one thing. If you decide to use a theme that is currently or becoming popular, your game may run the risk of being drowned out by other games using the same theme. In this case, you would need to ensure that your game will stand out from the rest by introducing a twist to it or implementing an interesting mechanic.

However, this approach does make it easier for you to design your game, which I'll explain further in the next topic.

b. Are you filling a hole in the market? Before I begin, note that it doesn't necessarily have to be a complete void in the market, it could simply be a niche. Keep in mind, however, that this approach may require you to do a fair amount of research, especially if you don't closely follow the tabletop scene.

One advantage of choosing this approach though, is that your game has a higher chance of standing out from the crowd, especially if you use an interesting theme.

c. Are you modifying an existing game? Now, this can branch off into two paths – fixing a game or improving a game. What I'm referring to are those times when players say things like:

When you hear things like this, take note of why people are saying this. What part of the game's rules or mechanics is triggering these reactions. Pinpoint the source and then find a solution for it. With that being said, however, be careful not to overlook the game's reasons for certain rules and mechanics. They could be in place because of the game's theme, to evoke an emotion from the players, or to give the players a specific experience. For example, it's arguable that the very long game length for Twilight Imperium helps to evoke the feeling of a grand space opera.

d. Are you showcasing a new or interesting mechanic or feature? This is an approach that I often like to go for when conceiving a new idea for a game, since it usually piques a person's interest enough that they want to try it.

Some examples are:

This approach is similar to inventing something in the real world. Either invent something no one has ever thought of, or combine two or more things to create something new.

However, a word of warning. If you end up thinking of an idea that you've never seen before, it may be that someone already has but the idea didn't work. So make sure that that is not the case for your idea.

2. Designing the Game

Once you have decided on a game idea, it's time to design it. Please note that I'm only going to talk about the parts that are most relevant to this particular article since game design is a very large topic.

When developing a game, it is often best to set some design pillars. These act like strong guidelines for your design and they form the foundation for your game. They also help with decision making throughout the design process and ensures that you remain focused.

For example, you may come across a problem that needs solving or a mechanic that you're wondering on whether you should implement or not. Well, this is where the design pillars come in handy. If the solution or mechanic does not conform to your pillars, then you may want to consider something else.

Generally, the bigger the scope of the game, the more pillars it may have. However, I recommend reducing the number of them as much as possible.

For example, the core pillars I set out for Sellswords were:

Remember, restrictions breed creativity.

If you are developing a game for players to experience a theme, then use the theme to help with setting the game’s design pillars as well as the game’s rules and mechanics.

For example, let’s say you are designing a horror game where players take on the role of scientists or soldiers exploring a derelict ship. In the ship are monsters that are sensitive to noise and you want to create some tension for the players while they explore the ship. Then perhaps your game can have movement on a square grid. When moving, a player may move any number of spaces. But at the end of a player’s turn, they have to reveal a number of cards, one by one, from the top of a deck equal to the number of spaces that they moved. If a card shows a monster, then they get attacked and combat triggers.

The tension in the above example comes from the mechanic of revealing cards one by one from the top of a deck and fits perfectly with the theme of the game.

When designing your game, there are also some general things that you should keep in mind. Note that these are not rules or compulsory in any way:

     a. What are the players doing when it's not their turn?

     b. How much book-keeping do players need to do?

     c. Does a particular action or effect cause too much ripples?

     d. Does the game have too much randomness?

     e. When a player loses, do they blame the game or themselves?

a. What are the players doing when it's not their turn? This may seem very minor but sometimes, I feel that designers should try to make their game engaging for a player even when it's not their turn. Of course, some games can naturally accomplish this such as co-operative and competitive one-on-one games.

The main reason why I want designers to keep this in mind, is because sometimes you end up creating a game where it feels like a single-player game but just with more people. I've played a handful of games like these, including one I made several years ago. The result is that inactive players became bored waiting for their turn and for the active player, other players simply acted like the game's artificial intelligence or random factor (such as the Epidemic cards in Pandemic).

b. How much book-keeping do players need to do? Generally, the more complex a game is and the more players are involved, the more book-keeping it may require. This isn't necessarily a bad thing (as some games just can't avoid it), it's just ideal if there were less book-keeping that the players need to do.

If you can't simplify or remove things any further, what you can do is make things easier for the player by collaborating with your graphic designer. Prioritize the different types of information in the game, from most commonly used to rarely used, and design the game's graphics accordingly.

For example, as a game goes on in Sellswords, there are a lot of tiles to keep track of on the board. In the early days of playtesting, players sometimes forgot about continuous effects such as that from the Blacksmith (which was changed to a Necromancer). So in order to help players remember, I changed the Blacksmith's tile border to bright gold. This meant that when a payer is scanning the board for a good spot to place their tile, the eye-catching gold border would remind them about the tile's continuous effect.

c. Does a particular action or effect cause too much ripples? Remember that with physical games, players have to do everything. This includes doing the repercussions for their actions. You want to minimize the ripple created from a single action, especially when there are fewer players.

Of course, as players become more familiar with the game, this is usually not a problem. Though it can happen from time to time. The risk that comes from having too many ripples is players forgetting to do something which may affect the outcome of the turn, phase, or even the entire game. This can result in the players missing the full experience of the game or not experiencing the game as intended by the designers. This can also result in a player falsely winning or losing (which can annoy other players even if it was unintentional).

d. Are the random elements, if any, implemented correctly? Adding randomness into a game can be very tricky. On one hand, it can increase the game's replayability, make the game more exciting, and/or it can keep the experience fresh for the players. On the other hand, it can create unfair swings and/or make losing more frustrating.

Take the digital card game Hearthstone for example. This game has a good amount of random effects like spawning random minions, casting random spell cards, or damaging random targets. This makes for an entertaining game to play and watch as you don't know what can happen. However, losing in Hearthstone can become much more frustrating, especially if it was due to a random effect that was triggered by the losing player.

If you do add randomness to your game, consider adding in more controlled randomness and/or finding ways to mitigate it.

Using Hearthstone again as an example, there is a minion card called Stampeding Kodo which has an ability that when it comes into play, it will destroy a random enemy minion with two or fewer attack. Although this is a random effect, it’s more controlled as there are ways to decrease this randomness by reducing the number of valid targets on the board.

In some tabletop games, random effects like dice can be mitigated by certain mechanics in the game that allows players to re-roll or manipulate the results.

e. Whenever a player loses, do they blame the game or themselves? Whether it's a tabletop game or a video game, ideally a player should blame themselves whenever they lose... not the game.

This is based on how much control a player has in the game.

If the player has a lot of control and loses, then it is likely that they will blame themselves. In this scenario, the player will more likely be tempted to try again because they will think that they can do better by trying something different (like a new strategy) and so they are likely to play again. When was the last time you saw a chess player lose and then blame the game for it?

But if the player has very few control and loses, it is likely that they will blame the game. If this happens, they will be more hesitant to play again because they will think that no matter what they do, they will probably lose due to something out of their control.

3. Prototyping

Once you've designed your game and are happy with it in theory, it's time to create a prototype of it. Before I continue, this topic is not exactly about what materials you should use or how to make your components. This is more about what to do and what not to do when creating your prototype.

First of all, decide whether you are creating a prototype for yourself or for others. The reason I say this is because the first handful of playtests will be to simply see if your game, as a concept, works (I'll talk more about this in the next topic). Because of this, a game may be small and simple enough that the first couple of playtests can be done by yourself.

As an example, the very first prototype for Sellswords that I made was just for myself. Thus, the prototype was very basic. It was comprised of small, square papers and on them, I had written down the four numbers and a codeword to represent the different powers (since I designed the powers and remembered them all, a simple codeword was enough). It was ugly, but it served its purpose perfectly. Of course, when I moved to doing playtests with others, I made my prototype more presentable.

When you are creating your prototype for others, then your graphics (such as text, symbols, and icons) should be clean, clear, and easily distinguishable from each other. The same can be said with components. Here are some general guidelines:

4. Playtesting

Once you've created your prototype, you can now begin playtesting! There are three stages of playtesting, at least in my opinion:

     a. Proof of concept

     b. Balancing

     c. Blind testing

a. Proof of concept. As I mentioned in the previous topic, your first handful of testing will be to see if your game, as a concept, works. This is otherwise known as a proof of concept. The purpose of this stage is to check things such as the following:

b. Balancing. This is where you start balancing the game by tweaking certain mechanics or numbers. However, I'm not saying that balancing only takes place during this stage. Balancing is an ongoing process that almost never stops. I'm simply saying that the majority of balancing usually happens during this stage between the proof of concept and the blind testing.

c. Blind testing. You move onto this stage once you've written your rulebook, which I'll talk about in the next topic. Blind testing is when you give your game to your playtesters, along with your rulebook, and then sit back and not interfere whatsoever. Don't correct them, don't advice them, and don't help them at all. The purpose of a blind test is to check that your rules are clear and understandable. Remember, when your game gets published, you won't be there with the players to help them. Therefore, your rulebook must clearly explain your game and answer any question they may have as well as clear up any confusions.

5. Creating the Rulebook

The rulebook is the most important part of your game because without it, players will not be able to play your game the way you intended. The rulebook needs to explain everything there is to know about your game in a clear, concise, and logical manner.

Since each rulebook will be vastly different from game to game, below are some general advice and guidelines:

6. Approaching Publishers

Before you start sending emails and meeting with publishers in person, I highly recommend doing some research first. What you want to research is which publishers would be perfect for your game. Remember that some publishers specialize or avoid certain games. Doing research not only increases your chance of a publisher picking up your game, but it will also prevent you from wasting your time as well as the publisher's.

Once you've made a list of all the publishers that you think would be perfect for your game, it's time to approach them. There are two primary methods of approaching publishers with your game:

     a. Meeting in person.

     b. Sending an email.

Before continuing, I thought I'd mention something just to clarify things. Do NOT send an unfinished game to a publisher. They are not there to finish or fix your design. They are there to publish. So ensure you approach publishers with a finished product.

a. Meeting in person. This method is probably the most recommended way of approaching publishers as they not only get to see your game, but you'll be able to teach them your game personally as well as answer any questions on the spot about the game.

However, if you are doing this method, I recommend contacting the publisher first and setting up a meeting somewhere, such as at a game convention that they will be attending. Doing so will guarantee that you will be able to show your game to them.

When contacting a publisher to possibly set up a meeting, I highly recommend sending them your game's Elevator Pitch.

An elevator pitch is a short but descriptive summary of your game. It generally describes the theme, main mechanics, goal, and/or how players achieve that goal. For example, an elevator pitch for Magic: The Gathering could be something like this:

"It's a competitive two player card game where players, known as planeswalkers, battle each other by summoning powerful creatures and casting devastating spells."

This technique is known both in the tabletop and video game industry. It stems from a scenario where you and a potential publisher both have stepped into an elevator and you only have until the elevator reaches its destination to sell your game idea. Some people have even said that if you can't describe your game in one or two sentences, it's far too complicated.

When you finally meet with a potential publisher, feel free to elaborate more about your game and/or play it with them (whatever you scheduled with them). Here are some guidelines:

b. Sending an email. Sometimes, you may not be able to meet with a publisher in person, for whatever reason. In this case, your best chance is to sell your game via an email. With emails, you'll have plenty of time to revise your pitch before sending it, so make sure you take advantage of this.

Below are some guidelines when writing your email:

Along with all these, there is also the option to attach a Sales Sheet. A sales sheet is generally a single piece of paper (physical or digital) that is used to show a full summary of your game. Think of it as an advert for your game that you would hand out to people or what the back of your game’s box could show.

7. Conclusion

There you have it! I hope that this post was helpful to you all and has given you at least some ideas of the process of developing a tabletop game. I hope that this has helped you or even inspired you to create your own games.

Good luck and all the best!