The Mana World - User contributions [en]

Archive:Ports

2005-11-11T12:53:16Z

Nym:

<b>The Mana World is known to work on the following systems:</b>

* Windows XP/2K/9x (either Dev-C++ or MSVC)
* GNU/Linux x86 and amd64
* FreeBSD 5.4
* Mac OS X ([[MacOSX port]])

<b>The following need testing or are in progress:</b>

* GNU (aka GNU/HURD)
* BeOS (BeOS Max 3.1 beta 1) ([[BeOS port]])
* Zeta (BeOS based)
* GNU/Linux PPC
* OpenBSD 3.8
* NetBSD 2.0 ([[NetBSD port]])
* Mac OS X x86

User:Nym

2005-07-16T10:23:09Z

Nym: /* Links */

== About ==

'''Name:''' Aaron Marks

'''Location:''' Australia

'''Occupation:''' Student (studying I.T.)

'''Email:''' nymacro * gmail * com

'''Working on:''' Server mainly, various fixes and updates to client.

== Links ==
[http://satgnu.org/nym/ Homepage]

[http://www.nongnu.org/gpack/ GPack Package Manager]

[http://gusanos.sourceforge.net/ Gusanos]

User:Nym

2005-07-16T10:22:34Z

Nym: /* About */

== About ==

'''Name:''' Aaron Marks

'''Location:''' Australia

'''Occupation:''' Student (studying I.T.)

'''Email:''' nymacro * gmail * com

'''Working on:''' Server mainly, various fixes and updates to client.

== Links ==
[http://www.nongnu.org/gpack/ GPack Package Manager]

[http://gusanos.sourceforge.net/ Gusanos]

Archive:Update system

2005-07-05T06:56:33Z

Nym:

== Update System ==

The Mana World plans to be an 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. The Mana World up to this point has been using a monthly release cycle to update the game, but this distribution method suffers in the following ways:

* Data redundancy - This is a major concern for those who have slower connections to the Internet.
* Releases aren't frequent enough - Players want new material as fast as they can get it. Players like a fast updated, dynamically changing game world in which they can immerse themselves - any stagnation can lead to player loss.
* Bad releases hard to update - Once a package has been released, soon after its release some major problems may be found, which may require immediate attention. The old package must then be removed and replaced with a new fixed package, by this time many people would have downloaded it and would probably not know about the new updated release. This is a major problem in itself.

Regarding the last topic, we discussed it a bit, and thought that first of all, we need a version checking, so that everyone is informed about a new release. In windows we were evaluating the possibility of directly replacing the binary, while this won't be possible in GNU/linux. I guess we will continue with monthly releases, and will discuss in this article only static data updates. --[[User:ElvenProgrammer|ElvenProgrammer]] 02:08, 4 Jul 2005 (PDT)

The Mana World wishes to address this by using an in-built update system which will automatically download the latest game media. By doing this, the second and third points noted above are eliminated. This update system should provide the following features:

* Smart updating - the updater should be able to find files which need to be updated and update them, without trying to update files which are already up to date.
* Cumulative patches (Optional)
* Media updates - should be able to fetch new and updated game media.
* Executable updates - should be able to update the binary executables appropriately.

The option of using a built-in updater is meaningful if using bitTorrent protocol (even if not necessary). If using HTTP/FTP, it could be valuable using an external application to avoid increasing the number of dependencies/size of executable in the client. About executable updates, see comment above. --[[User:ElvenProgrammer|ElvenProgrammer]] 02:08, 4 Jul 2005 (PDT)

== Update Format ==

The patch format must be easy to use and flexible, and should support the required features mentioned above.

* The format will be added here.

The patches will be released using compressed archives. Probably using bzip compression is a wise choice to reduce downloads size. I suggest that every client keeps a local copy of the version of each file:
''/data/items.xml 0.12''
''/data/music/Faith.ogg 0.3''
and every patch file will have a list of the changes, let's say changes.txt:
''/data/items.xml U 0.13'' means it was updated, check version anyway.
''/data/music/desert.ogg R'' the file should be removed, no longer used
''/data/graphics/avatars/hammerbearcaricature.png A 0.1'' new file, needs to be added to local list
Using those infos, the previous data packages could be easily merged with the patch.
Note: this is a quick suggestion, we could think of a lot of better ways. --[[User:ElvenProgrammer|ElvenProgrammer]] 02:08, 4 Jul 2005 (PDT)

----
''This could be changed to:''

Updates come in compressed archives, probably .zip files as they are easy to create and allow individual files to be read directly from them (this is already being abstracted using PhysFS, so there is no need to inflate the archives after downloading). Initially, the client will retrieve an ordered list of archives that is should load, for example:

<pre>
tmw-base-1.0.zip
tmw-base-patch-1.1.zip
tmw-tonori-region-1.0.zip
</pre>

The client will check whether all the listed zip files are present in its data directory, and attempt to download any missing ones (see update distribution below). Once downloaded, it will put each archive in the virtual file system provided by PhysFS. Once a data file is loaded, the archives are search bottom to top so that the 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.

Correct me if I'm wrong, but this won't keep all the old data? Or maybe old packages will be overwritten by new ones?
If not just think that having 3 different versions of a song would lead for example to not required 6-9 MBs. --[[User:ElvenProgrammer|ElvenProgrammer]] 12:55, 4 Jul 2005 (PDT)

This ordered list could should contain protocol information for file retrieval and information concerning the platform which the patch can be used. Such a list could look like:
<pre>
win32 http://themanaworld.org/updates/tmw-base-binary-win32-1.1.zip
osx http://themanaworld.org/updates/tmw-base-binary-osx-1.1.zip
all ftp://themanaworld.org/updates/tmw-maps-tonori-1.3.zip
all http://themanaworld.org/updates/tmw-gfx-items-1.1.zip
</pre>

It is also suggested that the updates can be used in the configuration director (~/.tmw) on UNIX based platforms, as root priveleges would be required to install the updates correctly otherwise.
[[User:Nym|Nym]] 23:56, 4 Jul 2005 (PDT)

== 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 Bit Torrent] 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 Bit Torrent], see the [http://www.bittorrent.com/introduction.html Bit Torrent Introduction].

To easily utilize to the Bit Torrent protocol, one of the following libraries can be used:
* [http://libbt.sourceforge.net/ libbt] - C
* [http://libtorrent.sourceforge.net/ libtorrent] - C++

Yeah I know we already choosed 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] to retrieve the updated data files through HTTP or FTP. --[[User:BjÃ¸rn|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.--[[User:ElvenProgrammer|ElvenProgrammer]] 12:55, 4 Jul 2005 (PDT)

Archive:Update system

2005-07-04T07:57:11Z

Nym: Initial edit of update system!

Main Page

2005-07-04T07:25:10Z

Nym:

<div style="text-align: center; margin: 20px; font-style: italic;">Welcome to The Mana World wiki! This wiki is meant to provide information to our players, to provide an easy way to contribute to the development of certain parts of the game and to improve collaboration between people on the development team. We hope you will find what you are looking for. To be able to edit you have to login, but signing up is free and requires no activation.</div>

{| cellspacing="3" cellpadding="5" width="100%"
|- valign="top"
|width="50%" style="border: 1px solid #e0c8b8; color: #000; background-color: #faeee6"|
<h2>Project information</h2>
* [[Project description]]
* [[Developers]]
* [[FAQ]]
* [[Dependencies]]
* [[System requirements]]
* [[Roadmap]]
* [[Ports]]
* [http://cvs.sourceforge.net/viewcvs.py/themanaworld/tmw/ChangeLog?rev=HEAD&view=markup Change log]

<h4>References</h4>

* [[Guilds]]
* [[Quest list]]
* [[Monster reference]]
* [[Item reference]]

<h4>Organization</h4>

* [[Suggestions]]
* [http://themanaworld.org/archive/galerie.php Gallery]
* [[Developer meetings]]
* [[Quotes]]
* '''[[Summer 2005 real life developer meeting]]'''

|width="50%" style="border: 1px solid #c9c9ff; color: #000; background-color: #f3f3ff"|
<h2>Development</h2>

'''World'''
:[[World development]], [[World backstory]], [[Map development]], [[Landmarks]], [[Kingdoms]], [[Important NPCs]], [[Finished NPCs]], [[Quest development|Quests]], [[Calendar]]

'''Graphics'''
:[[Guidelines]], [[Concept art]], [[Tileset development|Tilesets]], [[Playerset development|Playerset]], [[NPC development|NPCs]], [[Monsterset development|Monsters]], [[Hairset development|Hairsets]], [[Itemset development|Itemsets]], [[Equipment development|Equipment]], [[:Special:Newimages|New images gallery]]

'''GUI'''
:[[GUI development]]

'''Sound'''
:[[SFX]], [[Music]]

'''Game'''
:[[Game systems]], [[Update system]]

'''Server'''
:[[Server development]]
|}

User:Nym

2005-06-13T09:27:44Z

Nym: Added :)

== About ==

'''Name:''' Aaron Marks

'''Location:''' Australia

'''Occupation:''' Student (studying I.T.)

'''Email:''' nymacro * gmail * com

== Links ==
[http://www.nongnu.org/gpack/ GPack Package Manager]

[http://gusanos.sourceforge.net/ Gusanos]

Development:Developers

2005-06-13T09:21:28Z

Nym:

{| border="0" cellspacing="0" cellpadding="5" width="100%"
! style="background:#efdead;" width="75px" align="left" | Name
! style="background:#efdead;" width="200px" align="left" | Occupation
! style="background:#efdead;" width="200px" align="left" | Location
|-
| [[User:Bear|Bear]]
| Scripter
|
|-
| style="background:#f6f0e0;" | [[User:BjÃ¸rn|BjÃ¸rn Lindeijer]]
| style="background:#f6f0e0;" | Lead Programmer
| style="background:#f6f0e0;" | The Netherlands
|-
| [[User:ElvenProgrammer|ElvenProgrammer]]
| Project leader, programmer
| Italy
|-
| style="background:#f6f0e0;" | [[User:Demon|Demon]]
| style="background:#f6f0e0;" | Pixel artist
| style="background:#f6f0e0;" |
|-
| [[User:deviexx|deviexx]]
| Content manager
|
|-
| style="background:#f6f0e0;" | [[User:Golgo|Golgo]]
| style="background:#f6f0e0;" | Pixel artist
| style="background:#f6f0e0;" |
|-
| [[User:Irukard|Irukard]]
| Pixel artist
| Poland
|-
| style="background:#f6f0e0;" | [[User:Javila|Javila]]
| style="background:#f6f0e0;" | Programmer
| style="background:#f6f0e0;" |
|-
| [[User:kindjal|kindjal]]
| Programmer
| Italy
|-
| style="background:#f6f0e0;" | [[User:Kyokai|Kyokai]]
| style="background:#f6f0e0;" | Game systems designer
| style="background:#f6f0e0;" |
|-
| [[User:maci|maci]]
| User support
| Germany
|-
| style="background:#f6f0e0;" | [[User:Magick|Magick]]
| style="background:#f6f0e0;" | Musician
| style="background:#f6f0e0;" |
|-
| [[User:Modanung|Modanung]]
| Pixel artist
| The Netherlands
|-
| style="background:#f6f0e0;" | [[User:Mra|Mra]]
| style="background:#f6f0e0;" | Programmer
| style="background:#f6f0e0;" |
|-
| [[User:Nym|nym]]
| Programmer
| Australia
|-
| style="background:#f6f0e0;" | [[User:Pajarico|Pajarico]]
| style="background:#f6f0e0;" | Concept artist, writer
| style="background:#f6f0e0;" | Spain
|-
| [[User:Rotonen|Rotonen]]
| Head of art, story and music
| Finland
|-
| style="background:#f6f0e0;" | [[User:Clef|Clef]]
| style="background:#f6f0e0;" | Pixel artist
| style="background:#f6f0e0;" |
|-
| [[User:Talaroc|Talaroc]]
| Pixel artist
|
|-
| style="border-bottom: 2px solid #efdead; background:#f6f0e0;" | [[User:Usiu|Usiu]]
| style="border-bottom: 2px solid #efdead; background:#f6f0e0;" | Programmer
| style="border-bottom: 2px solid #efdead; background:#f6f0e0;" | Poland
|}

Archive:Server development

2005-06-07T08:42:15Z

Nym: /* Scripting */

== Related subtopics ==

* [[Player control]]
* [[Client-server message list]]
* [[Pixel based players in a tile based world]]
* [[Main server loop]]
* [[Account creation]]
* [[Database specifications]]

== Very global idea of some of the main components of the server ==

http://www.lindeijer.nl/~bjorn/globalidea.png

=== Connection Handler ===

The connection handler has one thread to listen for incoming connections, and one thread for each connected client. I think it's best to use TCP as the basis of our protocol, because I'd like the reliability which saves a lot of trouble.

The listening threads will drop incoming messages in a message queue, which is processed in the main thread. The incoming messages are then dispatched to a message handler (described below), which won't have to deal with the threading issues.

=== Message Handler ===

Actually multiple messages handlers (classes implementing handler interface) can register themselves at the connection handler to handle a certain kind of message. An ''IncomingMessage'' class will be used to pass the message around which contains the data, information about the sender and methods to conveniently extract primitive datatypes from the raw message data.

Here is a small diagram to illustrate the role of the connection and messages handlers:

http://www.lindeijer.nl/~bjorn/network.png

=== Message Types ===

This provides an overview of the messages which the server will send and/or receive.

The various types of messages the server will recieve include:
- Login
- Logout
- Player chat: a player wants to send a message to other players.
- Object action: the client has performed a certain action on an object.

The various types of messages the server will send to client include:
- Player chat: another player has chatted.
- NPC Dialog: notify the client about in-game dialog.
- Create object: notify the client about a new object.
- Update object: notify the client about updated player information.
- New map: notify the player to load a new map.

(We must create a formal specification of protocol for server)

=== World ===

The server maintains the world state, or a designated part of it (in the case of multiple map servers). This includes a list of active maps (maps without players could be unloaded to save cpu and memory), and a list of all active beings and objects. For the beings and objects, it will also need to know about all possible types of beings and objects. These types will be defined with a combination of XML data and scripts.

An ''OutgoingMessage'' class is used to construct messages to be sent towards the clients. A mechanism is required to conveniently determine for which clients a certain message is relevant. These messages will be dropped in an outgoing messages queue (or one for each client, not sure yet), and finally be sent.

=== Persistent Storage ===

When the server crashes or needs to be restarted for other reasons, it would be rather inconvenient if this resulted in a world reset. Because of this we need a persistent storage of world data that includes all active beings and objects, that is continuously (but at a slow pace) being kept up to date. At the same time this means this will also be the place where character data is kept, and when a client reconnects he can expect the player to be still at the same spot as when he left through this method.

This last thing will need a special notice, because the above describes a server that is potentially cooperating with other servers in order to together be able to handle the required bandwidth and processing resources. Hence it would be convenient when the persistent storage was a centralized database used by all map servers. This is unfeasable and too unreliable though, so we'll probably need to use a mixture of slow-pace updating of a local database, and very-slow-pace updating of a central database. Or probably better than the last thing, very-slow-pace replication to other servers.

=== Scripting ===

The Mana World aims to be a dynamic, ever improving game. Scripting allows more flexible control over various components of the game, such as enemy behaviours and in-game events. Scripting will be implemented server side (although in the future some scripting features may be migrated to the client), this allows a greater control over in-game objects, events, and various other components of the game.

Many scripting languages would be suitable for embedding in the server, such as Lua, Io and Ruby (plus alot more). Each language has their pros and cons, and some are larger and more featureful than others. It is also possible to use a language interface such as SWIG to take care of the language implementation details, allowing a multitude of languages to be used. More research must be done into the suitability of various scripting languages for use in The Mana World.

Suggested suitable languages:
* [http://www.lua.org/ Lua]
* [http://www.iolanguage.com/ Io]
* [http://www.ruby-lang.org/ Ruby]

UPDATE: Ruby has been chosen as the language for use in TMW server.

Suitable uses of scripting:
* Enemy behaviour
* Dynamic NPC behaviour

''- [[User:BjÃ¸rn | BjÃ¸rn Lindeijer]] & [[User:Nym | Aaron Marks]]''

Archive:Database specifications

2005-06-07T08:39:14Z

Nym: (fixed up last update)

== Server Database Specification: ==
'''SQL[ite] Table Specifications:'''
* Account Information Table
create table tmw_accounts (
-- Username
user varchar(32) unique primary key not null,
-- Password hash
password varchar(32) not null,
-- Email address
email varchar(128) unique not null
);

* Character/Player Information Table
create table tmw_characters (
-- [Unique] character name
name varchar(32) unique primary key not null,
-- Username
user varchar(32) not null,
-- Player information
gender int not null,
level int not null,
money int not null,
-- Coordinates & map
x int not null,
y int not null,
map text not null,
-- Statistics
strength int not null,
agility int not null,
vitality int not null,
intelligence int not null,
dexterity int not null,
luck int not null,
-- Player equipment
--inventory blob not null,
--equipment blob not null,
-- Table relationship
foreign key(user) references tmw_accounts(user)
);

* Item type table
create table tmw_base_items (
-- Name of item
name varchar(32) unique primary key not null,
-- Item attributes here
weight int not null
);

* In-game object table
create table tmw_items (
id int unique primary key not null,
name varchar(32) not null,
-- Special (unique) item attribues
-- Table relationship
foreign key (name) references tmw_base_items(name)
);

* Character inventory table
create table tmw_inventory (
-- Item
id int not null,
-- Character who has the item
name varchar(32) not null,
-- Table relationship
foreign key(id) references tmw_items(id),
foreign key(name) references tmw_characters(name)
);

* Character equipment table (items which are equipped)
create table tmw_equipment (
-- Item
id int not null,
-- Character who has item
name varchar(32) not null,
-- Item slot equipped on
slot int not null,
-- Table relationship
foreign key(id) references tmw_items(id),
foreign key(name) references tmw_characters(name)
);

''Example queries''
* Count total number of in-game objects
select count(*) from tmw_items;

* Count total number of item types
select count(*) from tmw_base_items;

* List player inventory
select distinct tmw_items.id, tmw_items.name
from tmw_items, tmw_inventory
where tmw_items.id = tmw_inventory.id
and tmw_inventory.name = 'nym the great';

* Find weight of player inventory
select sum(tmw_base_items.weight)
from tmw_base_items, tmw_items, tmw_inventory
where tmw_base_items.name = tmw_items.name
and tmw_items.id = tmw_inventory.id
and tmw_inventory.name = 'nym the great';

Archive:Database specifications

2005-05-23T08:24:06Z

Nym:

Archive:Database specifications

2005-05-23T08:23:36Z

Nym:

Archive:Server development

2005-05-23T08:22:50Z

Nym:

[[Database Specifications]]

--[[User:Nym|Nym]] 01:21, 23 May 2005 (PDT)

Archive:Server development

2005-05-23T08:21:21Z

Nym: Server Development Information