Best Practices in Patch Management; Part 3 of 3
Learn about the best practices for online game patching to ensure the best possible experience for your gamers in this three-part series.
Our previous posts, Build a Patch Management Strategy That Works and A Better and Friendlier Approach to Game Patching, covered the challenges associated with PC and Mac game patching; the importance of an efficient patch management strategy; and how to provide players the shortest update path to get them to the most current version of the game.
In this post, we highlight game asset management and our two-step game patching strategy.
Large numbers of loose files tend to be bad performers for installing and patching asset data. Creating new files and directories has an overhead far above what is reflected by the simple byte size of the files. For this reason, a standard practice in online game development is to package asset data in some sort of archive file. A common format for these asset archives is the PAK format, though many others are also used. Asset archives are used for several other reasons as well; ranging from the obfuscation of asset data to application/game performance considerations over loose files.
Points to consider when using asset archives:
Make archive files smaller. A range around 400MB is a reasonable ceiling, but smaller is always better in this situation. If the game can work with a larger amount of smaller files as it does with fewer larger files, go smaller.
Certain assets are updated more frequently than others. Some types of assets are changed on every build. Put frequently updated assets together in the same archive file.
The archive files in which assets are contained and the order in which they are written to the archive MUST be deterministic. This ensures that from build-to-build, as few archive files change as possible.
Do not write always-changing data to each archive. For example, if the archive file format involves writing “build times” to directories, try to find some way to do without that. Non-changing archives from build-to-build are the key to efficient patch management.
Solid State Networks’ Two-Step Patching Strategy
We recommend a patching strategy with good balance between patch build times, storage space, and user experience. The idea is to build small patches around large, infrequently created “Major” release versions that act as a hub for other minor releases to update to and from. A new major release would only be created when the differences between the previous major release and all the subsequent minor releases become large enough that a new “Major” release would be more beneficial when building and applying patches.
Part 1: Build a Patch Management Strategy That Works