5
\$\begingroup\$

I'm currently in the last phases of an original release for my upcoming risk game - I'm looking at making a patching system to autopatch the game.

My current concept for it is-

1: Player opens the game

2: Game checks valid serial key

3: If valid, game checks latest version

4: If newer, game prompts opening of auto patcher

5: If opened, patcher downloads version list, with all version

6: Patcher loops through list to find all newer patches and downloads all version files with links to patch data

7: Patcher checks with the website for each file, checking if downloading all patches is smaller than downloading the latest version of the file: if smaller, downloads patches; if bigger, downloads latest file

8: If smaller patch file, patcher incrementally alters file with each patch applied by each small patch file, from oldest to newest. If larger, patcher simple overwrites the file

9: Patcher asks exit/launch game so players can enjoy the game

Does this sounds like a sane way to do the patcher or will it come back and bite me later on?

\$\endgroup\$
2
  • \$\begingroup\$ I do like to use the torrent-protocol as a patcher. It is easy to implement, can run on both serverside and clientside, it verifies the files, downloads only changes* and can be faster since it can also download and share from and to other clients. A lot of game-launchers these days use torrent. (* If a big file changed you may need to download everything starting from the changed byte to the end of the file, but other than that, torrent should only download new files and maybe some bytes at the beginning and the end of old files if chunks change around) \$\endgroup\$
    – tkausl
    Feb 2 '16 at 22:44
  • \$\begingroup\$ You could move the serial key check to the server (make sure not to send unencrypted keys). That aside it looks like a good way to implement an auto patcher. For the polish: Progress bars (current file downloaded/total size, total progress) and maybe a network graph so users can estimate how long it takes them to patch. ;) \$\endgroup\$
    – Exilyth
    Feb 19 '16 at 16:05
2
\$\begingroup\$

The reasoning and processing at points 5-8 is fixed for a given pair of old version and latest version.

Therefore, do it once on the update server: the protocol can be simplified to a single exchange in which the patcher says the installed game is version X and the server sends a "recipe" with a list of the appropriate incremental patches and replacement files, which the patcher then downloads and applies.

Don't forget to allow for forced partial or total replacement of any game client files, either by user request (e.g. after removing malware or after a file system accident) or because the patcher says so (e.g. some file doesn't match the expected hash).

You also need to update the patcher itself.

\$\endgroup\$
1
  • 1
    \$\begingroup\$ I'm going to allow the user to do a full file verification from the patcher. Your suggestion was basically my original plan. Send the server the version the person has. The server then checks all files to see if downloading the whole file is smaller then all patches (say someone install the game vanilla and patches to 3.0.5 and all patches are bigger then the file, download the new file) - if not, it downloads and applies all patches in incremental order. (FileAPatch1.0.1 download apply, FileAPatch1.0.2 download apply, etc) I was actually thinking of patching the patcher this morning :) \$\endgroup\$
    – Charles
    Jan 28 '16 at 19:45
0
\$\begingroup\$

I recently developed an autopatcher/autoupdater in c#. It expects the existence of server-side metadata containing for each file its respective md5 hash as well. i don't know if you've considered this hash approach for file comparison instead of relying in a "version number". It could also solve your "incremental patch" problems.

This also means that on the server-side, you only need to keep updated a single directory with the most recent files and then recompute the server metadata to refresh all their hashes whenever you want to make public the fact that there is a new version.

Checkout my open source repository if you're interested in this approach: https://github.com/igor-ruivo/generic-auto-updater

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.