Creating the First Version of Game Rules – Dev Diary: 04/07/17

Posted on Posted in Dev Diary

The following is a cross-post of the Dev Diary for Highways & Byways from my blog, Brandon the Game Dev.


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.



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


Leave a Reply

Your email address will not be published. Required fields are marked *