Game Versioning Best Practice?

Started by
5 comments, last by Meatsack 10 years, 9 months ago

I've looked at some articles and the Wiki on software versioning, and read that the numbers basically mean what you want it to mean. Still being in the hobbyist category of game developer, I'm asking for a professional opinion on how games should be versioned as they progress.

Personally, I use the 2-number system of Major.Minor progress. My prototypes go from 0.1 to 0.whatever until I think the game is in a playable state where I am willing to share it with others to get some feedback. That, to me, is 1.0. Bug fixes and feature usually creep come next while I hunt for art and music talent. That's where most of my enthusiasm loses steam. I'm thinking that if I ever got the art in place, that would be a +1 to my Major version. Same with music. So my beta release would be 3.0? That seems odd to me in a way that I can't put my finger on it. (Besides it being an odd number, wiseguy!)

Again, I found no hard and fast standard to follow when it comes to versioning my games. And I like structure. So what do the pros do? Indie or otherwise. Is there a generally accepted system to follow?

Writer, Game Maker, Day-Dreamer... Check out all the wonderful things I've thought up at Meatsack's Workshop!

Check out the Current Ranking of Super Gunball DEMO on IndieDB!

Advertisement

One system I am aware of

0 . 1 . 1

or in English

(Alpha/Beta)/Release/expansion . Major patch/progression(incorporates all previous minor versions developed after last major update . Minor patch/progression

The system works by implementing minor works/fixes. Each new implementation increments the counter by 1 i.e. 0.1.1 becomes 0.1.2 becomes 0.1.3 until as such time as you incorporate current minor works implemented into a classified major state i.e. 0.1.342 becomes 0.2.0. On release (or when "going gold") you increment the first point i.e. 0.2.0 becomes 1.0.0 at which point progression is then considered patch versions. With regard to alphas and betas everyone seems to do differently that I have worked with.

Take a look at this: http://semver.org/

From what I have seen, it seems that a game is designated as version 1.0 when it is considered ready for retail. Any subsequent patches are designated with the number after the decimal point (e.g. 1.1). Of course, if your game is still in development, you could consider using two decimal points (e.g. 0.1.5) if you want to break the progress down even more.

StormyNature has the version we use professionally.

Have you advanced your project enough to have automated builds? It is an easy practice. Every day that something was submitted, the build number gets incremented by one.

If you have done that, the daily build number also makes a good version number.

Another version I've seen around is: 2013.07.24

Using the current date as a version - though this might cause problems if you need to support multiple versions of something simultaneously (say, supporting an older branch with new bugfixes), but should work fine for something where everyone is forced to stay updated (like a online game client).

Thanks for all the responses! This gives me a commonly accepted numerical structure to follow as I make progress on my projects.

Right now, because it's infrequent, I'm going to go with what Stormy posted and just add a "0.'' in front of all my version numbers. Nothing is retail-ready. When I get to releasing the public demo, I'll call that version 1.0.0 as it'll be the equivalent of "going gold". The other two places will stay major.minor progressions.

Again, thanks for everyone's insights.

Writer, Game Maker, Day-Dreamer... Check out all the wonderful things I've thought up at Meatsack's Workshop!

Check out the Current Ranking of Super Gunball DEMO on IndieDB!

This topic is closed to new replies.

Advertisement