Game Development Community

Game Patcher

by John Spivey · in General Discussion · 02/09/2006 (7:41 am) · 29 replies

Today I have been looking for 3rd party software providers that have a simple "patcher" as we have all come to love in those MMO's we play so much. It needs to check to see if the end user has the same files as the client. So if i accidentally corrupt my .mis file all i need do is delete it. The patcher will see that its gone then replace it from the patch server.

I thought this would be an easy thing to find but as it turns out most patching software talks more about network security...blah blah blah. So I am not sure if these aplications would work for what I am trying to do here.

Simply put out team is making an MMO and we need to get a patcher program in there and running. Does anyone here have any idea where I might find an application like this?

Thanks for any help you can give.
Page «Previous 1 2
#1
02/09/2006 (7:56 am)
Try rsync:

http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=2020
#2
02/09/2006 (9:13 am)
This is pretty easily done in TGE, even in script.
#3
02/09/2006 (9:52 am)
Thanks I really apreciate the input. But it says that its for Unix systems. Need windows based program.
#4
02/09/2006 (10:23 am)
There are windows based ports of the same tools, look on the web.

If all you do is delete and replace the files changed, then doing this in script is very effective.
#5
02/09/2006 (11:01 am)
Another Option

I found this. Gonna run it by team. Thanks for the information again guys. Was most helpfull.
#6
02/09/2006 (3:53 pm)
Is it really so easy? I've been looking for a solution for this too, there's almost no info or tutorials on doing it. I think TDN has a space open for this...
#7
02/09/2006 (4:00 pm)
1. parse local directories and cull information regarding what files exist where and what their timestamp is.
2. parse server log for its list.
3. version as necessary.

That's an extremely simple version, but it will do the grunt work.
#8
02/09/2006 (7:04 pm)
Greetings!

David's idea is a good one. Another method to compare files is to build a hash for each file (such as MD5) on the client and download a complete file/hash list from the server. Compare the two and you'll know what you need to retrieve. The advantage is that you're comparing the file's contents rather than the time stamp -- which may be modified by both innocent and nefarious methods.

I believe this is how Josh does it with Minions of Mirth. I also like his idea of using Subversion as the file repository. :o)

- LightWave Dave
#9
02/09/2006 (7:17 pm)
That's the more complex (and MUCH better) way. That's how we deal with updates in our computer labs here at work. We started with the basic idea that I proposed, but moving files between servers can sometimes play with the timestamps. It was quick and dirty, but not that effective. David's solution was what we ended up working with. :-)
#10
02/09/2006 (7:20 pm)
David Blake. Could you please be more specific as to what you are refering to? Rsync not the way to go?
#11
02/11/2006 (6:42 pm)
Rsync would sure prove to be useful for larger files John. But for smaller files, checking CRC on the file and replacing it works as well.
#12
02/11/2006 (7:38 pm)
I would lean towards rsync, even if this IS possible from script. Using rsync provides you with several benefits:
1) Block-level checksumming means that only the *parts* of the file that have changed are transferred.
2) Compression.
3) Never having to worry about whether or not there's a bug in the code that downloads updates.
4) Not having to worry too much about whether your download solution will need to be revamped because you made an architectural decision that moved you from say, many small files to a few large files*.
5) All use-cases are handled properly: Add file, remove file, update file, add directory, remove directory, change file permissions, change directory permissions (relevant on MacOS X).

* - This one can't be eliminated entirely. Note that World of WarCraft uses a peer-to-peer system for downloads to minimize bandwidth consumption and server load. If your game gets REALLY big, you might find yourself needing such a solution too.

-JF
#13
02/11/2006 (8:09 pm)
Josh Ritter of Prairie Games implemented an auto-patching system for Minions of Mirth using Subversion. You might want to check out his post-mortem at
www.garagegames.com/mg/forums/result.thread.php?qt=37703

From his post:

> Multiple SHA checksums are then generated for every file and the results are stored in a manifest.zip file.
> The client keeps a cache of local SHA checksums and connects to the game's Subversion repository which
> is being served over SSL. It requests the manfest.zip and compares the SHA checksums with the local ones.
> The client then downloads any missing or changed files, verifies them once downloaded, requests the user
> to restart the application, and then copies the new files into the install. It's all very anal and has performed
> beautifully.

You might want to be careful if you do auto-updating that you don't delete files the user may have placed in the directory. As a game developer, you arguably only have permission from the user to update files or delete files that are part of your game. If the user decides to put her term paper in your game directory and you delete it, she won't be very pleased with you!
#14
02/12/2006 (4:14 pm)
Subversion certainly isn't a BAD way to go, but it strikes me as a bit heavy-weight compared to rsync. One should be able to achieve the safety of not deleting files accidentally by doing something like "--exclude '*' --include 'x' --include 'y' ..." -- I.E. exclude everything, then specifically include the files from your game.

-JF
#15
02/14/2006 (11:13 am)
I believe rsync can be configured to not delete files in the destination directory. Rsync might work fine, but it may not be the solution for everyone. One cool thing about rsync, though, is the ability to set up a public "rsync server" (see for example www.kernel.org, where you can download the linux kernel via rsync), and allow your clients to dynamically connect to your server for the updated files. I'm not sure what it would take to prevent world+dog from downloading your files, though.
#16
02/14/2006 (12:47 pm)
By default rsync wont delete files in the destination directory, but the solution I was proposing was meant as a way of allowing you to turn that on (for purposes of allowing you to remove files from your game in updates and leave garbage on your users' machines) but not harm the data of users that are silly enough to be putting their shopping lists in your game's directory.

I haven't looked at public rsync much, but one option for controlling access might be to tunnel through SSH and use a public/private keypair that gets distributed with the game. Anyone who gets the game has the private key and can pretty much run wild but that keeps out casual observers.

Use of SSH for authentication also grants access rights, so you can have "demo" and "registered" privileges, ensuring that people can't just download the latest full version via rsync just because they got a keypair with the demo.

One could even use this mechanism, theoretically, as a means of helping to control piracy: Every registered user gets their own keypair. Of course that doesn't work so well for games distributed on CD, and there is the question of just how many public keys can you put in your keychain (server-side) before SSH begs for mercy.

Of course, Subversion also provides excellent access control mechanisms too. :)
#17
02/14/2006 (2:01 pm)
www.garagegames.com/blogs/49324/9799

This above looks pretty good, and its from the community. :)
#18
02/14/2006 (2:55 pm)
Chip: For those targetting only Windows that may be an excellent option, although you should be careful -- it looks like that will download the entire contents of a file that's changed. If you're bundling things into a zip archive, or have large resources, it could be an issue.
#19
02/14/2006 (10:10 pm)
That and it's based on .NET which means the end user would need the .NET runtime installed too..
#20
02/16/2006 (9:37 pm)
You might want to look into bsdiff/bspatch
http://www.daemonology.net/bsdiff/

An easy approach would be to zip up all the bsdiff's and let the client unzip and bspatch.

-Jerry
Page «Previous 1 2