How would you make your game check for updates at the beginning of startup, and if there are any updates, how would you make them install? Thanks in advanced

  • \$\begingroup\$ This is an extremely common thing, even for indie games. I am surprised there are no tutorials or articles on this given its popularity even among low budget games. \$\endgroup\$ – user31353 Jun 2 '13 at 19:13
  • 1
    \$\begingroup\$ Too simple for an "Answer" entry: typically the EXE you run is just a shell that runs another EXE which is the game itself, but first it calls home and asks if this is the most recent EXE (and data) and downloads if necessary. Alternately it's a shell for a demand-loaded DLL, but same concept. \$\endgroup\$ – Patrick Hughes Jun 2 '13 at 20:14
  • \$\begingroup\$ My question isn't exactly the same, they seem to be asking for a program that would help achieve this. I am asking what code I would use to have it as part of my game to check for updates \$\endgroup\$ – TheQuantumBros Jun 2 '13 at 22:48

Seeing as this is XNA, the simplest method is probably to use ClickOnce. This has built-in support for managing updates for you.

See the tutorial on MSDN, which points out where in the ClickOnce wizard you can set up automatic updates (you can also modify these settings in the project properties later on).


One simple method is to provide a 'launcher' that checks for an update using the HTTP protocol, downloads it with HTTP, installs it and then starts the game.

1) User starts the game (which is actually the launcher). The launcher downloads and parses some kind of manifest file that details the available updates. The manifest may look something like this pseudo XML:

<update version="2" from="1">
<update version="3" from="2">
<update version="3" from="1">

The manifest has enough information for the launcher to update the game from it's current version to the latest version. In this example the latest update is version 3 and there are files to download to update the game from version 1 and version 2 installs. The above XML also tells the launcher that if the user has version 1 it can update immediately to version 3 by downloading the correct update archive.

If you are going to publish frequent updates, you will definitely want to write some tools to generate the manifest and archives automatically.

2) If the currently installed version is older than the latest update then download the required update over HTTP. Show a progress bar or something to keep the user occupied! Once the download has completed, decompress the files to where they should be. The update files are simply archives with all the files that have changed between versions. Decompress them over any existing files.

3) Launch the game.

If your aim is to publish on Steam, the App Store or Google Play then most of this is handled for you.

This is a very basic framework, you might also consider:

  • Allowing the user to skip updating.
  • Only checking for updates every N hours or days.
  • Check that the user has enough drive capacity to install the update BEFORE downloading it.
  • Check that the user has permissions to modify existing files or create new ones where the game is installed.
  • Pre and post update scripts or executables. i.e. The latest update changes the save file format. The pre-update script backs up the existing saves and the post-update script converts the old saves to the new format. This could be implemented in the game engine itself.
  • If the update is content only and doesn't modify the game's executable file, the game engine itself might handle the the decompressing during startup.
  • Instead of the update archives containing every file that has been modified or added, you could instead use a diff tool to create the updates and the launcher would patch the changes into the exiting files. See also Delta encoding. Depending on the files being diffed and patched, this can greatly reduce the size of the updates.
  • The update archives might themselves contain another manifest file with more detailed updating instructions that the launcher can understand.
  • A method made popular with the Quake engine was for each update to come in sequentially numbered archive files, and the engine only loaded an asset from the highest numbered archive it was found in. i.e. game01.zip and game02.zip both contained an asset called explosion.wav, but the engine would only load the (newer) explosion.wav from game02.zip. If game03.zip was later added with a newer explosion.wav file, it would be used instead.
  • Because you chose to use HTTP instead of inventing your own protocol, when your game becomes uber-popular you can benefit from a content delivery network hosting your updates.

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