I never planned to make a game — the constraints chose the scope

Making a game was never part of my plan. For seventeen years what I wrote was business software; games were something I played, not something I built. Without a few friends starting to build games and pushing me persistently, this post would not exist either.

When the push came, the first question I asked was not “what should I make” but “what can I make”. This post is the story of how the answer to that question — a list of constraints — turned into a game design. The short version: constraints did not narrow the scope, they chose it. The decision that a match must finish in one sitting determined the turn limit, the dice-free combat and the serverless architecture one by one; I did not pick any of them separately. What came out of it is called Regnarium.

The only genre I knew

Being honest with myself, I had exactly one asset: the tens of thousands of hours I had sunk into strategy games. I did not know any other genre as well as I had played this one, and trying to design in a genre you do not know is the most expensive way to spend time on a one-person project.

That was the first constraint, and it was really an advantage. Knowing a genre well as a player means being able to say, as a designer, “this is where I get bored”. In 4X strategy that point is well known: the middle of the game. Exploration is over, the war has not started, and you keep pressing the end-turn key.

A list of what I did not have

The second constraint was scale. I am one person, not a studio. That meant there was one thing I could not compete on: content volume. Large productions have hundreds of units, dozens of civilisations and deep technology trees, and all of that means person-years.

The mistake here would have been trying to do the same thing with less — that is, building half of every system and finishing none. Instead I kept the lists deliberately short: five units, five buildings, four terrain types, three resources. The single rule was that every entry must have a job you can tell apart on the board. If a unit is just a slightly better version of another unit, it lengthens the list without enriching the game.

What “it has to finish in half an hour” chose

The third constraint was the most decisive, and it was personal: I was designing this game partly for myself, to play while waiting for something. So a match had to be over in half an hour.

Look at what that single sentence chose:

• A fixed turn limit. The game ends itself: a match closes after at most sixty turns, and if conquest is incomplete the score decides. The clock is not a warning, it is part of the rules. A design that says “keep going if you like” would have broken the half-hour promise on day one.
• A small but dense map. The size of the board came straight out of the turn count: exploration finishing, expansion tightening and a front forming all had to fit into sixty turns.
• An opponent that does not keep you waiting. The AI’s decision time became a budget line; every second the player spends waiting for their turn is a second stolen from the half hour.

I chose none of these because they were “good design”. All three fell out of one constraint.

Dice-free combat is a design decision

The fourth decision came not from a constraint but from my own time as a player — and it is where I thought the longest.

A combat system that rolls dice lets a player blame the system for every lost match. They question the roll instead of their own call, and in a short game that is fatal, because you do not have three hours to recover. So combat is fully deterministic: the preview you see before attacking is the same calculation the engine applies. Writing a separate “estimate” function would have opened the one door through which preview and outcome could drift apart; that door was never opened.

It comes down to one sentence: no surprises, only regrets. The match you lost was lost because of a number you did not read.

Randomness is not absent — the map comes from a seeded generator — but it does not leak into play. That distinction is also what makes offline play possible: because the same seed and the same sequence of commands always produce the same match, a save does not have to be a full copy of the state. The seed and the command list are enough, and loading replays them. The need for a server, an account and synchronisation fell away right there.

I did not write the code, I held the architecture

This belongs in the record: I designed the mechanics and the architecture, and an AI wrote most of the code. My job was not production but preventing drift — keeping the architecture I had set, keeping the wrong library out of the project, keeping one rule from being computed in two places. I wrote about that distinction before, across three levels; here I ran the experiment on myself, and it did not change my argument.

One thing I would add: guarding a rule by eye does not scale. So I handed most of the constraints to the machine — the rules core is banned at the lint gate from reaching the clock, the network and the browser, and whether that gate actually holds is tested separately with files written to be wrong on purpose. A rule being written down is not proof that it binds.

At the end of the day

The result satisfied me, and not because the game is large — because it is finished. On a one-person project, cutting scope feels like a concession; in practice it is the opposite. Scope you never cut means finishing no system at all.

That is the only thing I would tell someone building a side project. Write your list of constraints first — how much time you have, what you genuinely know, where the product will run — and derive the design decisions from that list. Starting from a blank page looks like freedom; it is actually the shortest path to never finishing.

How it was built and why each decision went the way it did is in the Labs entry; the game itself runs in the browser, with no account and offline.