Branch Line: designing a railway puzzle game before writing it

Rail Route, Mini Metro, Transport Fever and Cities: Skylines all have the same puzzle at their heart, and it’s the bit I enjoy. You connect a few places, they grow, and the junction that was perfectly fine last week starts backing up. So you rebuild it to untangle the flows, and then the next one goes.

So I’ve been sketching a game of my own, working title Branch Line: a casual, browser-based railway game about keeping automated trains flowing through a growing network. There’s no code yet, only design notes and four throwaway HTML mock-ups from one evening. This post is me thinking out loud.

What I don’t want

Rail Route is the closest thing to what I’m after. I like its simplified schematic view of the railway. I like that on-time trains earn you the budget to lay more track, and that signals and automation unlock as you go. But before the automation kicks in, there’s a lot of micro-managing: you dispatch every train yourself, throw the points yourself and turn trains round by hand, which gets pretty tedious.

I want it more relaxed than that. The game should warn you when two paths could conflict, and your job is to keep the trains flowing, not to drive each one. I’d also like a hex grid, with stations that are limited in where they can go or are even placed for you, so the puzzle is in how you join them up.

The conflict grammar

The first thing to pin down was what a “junction problem” actually is. Claude’s first mock-up had a flyover on a single-track line, which is nonsense, and I had to put it right. A flyover only helps when trains are going in opposite directions. Two lines merging onto one track still have to take turns beyond the junction, however much concrete you pour. What a flyover removes is a crossing: a train cutting across the opposing flow. On double track, a branch joining from the wrong side is a crossing, and that’s the whole reason flying junctions exist.

Pull on that thread and you get six kinds of conflict, each with its own fix:

The player’s skill is diagnosis: work out which one you’ve got before you spend money. The merge is the interesting one, because its best fix is often free. Shift one service a few minutes in the timetable and the queue disappears. That’s the moment you learn the timetable is a tool, not just a readout. The turnback, meanwhile, is Rail Route’s fiddliest chore turned into a single decision: you choose where trains reverse once, when you build the station.

Making success the problem

A bare “earn money, build more” loop is a treadmill. You’d just keep expanding into empty space where nothing conflicts. The rule that fixes it is simple: demand grows fastest on the routes you serve best. Run a punctual service and that town grows, which sends more trains through the junction you built for it, which breaks it. The reward for doing well is more trouble in the same place.

A few more rules keep that from turning nasty:

• Growth is opt-in. A town that’s ready to grow offers a contract, something like “two more trains an hour, +£400/hr”. Turning it down is a legitimate move if you can’t afford to rebuild that junction yet.
• Delays stall growth; they don’t shrink things. No crashes and no game over. The worst that happens is losing a contract you took on and couldn’t run.
• The network runs one repeating hour. The same hour loops until something changes, which is exactly what a real railway’s train graph shows, so the graph becomes the obvious way to see where the minutes go.
• Land is the real currency. Money piles up; space doesn’t. The flyover that needs three cheap hexes early on needs demolition or a long detour once the town has grown round the station. Build early and it’s cheap; build late and you pay in geometry.

The mock-ups

The first mock-up tried three ways to schedule the trains. In “timetable-first”, you drag departure times and buy passing loops on a 100 km single-track branch, with a train graph beside the track so a loop lines up with the point where two diagonals cross.

The second replaced a “build flyover” button with an alignment editor. You draw a route for a quarry branch hex by hex, past a town, a river and steep ground. The game works out the heights, and the gradient rules decide whether you can get over or under the main line in time.

The third and fourth ran a small district for weeks of game time. In the fourth, the signals show their aspects live, and a red ring marks a train that’s being held.

The pressure-curve mock turned up the most interesting lesson, and it wasn’t about trains. Its first version had no randomness at all: every train left on the dot and took exactly as long as it should. It was unplayable. Punctuality sat at 100% for thirty weeks, then fell to 61% in a single week. That’s a textbook result from queueing theory: with no variability, there’s no delay right up to full capacity, and then it falls off a cliff. Add a minute or so of jitter and delays start creeping in at around 75–80% utilisation instead, which is roughly where real railways start to struggle too. The noise isn’t decoration; it’s the early warning the player needs.

The fourth mock also showed that the diagnostics have to separate primary delay (a train that arrived on time and still had to wait: a genuine pinch point) from knock-on delay (a train that was already late). Without that split, the game kept blaming a line that had already been fixed, because late trains queue at everything downstream.

I should own up: this whole design was a conversation with Claude. I wrote the brief, and Claude wrote up the mechanics and built the mock-ups, which were quick enough to throw away that I could keep asking “what if?”. It’s a surprisingly good way to find out whether a game idea has legs before writing any real code.

Where it stands

It’s still a design with four toy prototypes, and the list of things to test is longer than the list of things I know. The big ones: does “success creates pressure” feel like a squeeze or like admin? Is turning down a growth contract ever actually the right call? And does the map filling up feel like a tension you can see coming, or a punishment you only notice at the end?