[Savannah-hackers] submission of The Daemonarch - savannah.nongnu.org

[dan_adrian_valentin]

A package was submitted to savannah.nongnu.org
This mail was sent to address@hidden, address@hidden


Dan Adrian Valentin <address@hidden> described the package as follows:
License: gpl
Other License: 
Package: The Daemonarch
System name: daemonarch
Type: non-GNU

Description:
The Daemonarch is a distributed network of servers aiming to create a networked 
game system that will provide a framework for MMORPG\'s or other types of 
network games.

It mainly consists of a toolkit that could be used to create network servers 
named here \"daemons\" , but it will also contain a number of standard ones .

These servers will interact with each other transferring the information which 
is necessary for the simulation.  

I have individualized a number of 6 standard daemons and named them after some 
mythological gods/demons .

These standard daemons are :

Samael : 
it is the server responsible with the autentification and imerssion into the 
network providing a safe way of logging by checking for a valid account and 
return a unique session id which will be used as a way of obtaining information 
about other daemons , after the login process was completed , Samael instructs 
the daemon in the next steps of its immersion into the network like how to 
contact the other daemons , and even after all these steps are completed it 
will still help by providing informations.
It will have to be unique within its network

Hecate :
These daemon could be also called a location server because it controls and 
coordonates a certain area in the game ,by keeping 
track of the objects in the area and their properties ,each property has a 
modification time value assign to it sa that we only pass that necesary 
information when syncronising objects with another daemon .
A good example is a player that leaves a certain area and after some time 
returns , on his return the daemon only informs him of the object changes that 
have happend since the last time he was present (this is not a detailed 
description of the mechanism).
Also Hecate daemons will have to interact with each other and they will do so 
by using some areas which will be syncronised by both daemons so that a object 
belonging to a daemon could enter such a area  
and then be syncronised by both daemons so that if it moves out of its 
up until a moment ago daemon area it will now belong to the other daemon thus 
providing a way to pass fluidly between two areas controled by two different 
daemons.

Azael : 
it is basicly the \"client\" daemon ,the one which is responsable for the 
interaction of actual participants in the game ,
it will be provided with a graphic/sound interface.
For security/common sense reasons it does deal with objects directly 
in its request for the Hecate but with a number of actions very flexible 
actions that affect only the object being controlled by the daemon (ex : player 
body).

Raziel :
it is the daemon that is supposed to collect information from other daemons 
mainly from hecate daemons and execute action scripts on demand it does not 
execute them directly but passes the instructions to their apropiate executor 
daemons.
Ex : a script to open a secret door when pulling on a lever :)
The daemon receives the request and looks the script up in its database then 
begins to execute it by asking the apropriate hecate to preform the door open.

Persephone:
it is a proxy daemon intermediating the connection for a number of other 
daemons , and it is recognized by the other daemons as being a proxy (it does 
not emulate the behaviour of the destination daemon) so it can act as a two way 
comunication channel.
Ex : An group of Azaels connects to several Hecates and a Raziel connects to 
several Hecates while all being connected to the same Samael .

Lilith:
it is a more complex version of Persephone because it does not only 
intermediate comunication for a group of daemons but it also simulate the 
daemons internally , in short its an AI daemon capable of simmulating a large 
number of Azael like things. The difference is that all of them will share the 
object data so that it does not have to be syncronised for each contained 
entity and some other differences


All these daemons are just the standard ones and are just a modification of a 
daemon skeleton that could be used to add more

Basicly they are intended to be run on different machines to reduce the 
workload thus permitting an increased number of participants to the network , 
but could be runned on the same of fewer machines , support for running a 
daemon on several machines could be implemented later on.

Right now we dont have any code because we are still in the designing phase but 
i have presented here the basics concepts of the network and the final design 
will be just this with some minor techinal modification.


Other Software Required:
We are planning on using Crystal Space SDK as a 3d realtime rendering engine 
for the Azael daemon which is covered under the GNU Library General Public 
License v2 .

Other Comments: