Updating strategies

PATCH requires builds and patches to be available on the server. This could waste a lot of space in the long term, in particular if your game is really huge. Not only, this could have implications on how the content is served to your users.

That's why it is really important to plan a good and maintainable strategy to handle your updates.

The problem

Nobody stops you from having just a single build uploaded on your server, then you only upload patches. But let's analyze the implications. Builds are like snapshots of your game at a given time. Patches are the diff that allow the Updater to "navigate" through these snapshots, obtaining the expected state.

Now, let's analyze some problematic scenarios.

Context: let's say we have build 0.1.0 and 50 patches (that we assume to be sequential), up to version 0.50.0, on the server.

What happens when a new user wants to download your game? The Updater identifies the latest available build on the server (0.1.0), downloads it, then it checks for the shortest patch path. The shortest patch path in this case is composed by 50 patches. So your user must go through 50 patches to obtain the latest build (0.50.0) of your game.

What happens when an user with an already existing build of your game (let's say 0.49.0) needs to repair the game? Same thing as before: the Updater identifies the latest available build to get a valid snapshot of your game and repairs to that. In this scenario, it would be 0.1.0. So the user will need to re-apply 50 patches even if they were already on 0.49.0.

What could we do to mitigate this problem?

Updates storage

A good strategy would be to only store your latest X builds on your server, for example 5. Based on your storage and resources you can expand that X accordingly. Same thing for patches: you can store on your server just patches among your latest X builds.

If you are afraid that your less active users will not be able to update anymore if they don't play for a very long time, the Launcher can solve this for you. Normally the repair functionality checks for files validity based on metadata stored on your server. But if the repairer can't find that metadata and the local version on your user's side is older than the oldest version on your server, then a full repair is triggered.

A full repair just repairs your user's game to the latest available version, without the need of applying patches. It requires your user to fully redownload the latest version of your game, but it is a safe tradeoff when a user does not play for so long periods of time.

One-step updates

Another thing you may want to solve is the following situation: if your user does not play so often, but they still are out of full repair range, they will probably end up applying up to X - 1 patches.

It requires time and it is boring. And you don't want your users to be bored.

Based on previous strategy to store updates, you now only have X builds on your server. You can simply build all shortest paths to the latest version from all previous versions.

For example you have 5 versions: 0.1.0, 0.1.1, 0.1.2, 0.1.3, 0.1.4. You will generate 4 patches:

• 0.1.0 to 0.1.4
• 0.1.1 to 0.1.4
• 0.1.2 to 0.1.4
• 0.1.3 to 0.1.4

Now all users will update in just a single step!

Let's say now you add 0.1.5 version. You delete from your server 0.1.0 build and 0.1.0_0.1.4 patch.

Warning

When you delete a build and/or a patch, you must have care to update builds_index.json and patches_index.json to remove deleted build and patch entries.

You will now generate 4 patches again:

• 0.1.1 to 0.1.5
• 0.1.2 to 0.1.5
• 0.1.3 to 0.1.5
• 0.1.4 to 0.1.5

Again: single step update for your users!

Automation

All these steps above can be hard to do manually every time. That's why I highly suggest to prepare a deployment pipeline. You can prepare a script on your own or you can take advantage of stuff like Jenkins, GitHub Actions, GitLab CICD, etc.

In the PATCH package you can find a commandline utility that perfectly suits this task.