Compare builds and patch size
See what players will download, and the packaging settings that make updates bigger.
Before you publish, compare the new build with the one players have. In the Deltaship tab, under 2. Compare with a previous build, choose Compare with an older build (a previous prepared build folder) or Compare with a saved release. The plugin tells you how much a player with the previous build will download, for example "Players on 1.0.0 will download … of … (… reused from what they already have)."
What the comparison shows#
| Figure | Meaning |
|---|---|
| Download | What a player with the previous build downloads. |
| Reused | What their launcher copies from files they already have, inside files that changed. |
| Unchanged | Files that did not change at all. |
| Changed, unchanged and removed files | How many files of each kind. |
| Free space needed | Extra disk space a player needs while updating: the size of the largest file that changed. |
Players only download what changed, even inside a large file. A few edited assets in a big pak usually mean a small download.
Packaging settings that make updates bigger#
Under Project settings that affect update size, the plugin reads your project's packaging settings and warns about the ones that inflate updates. In plain words:
Encrypting your assets#
When assets are encrypted, a small edit makes the whole encrypted file look different, so players download much more than what changed. Turn off Encrypt assets in Project Settings > Crypto unless you need it, or expect larger updates.
Encrypting only the pak index, or config files, adds little: those files are small.
Changing compression between releases#
Compressed content is fine. Changing the compression format, level or block size between two releases rewrites every file, and the next update becomes a full download. Pick your compression settings once and keep them.
Reordering content#
If the order of content inside your paks changes from build to build (for example after changing cooking order settings), more of each pak looks new. Keep packaging settings stable between releases.
One huge pak instead of several#
Players only download what changed either way, but while updating they need free space equal to the largest changed file. If most of your game is one file of many gigabytes, split it into several paks: turn on the packaging option that splits content into several paks in Project Settings > Packaging, and assign content with Primary Asset Labels.
Loose files#
Builds without paks give the smallest updates, but a very large number of files makes installs and checks slower for players. Fine for test builds.
Pak signing#
Signature files are rebuilt for every pak that changes. They are small, so this is usually fine.