All PC Games need patching, regardless of the developer’s roadmap, stance or opinion. Creating a routine to making your own game patcher is a must in this day and age. Writing out hundreds (maybe thousands) of lines of code is not cool, not to mention the constant debugging and testing that comes with creating a patcher.

Having a suitable, efficient and fast patching system for your game, ensures that your users are running the most up to date version you have assembled. The problem is, there are also numerous different ways to patch a game.

What is right and what is wrong in the world of game patching? There isn’t really a right or wrong answer when it comes to making a decision on making a patch routine, however, there are standards most developers seem to follow and we have a professional standard we want to introduce you to.

The Old-Skool method of Game Patching

Back in the ol’ days, the standard method of patching was to either download the latest installer (and overwrite the files), then updating registry settings or INI file settings, or maybe even just a local file containing a list of installed files.

The user would download the install.exe then run it and just do a complete overwrite on the install. This was okay, this was the standard. There are however, a few flaws with this method.

The first being, sometimes (most times) the installer would not remove redundant files, in which case the users computer ended up cluttered with files that would never be used again, this is uncool. The second reason being, it meant the user had to re-download the entire installer just to patch maybe 1-2 files. If your total install is say, 500MB, this is a lot of bandwidth just to update 1-2 files on the users computer, again, very uncool. Not only is this costly in bandwidth but it’s not cool for the user to have to sit through a download which may take up to an hour just to patch over 1-2 files.

The new-skool method of game patching

So what’s the modern standard of game patching? Well, again this is entirely developed-based. Each developer or development studio has their own opinions and concocts their own system to designing and developing a game patching method for their games.

With the advancement of DNS servers and fast-caching nodes such as CloudFlare enabling you to host your files on a huge number of servers around the world, allowing the user to download from the server that is closest to them and with the fact that the Internet is widely available globally with speeds increasing literally everywhere, the trendiest way is to provide a delivery system that can patch only the files that need to be patched.

So if your game is 500MB in total file size including all the folders, data, graphics and sound and you update say 2 images at 128kb, then surely the user doesn’t need to download and overwrite the whole 500MB again just to overwrite 2 image files at 128kb, you simply just download the 2 images at 128kb and patch just them.

Patching with Windows Accounts

Post-Windows XP, Microsoft introduced a new system that allowed for Standard user accounts and Administration accounts on PC’s. The system was introduced so app/games (executables) could choose a model, to be invoked by a Standard user which grants both the game and the user to low-level access to the computer. An administrator account is elevated privileges that allow for high-end access, such as writing to Program Files and other typical read-only directories on the computer.

The system is great, it allows a basic layer of security for the operating system and the computer. It can however make the development of a patching system more cumbersome in that there are regulations and roadblocks that crop up due to this secure layer that Microsoft developed. For example, the executable that is copying (and overwriting) the files to be patched, can be denied access and sometimes, you cannot even pull an error back to catch this. It can just be silent, but it’s Windows simply just not allowing the game to patch due to low-level access.

Not only does your patcher need to have elevated rights for the execution level, but also enforced within the Manifest. A typical MANIFEST will look like this

<?xmlversion=“1.0“encoding=“UTF-8“standalone=“yes“?>
<assemblyxmlns=“urn:schemas-microsoft-com:asm.v1“manifestVersion=“1.0“>
<trustInfoxmlns=“urn:schemas-microsoft-com:asm.v3“>
<security>
<requestedPrivileges>
<requestedExecutionLevellevel=“requireAdministrator“uiAccess=“true“/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

This will either need to accompany the executable (same directory) or will have to be embedded into the executable file itself.

Game Patching with Checksums

So, how do you know if a file on the users computer differs from a file that’s been released as patched? Checksums. A checksum is a unique string that is generated from a unique set of data and hashed to make it even more unique. You would then compare the hash from the patched file to the hash of the file located on the users computer.

Patching via checksums is most certainly the standard today, it not only provides a unique way to identify files that differ, but it also provides a more secure method of file comparison as the hash has to be unique and unique only to your development, or game, or app.

You can hash with literally any level of security such as SHA-2, but you can also use just the basic form of MD5. An MD5 signature, provided it is salted.

So how do you salt an MD5 signature? Well there are two ways, statically and dynamically. So you could use “justthislittleformedstring” to add on to the end of the already-existing checksum string, or you could generate something that is dynamic (and random) to go with it. The latter, is a tad overkill for game patching. It’s not really required to be super-stringent on security because afterall, this is your game development, it’s already unique and it makes no sense for someone to do anything other with the file, than install it.

MD5 provides a basic layer of encryption, but it also provides a unique signature per file depending on at least one of the factors making up the string to be hashed, is dynamic. With file patching or game patches, you would usually take the filesize (in bytes) for the longest filesize integer plus the filename plus the last modified date of the file.

This will give you a unique MD5 signature, enough for patching files, even if you had over 12,000 files, it’s still ample.

The Advanced Online Patching System

The AOPS (Advanced Online Patching System) was designed and built into Game Launcher Creator V2 Pro, to allow game developers to skip all the required programming and coding to design and develop their own game patching system.

GLC V2 Pro contains an already developed and customizable system that will generate a patching routine exclusively and uniquely for your game developments. You simply fill out the method of game patching and just release the launcher with your game.

Your users (players) can now simply click a customized button in your launcher and it will start the patching process. The AOPS system will first check for an update, if there is one available, it will prompt the user and they can begin patching their game up to the latest version.

It’s quite customizable and there are many switches available for the AOPS patching system, such as suppressing the prompt and just auto-patching and even performing an auto-update check. It will literally save you hours designing, developing and testing your own coded patching system as well as debugging any issues that may crop up.

The AOPS patching system also includes a debugging log system, which means if you users ever experience difficulties or errors, you can debug immediately by looking at the debug log. It’s a fool-proof, highly advanced patching system that you can setup in literally 2 minutes.

We highly recommend you check out the AOPS system and if you don’t have it yet, purchase GLC V2 Dev edition today.