Unity and the art of game version numbers

Version numbers for me have one main purpose: identifying the version players are playing. If somebody is playing version 0.0.1.106 and reporting a bug that was fixed in version 0.0.2.391, I can keep track of things.

I had zero previous knowledge on how to do version numbers automatic in Unity, so I did the following: I created a game object where I can type version (such as “0.2.3”) and then this tiny lil piece of code adds something like “.231″ in the end. This gives me a nice little unique build number so I can somewhat compare builds.

This system adds a build number after every time you click “play”. This means if you try playing your game in the editor 3 times, each gets a new build number.

Not perfect. Not ideal. Not even useful always, but at least bit better than just having a manual version number like 0.2.3 that one forgets to change when building new things.

Here’s the updated (thanks to Mr. Reto) piece of code. Use as you please, and if you know better ways, I’m totally listening.

Attach this piece of code to a gameobject inside your game, and it should work pretty ok.
// BuildHandler.cs

Juuso Hietalahti

Post navigation

9 Comments

correct me if i’m wrong, but how is this supposed to be add a build time number?

if i read this correctly, it does add a timestamp, which measures time in seconds when the game is started. counting seconds from 1.1.2014. however i dont see anything related to saving a number when the build happened. the public variable would be the only information that could be included into a build. however it will not be automatically updated in the editor, because it’s not a editor script.

so this script will work when run in the editor, but i dont see how it works when sending a build to a tester (because everybody gets a different timestamp)

We use a combination of the SVN revision number and the player settings build number. This script is ran by our custom build process (ran by our build server), so a build number looks something like 1.2.0.3889.

Part of the build process saves this version number as a text file in the /Resources folder so we can load it programmatically and display it to the user in a relevant location.

I’ve seen systems that use the svn or git revision number for the source the build came from for the same end. The huge advantage there is you categorically know that the same revision will produce the same output – assuming everything is versioned together – and you can easily see if the bug has since been fixed…