Jump to content
  • Advertisement
Sign in to follow this  
Fuji

Explain a patcher

This topic is 2991 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I decided that I should try to design a patcher for my next project, but now I'm wondering what exactly a patcher does. I know it updates, but it doesn't handle full builds so it must only edit scripts and images that are used from an external directory. Is this correct?

The patcher checks the directory for files and writes them if they aren't there. It connects to a server. I understand this much, and it could be handled fairly easily I believe.

Still, I don't want my users having to download a new client constantly. I just don't know if the patcher could handle the native files as I most likely won't use XML files to be managed by some class in my project.

Share this post


Link to post
Share on other sites
Advertisement
First of all I have no idea how patchers work, and I haven't ever made one. Ok, here's how I would design it:

1) The game stores its version in a (possibly xml) configuration file. So every time the game starts, it sends a reqeust to a server and the server replies with the most recent version. If this is not the version in the config, an update will take place.
2) The client downloads a "update description", which actualy tells the program which files need to be downloaded, from where, and where they should be placed, what should be edited etc. Most propably, you won't need to edit anything, just download/replace files.
3) The client downloads the necessary files from the server and copies them to the correct directory. It also edits the config and saves the new version id.

Now, about XML, you will need to store your version information somewhere no matter what you do, and XML would be a great way to do this. Though a simple text file with just the version id in it would be enough I guess...

If you make the patcher yourself, handling native files shouldn't be (too) difficult.

"The patcher checks the directory for files and writes them if they aren't there"
I don't get the point of this. It doesn't need to check anything, but simply download/copy/replace specific files.

Share this post


Link to post
Share on other sites
Well, the file doesn't need to be replaced every time the patcher is used. It only needs to be copied in again if the file is a file not stored on the client directory or if the file has been modified.

Share this post


Link to post
Share on other sites
There are a lot of things you can do:
1) You can just download all the files. paste them in the game folder. and go. this eats a lot of bandwidth and isn't really a "patch", but it only requires you to keep a version number around. The client sees "version 5? i'm only version 4!" and downloads everything.

2) You can trim that down. run "diff" on all the files. Any ones that are different, you only send those to the client. Now, you probably want to do this offline. On your server, you store version 4 and version 5, and run a diff on them. This makes one big list of changed files. So the client will come by and say "i'm v.4", and the server will send down the patch list and all the files, and say "when you're done, you'll be v.5"

3) You can continue to trim things down, because "patch" lets you directly apply a diff to a specific file. Since the diffs are a lot smaller than the files, you can just send all those diffs you made from option 2. On the client, you run "patch" to apply the diffs.

4) All of that works fine for a subset of files, but doing a "diff" and "patch" on a 600Mb pak file isn't always going to be the best idea. Expecially considering a zipped file will have a lot of changes in it from just a small asset change. You could end up with a several MB diff off a few KB of changes.
So, what a lot of games do is fix this in the loading process.
You load up "assests.zip" then go looking for "patchX.zip" and load all of those in numeric order. if "assests.zip" has "zombie.tga", but "patch2.zip" also has "zombie.tga" then when the game goes to actually read the files from disk: It looks at all the zip's file tables and sees "patch2.zip/zombie.tga" before it sees "assests.zip/zombie.tga" and so loads the newer file. So you're back to option 2 with this one, but it keeps you from having to actually mess with the installed files. It also has the benifit of making modding really easy, since you can just put a game mod in "mod.zip" and treat it exactly like you would patch5.zip.


Now there are some extra steps to patching.
1) In windows, you can't access a running program's .exe file. So the game launches, sees it needs to patch, then launches the patcher and quits. The patcher waits around till the game has quit so it can patch the .exe for the game.
2) You often preform the patches to temporary files, then delete the origionals and rename the temp. If something goes wrong in the middle of the patch you haven't borked their install.
3) It is really helpful to keep around a really big list of diffs. If your newest patch contains diffs from a few previous versions, then it can patch them all in order up to the newest version. This saves people a lot of trouble from having to download 100 different patches after a clean install. It also means that if you have a "patch tuesday" for an online game, someone who is a couple weeks behind only needs one patch download.

You may want to look at RakNet. Their networking library comes with a demo patch program you can incorporate into your game.

Share this post


Link to post
Share on other sites
The DirectX SDK includes an article called "Patching Game Software in Windows XP, Windows Vista, and Windows 7".

While the technical details are Windows-specific, the concepts also apply to other major operating systems since there are user- and machine-specific storage in Mac and Linux too.

Share this post


Link to post
Share on other sites
What classes should I break the patcher into then? A lot of the file handling can be handled by the API but I should still break this up some way or another.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!