Updater

Newbie & Debugging Questions
#1

Hello,
I believe a few of you know the problem that they wrote a game, and after they’ve finished and released it it’s the time for the first big update/patch. Now it would interest me how you do these updates. Do you post a new version on your website? Do you only update your applet (if you have one)? Or do you perhaps have written an updater for your client, that automatically checks for updates?

What interests me the most, is the last one, the updater software, how would you write one if you haven’t? Or if you have one how did you write it? Do you use an FTP-Server with the new Fileversions? Or did you write your own Fileserver with its own Protocol?

Many Greetings
biro

#2

What I tend to do (I don’t know if this is the best way for now) is have my desktop game periodically check for an update from either a server I have running, or more simply, a hidden text file on my web site. If there is a new update, I can either download it automatically or open the browser to the download page.

#3

Hi,
thanks for your answer, it looks like you’re the only one that thinks about using an Update software for his/her game^^.
Now to your answer:
I believe the problematic part is the download part. I wouldn’t open a broswer page, because for me that looks kind of unproffesional, so my software should be able to download the update too. The problem is, how do you get the file from the server to your client? I have a few ideas about that, one is using an FTP Server with subfolders that are namened after the programmversions, so the client must only look for the right subfolder, and than needs to download everything inside it. If you use an FTP Server I think it’s the best approach to use one of the few FTP Libarys for java, which have already implemented the FTP protocoll.
More interesting is, at leat I think so, to write your own protocoll and Update-SERVER. I already tried to play a little bit with the filetransfer in java, it doesn’t look so hard, you read the files with an InputStream, then you send it to your client through an OutputStream, sounds very easy, but strangely if I send the file to another PC I often have a package loss… But if I make the filetransfer PC-Intern it works fine…

how would you solve the problem to get the Files from the Server to the client?

Many Greetings
biro

#4

You don’t really need an FTP server. All you need is that file available at least on a web server and when your game checks for an update, it gets the version number and uses InputStream to read in the file. For example, your game asks the game server for any new updates, it returns 1.1, so you would do:


double version = //read in new version from server
FileInputStream fis = new FileInputStream(new File(new URI("http://www.website.com/repo/version"+version+"/Game.jar")));

FileOutputStream fos = new FileOutputStream("Game.jar");

int i;
while((i = fis.read()) != -1)
    fos.write(i);

fos.close();
fis.close();
#5

Also it’s probably best to wrap your streams in BufferedInputStreams/BufferedOutputStreams, and read/write more than 1 byte at a time, especially over teh interwebs.

#6

Yes I just wanted to make it simplistic. You’ve got the entire java.io package to play with :wink:
But BIS and BOS aren’t really necessary when you’ve got similar methods in FIS and FOS that use arrays.


...

//read and write 4KB of data at a time
while(fis.available() > 0) {
    byte b[] = new byte[4096];
    int read = fis.read(b);
    fos.write(b,0,read);
}

...
#7

Why bother with version files and having different versions uploaded? Just have a single archive at a known url that’s always updated to the latest version.

Then use HTTP and eTags to only download it when it changes.

Also, if you are going to store the version seperately, you really don’t want to use a double for it.

#8

I’ve toyed around with making a launcher app like Minecraft does, it’s pretty easy to implement as long as your launcher doesn’t need to change. The reason for doing this rather than http tags is that you can have the launcher force version parity, which is really nice as it cuts down on supporting older versions.

Basically your launcher will automatically contact your site to see if it has the most recent version, and if it doesn’t it downloads it. Pretty easy. I would absolutely advise the use of zips or other compressed formats rather than downloading individual files, as it will be much easier on the server and faster to download. However, you then need to either have users redownload every single game asset (if you’re updating the same zip), or you need to write code to automatically prioritize later zips you get. Fortunately because you’re using Java you can just add the most recent zips at the end of the classpath and it will pull those assets last.

#9

You can write your launcher to do that just fine with http+etags. Why make things more complicated than they need to be?

#10

Yeah, if you don’t want a repository of all previous version then 1 copy is all you need. And my bad for using double :persecutioncomplex:

New code:


//check for new version, here I used text file on server.
Scanner scanner = new Scanner(new File(new URI("http://www.website.com/game/version.txt")));
if(scanner.nextDouble() > this.version) {
    scanner.close();
    
    FileInputStream fis = new FileInputStream(new File(new URI("http://www.website.com/game/Game.jar")));
     
    FileOutputStream fos = new FileOutputStream("Game.jar");
     
    //read and write 4KB of data at a time
    while(fis.available() > 0) {
        byte b[] = new byte[4096];
        int read = fis.read(b);
        fos.write(b,0,read);
    }
     
    fos.close();
    fis.close();
}
#11

That’s if you’re running it from an applet or off a website, but if you have a downloaded app you can’t do that - the user still would need to redownload the update. Unless you have a launcher. For a purely online experience I definitely wouldn’t do that.

#12

I think you’re missing my point completely. I suspect you’re confusing html tags with http etags because nothing you’re saying makes any sense.

#13

Even a desktop app could download the its own new version, install it, and restart it.
All an applet needs to do is refresh the page (and have the parameter “separate_jvm” set to true) to update to the new version.

#14

Perhaps so, but I don’t think so. As I understand it, and eTag is a way more or less of versioning a web resource.

Here is what I am thinking:

  • You download App X.
  • You run App X.
  • App X determines it is out of date.
  • App X downloads App X v2.
  • App X must restart so that it can run v2.

Regardless of eTags, how can you possibly avoid that situation without a launcher app that does this:

  • You download App X Launcher.
  • You run App X Launcher.
  • App X Launcher determines that App X is out of date.
  • App X Launcher downloads App X v2.
  • App X Launcher seamlessly launches directly into App X v2.

Am I missing something? The problem seems clear to me.

#15

There is always webstart, which has an updater built in.

Endolf

#16

@endolf
Yes but webstart is very glitchy and unreliable.

@Eli
What’s the difference between “restart” and “seamlessly”? In both situations you still need to close the current instance and run the new version. The best way is to do “Runtime.exec(“java -jar MyGame.jar”)” then “System.exit(0)”.

#17

You could try GetDown, its suppose to be a better webstart.

#18

LWJGL has its own Webstart that I have heard is better than GetDown :wink:

#19

Yes, on PC you run two instances of the same app, but on Mac OS X that call would do nothing unless you rename v2 of the app, which IMO is a bad user experience. By seamlessly I mean you don’t actually see anything quit, because the launcher basically just calls a method within the new JAR you downloaded. Just think Minecraft, which is whose behavior I emulated when I made a launcher, anyway…

#20

Ah, I didn’t know about the Mac OS X thing. Another reason why Mac sucks :smiley: