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.
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 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.
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:
- 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.
- Play test State Route 2. Gather data.
Key Takeaways for Game Devs
- Don’t fall in love with your ideas. You’ll have to throw out lots and lots of them to make a good game.
- Prioritize the “core engine” of your game first – the bare minimum mix of mechanics you need for your game to function, even if it functions poorly.
- Go through game versions rapidly and have a goal for each one.
- Track your testing results, preferably in Excel.
- Pick priorities for the coming week, and keep track of what you have and haven’t done.
- Take regular breaks to recharge. It takes a long time to make a game.