I'm some days away from releasing a major upgrade and one of the features that is now included is a self-updating mechanism. When I say self-updating I mean that in the launcher screen (a small window that pops up before the main game launches that let's you set visual preferences and similar) there is a nice friendly button named "Update". Press it, wait for a few seconds while the app downloads new data, and presto! you are running the latest version. If you update your game regularly this is a major benefit to your players. My main goals were (in order of importance): 1. Use freely available components and only write "application" code 2. Can update running executable 3. Portable (Win32/OSX/Linux) 4. Optimized network transport layer 5. Easy to manage releases and server The system I'll describe fits all goals. In the end I wrote about 300 lines of code in the game and managed to avoid all server coding. Of that about 100 lines is for swapping executables, quite straightforward but tedious. The major design features are: - The library used for transport and version management is Subversion, the open source version control system created to replace CVS. The application uses the svn_client.h interface and just 2 functions (svn_revert and svn_update). The library is compiled with support for only standard WebDAV without encryption as transport. The server runs a standard Apache2/WebDAV/SVN server on a Debian box. - A lot of things result from using SVN. There are excellent tools for managing a repository and it's portable across all platforms. SVN is also free (as in speech and beer). The best part is that SVN is optimized for minimizing network load. All the files are stored separately and when you update only changes are propagated over the wire. You also get all future optimizations for free. - To facilitate updating of the running program all binary files (*.exe and *.dll) are placed in a "binary_win32" folder (under version control) with local copies in the installation directory. The update sequence is as follows ("\" is the installation root): 1. \simulation.exe updates the "\binary_win32" folder 2. \simulation.exe launches "\binary_win32\simulation.exe -hotcopy TASKID" and quits 3. \binary_win32\simulation.exe waits for TASKID ("\simulation.exe") to quit 4. \binary_win32\simulation.exe copies all *.exe and *.dll files from \binary_win32 to \ 5. \binary_win32\simulation.exe launches "\simulation.exe -postupdate TASKID" and quits 6. \simulation.exe waits for TASKID ("\binary_win32\simulation.exe") to quit - Just packing up a checked out copy would be wasteful as SVN stores pristine copies of all files in the .svn directory ("text-base"). To get around this the installer is built only using the contents of the .svn directories without the "normal" files. After this structure is unpacked on the players machine (resulting in en empty directory tree with a lot of hidden .svn directories) the installer runs svn_revert on the repository directories thus "reverting" the whole directory tree to the pristine copies stored in the .svn directories. All in all composing the installer from a live working copy adds just a few 10's of KB. I'm most happy about the fact that everything is based on proven tools that I use daily anyway and that the amount of code to write was minimal. I hope you find this technique useful. Take care!