[MUD-Dev] Collecting ideas for a MUD server... (fwd)

[Rahul Sinha]

A few folks have asked for more details about the planned design of my
project.  Keep in mind that while we have researched this for about a
month, (and are reusing some code from my job (don't worry, allowed to
distribute said code if I wish... in fact I think they are letting me keep
copyright) it is not yet completely implemented (some code written)

NOTE: we are currently considering making this mud roomless, and
contemplating what changes this implies to this structure

		OUTSIDE WORLD
========================||==========================
			\/
	/-----Server-Side-Client (many instances of this process)
	|	 |	       | |     
	|	 |	       |  \----------\
	|	 |	       |	      |
	| Messaging Daemon    Combat Daemon   |
	|  | 	       |       |       |      |
	|  |	      Mob Daemon---Event Daemon
	|  |	      |      		|
	Database wrapper----------------/

(the above are all distinct processes)

SSC (Server-Side-Client)
Players either ssh or telnet into server; they connect to a concurrent
server (fork-on-connect) that is nothing more than a server side client.
It generates what the user sees, parses information it recieves from the
Event Daemon as well as information it retrieves from the Database
wrapper.  Any communication, IC acts etc are done through the
messaging daemon, and the eventd never sees them.  Combat
also does not exactly take place in the event daemon, more on
this later.

Different SSCs can be written to suit different needs, for example one
person wants to write a Circle-clone client that parses the
output, keybindings, etc to look like our favorite Diku decendant, not to
mention totally compatible with Zmud, while the one I plan to write will
actually incorporate some of the features of Zmud (mapping for example)
and do them server-side)

The Event daemon 
The core of the mud, this represents the physics of the world.  Here is
where you move, where your health is lost and gained, where your skills
take effect, etc etc 
	[ED: currently a small amount of controversy exists, as to how
	much functionality to pull out of the server.  While we have all
	agreed that combat, messaging, and mob ai do _not_ belong here,
	there remains some question as to skills and magic, whether they
	should not just connect to the messaging, combat and event
	daemons, get command from event (and stats) process, report IC
	viewable reactions via messaging, in-combat reactions via combat,
	and manipulate the game world via event]
the main structure is a web of datastructures that represent the data that
we want in RAM at all times (no descriptions, (that can be handled by the
db and the disk cache) but for example hit points should not hit the db
layer every time they change mid-tick.)
Packages of skills, magic systems (multiple ones planned) etc are
implemented as .sos
The mud operates by having a thread alive for every zone that is occupies,
as well as one for any zones that border occupied zones.  The threads
process queued commands coming from players, then block until the next
tick strikes.

The Combat Deamon
The actual structure of combat (from a player perspective) has not been
determined, except that it will be based on an additive initiative system
(round-less) where (for lack of a better word) combat-ticks iterate, and
turns get taken when (combat_tick) % (initiative rating) == 0
regardless of the remaining details, the async (relative to eventd) nature
of combat means that all combat computation occurs here, with calls into
eventd to get/change stats.
	Either we are going to have a combat-request-process thread that
	does not block on tick, or employ shared memory (know less about
	the latter, but it seems more likely the more I learn about it)
	Either way, clearly much mutex happiness will surround the core
	data structures. (only real place for thread collision)

Messaging Daemon
All communication player-player, player-mob, etc occurs from here. Any
daemons that are not "physics-based" communicate through this layer.
In addition, as this mud is going to run on a box masqueraded through my
LUG's internet connection, LUG members who are logged into the MUD will be
able to send/recieve "pages" while inside through this layer. I am on the
IETF IMPP working group, and as soon as that protocol (which will replace
AOL IM and ICQ (AOL has agreed to shift over, MS and Yahoo have also
agreed to the resulting standard) is finalized, any MUD user will have a
IMPP presence point through the mud, and be able to send/recieve messages
while logged in (discussing with the rest of the admin staff wether to
allow IMPP client connections to the messaged (which woudl then be binding
the IMPP port) such that mud users could use this service while not
explicitly logged into the mud, (not to mention use other clients than the
mud SSCs ;-))
	Considering that the number of socket connections resulting from
	users exists at O(1) for all areas of the mud other than the SSCs,
	(which are O(4n) according to above) We are considering moving
	_all_ communication through the messaged, which begs the question
	wether the SSCs are needed at all (except for some reason 100
	processes bothers me not at all, while 100 threads makes me feel
	quite ill)

Mob Daemon
Here lies the mob AI.  All of it ;-)

Database wrapper
Just what it sounds like

comments welcome, please debug our planned structure so we dont undergo
hell debugging the implementation of it ;-)

if you have any other questions, let me know

	-RS

	Rahul Sinha
Computer Science/ Government,
University Of Maryland College Park
AIM: qui dire	ICQ: 9738191	(301)935-5542






_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev