[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers] submission of The Daemonarch - savannah.nongnu.org
From: |
dan_adrian_valentin |
Subject: |
[Savannah-hackers] submission of The Daemonarch - savannah.nongnu.org |
Date: |
Mon, 05 May 2003 19:09:30 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 |
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:
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Savannah-hackers] submission of The Daemonarch - savannah.nongnu.org,
dan_adrian_valentin <=