I absolutely agree that improvements could be made to our patching system, so here are a few more details as to why we do things how we do them. 1) It is actua

I absolutely agree that improvements could be made to our patching system, so here are a few more details as to why we do things how we do them. 1) It is actually working right now. This is the biggest deal at a startup. It's good enough. We have lots of other features to work on that will give us higher bang for our buck. 2) We wanted to be able to use an "off the shelf" CDN for distribution. It's nice to be able to farm out parts of your infrastructure you don't want to deal with. 3) We don't want to have to deal with versions in the patching system. Our patching systems first use is right in our office. The same deployment infrastructure that deploys the game to production runs in our office with every commit from a programmer or artist. When someone runs the game client (or one of the in house tools) the patching system syncs up the files to the latest version. For real production clients, there can be several versions between the last time someone ran the game client and the next time. It's easier conceptually to deal with. 4) The client is over 100,000 files. Each file is generally quite small which limits the damage of not using an actual diffing solution. The larger files like textures and audio don't diff very well anyway when artists make changes due to the nature of the data formats. 5) It was really fast to develop. It's just libcurl. Once again, we are a small startup so we have lots of things we need to be focusing on that are not our patching system. All the files are checked against hashes after download so we can correct errors. This is especially important due to the surprisingly large number of buggy caching proxies that some users seem to have in front of them. One day I would love to make the best possible patching system. Unfortunately it's just not as high on the list as so many of the other things we need to be doing!