How to Play-Test the Core Engine of Your Board Game

Posted on 1 CommentPosted in Start to Finish

Board game development is a very individual process. Every single developer has different methods for creating their games. This article is the second 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 is 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.”

Last week, I talked about How to Design the Core Engine of Your Board Game. This week, I’ll tell you how to test your ideas to make sure they hold up well enough to make a game out of them. If you need a refresher on good play-testing practices, please see The Art of the Play Test: Designing Tests and Keeping Records. When in doubt, keep a spreadsheet with information on how the game went. You can always refer to that data later if you don’t catch something important when you first play.

In order to teach you how to play-test the core engine of your game, I’ve split this article into three sections:

  1. Making a Core Engine You Can Test
  2. Setting a Definition of Success
  3. Testing the Core Engine of Your Game

 

Making a Core Engine You Can Test

 

 

First things first, in order to test the core engine of your game, you need something playable. It doesn’t have to be fun, challenging, or meaningful. Your game, during this very early stage of development, just needs to be an activity which can be completed by following instructions.

If you haven’t made a functioning game yet, you’ll need to make one. The way you go about this differs based on the idea that you are trying to capture.

For War Co., this involved creating about 300 really rough cards that followed extremely simple trade-off calculations. The trade-offs were the engine I needed to test, but in order to test them, I had to make cards. The trade-off calculations behind it were designed to slowly dwindle all players’ resources to make them feel like they’re in a post-apocalyptic situation.

For Highways & Byways, the idea was to make players feel like they were travelling across the United States, exploring all of its hidden roadside treasures. The way I created the core engine was by making a map of interconnecting roads. I needed this in order to be able to move a piece across the map. This was how I built the game to have the constant sense of motion.

 

Setting a Definition of Success

 

After you have a testable version of your game’s core engine, you need to define what success looks like. For War Co., I just needed a game that steadily removed cards from players. If after a few simple tests it consistently performed this function, that would be successful. Likewise, with Highways & Byways, as long as I was able to move around the board non-stop, that meant the core engine was working.

Again, I’d like to reiterate that you’re not looking for fun. You’re looking purely for function and coherence. At this stage of development, War Co. was terribly unbalanced and Highways & Byways had no objective – it was just movement.

 

Highways & Byways Test Board
Not pretty. Just functional.

 

Testing the Core Engine of Your Game

 

At the risk of sounding sacrilegious to experienced game designers, I recommend that you test the core engine of your game alone (or with only teammates). Obviously, it’s not acceptable to test your game alone and push it to Walmart shelves without another person laying hands on it. Yet at this stage of game development, you’re not testing for subjective experiences like player enjoyment. You’re not even testing for unexpected strategies. You’re testing purely for functionality. That is something you can test alone.

However, I’m not just saying you can test alone. I’m saying you should. Play-testers can be hard to find and their time is valuable. You don’t want play-testers to get a look at your game too early on. That can make it hard for them to give meaningful feedback later on. It’s a weird psychological issue caused by people knowing where your game came from, how far it’s advanced since it started, and how much they’ve invested in it emotionally.

The other benefit of testing this way is that you can stop the test if anything breaks. You can fix it on the spot and either restart or resume testing as appropriate. I play-tested Highways & Byways alone until I knew I could move freely about the board without getting stuck anywhere. When I did get stuck, I’d draw a new line and drive across it.

How long does it take to get through the core engine testing? There is no clear answer to this question. It could take a few speedy run-throughs or fifty games. It really comes down to the complexity of your game and how you choose to express it. You just have to keep testing until your game is functional on a basic level and it succeeds at expressing the ideas you want to express.

 


 

To summarize, testing the core engine of your game requires three parts. First, make sure you have something really simple and basic since you’re just testing for functionality. Set a clear definition of success so you know if your play-testing is successful. Test alone or within your team. If at any time during the testing, you are unable to complete a test, stop the test and tweak the game.

In next week’s article, we’ll talk about how you make mechanics for your game. This will help you add some meat to the bones of your game’s core engine. In the mean time, please leave your questions and comments below 🙂

How to Design the Core Engine of Your Board Game

Posted on Leave a commentPosted in Start to Finish

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?

 

Well, if you want to be literal about it…

 

The core engine of a board game is what’s left when you strip a game of mechanics and obstacles. The core engine 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.

 

To illustrate my point, here are the core engines of some games you might know:

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 & Bywaystravel, 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.

 

Before I ever spoke a word about it online, this is what Highways & Byways looked like. I was still doing research to make a good 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.

 


 

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 🙂

Performing a Board Game Autopsy: Learning from Your Mistakes

Posted on 2 CommentsPosted in Start to Finish

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.

 

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.

This is a partial list of some of the things that I believe I did wrong in the campaign. Other headers include:

  • Things I Did Wrong with the Product
  • Things I Did Wrong with Fulfillment
  • Things I Did Wrong with Sales
  • Things I Did Wrong with Social Media
  • Things I Did Wrong Financially
  • Things I Did Wrong with Customers & The Market
  • Things I Did Wrong 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
  • Game Production: Prototyping
  • Game Proudction: Manufacturing
  • Marketing: General
  • Marketing: Targeting
  • Marketing: 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.