next »

[Christian Knudsen]

Which brings us back full circle to showing a dialog every time it runs.

Showing a dialog every time it runs seems annoying to me. But I would like it to show a dialog when there's an update available, asking the player whether or not they want to update right now. I personally want to be asked before a program starts updating, especially if updating impacts gameplay, savegame compatibility and the like...

[Rob Lach]

Also I think have a single ".pack" file is overly complicating things and could unnecessarily roadblock development pipelines.

It'd be much easier to have a ".pack" file that has the whole package but also have the game files hosted sparsely. I gather if you're doing an update you'll only be updating one to a few files (executable, a few assets).

If you have the files hosted sparsely you could do things like just updating the placeholder art directly instead of having to rebuild a distribution pack each time.

[Rob Lach]

Which brings us back full circle to showing a dialog every time it runs.

Showing a dialog every time it runs seems annoying to me.

If you put some functionality into the loader (such as a resolution dropdown or fullscreen enabled checkbox) it would take away from that annoyance.

Games would implement those selections through arguments. What options are available could be defined in the config for the loader.

That's what we did for one of my old games: http://www.acm.uiuc.edu/gamebuilders/files/EinSetup.exe

Aside but relevant:

I actually prefer it that way. I find it odd that games nowadays take all this time to load the menus and show you studio logos just so you could goto the options, change graphics settings, and then be forced to restart and do all that loading again. Rather have something lightweight up front.

[Evan Balster]

Rob - sparse updates and game config options are nice features, but for now I think we're going for a minimal set of requirements so as to have an initial version of this operational soon.  This is especially relevant given our current approach involves rewriting the (small) program for each platform in order to achieve the best deployment schemes.  (Single files, in the case of Windows and Linux.)

And for whatever it's worth, I'd *really* rather avoid showing a dialog when the game isn't being updated.  But it may be that we can't come up with a better scheme for uninstalling.

[Rob Lach]

Yah good move. I'm just throwin' ideas out.

[Evan Balster]

Most def.  Part of the glory of this is that no matter what we end up deciding on, its source will be made available so folks can modify it freely.  :D

On an amusing note, the trivial way to deploy updates to an autoupdater that doesn't support them would be to add the new autoupdater to the game files, and have the old updater launch the new one, which in turn launches the game.

[JobLeonard]

I find it odd that games nowadays take all this time to load the menus and show you studio logos just so you could goto the options, change graphics settings, and then be forced to restart and do all that loading again. Rather have something lightweight up front.

I would just like to point out I completely agree with this. Though it doesn't apply to most indie games, since they generally boot up quite fast, and can change settings without restarting.

[technogothica]

Hi Guys,

The windows version is almost finished. But there's one last design consideration that needs to be addressed.

I've started to re-evaluate my position on using XML for the manifest file (we're calling it that now, yes?). I was originally opposed to the idea because parsing on a line-by-line basis is a lot easier. But during testing I've come across a couple of areas where the integrity of the downloaded manifest file is an issue.

The launcher uses MD5 hashes to check the integrity of all downloaded files. However, the manifest file itself cannot have such a check due to a chicken-and-egg paradox. That is, the manifest file cannot store its own checksum or MD5 hash.

During testing I've encountered the following scenarios:

1) If the TCP connection drops out half-way through the download, some of the lines may be omitted, and the launcher may incorrectly assume that all files are accounted for.

2) The web server may respond to 404 and 500 errors with a standardized error HTML page. The downloaded file is valid and complete, but not a manifest. The manifest parser will read the lines and proceed to use the garbage data as if it were actual file descriptors.

I've addressed these problems by introducing start and end tokens:

Code:

*UPDATES-BEGIN
(filename) (size) (hash) url
(filename) (size) (hash) url
(filename) (size) (hash) url
(filename) (size) (hash) url
(filename) (size) (hash) url
*UPDATES-END 

Parsing does not begin until an *UPDATES-BEGIN token is encountered. That solves the problem of identifying and rejecting garbage data. Also, if the *UPDATES-END token is not encountered before the end of the file, then the parser assumes the download was incomplete and aborts.

This works quite well in all scenarios that I have tested.

But it has occurred to me that XML is actually well suited to this scenario, because it has its own built-in integrity checks. Consider this alternative format:

Code:

<?xml version="1.0"?>

<update version="1.0">
   <file name="file1.ext" size="1234" hash="abcdef..." href="http://www.server.com/update/file1.ext"/>
   <file name="file2.ext" size="4567" hash="abcdef..." href="http://www.server.com/update/file2.ext"/>
   <file name="file3.ext" size="8901" hash="abcdef..." href="http://www.server.com/update/file3.ext"/>
</update>

Using XML may make the program a little more complex, but far more robust. Also, an XML syntax will make adding new features easier in the future.

What do you guys think?

[zamp]

You might want to make the files.xml file be generated with PHP based on the date. Let's say client has last updated 1th Jan 2011, it'll pass that to the http request and the PHP side would just fill the xml file list with only files that have been updated after the date given.

[Jase]

I'm new to this discussion, and these forums in general, but I'm very interested in this concept and will be keeping an eye on the progress

As for the manifest file format, I'm in favour of the use of standardised formats over custom ones purely from the ease-of-use point of view. Standardised formats have existing tools and libraries that people can use to generate manifests quickly and easily.

Using XML as a file format means that you get inherent document validation and the ability to use existing libraries across many different languages to generate the manifest, which is a big win in my point of view.

Just my 2c.

[Evan Balster]

XML is acceptable, given the tools to parse it are tiny and can be statically compiled.  I'm game, though on the other hand it means a little more work for devs.  However, we're going for end-user convenience more than developer convenience, so the heck with them. 

zamp - As mentioned before we're probably going to hold off on partial updates until we've got a 1.0 version running.  After all, most folks' games (around here) are under 20 MB or so.

[JobLeonard]

Well... if the format is standardised, it wouldn't be impossible to make an "update generator", would it?

[technogothica]

Well... if the format is standardised, it wouldn't be impossible to make an "update generator", would it?

Do you mean generate the manifest file? No problem. In fact, I've already written one

[Jase]

Well... if the format is standardised, it wouldn't be impossible to make an "update generator", would it?

Do you mean generate the manifest file? No problem. In fact, I've already written one

Kind of the point I was trying to make. It would be ideal if updates could be created as part of a triggered build in a CI server (CruiseControl) using existing tools. At least, that's what I would do

[technogothica]

Well... if the format is standardised, it wouldn't be impossible to make an "update generator", would it?

Do you mean generate the manifest file? No problem. In fact, I've already written one

Kind of the point I was trying to make. It would be ideal if updates could be created as part of a triggered build in a CI server (CruiseControl) using existing tools. At least, that's what I would do

I don't know anything about CI server. But the program I wrote writes output to stdout so it can be added to any scripted tool chain.

zamp's suggestion of using a PHP script is also a good one. You can either host the script on the web server or run it locally through CLI. That task is trivial to the point that it can be done easily in just about any language.

[zamp]

zamp's suggestion of using a PHP script is also a good one. You can either host the script on the web server or run it locally through CLI. That task is trivial to the point that it can be done easily in just about any language.

Yeah and if you ever need to update/check all files you could just pass 0 as the timestamp. Maybe add a checkbox "check all files" in the updater or something

[Evan Balster]

How's progress? 

[technogothica]

How's progress? 

I'm literally within hours of release of Win32 version.

But my family's Easter holiday and writing an animation editor are my current top two priorities It should be available by the end of the week.

Enjoy your Easter break!

[bluescrn]

I've only skimmed this thread... but if you're implementing an auto-updater in your project, you should consider security quite seriously when hosting your update files.

It's scary that the average PC has maybe 5-10 or so different auto-updaters running for all sorts of apps - Flash, Java, Windows Update, AV software, and many more... and any one of these could deliver malware to millions of PCs if the server was compromised...

Would be much better if all software shipped complete and mostly-bug-free...

[technogothica]

I've only skimmed this thread... but if you're implementing an auto-updater in your project, you should consider security quite seriously when hosting your update files.

Agreed. All developers, whether you use this updater or not, should learn computer security practices. Paranoia is the only option.

Indie != Lazy

Would be much better if all software shipped complete and mostly-bug-free...

Yes that would be wonderful. Ok, back to reality... 

Seriously though, this updater is not just about bug fixing. There are marketing benefits to being able to roll out new features after release. The epic and enduring popularity of Minecraft is probably partly due to the fact that new features are being added all the time.