I don't talk all that much about the nuts and bolts of game creation like prototyping because I think by and large everyone just hits upon their own solutions and goodness knows my own processes aren't especially sophisticated or worthy of emulation.
But I do think it's interesting to talk about how one tracks the evolution of one's game. I suspect people have different conventions for this but my own is to label versions of my games as [number].[number][letter]
So for example, Lost Adventures, which I discussed in the last post, was, going into that post, at v16.4b, but now after that post (and a quick test) it's at v17.0a.
The first number is for major systems changes: something like the way actions are selected, or the way points are awarded, something big and sweeping.
I recently talked about changing Evangelists's turn mechanic from "take a cube of each color, each signifies a type of action you can take" to "receive 6 black cubes, pay 1/3/6 cubes to use an action once/twice/three times". That's a big change and so it gets a new version number. Changing Lost Adventures from a gamer-weight game to a family-weight game entailed some sweeping changes and so the counter ticks from 16 to 17.
Having this coarse-grained "version number" is useful in a way that giving every single change a version number wouldn't be.
For example, version 4 of LA used a temple exploration with first-person perspective cards and a lookup table (actually it was pretty cool), v7 was our first "main version" and it had a 2D temple crawl on temple tiles, tiles that each contained several rooms, v10 had a temple made of cards, v12 was the first "the temple is a row of cards, no exploration" system, and so on. It's easier to think about these big changes because of the relatively smaller number of version numbers, whereas if those were v9, v17, v26, and v45, respectively, it would be harder to keep the differences straight.
The second number is for sub-system changes. Perhaps you have settled on a card-based action selection system but have changed some of those actions, or perhaps you have an area majority scoring system but have changed the way the board is laid out. These changes aren't major in the sense that they change the gameplay dramatically, but they change the way the game is played by the players and are therefore useful to track at a level below the version number.
For many designs and many designers these two numbers would be sufficient, but I also like to use a third designator (which could just as well be a second period and a third number), to signify minor changes that don't alter any of the major or minor systems. Perhaps this means something like changing the card distribution a bit, or renaming some things, or changing the dice results table. These may be things that affect the game, but they often aren't rules changes but rather components changes. Although, they still usually necessitate changes to the rulebook examples!
I think there are a few benefits to tracking your version changes.
It's easy to go backward. If a change turns out to be a wrong direction, easy enough to go back to the "last known good" version of the game and start over from there.
It's fun to see where the game has been. As mentioned above, we can speak of v4, v7, v10, and v13 as major turning points in the Lost Adventures design, and those have become part of the game's unfolding story.
It can force you to question whether you've done enough.
For example, of the games I talk about here:
Sands of Time was published as v19.4d
Lost Adventures is currently v17.0a
Collusion is currently 9.6b
Evangelists is v7.0
Le Sablier is v8.1
Downhill Racer is v3.2
Funnel Clouds is v1.0 (!)
If a game has too few version numbers, it makes me wonder whether I was sufficiently aggressive in trying different things. Did I leave any stones unturned?
Funnel Clouds, my real-time auction dexterity game, is a fun example; the day I came up with the game, I wrote its core rules on a post-it note, and have never changed the game since then. It's still the exact same game it's ever been.
It can help apportion credit. Rulebooks should acknowledge playtesters, and sometimes if you receive a few copies of a published game it's nice to give those to playtesters as well. Who gets credit, who gets games? One fair way is to give the playtesters who contributed the most time, but another is to look at who was involved in the playtests in which the most decisive changes happened and reward the testers whose suggestions brought those about. The version number approach makes that easy.
One surprise, to me, is that:
I don't personally find a pattern to how the numbers change. You might expect that early in development, the version number changes a lot with only a couple of iterations of the minor system number for each version, until the design stabilizes, at which point the version number "locks in", then the minor number goes up to a high number, and then finally the letters start to change as you tweak little things.
So you might expect the final version to be something like "15.21s". But none of my games have really followed a trajectory like that. I'm not sure what to make of that.
But I think part of it might be that game design isn't necessarily hierarchical like this. You'd think it would be "lock in the big stuff, then adjust the minor stuff, then nail down the specifics". But it doesn't always work that way. Just because you've changed a major system, it doesn't mean you start over from scratch and now have a zillion sub-system changes to make. Maybe you do, but not always. And contrariwise, it may be that after a half-dozen minor system changes you realize you're going down the wrong path and that actually a more sweeping change is needed, and once you make it things lock into place.
I'm sure people have all different conventions for tracking their game's progress; by all means please share yours in the comments!
Every take a hot take
29 Jun 2020
- [+] Dice rolls