Brandon the Game Dev

Board game development is a very individual process. Every single developer has different methods for creating their games. This article is the first of a 19-part suite on board game design and development. I am going to teach you my own methods every week for the next four to five months.

My board game design philosophy stems from the Five Levels model, which I created and explain in depth in Five Levels of Communication through Game Development. The basic idea is that board games are a means of communication that facilitate gameplay. This communication happens on five levels: the core engine of the game, mechanics, rules, the internal narrative or “theme”, and the external narrative or “community and marketing.”

This guide comes in three parts:

1. What’s the core engine of a game?
2. How do I come up with an idea for the core engine for my game?
3. How do I turn the idea into a working game engine?

What’s the core engine of a game?

The core engine of a board game is what’s left when you strip a game of mechanics and obstacles. It is a mix of the objective of your game and the feelings you want it to evoke. The core engine is the bare minimum set of mechanics and concepts you need to have a functioning (but not necessarily fun) game.

Examples

Pandemic: The purpose is to wipe viruses off the face of the earth, save lives, and be a hero. The core engine involves this concept plus mechanics related to virus eradication. The movement, the classes, the geography, and so on are not part of the core engine – they are means to an end.

Carcassonne: The purpose is to build the best village. The placement of tiles is part of the core engine. The scoring and more finicky rules about tile placement are not part of the core engine – they are means to an end.

Twilight Struggle: You play as the US or USSR trying to win the war through strategic and tactical maneuvers. The core engine of this game relies on tension and area control. All the cards, the particulars of scoring, and the strategies are not part of the core engine.

Chess: Defeat the enemy by killing the king – that’s the core engine. The fact that you start with sixteen pieces and that pieces move in different ways back up the core engine as non-core mechanics.

My own game, Highways & Byways: travel, explore, and move fast across the United States. That idea coupled with a board full of connected roads are the core engine. Every rule on how fast you can move, where you can go, and what can slow you down or speed you up is not part of the core engine.

You’ll notice that most of the games I just listed have a mix of basic mechanics and “theme” in their core engine. That’s no accident. You can’t take viruses out of Pandemic – it wouldn’t be Pandemic any more, even if it were functionally the same with a swapped out theme. The core engine is like a game’s “soul.”

How do I come up with an idea for the core engine for my game?

How do you know what your game’s core engine is? Well, it’s different for every game and every creator. Plus, if you ask gamers what the core engine of your game is, they’ll give you different answers. That means the core engine is an incredibly subjective matter that requires some introspection on your part. Don’t get hung up on perfection – it’s not possible here!

Your core engine centers around an idea. Here are some questions to help you come up with that idea.

Deep down, what do I want this game to be about?

I wanted War Co. to be a sinister game about the destructiveness and futility of war. Out of that, the core engine became slowly dwindling your opponents’ resources down to nothing and scraping by in the end with far less than you had to begin with. In order to do that, I needed some cards that followed simple, repeatable rules that allowed for the elimination of cards.

On the other hand, I wanted Highways & Byways to capture the feelings I had on my Great American Road Trips (yes, all caps is necessary). I gave it a sense of motion, travel, and exploration, because that’s ultimately what my road trips were about. In order to do that, I just needed a network of roads.

If your game were a statement, what would that statement be? Creators, whether or not they mean to, often build around messages. What I want you to do is take that vague vision and spell it out explicitly. By describing the game you want on the most basic level, you can begin to build around that. Mechanics, rules, and so on – they’re all just a means to explore that idea.

What’s the one thing about this game I can’t give up?

Sometimes you want to build a game around a mechanic. Sometimes you want to build it around a theme. Either way, there is something behind your desire there. Why are you so set on a specific mechanic or theme? What draws you to it? Spell out the basic emotions behind your desires and you may very well develop a core engine out of that.

What do I like to play?

If you think about the games you like to play, you will probably find that you’re drawn to certain mechanics and themes. Much like the previous question, that’s a sign you should think more deeply about the emotions behind those mechanics and themes. Why do you like them? Do you want to emulate them?

How do I turn the idea into a working game engine?

There is no easy answer for this. You can try creating the first thing that comes to your head. You can also try looking at Board Game Geek’s list of mechanics and picking out the ones you think will support your ideas. This is not an exact science – this is all on you.

As an example, with Highways & Byways, I started Googling scenic roads in the United States. I pasted their shapes on a map. Then I drew lines between them for highways so the whole map was connected. Then I added spaces to regulate distance in the game. When I finished doing that, I had the core engine of my game. I was able to move pieces around the board. That’s it – everything else is just polish on top of the core engine.

When you take your basic idea and give it just enough to be able to do something, you’ve got a core engine. That can mean having a network of roads you can move a piece on without any breaks like in Highways & Byways. That can mean having a card game whose core concepts allow you to eliminate cards from your enemies like in War Co.

Final Thoughts

Game design is a notoriously imprecise science. Board games are entertainment, meaning they are based on emotion deep down, on-purpose or not. As a designer, you can benefit from consciously recognizing the emotions you want to evoke, articulating them into a basic idea, and building an engine around that idea.

Coming up next week, we’re going to be discussing how to play-test a core engine. Until then, please leave your questions and comments below 🙂

Few words carry the emotional weight that “autopsy” does. It’s a morbid term associated with an analysis of what we’re all afraid of deep down. In a business context, autopsies don’t help us diagnose death, but rather failure. It is a way of helping us learn from our mistakes and adjust our behavior accordingly. A business autopsy is when you use evidence to determine why and how a project failed.

Performing a board game autopsy is scary because it requires you to look long and hard at your failures. That fear is why I saved this Start to Finish article for the spookiest time of the year. My first board game autopsy was one I did of my first game, War Co., that I wrote in April of this year. This was a little over two months after I successfully fulfilled the campaign on-time and under budget.

You’ll note that while War Co. was successful in some respects, I wrote an autopsy nonetheless to identify weak areas. You can have a successful project and still perform a project autopsy. You can even perform autopsies on projects in anticipation of failure as a way of identifying weaknesses before they are a problem. Below are some excerpts from the autopsy.

Excerpts from War Co. Autopsy

War Co. is dead. It is survived by its creator and the hundred-or-so people who believed in it enough to put money into the Kickstarter campaign.

I started the writing with humor. It made me feel better about the fact that I was about to eviscerate a childhood dream.

Things I Did Wrong with the Campaign

• THE ELEPHANT IN THE ROOM: Still not enough honest board gamer interactions.
• ANOTHER ELEPHANT: International shipping costs were way too high.
• Graphics, video, and photography were all weak.
• Stretch goal structure was really poorly done and failed to sustain momentum.
• Product still looked dodgy before the redesign in the second week.

Other Excerpts

This is a partial list of some of the things that I believe I did wrong in the campaign. Other headers started with “Things I Did Wrong with…”:

• The Product
• Fulfillment
• Sales
• Social Media
• Financially
• With Customers & The Market
• Emotionally

Moving Forward: Talk to gamers more (or at least read). Charge less for shipping. Make a better looking page. Make a better product.

This is my prescription for improving in the future. Under each header, I listed things I did wrong, and under each list, I provided suggestions for moving forward like what you see above. Providing suggestions for moving forward prevents the autopsy from being a document about kicking yourself, rather turning it into a tool to identify issues and their solutions instead. In a way, you’re putting Do Not Enter signs along paths you’ve traveled that do not work so you don’t make the same mistakes twice.

At this point, I’d like to provide a guide on how to perform an autopsy on your board game project. Each autopsy write-up you do will be highly personal and distinctive, but these five steps will give you a rough guideline.

Step 1: Start with a blunt, uncompromising statement of the facts (or your imagined worse-case scenario).

The magic of doing a project autopsy is that it provides an unflinching negative viewpoint of your project. So many creators get either excited or defensive, where both emotional states are divorced from the raw facts. State how long you’ve been working on your game, how much you’ve gotten done, how many people are paying attention, and how much money you’ve made. Tell how much you or your team have enjoyed or hated the process. Talk about what you see happening from here. Be honest as you’re doing all of this.

Step 2: Create several sections, one for each of the areas you got wrong.

The sections you choose to use in your analysis are up to you. You can use as many or as few as you like. Sectioning off your autopsy provides you with the ability to easily give it structure and prompt you to acknowledge mistakes you may have forgotten about. To get you started, here are some section suggestions.

• Game Design
• Game Production, General
• Prototypes
• Manufacturing
• General Marketing
• Target Market
• Outreach
• Kickstarter: Campaign (if you do a Kickstarter)
• Kickstarter: Fulfillment (if you do a Kickstarter)
• Sales
• Emotions
• Money
• Legal

Step 3: List all the things you or your team did wrong under each section.

This is pretty self-explanatory, though it’s arguably the hardest part. For each of the sections on the autopsy, list as many things as you can think of that you did wrong. Don’t worry about repeating yourself or meeting some kind of minimum. Don’t ignore problems because you have too many written or create ones because you don’t have enough. The point of a project autopsy is the raw honesty of it.

Step 4: List suggestions for preventing similar mistakes in the future.

Under each section, provide a list of general principles to follow going forward that will prevent you from making the same mistakes. For example, when talking about failures of War Co. as an overall product, I wrote “better play-testing, better market testing, more rigor in product manufacturing and design, don’t do multi-SKU products.” By that I mean that different play-testing and market testing methods would have helped me find more people who would have liked it sooner. More rigor in product manufacturing in design is referring to some things I’m not a fan of with the packaging, mostly minor gripes. That bit about the “multi-SKU products” refers to the fact that War Co. is a six box product, which made it tricky to deal with as a first-time game publisher. My customers never saw evidence of those struggles, but that’s because there was some hardcore organization behind the scenes.

Step 5: Periodically look back of your autopsy and compare it to your current project.

Lastly, your project autopsy should be periodically looked at. You’ll get the most benefit out of doing it initially, but every once in a while, you’ll want to compare your current project to your old autopsy. It’s so easy to slip back into old habits and make the same mistakes twice. Many times, that’s what destroys a promising creator’s career – making the same mistakes too many times before eventually falling into stagnation.

I’ve talked about the benefits and challenges of working alone in the board game industry. That’s how I do things. Yet I’m a bit of an odd beast in the board game development world since most people prefer to work in teams.

To give you a sense of what it’s like to work on a team, I’ve reached out to the three members of Undine Studios – Ben Haskett, Sarah Reed, and Will Reed. They made Oaxaca: Crafts of a Culture – one of the prettiest and most promising board game Kickstarters I’ve seen this year.

I initially reached out to Sarah, who I know through Twitter. After a little Twitter-fu, I got all members of the team in my Discord to have a group chat about team dynamics in the board game industry.

What follows is a lightly edited transcript of our conversation over DMs in Discord. This interview is a long one, but I’ve left it mostly verbatim because I find it insightful. I’ve split it into five sections for your convenience:

1. How Ben, Sarah, and Will Got Started
2. How Working in a Team Feels
3. The Downsides of Teamwork
4. Communication in a Team
5. Advice for New Game Devs

---

How Ben, Sarah, and Will Got Started

Brandon: Sarah, Ben, thank you both for agreeing to help me out on this post!

Ben: Yeah, thanks for having us!

Sarah: Looking forward to it! I’ll also be writing responses for Will. So you’ll be getting three perspectives.

Brandon: Excellent! Good to have you on as well, Will!

Brandon: If you please, go ahead and tell me a little about yourself and your company. How long have you been making games? What games have you worked on?

Sarah: We started off our board game life as role-players and Magic the Gathering players in college. I had been playing RPGs since high school and introduced them to Will when we met. We played mainly those and a few board games until spring of 2012 when we decided it was time to take a break from RPGs. We checked out a new local game store where we discovered Dominion.

Sarah: It was summer of 2012 that Will had the idea to make a board game for my birthday, but didn’t know how to go about it. We started designing games together. Early in 2013, our local game store owner mentioned that there were other designers in the area. We had our first game design meetings, which I continued to organize and have been running since.

Sarah: It was also in 2013 that we met Ben and were playtesters for his game Tower, which he launched on Kickstarter early in 2014. Will was also lead story writer for Tower. We worked on a few designs during this time, but ended up shelving them. It wasn’t until Project Dreamscape that we had a solid game and Ben liked it so much he became our business partner and ran a Kickstarter for it in early 2015. After that, we designed Oaxaca: Crafts of a Culture, for which Ben continued to be our business partner and ran a Kickstarter for it in June of 2017. Along with handling all the business, Ben has playtested and helped develop our designs. Will is the lead designer. I’m a designer, and I do development and social media outreach. Our next game is Haven’s Vault, which will hopefully be on Kickstarter early in 2018.

Ben: I think I was about 26 the first time I played a board game that wasn’t Monopoly, Sorry, or some other super ubiquitous game. It was Catan at a friend’s house, followed up by Carcassonne, and the two games really surprised me and got me interested in the hobby. I was, and still am today, mystified that you can take a box crammed full of little cardboard bits, sit down, look at a sheet of rules, spread out the pieces, interact with them, and not only have it make sense, but have it be fun, too. I was hooked.

Ben: It wasn’t long before I designed a small dungeon crawler of my own and pitched it to a small (now defunct) publisher. As Sarah and Will said, next up for me was Tower, which I self-published. Afterwards, I sort of naturally transitioned into the publishing side for three reasons. The first was that I really couldn’t get another design together that I liked. The second was that I really enjoyed the Kickstarter/publishing process. The third was that Sarah and Will were designing games that were compelling and fun to play. These days, as my young daughters get older and I have less time, I’m transitioning more and more of the fun to Sarah and Will–they’re going to help with a lot of the fulfillment for Oaxaca, and may even play the primary role in the next Kickstarter campaign.

Brandon: MTG, Dominion, Catan, Carcassonne…these are all really good intros into modern board games and I can totally see how they ignited your passion and curiosity.

Brandon: I’m particularly glad to see Oaxaca take off because you all ran a really good campaign.

Brandon: So is Undine Studios just the three of you?

Ben: Correct–in fact, Undine has been around for over ten years to represent whatever I’m doing. It used to be the name I used for Flash web design, if you can believe that. When I got into publishing, it was a natural transition for the name. Last year, I even self-published a book with the Undine name on it. With the setup that Sarah described, Undine is indeed just the three of us.

Brandon: Ah, so the organization has grown organically as you have!

How Working in a Team Feels

Brandon: Here’s a question for all of you.

Brandon: One of the odd things about my blog is that it’s written from the perspective of someone working alone. This is unusual for most game devs, I think. How would you characterize the experience of working as part of a team, compared to working alone?

Will: I know for me personally, projects are a big concept. A lot of skills are necessary to complete a project. I’m only interested in a portion of those. I know being interested in only one small portion and being good in that small portion is a strength, but it does mean the rest of the project will feel weaker if I’m not good at all aspects. Working with Sarah and Ben really eases my mind because they have strengths in areas I don’t.

Will: I trust and respect their opinions so much that it has allowed me to more easily take their feedback in and make any game I work on better for it. To give a good example, I suck at writing rules and they don’t really interest me. However, Sarah’s attention to details and Ben’s graphic design and formatting not only creates a really slick looking ruleset, but a highly functional one as well.

Sarah: Stuff actually gets done as a team. If it were up to me alone, it’d never get done. I am a terrible procrastinator and I have a high fear of failure, so much so that I sabotage myself. By working in a team, I feel a responsibility to Will and Ben to get my portion done and not drag things down. I like organizing and, as Will said, I pay attention to the details. So I can keep us moving forward in a way that I can’t do if it’s just me. So I prefer working on teams and really enjoy the collaborative process of everyone coming together with their strengths and overcoming individual weaknesses.

Ben: What I love about working as a team is that the result is everyone’s best ideas. Not only do we bring our best ideas to the table, but we also brainstorm and challenge each other to make things as nice as possible. When I start working on graphic design, I always swear to myself that my first attempt is the best I can do–but Sarah and Will always have suggestions, and the final design is usually after a dozen revisions. Similarly, even though Will is the primary designer, he’s always open revisions and the the final game design is always better for it. Every aspect of each game we get together on has input from all three of us, and the game is always better for it.

Brandon: Will, it makes a lot of sense to me that one of the big benefits of working in a team is that everybody can specialize in something they like or at least tolerate. You help balance out each others’ weaknesses.

Brandon: Sarah, it sounds like you see working in a team as a good way to stay motivated. Either through being accountable to or inspired by others, you find ways to stay productive.

Brandon: Ben, you make a keen point about everybody’s best ideas being able to surface when working in a team. More people, more ideas, more chances to get it right.

The Downsides of Teamwork

Brandon: What sort of challenges do you face working in a team? How do you overcome those?

Will: The biggest challenge for me is when I feel a little too strongly about a particular aspect of a game design because I’m dead set that that’s where the most interesting and fun part of the game is. It can be a bit hard when either Sarah or Ben tell me that it needs to be streamlined or taken out completely. Through working together, I’ve learned it’s really bad for me to throw my weight around and reject them outright, even in my area of expertise. But after mulling their suggestions over, I can see they’re right. Oaxaca was a very different game at the beginning and it changed drastically when Ben and Sarah pointed out certain aspects of it.

Will: I now tell myself that designing as a team means all of our opinions need to be reflected rather than just having a game that I’m personally happy with. It’s no surprise that the outcome often is much better than anything I could envision myself. Other than that, I’m pretty flexible on most other aspects of game design. I can’t really see so well, so art and graphic layout don’t bother me. I’m perfectly fine retheming anything I work on. I’ve learned to make their opinions as valuable as my own.

Sarah: I think one of the biggest challenges I’ve seen in our team is that everyone works at a different speed due to a variety of reasons. Will is the fastest at getting things done, partially because he hates procrastinating and he has more time. Ben and I switch off as to who’s the slowest depending on the phase we’re in. For me, I have a lot of health challenges and so I’m often too drained to work on game design when I get home.

Sarah: I’m the one who makes the early prototypes and I’m in charge of the playtesting. Ben has a full family life that leaves him little time except at night to get anything done. He takes care of the end product in terms of graphic design, working with manufacturers and shippers and running the Kickstarters. Will’s often told me how frustrated he’s been when I’m slow to get things done and, admittedly, I get frustrated when Ben is slow and doesn’t get things done. Heck, I get frustrated with myself for not getting things done!

Sarah: Will has already learned to let go. When he gets his part done, he just sits back and is patient with us. I can’t say I’ve overcome this challenge yet, but I’m working on it. I need to remind myself that we have no true deadlines. We’re doing this as a hobby, for fun. I shouldn’t be stressing about how quickly we do or don’t do something. It’ll happen when it happens.

Ben: A big challenge for me usually occurs early on in the design – I’m reminded when I talk to Sarah and Will sometimes that I have really thin skin, haha. I mentioned that we go through a lot a revisions, but I still expect each design revision I bring to them to not only be the final revision, but that it will literally blow their socks off. When it doesn’t work out that way, I have an embarrassing tendency to pout about it for a little while before getting my head back in the game. Thankfully, Sarah and Will are always constructive. 🙂

Ben: Then, as Sarah said, time is a big issue, especially lately. I got a new job late last year and it’s severely cut down on my free time. Further, and again echoing what Sarah said, my two daughters are getting older–it’s no longer a rush to get them home, fed baby food, and in bed. My oldest is starting school soon, meaning there will be homework, etc., and we’ll have to consider the time it takes to get her to and from school. Finding time not only to work on games, but work on games cheerily, can be a challenge.

Brandon: As for the challenges, it sounds like for all of you, it mostly centers around passions running high and scheduling. The former being something you deal with as you get to know each other in a working relationship. A lot of it comes down, as you pointed out, to knowing when to hold you ground and knowing when to let go.

Communication in a Team

Brandon: How do you coordinate your efforts?

Will: For the most part, we use Facebook Messenger to communicate. As for the game’s development, Sarah does most of the early playtesting coordination and then it switches to Ben for final production and running of the Kickstarter.

Sarah: In addition to Facebook Messenger, we call each sometimes so we actually can all meet at the same time. Some of our coordination is made easier since Will and I, well, live together. Two-thirds of the operation is in constant coordination. The good news is the way the process flows, this works pretty well. I personally use lists a lot to keep myself organized so I don’t forget anything. This often includes notes on who needs to be contacted about what. That’s about as complicated as our scheduling efforts get. Living together certainly helps!

Ben: I’ve pushed for Facebook Messenger a lot, because it’s just so dang convenient. There’s no programs to install on a computer to use it, and it came pre-installed on my phone. It’s like text-messaging, but for lengthy messages, you can sit down to a keyboard. On top of that, it’s super easy to send pictures, you can make calls, and even send videos.

Brandon: Sounds like you don’t plan too extensively, but rather work in the moment based on what needs to be done. Short phone calls and text-based messaging to keep in touch and check in with each other, then.

Advice for New Game Devs

Brandon: One last question. Is there anything you’d like to go back and time and tell yourselves before starting your projects?

Will: Yes. When designing the game itself, it’s more important to marry yourself to the experience than it is the mechanics of the game. Don’t be afraid to drop entire portions of the game if they don’t lead to the experience you want for players. So many times, I was dead set on having a mechanism in a game because I liked the idea of the mechanism, but it always made the experience suffer by making it too complex, too rigid, or just not fun at all.

Sarah: When making early prototypes, focus on function over form and don’t waste a lot of money printing it on high quality materials or through a professional service unless you need to see samples of products to know whether it’s what you want to design with. This also applies to not spending a lot of time on the art or graphic design. An early stage game needs to look the way it plays – unpolished. The time to do quality printing, like with The Game Crafter, is for late stage prototypes that need to look as good as the game finally is.

Ben: I mostly echo Sarah’s sentiment on focusing on function alone early on. Some prototypes I prepared (at The Game Crafter) were actually so nice that it worked against us. People sat down and felt like they were playing a finished game, and when “bugs in the programming” revealed themselves, play-testers had really adverse reactions. On the other side, when people sit down and play a game with cards that were printed out at someone’s home and painstakingly cut out, they know 100% that they’re playing a prototype.

Brandon: Will, I agree with that so much. Focusing on the experience over specific mechanics is really, really important.

Brandon: Sarah, Ben, I agree with this as well. In fact, the cost of early prototyping is why I push Tabletop Simulator so much.

Brandon: Thank you all for sharing your experiences! I look forward to sharing this online!

---

Do you work in a team? Would you like to? Please leave a comment below to share your experiences or ask questions 🙂