Version and Update Numbers

[qwsaq]

It goes without saying that it's somewhat of a faux pas to label your first release of a game "v. 1.0" when it's still ostensibly in the early-alpha/concept phase. There's a general agreement that the leading digit should always be 0 until you have a complete game that's playable from start to finish with all the features, plot points, and polish that make it "finished" and any update after that is gravy.
Beyond that: what is the "ideal" format version numbers should follow if you had the power to change everyone's mind?

Spoiler: My dumb opinion

You don't have permission to view the spoiler content. Log in or register now.

 

[Droid Productions]

Yeah, I usually follow a similar pattern.

For Love of Magic:
Book 1 (The Crown) : 1.2.6
It's done (released on Steam, so it gets its 1.x.x), it's gotten two major updates since then (x.2.x) and part of the second update cycle involved several internal releases

Book 2 (The War) : 1.0.8b
It's also done, and out on Steam, so it's a release 1.x.x. It's had no major updates with new content, but it's had a couple of bug fixes, including one that got an immediate hotfix afterwards (the x.x.xb part of the version).

Book 3 (The Return): 0.2.18c
(This is the latest on F95; on Steam it's 0.2.31b, which is the final build of the Act XIII+ build cycle, and it'll hopefully go up today, if the mirrors collaborate).

This is the second Act of Book 3 (0.2.x), and there were 18 internal content releases to testers on Discord/Steam along the way (That act had a 2 months development cycle, 18 releases, so 2-3 releases/week). The C part means this is the second hotfix to that release, containing only bug-fixes.

 

[F4C430]

I just don't like it when dates are used instead of version numbers. That gives no indication of the significance of the update, nor does it give any indication of how far along it is.

 

[Rafster]

That's the pattern I follow.

X.Y.Z

X: it's 0 because it's not finished. When I'm done with the content, it will change to 1, no matter if we are at 0.5
Y: Every major content release. So far, I had 21 since I started the project
Z: It's a letter (a,b,c...) indicating hotfixes or minor additions

 

[MissFortune]

X.Y.Z

X: it's 0 because it's not finished. When I'm done with the content, it will change to 1, no matter if we are at 0.5
Y: Every major content release. So far, I had 21 since I started the project
Z: It's a letter (a,b,c...) indicating hotfixes or minor additions

As Rich Hickey so eloquently put it, You'reScrewed.Don'tCare.Don'tCare.

Which is largely the flaw of the semantic versioning being used here, and with most of the other games around here. X doesn't mean completed; it just means a Major version update. X would be the minor additions/bigger fixes. Z is the hotfixes, patches to fix a usability-breaking bug, etc. These numbers are (not yours specifically) so arbitrary, that there's no true scale in which to judge by, which defeats the entire purpose of a 'standardized' numbering system. Which creates the illusion that F4C430 is falling into. Dates say no more than your average 0.3 or 0.7 around here. There's a few 0.3's around here carry far more content than a 0.7.

 

[Droid Productions]

Dates say no more than your average 0.3 or 0.7 around here. There's a few 0.3's around here carry far more content than a 0.7.

Sure, but... the fact that some people misuse the versioning system doesn't make versioning useless

I think using the MSD as a 'major update' tracker would be silly. You can do that on general software, but at that point you'd say your first release (surely a major event) would be the coveted 1.0.0

Anyway, specifying playtime SHOULD be a mandatory thing, including a full changelog and a TL;DR version should both be best practices.

 

[qwsaq]

These numbers are (not yours specifically) so arbitrary, that there's no true scale in which to judge by, which defeats the entire purpose of a 'standardized' numbering system.

I'd like to think what I proposed is pretty close to "objective" in the sense that even though the version number won't necessarily tell you how much content there is, it does contain information relevant to anyone following the game's development. Namely: Y lets you know the dev has reached some sort of pre-determined milestone that was expected to take several updates. How sensical this is does depend a lot on the dev's workflow and the nature of their project, of course. But, especially for games with a broad scope, the dev could communicate their medium-term goals to their fans and the update number will reflect that this is where the current focus lies for now and how many updates have been dedicated to it so far.

 

[Gwedelino]

I'm pretty sure some devs spotted that naming their first release V 0.1 wasn't really helping them to get people trying out their game.

I mean, we always see at least 1 comment on the first page saying : "Screenshot look promising, Will wait a year before downloading this game."

So we get to see the "V.1.0" first release or even better the "Chapter 1" for 10 mins of content.

Doesn't matter if people feel tricked by that as since they like the demo they'll forget everything else and if they dislike it they'll drop anyway no matter if they felt tricked or not.

 

[Glib_Gentleman]

Sure, but... the fact that some people misuse the versioning system doesn't make versioning useless

I think using the MSD as a 'major update' tracker would be silly. You can do that on general software, but at that point you'd say your first release (surely a major event) would be the coveted 1.0.0

Anyway, specifying playtime SHOULD be a mandatory thing, including a full changelog and a TL;DR version should both be best practices.

I agree that it SHOULD be X.Y.Z format, and X shouldn't change from 0 until the game can be completed start to finish and is feature complete.

And yes, it would be nice if playtime could be specified, but it's a hard thing to come up with. A dev is naturally going to play the game faster than anyone else, since they know all the triggers. Some paths could be longer or shorter in a branching narrative, etc. Some players will read everything and gaze longingly at every new picture, while other players will skip until they see get to a new picture or choice.

I'm making a text-only game, so I calculate 250 words as a minute of gameplay. (Most adults have a reading speed of between 200-300 words per minute.)

But it can be harder to quantify for other types of games. Like if a game has puzzles - how long does it take a player to figure out each puzzle?

I'm pretty sure some devs spotted that naming their first release V 0.1 wasn't really helping them to get people trying out their game.

I mean, we always see at least 1 comment on the first page saying : "Screenshot look promising, Will wait a year before downloading this game."

So we get to see the "V.1.0" first release or even better the "Chapter 1" for 10 mins of content.

Doesn't matter if people feel tricked by that as since they like the demo they'll forget everything else and if they dislike it they'll drop anyway no matter if they felt tricked or not.

Yeah, I think this is the case, but it's still pretty crappy before, no matter the justification.

The way to get out of V 0.1 and get people trying your game is to . . . release steady updates. At some point, probably relatively quickly, you'll release enough updates to hit 0.2.

Doing anything else cheapens the significance of the 1.0 releases.

To me, if your game is in chapters (which is fine), you should roughly know how many chapters your final game will have, and version number accordingly. Game has ten chapters? Chapter 1 release is 0.1. Chapter 2 is half-way finished? That's 0.1.5. Chapter 2 comes out? That's 0.2.


And yes, some games will have significant amounts of content at 0.2.5, while other games will have less content and be at 0.6. The important thing is that each development is consistent.

And I would add that a Changelog or Update Notes are really important, both for players to get an idea of the amount of content, but also to build a following for your game.

I know I'm more likely to follow and pledge to a game if I can look back at a literal record of the updates and when they were made. Like, "Holy crap. This dev is a beast - they're releasing significant new content each update and they are updating every month, and they've been doing this for a year. I feel confident this is not going to be abandoned and may be completed at some point."

 

[Vanderer]

I use the format Update-"number"-"letter"(for fixes without added content). ex: Update 2c

It's simple and easy for users. It works.

There are ways to obfuscate the amount of content no matter what system you use, the versioning system won't change that.

To me, if your game is in chapters (which is fine), you should roughly know how many chapters your final game will have, and version number accordingly. Game has ten chapters? Chapter 1 release is 0.1. Chapter 2 is half-way finished? That's 0.1.5. Chapter 2 comes out? That's 0.2.

Not always. I have a rough plan of how my VN will progress, and several endings in mind depending on how the game is doing, and what happens IRL. Shit happens, and at least I have several points along the story where I can bring the game to an end that will be satisfying for the players.

Hence why I have chosen that type of versioning.

 

[F4C430]

These numbers are (not yours specifically) so arbitrary, that there's no true scale in which to judge by, which defeats the entire purpose of a 'standardized' numbering system. Which creates the illusion that F4C430 is falling into. Dates say no more than your average 0.3 or 0.7 around here. There's a few 0.3's around here carry far more content than a 0.7.

They're arbitrary, yes, but they are still far more useful than a date. If i last played v0.3 and the current version is v0.7, i have some idea of the progress because it's at least relative within the same project. If i'm coming across a game for the first time and its current "version" is October 2022, i have no idea how far along it is. Whereas if it's version 0.19.2, i have some clue.

 

[anne O'nymous]

Oh, it's been a while...

There's a general agreement that the leading digit should always be 0 until you have a complete game that's playable from start to finish with all the features, plot points, and polish that make it "finished" and any update after that is gravy.

No, and I really mean no, there's not a single agreement when it come to versioning. At most the semantic versioning scheme (Major.minor.patch[alliteration]) is supposed to be the most used one, but no one is really sure.
But well, let's say that there a general agreement, because it's funny to demonstrate why it should be this one.
Side note: It would be also funny to demonstrate why the one I will come to shouldn't be it itself

• Major
  Mark a significant change in the software. Can be either the addition of significant features, a paradigm change, or a refactoring that don't guaranty the backward compatibility.
  The Major version number must be incremented each time there's no guaranty that a previous version would be able to fully understood and proceed the data generated by the software.
• minor
  Small changes in the software. Any addition of features/functionalities that do not change the effective behavior of the software "data side".
  The Minor version number should be incremented only when the change do not correspond to a bug fix or vulnerability patch, and do not prevent the previous version to fully understand and proceed the data generated by the software.
• patch
  Any change in the actual code that fix instead of adding. In can include pure code refactoring when they are done to improve the performances.
• alliteration
  Fuck, we forgot/messed something with our previous patch. Please, pretend that you seen nothing.

So now...

The consensus on the Open Source community, is that a software should only stay at a Major version 0 during its early process.
This number represent the alpha stage of the software. It's the period during which the stability of the software is not guaranty. Only experienced users should use it at this time, because there's risk to loose your data, damage them, and it can possibly generate some OS instabilities.
Once the stability the software is reached, there's no more risk for the data, and the main features are implemented, the software should pass to the Major version 1. This will tell to the public that it's now safe to use it, even when you are an inexperienced user.

Therefore, at least when it come to VN-like games on the scene, there's clearly no reason for any version, except an effective early demo, to ever be a 0.m.p. The main features are implemented, the game is as stable as any other, and there's no risk to use it, the first release should be numbered 1.0.0.


This being said, there's another issue here, once again, "at least when it come to VN-like games on the scene". Why the fuck should the following releases be numbered at minor level ?
At no time those releases represent a small change in the game. They all implement significant addition, and strictly speaking the previous version wouldn't be able to understand and proceed the data generated by this new version.

Therefore, every following release should have a change in the Major version. This unless they correct a bug (patch) or add a new feature to the game but absolutely no content (minor).



Thanks for your attention, and remember, your first release should be numbered "1.0", and the following should all increase the Major version number. It's not me who say it, it's the logic behind the most used versioning system.

Or you can continue to do however you want and don't fucking care a single second. Because we, players, only care about one thing when it come to the version number of your game: "Was this version released after the last I played ?"
Everything else is just talks to occupy old grumpy guys like me.