(Re-added some old questions raised) |
m (removing category) |
||
| (15 intermediate revisions by 5 users not shown) | |||
| Line 1: | Line 1: | ||
:''This article is about the technical aspects of the updating system. See [[how to release an update]] for the steps currently required to release an update.'' | |||
== Introduction == | |||
The Mana World is a constantly expanding game, with new features, maps and other game media being added all the time. This constant addition requires some way to distribute new material. Our update system has been designed with the following requirements: | |||
* '''Low data redundancy''' - Files can be updated individually while not causing re-downloading of other data. | |||
* '''Easy and independent of release cycle''' - Allowing updates to be released fast and frequently. | |||
* | * '''Compatible''' - Updates can also keep older clients up to date, allowing them to keep playing without needing to update. Provided that any of the new data doesn't need new client features. | ||
* '''Multiple worlds''' - The updates that the client downloads are server dependent, so different worlds can be run on different servers. ''(Not implemented yet, 0.1.0 feature)'' | |||
* | |||
* | |||
== Update process == | == Update process == | ||
| Line 28: | Line 22: | ||
The client will check whether all the listed files are present in its data directory, and attempt to download any missing ones. Once downloaded, it will put each archive in the virtual file system provided by PhysFS. The archives will be searched bottom to top so that any file will be loaded from the last archive that provided it. This allows us to patch big data archives with a small archive that contains just the modified files. | The client will check whether all the listed files are present in its data directory, and attempt to download any missing ones. Once downloaded, it will put each archive in the virtual file system provided by PhysFS. The archives will be searched bottom to top so that any file will be loaded from the last archive that provided it. This allows us to patch big data archives with a small archive that contains just the modified files. | ||
Any files present in the data directory that are not in the list can be considered to be old, and could be cleaned up by the user with the | Any files present in the data directory that are not in the list can be considered to be old, and could be cleaned up by the user. Updates will be downloaded to a directory writable by the user. On Windows it is assumed the user has write access to <code>./updates</code> while on UNIX-like systems <code>~/.tmw/updates</code> is used. | ||
:''I think updates should be downloaded to subdirectories depending on the server, and that as little default data should come with the client as possible. An example directory used to store the server data would be <code>~/.tmw/data/testing.themanaworld.org</code>.'' --[[User:Bjørn|Bjørn]] 20:39, 24 December 2005 (CET) | |||
:''About the update window and news window: As the users really like to KNOW what is downloaded to their computer, (and that something for the game is downloaded btw), the news window should be one thing, and then an update button should appear if there are updates that are to be downloaded, and are not downloaded already.<br>Clicking on it would then show another window (that one listing the available updates) and with three buttons: Close, Update (if there is a selection in the list) and Update all (if there are still updates). And a scroll bar to show the progresses made. --[[User:Bertram|Bertram]] | |||
::''It would be a good idea not to start downloading immediately, but I think the news and update windows should remain integrated.'' --[[User:Bjørn|Bjørn]] 23:14, 18 September 2006 (CEST) | |||
== Update packages based on data structure == | |||
The <code>data</code> directory present in Subversion is no longer entirely included in releases. The following listing describes which parts are only released via dynamic updates, and to which subgroup they belong. | |||
<pre> | <pre> | ||
equipment.xml database | |||
items.xml database | |||
monsters.xml database | |||
graphics/images/minimap_*.png minimaps | |||
graphics/images/ambient/*.png ambient | |||
graphics/items/ items | |||
graphics/particles/* particles | |||
graphics/sprites/* sprites | |||
maps/ maps | |||
sfx/ sounds | |||
</pre> | </pre> | ||
The naming convention is <code><subgroup>-<revision>.zip</code> for a package containing all the data at a certain Subversion revision, and <code>update-<start>-<end>.zip</code> for a package containing the material that changed or got added between the start revision and the end revision. | |||
== Future update distribution == | |||
== | |||
Updates must be distributed fast and effectively, providing a decent throughput even when the update server is under a high load. The Mana World development team has decided that the [http://www.bittorrent.com BitTorrent] protocol will be utilised for update distribution. BitTorrent is a distributed peer-to-peer protocol which utilises the bandwidth of all users. For more information about [http://www.bittorrent.com BitTorrent], see the [http://www.bittorrent.com/introduction.html BitTorrent Introduction]. | Updates must be distributed fast and effectively, providing a decent throughput even when the update server is under a high load. The Mana World development team has decided that the [http://www.bittorrent.com BitTorrent] protocol will be utilised for update distribution. BitTorrent is a distributed peer-to-peer protocol which utilises the bandwidth of all users. For more information about [http://www.bittorrent.com BitTorrent], see the [http://www.bittorrent.com/introduction.html BitTorrent Introduction]. | ||
| Line 53: | Line 59: | ||
* [http://libtorrent.rakshasa.no/ libTorrent] - C++ | * [http://libtorrent.rakshasa.no/ libTorrent] - C++ | ||
Yeah I know we already | Yeah I know we already chosen for BitTorrent, anyway we shouldn't discard HTTP/FTP both because some people don't want to be forced to share their bandwidth or if they're having problems. Someone also asked for the possibility to stop sharing patches (in case updater is built-in). A noticeable example is WoW updater which both allows for bitTorrent or HTTP downloads. And the patch sharing is limited to the time you download the patch (until you don't press "Play game!" I guess). A deeper evaluation of band usage and lag problems should be provided. --[[User:ElvenProgrammer|ElvenProgrammer]] 02:08, 4 Jul 2005 (PDT) | ||
Because both libbt and libtorrent still seem immature and have annoying dependencies, I would suggest to hold off from BitTorrent for now and use [http://curl.haxx.se/libcurl/ libcurl] to retrieve the updated data files through HTTP or FTP. --[[User:Bjørn|Bjørn]] 12:06, 4 Jul 2005 (PDT) | Because both libbt and libtorrent still seem immature and have annoying dependencies, I would suggest to hold off from BitTorrent for now and use [http://curl.haxx.se/libcurl/ libcurl] to retrieve the updated data files through HTTP or FTP. --[[User:Bjørn|Bjørn]] 12:06, 4 Jul 2005 (PDT) | ||
| Line 66: | Line 72: | ||
== Questions == | == Questions == | ||
=== What about updating the binary? === | |||
Updating the binary is a very operating system dependent operation. On Windows this will likely need to be done using a separate executable or some re-launch trick and on Linux it is not reasonable to assume anything about the versions of installed libraries. On both Linux and Mac the rights of the current user will likely also be insufficient to update the software. | Updating the binary is a very operating system dependent operation. On Windows this will likely need to be done using a separate executable or some re-launch trick and on Linux it is not reasonable to assume anything about the versions of installed libraries. On both Linux and Mac the rights of the current user will likely also be insufficient to update the software. | ||
| Line 72: | Line 78: | ||
It is much more important to simply decouple client releases and data updates, so that client updates occur infrequently and can be handled in a convenient way on each type of operating system. This will also allow for a better compatibility, so that the game may be played with older clients until an update for a specific operating system is available. On Linux for example, using the existing package management system of the distribution is prefered, where it would be nice if we could even fit into a lengthy release cycle of for example [http://www.ubuntulinux.org/ Ubuntu]. | It is much more important to simply decouple client releases and data updates, so that client updates occur infrequently and can be handled in a convenient way on each type of operating system. This will also allow for a better compatibility, so that the game may be played with older clients until an update for a specific operating system is available. On Linux for example, using the existing package management system of the distribution is prefered, where it would be nice if we could even fit into a lengthy release cycle of for example [http://www.ubuntulinux.org/ Ubuntu]. | ||
=== What if we versioned all the datafiles separately? === | |||
Too tedious and also unnecessary. When using archives, all the client needs is the list of files it should have, a way to retrieve them and the order in which they should be loaded. A file should either be loaded or it should not be loaded, and in the latter it could be removed instead. It may be better to leave the cleanup to the user though, and just provide a one-click solution. | |||
=== What about downloading updates dependent on the client version? === | |||
A server will only assume a minimum client version (which will be checked), and ideally the game data that is downloaded is independent of this. The client version also shouldn't be used to determine whether certain updates are outdated, since contrary to what we're doing now, the idea is to stop distributing most of the game data with the client in the future. | |||
=== What about including the protocol in the list of required updates? === | |||
It is preferred that the protocol used to transfer the files is defined elsewhere, and it could even be a client option (for example mirror selection, or choosing downloading by torrent). | |||
Latest revision as of 07:04, 11 March 2015
- This article is about the technical aspects of the updating system. See how to release an update for the steps currently required to release an update.
Introduction
The Mana World is a constantly expanding game, with new features, maps and other game media being added all the time. This constant addition requires some way to distribute new material. Our update system has been designed with the following requirements:
- Low data redundancy - Files can be updated individually while not causing re-downloading of other data.
- Easy and independent of release cycle - Allowing updates to be released fast and frequently.
- Compatible - Updates can also keep older clients up to date, allowing them to keep playing without needing to update. Provided that any of the new data doesn't need new client features.
- Multiple worlds - The updates that the client downloads are server dependent, so different worlds can be run on different servers. (Not implemented yet, 0.1.0 feature)
Update process
Updates come in compressed archives (.zip files). They are easy to create and allow individual files to be read directly from them (we use PhysFS for this). Initially, the client will retrieve an ordered list of archives that it should load, for example:
tmw-base-1.0.zip tmw-base-patch-1.1.zip tmw-tonori-region-1.0.zip
The client will check whether all the listed files are present in its data directory, and attempt to download any missing ones. Once downloaded, it will put each archive in the virtual file system provided by PhysFS. The archives will be searched bottom to top so that any file will be loaded from the last archive that provided it. This allows us to patch big data archives with a small archive that contains just the modified files.
Any files present in the data directory that are not in the list can be considered to be old, and could be cleaned up by the user. Updates will be downloaded to a directory writable by the user. On Windows it is assumed the user has write access to ./updates while on UNIX-like systems ~/.tmw/updates is used.
- I think updates should be downloaded to subdirectories depending on the server, and that as little default data should come with the client as possible. An example directory used to store the server data would be
~/.tmw/data/testing.themanaworld.org. --Bjørn 20:39, 24 December 2005 (CET)
- About the update window and news window: As the users really like to KNOW what is downloaded to their computer, (and that something for the game is downloaded btw), the news window should be one thing, and then an update button should appear if there are updates that are to be downloaded, and are not downloaded already.
Clicking on it would then show another window (that one listing the available updates) and with three buttons: Close, Update (if there is a selection in the list) and Update all (if there are still updates). And a scroll bar to show the progresses made. --Bertram
- It would be a good idea not to start downloading immediately, but I think the news and update windows should remain integrated. --Bjørn 23:14, 18 September 2006 (CEST)
Update packages based on data structure
The data directory present in Subversion is no longer entirely included in releases. The following listing describes which parts are only released via dynamic updates, and to which subgroup they belong.
equipment.xml database items.xml database monsters.xml database graphics/images/minimap_*.png minimaps graphics/images/ambient/*.png ambient graphics/items/ items graphics/particles/* particles graphics/sprites/* sprites maps/ maps sfx/ sounds
The naming convention is <subgroup>-<revision>.zip for a package containing all the data at a certain Subversion revision, and update-<start>-<end>.zip for a package containing the material that changed or got added between the start revision and the end revision.
Future update distribution
Updates must be distributed fast and effectively, providing a decent throughput even when the update server is under a high load. The Mana World development team has decided that the BitTorrent protocol will be utilised for update distribution. BitTorrent is a distributed peer-to-peer protocol which utilises the bandwidth of all users. For more information about BitTorrent, see the BitTorrent Introduction.
To easily utilize to the BitTorrent protocol, one of the following libraries can be used:
- libbt - C
- libtorrent - C++
- libTorrent - C++
Yeah I know we already chosen for BitTorrent, anyway we shouldn't discard HTTP/FTP both because some people don't want to be forced to share their bandwidth or if they're having problems. Someone also asked for the possibility to stop sharing patches (in case updater is built-in). A noticeable example is WoW updater which both allows for bitTorrent or HTTP downloads. And the patch sharing is limited to the time you download the patch (until you don't press "Play game!" I guess). A deeper evaluation of band usage and lag problems should be provided. --ElvenProgrammer 02:08, 4 Jul 2005 (PDT)
Because both libbt and libtorrent still seem immature and have annoying dependencies, I would suggest to hold off from BitTorrent for now and use libcurl to retrieve the updated data files through HTTP or FTP. --Bjørn 12:06, 4 Jul 2005 (PDT)
- I agree, libcurl is at least used by libbt so if we're going to use it, it will be required anyway. I'd like also to say that libcurl it's really easy and could help us to create the HTTP/FTP updater in no time.--ElvenProgrammer 12:55, 4 Jul 2005 (PDT)
- "Q: Is anyone got it work under windows? (maybe any plan on porting?) A: Haven't heard of anyone doing so and i don't really care about the win32 platform and its lack of posix support. Unless someone pays me it'll propably not happen. ;)"
- Just to let you notice windows is not supported. --ElvenProgrammer 08:39, 20 Sep 2005 (CEST)
Questions
What about updating the binary?
Updating the binary is a very operating system dependent operation. On Windows this will likely need to be done using a separate executable or some re-launch trick and on Linux it is not reasonable to assume anything about the versions of installed libraries. On both Linux and Mac the rights of the current user will likely also be insufficient to update the software.
It is much more important to simply decouple client releases and data updates, so that client updates occur infrequently and can be handled in a convenient way on each type of operating system. This will also allow for a better compatibility, so that the game may be played with older clients until an update for a specific operating system is available. On Linux for example, using the existing package management system of the distribution is prefered, where it would be nice if we could even fit into a lengthy release cycle of for example Ubuntu.
What if we versioned all the datafiles separately?
Too tedious and also unnecessary. When using archives, all the client needs is the list of files it should have, a way to retrieve them and the order in which they should be loaded. A file should either be loaded or it should not be loaded, and in the latter it could be removed instead. It may be better to leave the cleanup to the user though, and just provide a one-click solution.
What about downloading updates dependent on the client version?
A server will only assume a minimum client version (which will be checked), and ideally the game data that is downloaded is independent of this. The client version also shouldn't be used to determine whether certain updates are outdated, since contrary to what we're doing now, the idea is to stop distributing most of the game data with the client in the future.
What about including the protocol in the list of required updates?
It is preferred that the protocol used to transfer the files is defined elsewhere, and it could even be a client option (for example mirror selection, or choosing downloading by torrent).
