Jump to content

Updating


Kazu Kun
 Share

Recommended Posts

So I have been looking around, and I don't really see anywhere where we would be able to update the game?

Are you guys going to just release a patch for the game, and then a separate copy of the full game?

Or how are you going to go about it? :)

Currently the game is in alpha stage, so we just release installers/packages of full version of 0 A.D. for each new alpha every couple of months. Those, who want to follow development more closely can use the SVN version and update it whenever they want. In the beta stage it probably will be the same and AFAIK for open-source games this model usually used after alpha/beta stage too.

Patch is something more related to commercial games world, with it's deadline rush before fixed release date, which is set be publishers without much taking into account the state of the project; then feature complete, but buggy release, complaining users/reviewers and a post release bug-fixing rush with 1.0.0.0.X patches.

In open source games there is usually no one feature complete release, but rather incremental releases with either bugfixes and new features with relative long testing phase. And release will be rather delayed than released with known bugs or untested functionality. And all bug fixes and new features even if they are done after few days after release are delayed until the next one.

We have a plan what features we want to have in 1.0 version and what features we can delay until later, so when all needed features will be ready we will switch from alpha stage to beta and work on fixing bugs/balancing etc. until the game will be ready to release, then we will release 1.0 version and theoretically there should not be any small patches right after this. We are not sure what will be next: 1.1 or 1.5 or 2.0 (i.e. how large will be changes in subsequent releases).

As far as I understood ricotz does some 'update' packages in 0ad.dev PPA (Ubuntu packages). And there was some discussion on IRC about something like build-in update system, but we don't have any steady plans about it.

Link to comment
Share on other sites

Built in update systems are cumbersome and usually platform specific. But something I that would be nice is to use jigdo or zsync to allow users to quickly update their installers. In addition, once either of those programs make a new "base", the actually updating can be cancelled, and the incomplete download can be used with BitTorrent. That combination is a very efficient way to roll out an update for alphas or releases, and requires no upstream changes.

Link to comment
Share on other sites

It's not possible to incrementally update the installer .exe files (or equivalents on other platforms) - they're compressed so their content becomes completely different whenever a single byte is changed. Any kind of patching system would need to be slightly more integrated with the post-installation game, so it can use the old installed public.zip as the base for the new version.

Link to comment
Share on other sites

It's not possible to incrementally update the installer .exe files (or equivalents on other platforms) - they're compressed so their content becomes completely different whenever a single byte is changed. Any kind of patching system would need to be slightly more integrated with the post-installation game, so it can use the old installed public.zip as the base for the new version.

see: http://zsync.moria.org.uk/

zsync has special handling for gzipped files, which enables update transfers of files which are distributed in compressed form.

Don't winzip and gzip use the same underlying compression algorithm? I'd hope that zsync's logic would work on that algorithm alone and not be hung up on the differences between *.tar and winzip's built in archive method

Link to comment
Share on other sites

@Sonarpulse

zsync (from what is said in their website) is basically just a file copy/sync program.

So, like Ykkrosh said, it can be used to integrate with an already installed game to sync any updated files from a central server.

There is a difference between an installer and an installed game. An installer contains all files to be installed (along with any metadata) in a compressed form. An installed game contained all the files in an uncompressed form. So, updating an installer does not really make sense and make require lots of unnecessary technical workarounds. That's why all patching systems target updating the installed game, as it is much much simpler.

And, gzip is one of the compression algorithms widely used. So, it can be used to compress the patched files, but the percentage of compression varies depending upon the type of file compressed.

Link to comment
Share on other sites

Don't winzip and gzip use the same underlying compression algorithm? I'd hope that zsync's logic would work on that algorithm alone and not be hung up on the differences between *.tar and winzip's built in archive method

See http://zsync.moria.org.uk/paper/ch03s02.html:

More complex formats, like zip files, would introduce too much complexity into the client, as it is unclear what one would do with the uncompressed stream corresponding to such a file: it needs the metadata from the compressed archive to be useful.

The Windows installer uses the LZMA compression algorithm (plus whatever headers NSIS adds), which is even less likely to work. The installed game's public.zip is uncompressed so something like normal rsync/zsync would work for that.

Link to comment
Share on other sites

The current approach (public.zip with no internal compression, then everything packed together and compressed with LZMA by the installer) minimises the initial download size - any other combination will make it larger. Most people will probably only play the game once, so I think it makes sense to optimise for initial download size, rather than doing a tradeoff of worse initial size for better incremental update ability. (And trying to reuse off-the-shelf tools probably wouldn't be any easier than developing a custom updater that incrementally updates the installed public.zip files, which would allow the best initial download size plus efficient updates.)

Link to comment
Share on other sites

wouldn't that mean that compressing public.zip and uncompressing the installer would hardly change the installer size? (besides the fact that LZMA is better than DEFLATE) (public zip could then be uncompressed after being downloaded so runtime speeds were not affected).

Also, are there any large compressed files within public.zip?

Link to comment
Share on other sites

(besides the fact that LZMA is better than DEFLATE)

That's a critical fact and makes a big difference :). (Also, zip compresses each file individually, while the installer compresses everything as a single chunk so it can exploit redundancy between files too.)

Also, are there any large compressed files within public.zip?

I think the main ones are lots of Ogg Vorbis files (which are hard to compress further), and lots of DDS textures (which are compressed but are easy to compress further).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...