| 1 |
-------------------- |
| 2 |
CLIENT AUTO-UPDATING |
| 3 |
-------------------- |
| 4 |
|
| 5 |
UPDATING CLIENT DATA |
| 6 |
|
| 7 |
For future clients we need to develop a way in which they can automatically |
| 8 |
update to new data like for example new images, maps or item, being and skill |
| 9 |
definitions. Here is described the sequence of actions that could implement |
| 10 |
this functionality: |
| 11 |
|
| 12 |
1. Client loads initial core data for login screen (always included with |
| 13 |
release) |
| 14 |
2. Client logs on |
| 15 |
3. Server sends client list of required packages (maybe with versions) |
| 16 |
4. Client notices he doesn't have a certain package yet or is out of date |
| 17 |
5. Client requests from server .torrent files (or maybe at first just URL) |
| 18 |
from where to get the the missing packages |
| 19 |
6. Client downloads them and puts them in "data" directory (~/.tmw/data on |
| 20 |
Linux, cause that's writable) |
| 21 |
7. Client loads the list of files server mentioned in PhysFS virtual |
| 22 |
filesystem |
| 23 |
8. Client tells server that it is up to date |
| 24 |
9. Client could load some common data like item definitions here |
| 25 |
10. Server sends client player position and so on, game starts, client loads |
| 26 |
and unloads additional data like maps, tilesets, sprites, etc. on demand. |
| 27 |
|
| 28 |
|
| 29 |
UPDATING THE CLIENT BINARY |
| 30 |
|
| 31 |
Updates to the actual client binary are also being considered, especially on |
| 32 |
the Windows operating system. While the plan is to move any specific game data |
| 33 |
outside of the binary, sometimes an update to the binary will be required for |
| 34 |
being able to play the game. Also especially Windows users are used to |
| 35 |
automatic update checks for many applications (possibly because of the lack of |
| 36 |
such a feature system-wide). |
| 37 |
|
| 38 |
On Linux this would require either installing a statically linked binary |
| 39 |
(which could still have some issues) or automatically compiling/installing |
| 40 |
from source. Neither are very attractive options, and I (Hammerbear) would |
| 41 |
prefer not to deal with automatic binary updates on Linux. |
| 42 |
|
| 43 |
On Windows a binary can't be replaced while it is running, so probably a |
| 44 |
separate update tool would need to be written that is run before the client |
| 45 |
to check for updates to the client and possibly replaces the client before |
| 46 |
running it. |