Creating the First Version of Game Rules

Posted on 1 CommentPosted in Dev Diary

I’m trying something different on the Dev Diary. Updates 1, 2, and 3 told you about Highways & Byways as a project. Important context information, yes, but that’s not what I set out to do with this series.

This is a teaching blog. I’m going to be using Highways & Byways as an example. I’ll be explaining my development processes for this game so that you can learn from them.

My hope with the Dev Diary series is that by being really direct and transparent about my own development experiences, you’ll see how I respond to real problems. I’ll be highlighting specific takeaways and also putting them at the bottom of the page. We’re in this together, game devs.

Looking for more resources to help you on your board game design journey?
Here you go: no email required!

Like this writing style?
Check out my latest blog on marketing here.


Development of Highways & Byways is continuing at a pleasantly brisk pace. I’ve created a usable board and I’m already on the second version of the game. I have a “core engine” in place that makes Highways & Byways playable, even though it’s deeply flawed – as all games are when you first start them.

The latest version of Highways & Byways in Tabletop Simulator. As you can see, it’s very, very rough.

When it comes to game development, you don’t want to get attached to your ideas early on. Your priority is simple: make a playable game as early as you can. Don’t focus on making your game good or pretty at first. Just get it playable. Perfect the core engine – the bare minimum mix of mechanics it takes for your game to qualify as a game.

What does the core engine look like with Highways & Byways? Well, since it’s a map-based game, the core engine consists of two parts. One, having a board where all the roads connect to at least one other road. Two, players must have cards that tell them where to go. All the others are rules or constraints, including the specifics of how those “destination cards” are drawn.

I tested this core engine in Tabletop Simulator until I could move my piece around the board without a hassle. I used a rudimentary card drafting mechanic to decide the destinations. My brother and I ended up liking the drafting mechanic. Version 1 (codename: State Route 1) is complete.

I don’t want to give too much away about the card drafting mechanic early on…

I go through game versions rapidly and I have a goal for each one. My goal for State Route 1 was simple – get the core engine to work. My goal for State Route 2 is to test a handful of mechanics. Specifically, I’m playing around with early game card drafting, early game “mulligans” which let you toss out roads you don’t want to travel, and a traffic/road closure mechanic.

I set up State Route 2 in Tabletop Simulator and played a little bit. I’m still gathering data, so I don’t have much to say about the results yet. However, I cannot emphasize enough how important it is to track data, preferably in Excel, on how each test goes. Get a few tests in before you iterate to the next version.

Playtesting Log
A sample of my playtesting log, taken from last week’s update.

Every week, I set priorities. This is very important. Set priorities for your game as a project and outline what you want to accomplish in the next week. Keep track of what you have and haven’t done. My upcoming priorities are very simple:

  1. Take a three-day break. I have not taken a day off since January 2. No matter how much you love your project, don’t burn yourself out on it.
  2. Play test State Route 2. Gather data.

Key Takeaways for Game Devs





What causes analysis paralysis? What should designers do about it?

Posted on 2 CommentsPosted in Philosophy

You’re playing a game of Pandemic with three of your friends. One of your friends is taking forever to make a decision. He opines to the open air: “should I go to Jakarta and handle this three-cube situation before there’s an outbreak or should I set up a research station that we really need in Bogota?” You look over at your friend. She’s on her phone. Your other friend is staring off in the distance. Exasperated, you put your hands over your face, lean back, and say, “just make a decision.”

Looking for more resources to help you on your board game design journey?
Here you go: no email required!

Like this writing style?
Check out my latest blog on marketing here.

Your friend has analysis paralysis.

Next to king-making, analysis paralysis is one of the most annoying board gamer behaviors. It happens whenever a player is so overwhelmed with choices and the urge to optimize that they don’t make a timely decision.

It’s really hard for designers to discourage analysis paralysis. It isn’t just a board game behavior. It afflicts people in business, politics, sports, and – dare I say it – love. That brings us to one big question…

What causes analysis paralysis?

Gamers are analytical by nature. We like thinking through all the possible outcomes of certain behaviors. We like making the optimal choice. We want to win. That’s why it’s so tempting to sit and try to think about all the possible things we could do in a game. Games don’t have any major effect on the world, though. Why measure our moves with such scrutiny when there’s no lasting effects?

I’ve given a lot of thought to this. Games have very powerful effects on our psychology. That’s part of why I have repeatedly said that games are microcosms of life. As gamers, we seek competency, achievement, and problem-solving. We don’t just want to win – a part of us needs to win.

Maslow’s Hierarchy of Needs – an old psychological diagram that roughly approximates human desires. Photo from J. Finkelstein, who posted it to Wikipedia under the CC BY SA 3.0 License (Source).

A lot of times, we’ll keep trying to find that perfect answer until we are overcome with decision fatigue and simply choose something a random because our willpower is spent. Obviously, as game devs, we don’t want people saying “screw it” and making haphazard choices as they disengage with the game. Yet when the problem of analysis paralysis is happening in the player’s head, what can we do about it? Quite a bit, actually.

What should designers do about analysis paralysis?

All games are built upon the basis of objectives and constraints. You need to make sure both are very clear. Your player needs to know what objective they’re trying to accomplish and what’s holding them back. I think the biggest cause of analysis paralysis ultimately comes down to failure to prioritize based on what is a successful game strategy.

Pare down on all the decisions that don’t make the game special. Every decision a player makes needs to affect the game somehow, except for maybe the color of their token.

Break complex processes down into simple steps. Break turns into phases. Make sure complex details are easily trackable so less time is spent thinking about it.

Make losing acceptable. Losing should not be cool or desired, but it should not take the fun out of the game. The gameplay itself needs to be rewarding, not just the taste of victory.





Dev Diary: 03/31/17

Posted on Leave a commentPosted in Dev Diary

Last week, I filled up a map of the United States with byways and breakpoints. They are the red and blue lines and dots you see below. This week, I’ve connected the dots with highways which are white and outlined in black. The highways exist so that players can move around the board between byways. Though they do not follow true paths of the United States’ multiple highway systems in shape, they do approximately reflect the distances that must be traveled between different points. In short: I have completed the first draft of the board.

Highways & Byways Test Board

Looking for more resources to help you on your board game design journey?
Here you go: no email required!

Like this writing style?
Check out my latest blog on marketing here.

Naturally, this game is nowhere remotely close to completion. This map is based on what really exists in the United States, but it doesn’t reflect what plays well on a board. Also, the game doesn’t have a defined win condition yet. Some game designers – and I count myself among them – consider to be win conditions pretty important to games.

I’ve pushed a rough version of the game out to Tabletop Simulator for my use only. I’ve created a playtesting log and I’ve done 11 tests so far. These tests can all be classified as “movement tests.” Basically, I’m drawing random cards that reflect byways that must be traveled and measuring how many “dots” I have to go over to travel the full set of roads I’ve drawn.

If you want to learn more about record-keeping and playtesting, I’ve got a great article for you to check out. I take my own advice, and this is what my playtesting log looks like.

Playtesting Log

I’m going to continue to do more movement tests to get a feel for what win condition(s) will work in this game. I have a mental image of how I want the game to feel, but I don’t know specifically what tactics I’ll be using to get there. It’s like trying to drive to Dallas from Nashville, but not having a map. You have to rely on your understanding of where things are located and follow the signs and the advice of others.

In the coming week, I hope to accomplish the following goals:

  • Create a rudimentary win condition to test
  • Experiment with a card drafting mechanic
  • Push version 1, edit 2 to Tabletop Simulator (version codename: State Route 1, Edit 2)
  • Playtest some more