Versioning a Videogame: Semantics

Every patch I ship carries a version number, and for a while mine meant nothing in particular. A build was 2.4.1 because the last one was 2.4.0 and this one came after. The number counted up, but it didn’t say anything.

That bothered me more than it should have, because the number is the first thing a player reads. Before the notes and before the trailer there’s a little 2.4.1, and if it’s going to be there anyway then it ought to make a promise.

So I adopted Semantic Versioning, the same MAJOR.MINOR.PATCH scheme most software uses, and then I moved one rule so it fit a game instead of a library. SemVer is built around a “public API,” meaning the functions other code is allowed to lean on. A game has an API too, and it’s made of controls and systems and the way the thing feels to play. The contract I care about isn’t a function signature. It’s how the game plays.

So I turned the three numbers into three questions a player actually asks. Will my saves and my mods still work? That’s the major number, and when it moves you should back things up, because I’ve broken something fundamental. Will the game play differently? That’s the minor number. Is this just better instead of different? That’s the patch number on the end.

The middle one is the part I care about most. In plain SemVer a new feature earns a minor bump as long as it doesn’t break anything. I changed the test. For me it isn’t “is this new?” but “does this change how you play?” And once you ask it that way, something surprising falls out, because a new feature can ship in a point release.

A photo mode doesn’t change how you play. Neither does a new hat, or another language, or a colour-blind palette, or a key you can finally rebind. They’re real features and I’m proud of them, but they leave the game itself untouched, so they ride along in a patch. The moment a change reaches into gameplay it’s a minor bump, whether that’s a new ability, retuned enemies, or a level that plays differently than it did yesterday. It’s a minor bump however small the diff looks.

I like this because it’s honest about where the risk lives. A bumped minor is me telling you your muscle memory might be stale and the notes are worth a read. A bumped patch is me saying the game is the same and just runs better, so update and carry on. The number does the reassuring so you don’t have to go digging.

There’s a discipline in it, too. Every build now forces a small argument before it ships: is this gameplay, or isn’t it? That question keeps me clear-eyed about what I’m actually changing. More than once I filed something as a patch, like nudging how fast fuel drains, and then realized it changed how the game plays, so it became a minor bump instead.

I wrote the whole scheme down on a versioning page so anyone can check my work, and so I can’t quietly talk myself out of it later. It’s a small thing, just three numbers with a dot between them. But I’d rather the first thing you read about a build already told you the truth.