This article contains information for Programmers working or interested in working for The Mana World

This proposal has been accepted

The development team has discussed the contents of this article and has decided that it should be implemented as described. But the implementation is not finished yet. You can help to bring the features described here into the game.

Related subtopics

• Being movement system
• Communication protocol
• Pixel based players in a tile based world
• Realtime action combat protocol
• Main server loop
• Account creation
• Database specifications
• Doxygen Server Documentation
• Design server ideas
• Long term server development

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

Connection Handler

The connection handler has one thread to listen for incoming connections, and one thread for each connected client. We decided to use the ENet library which uses UDP with some additional TCP-like control mechanisms. We believe that this is the best compromise between the realtime capabilities of UDP and the reliability of TCP.

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.

The following diagram illustrates the role of the connection and messages handlers:

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:

• Lua
• Io
• Ruby

Note: Lua has been implemented for server-side scripting. --Oct. 9, 2007

Suitable uses of scripting:

• Enemy behaviour
• Dynamic NPC behaviour