Automate build ID?

So now that we have a nice main menu, the game should be more than ready for sharing (assuming swapped over to JSON saving).

One important thing however is to know if there’s an easy or convenient means of generating build IDs / build dates.

  1. In the simplest use case I can just present these in the main menu UI and they can be useful for debugging purposes.
  2. In a slightly more advanced version, I can put the ID in the save file and error out if the save file is incompatible with the current build. I can then tell the user to start a new game or delete their save files.

I found a few sample scripts online but it looks like this is non-trivial so I put it as a talk vs ask. Maybe this will be the next addition to brians-tips-and-tricks?

This post has some tips from @Brian_Trotter (and me, but I was overthinking again). This is to try and keep the save files backward-compatible

There is good advice there. And familiar with many of those techniques. I will definitely adopt them.

Some stuff just plain breaks things like when we changed scenes and added a new scene number 0. Or maybe you want to rescale how experience is granted. I’m telling my play testers to not expect save file compatibility for the prototype.

The other nice thing with build IDs is that when folks report issues you can track it to a build.

This is fine during development/beta, esp if you include a caveat that their save files will not survive a transition to the final version. That being said, In the Game Industry version of Jeapardy, this is the answer to the question “The best way to ensure your game is uninstalled immediately.” :slight_smile: In a published game, all save files should be forward compatible. In other words, an old save file should always load (may be missing some feature or another, but it should load). If your data structure is already a JObject, this can be as simple as checking for an outdated tag and interpreting the data appropriately. For things like “I was saving a bool, but now I’m saving a JObject with a bool, and an int”, checking to see if (state is JObject stateDict)/else bool thing=state.ToObject<bool>() is sufficient.

I could write out an amazing script for this, but I’m going to pass you to a well regarded video on the subject:

Application.version is a string with the build version number. I’m unaware of any method that will return the build date, but if you keep track of the build version, you can keep your own records of the build dates. Much like the buildIndex we use in the Save file, you can also add Application.version to the save file. This is especially handy with the Json saving system so you will know right off the bat what version the player is using.

1 Like

Yes. 100%. I’m not even at beta. I am doing play testing for small pieces of functionality.

Also 100% agree that some changes are easy for backward compatibility such as checking data structures.

Awesome. I came across the 10 minute youtube video of this too.

My plan was to use System.DateTime.Now to get timestamps just before or after when the build ID gets incremented.

Privacy & Terms