Versioning Schemes

Normally I wouldn’t have another post up so soon, but the topic of versioning has become somewhat time-critical. I’ve been thinking over it quite a few times in recent months, but haven’t been able to make a final decision on where to go from here.

Why now? Well, know that in one sense--one of the more important senses, actually--next week Cogmind will be “done.” All the confirmed maps are in, all the major NPCs exist and are doing their thing, all the endings are in place… The story will be complete.

*fanfare, cheering*

Development will continue, but this is a pretty significant milestone.

That said, there are still certain items left on the TODO list that keep me from calling it a true 1.0. And honestly I’m not ready to handle all the meta work that should come with a 1.0, anyway, mainly on the marketing side which at the very least requires putting together a new trailer and getting in touch with press/LPers. (I still like the two-year-old alpha trailer and am tempted to just update it using new visuals, but even that takes a while.)

So what to do about version numbers in the meantime?

Searching for version numbers in the matrix.

We could at least wait until the Steam EA release (as a different kind of milestone) before switching to a new system. However, rather than basing it on an external factor like that it’d be nice to keep the system a little more relevant to the current state of development, and we’re definitely switching some gears here (more on that later).

Greek

I wouldn’t say continuing along with “Alpha #” releases is off the table, making next week’s release Alpha 15 as expected. Plenty of games do Alpha 1-2-3 their way to 1.0, and I admit I’m fond of the Alpha system, if only because I’ve been using it for a good while. But there are a few reasons for which, if possible, I’d like to find a satisfactory alternative.

Another vote for switching away from the alpha designation is that for most people it implies a game is in a very unfinished state, probably even buggy or unenjoyable, neither of which would describe Cogmind even years ago. While it’s true I’ve wanted people on the outside to believe that for the past couple years of alpha so that I could reduce the number of buyers and instead focus on development (not unlike my approach to pricing), I’m now more willing to allow the terminology, and first impressions, to start inching into new territory :)

For a short while I was thinking of using “Beta,” as it naturally follows Alpha, but that’s technically more of a “this software is feature-complete though still subject to pre-1.0 tweaks and fixes” sort of state. If we wanted to judge Cogmind’s development in those software terms, it’s clearly still in alpha and will be for a while, since I plan to do lots more with it! Even major new features…

Hey, maybe we could do something off the wall and go with “Gamma” releases? Haha, okay that might cause some confusion.

R for Release

Some games and libraries simply increment an integer with each release: R1, R2, R3… Pretty straightforward. I like it. I’ve also used it before, for X@COM. Minor patches can just add a decimal or letter, e.g. R5.1 or R5a.

If I went this way, another thought is to skip straight to the actual release number, so “R15,” just to keep the sequence going rather than starting over, though an “R1” is a pretty meaningful statement for that one release in its own way. A true new beginning rather than more of the same.

Maybe one day!

“RC#” is another option, though not too often used with games (?). Designating a Release Candidate is more akin to beta, or the final versions of beta software, not to refer to something that will continue receiving large feature updates for the foreseeable future. But then you have games like Starsector, which has been using an RC numbering system alongside their decimal-numbered releases for many years now :P

Decimals

Speaking of decimal systems, they’re definitely the most ubiquitous. But I don’t really like the idea of purely sticking with a bunch of numbers. (Just this week I posted about how and why I’ve circumvented numbers where seeds are concerned :P)

Numbers aren’t as easy to remember, and more importantly any sub-1.0 version numbers might be assumed to reflect the amount of development remaining until completion (e.g. 0.5 is half finished), even if they’re not intended that way. Given that there’s a huge number of possible future features, and I can’t say exactly which will make it in, it’s tough for me to nail down where a given release stands in terms of numbers.

Trivia: Technically Cogmind does have decimal version numbers, but they’re all simply 0.10 (a common “this is an early build lots more to do!” number) followed by the date, e.g. 0.10.170509. These are just for my reference, because I find it really useful to have the date in the “version” itself.

One way devs work around the boring number version issue is to give releases unique names. I did this for X@COM, for example “Sheer Terror” when adding terror missions, “Sound Like a Hero” when I added sfx, “Chryssalids in my Backyward” for… the chryssalid update :o. They’re a fun and easy way to remember, more interesting to read, and useful for setting the theme of a release.

Revenge with Blaster Bombs in an X@COM town. Damn that game’s a blast and I want to work on it…

I’ve thought of naming Cogmind releases for a long time, even retroactively naming older ones for consistency, but never went ahead with the plan.

Actually, I have sort of named each Cogmind release, if only in one place: IndieDB. For release announcement posts there I always name the release rather than reporting it as a number like elsewhere, just to give the post title a less boring look since it appears listed with other games, and also to give a hint of what the release includes. The next release is already dubbed “The End,” Alpha 14 was “Hack ‘n Slash” (melee multi-wielding), Alpha 13 was “Rise of Zion” (new plot thread), Alpha 12 was “The Place No One Lives to Tell About” (boss map), etc. While we’re at it, do you have any opinions on named releases?

In any case, version names are really just supplementary to another system, as ideally a game’s versioning should reflect some kind of sequence.

Dev Cycle

As far as other considerations go, the decision here depends somewhat on the future release schedule.

In the past it was easy to maintain a 4/5-week release cycle, with a couple weeks of adding a big chunk of content centered around a new map or branch, followed by a week of bigger feature(s) and then some little ones. While I really like that approach, which makes each release pretty substantial (and discussion-worthy!), future updates won’t usually have new maps to be focused around, which themselves lead to lots of other related required content, features, and mechanics.

I’m also looking forward to the pace being a little more flexible and responsive, such as releasing smaller batches of new features every two weeks or so. This change in pace would be another reason to depart from the original alpha designation, if only because sticking to the ongoing “Alpha #” system can distort and dilute the effort and value of the previous releases, each of which took a lot of work to complete.

Grid Sage Games release history as of 170504.

I very much enjoy the practice of releasing with meatier changelogs, but then players also appreciate more rapid development, so there’s a good chance I’ll be heading in that direction for a while, at least for much of 2017 (once past the “actually releasing on Steam” hurdle).

Are you done yet?

No, this is cathartic and I might be coming close to a decision :P

Having written all of this out, I’m leaning a lot more strongly towards an R# system, maybe calling it R1, kinda like a fake 1.0.

And beyond that? I guess then we can, okay, eventually declare a release the 1.0, and then I imagine there will be updates even beyond that (I probably won’t be able to stop myself even if I wanted to), so then we could go with numbers since there is no longer some kind of commonly-assumed target after 1.0, which just breeds updates like 1.01, and so on. Alongside it we’ll probably just continue with the R-numbering as well.

Anyway, regardless of what versioning we go with for now, I’ll keep up the same date-appended pure number version (still 0.10!).

So what do you think--have I overthought this enough yet? :P

I… still can’t decide. Because after sleeping on this post I woke up thinking about it from another angle and started to question the whole R-thing, in that unlike a < 1.0 decimal version number, or clearly having an “alpha” right in the version name, using something like “R” doesn’t even hint that the game still has a fair bit of development coming, or that it’s technically “early access.” That information has to be expressed externally to the versioning, which is somewhat annoying. Maybe just let innertia do its thing, call it Alpha 15 and stop thinking about this? Or is it time for something new? Hm.

Maybe Beta? It’s different from Alpha but clearly “not done,” and we can ignore what it really means in terms of software development (most games ignore it…). Hm.

Update later same day: For scheduling reasons I had to make a quick decision since it’s Friday and for some reason I really thought it was still Thursday :P. So… Beta it is. Huge feature preview for Cogmind’s Beta milestone is now posted!