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.

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 🙂