Keeping a history of releases of your games is a very important lesson we’ve learned during our gamedev journey. It’s more important to keep a playable version than the code, because code quickly becomes obsolete. And, it is helpful to name each release chronologically, with some reference to date and time.
How to store the builds
Store each release version in as small and compact a folder as possible. Where possible, always store the playable deployed version of the game.
To make life easier, we customise the storage builds with a custom title screen and release notes file. The custom title just has the version information displayed and the notes are development notes, ideas and project information relevant to that release.
We use Phaser for our web games, so if you’re also building web games you should pack the game to work in a single directory. The upside is that it makes the game easy to transfer and upload because it’s self contained. We’ve also used Phaser with Cordova for CarryKins Hot & Cold. Updating a single directory is just easier.
Why the need for a history of releases
The most important reason to keep a history is for the different game ‘feels’. Each release often has a unique feel to it where some mechanic has been slightly adjusted or some feature added or removed. These are very difficult to describe and even harder to replicate.
It’s very difficult to compare and understand why one version feels more fun, intense or engaging. When it comes to the emotional aspect of the experience, the code itself can’t give you any insight. You need to play each version to get the feel and understanding of it.
Conclusion
Whether or not you decide to keep a playable version or not, we still recommend using a versioning system or regular backups. The case for the playable game only holds true if you continue refining and updating the game, but even so, being able to walk down memory lane is fun in itself.