[MUD-Dev] Custom Server Roll Call?

[Marc Hernandez]

=09I decided to display my minimal server implementation to the
world.  I keep wanting to then talking myself out of it... ahh well.  Much
of what I am doing is for learning about programming multiuser systems,
but I would like to play my own system eventually.  It is not as
elegant or as simple as I would like, or as any other system.

(Comments about Ola's message then custom server detail below)

On Sun, 2 May 1999, Ola Fosheim [iso-8859-1] Gr=F8stad wrote:
> I think I'm ditching my design starting from (almost) scratch again :-) T=
his
> must be the third or fourth time or so.  The worst thing is, I'm getting

=09Yeah I have been doing this also.  I decided to stop running and
implement.  My first and second passes were under C++ with the later one
(or is it two now?) under Java[1].=09

> back to where I was *4* years ago regarding what I want to do now.  The
> basic reason for this is that I realize that I want to make it accessible=
 to
> handicapped people, to blind people and others who cannot easily use many=
 of
> the newer inherently graphical systems.  Which pretty much rules out the
> hardcore simulationist approach which I have been following so far.  So, =
I'm

=09Hmm.  Why would accessability have a dependancy on game mechanics?
You still have objects and such to do stuff with I assume.

> basically back at the scratchpad (well, I always liked design better than
> implementation :*).  Maybe I'll come up with something that will take les=
s
> than 3-5 man years to design and implement this time!! Hahaha... I haven'=
t
> been very good at that so far. :-X

=09Do you actually get much on paper?  I find I get a bit then decide
to go implement because I do not know how this or that will work.
Probably just immaturity in designing multiuser servers.

> So, what are you custom server guys doing?  Have you been able to stick t=
o
> your vision, or has it changed?  I see that Ben keeps pushing ScryMUD, bu=
t
> what about Jon and the roleplaying supporting client, JC, Caliban, Ling,
> Yospe and all the others?  Are you "pushing" (implementing) or "butching"
> (redesigning)?

> It would be interesting to see what you are doing and where you are going=
!!
> A mud-dev custom status quo, sort of.  Please share!

=09Whew ok.  I took a look at my codebase and it is not in as bad of
shape as I thought.  I am currently 'pushing' because I want something to
play with rather than endless bits of code that do not _really_ do
anything.  It is currently 2500 lines, supports persistant objects and
users and allows talking.
=09At the core the system is driven by events.  Everything that
happens has an event that makes it happen.  Events can be targeted, area
or generic. Targeted events effect one object (called components in my
system).  Generic events are generally system event.  For example I
have a 'ShowThreads' event that spits out threads to the log file.  Area
events effect a region of space.  For example sound or saying something
are area events.
=09All events pass through multiple filters.  Filters can eat events,
modify them or just pass them on through.  On sending, the event passes
through outgoing filters on the producer.  From there it depends on the
event type.  Generic events usually then just do their action.  Targeted
events then pass through the targets filters and then does it action.
=09Area events are a bit different.  They get produced and filtered
at production like other events.  Then they get filtered by the area they
are in.  The area filters them and decides how to propagate them.  Then
the area passes the events to the various objects that care.
=09For example.  Lets say we have a mouth component.  This mouth can
produce 'say' events.  So it produces one "Hello".  But you have a gag
filter.  This take that event and returns one with 'm's "Mmmmm".  The area
just passes it to all ear objects.  Your ear object has a hearing device
(which installed a filter in the ear) which takes a string and changes it
to all caps "MMMMM". =20
=09For my object system (objects are called components) I wanted a
uniform handling of abilities.  Thus components are really just
'containers' for Attributes.  An attribute is where all the work gets
done.  Some attributes:
Physical: maintains where a component is, including its connectedness. =20
Material: Any materials a component is made of.
Contain: this component can contain others that can be contained.
ContainedBy: this attribute maintains who it is contained by
(I use the 2 above for areas also.  Areas can contain other areas.)
Mind: A mind controls a body.  Some minds include: Text- this is a telnet
control for a body, Away- this is for controlled bodies that do not have a
connected human, NPC- for smarter NPC characters, MOB- for simple run
around creatures.


=09Rather than use simple pointers between components I have Slots.
Slots can have constraints placed on them.  Another component is placed in
a slot assuming it fits the constraint. =20

=09My current simple object model looks like so:
Basic:
=09Is the basic component.  Anything that is 'physically' in the
world will inherit from this object.  Has position.  Is containedby an
area.
Character:=20
=09Has a 'body' slot (which will only take objects of type Body).
Has a mind attribute.  Shell helper.  An interpreter for a MindText.
Server:
=09Dispatches events.  Holds a list (hashtable on ID) of components.
Body:
=09Every basic body will inherit from this. =20
BodyHuman:
=09Has slots to ear, mouth, movment.
Ear:
=09Can hear 'sound' events.
Mouth:
=09Can emit sound events.  Currently the Body is emitting the say
events.  Need to fix that.

=09Taking control of a body is as simple as changing the 'mind' of
the character.  If the character is reincarnated or turned into a goat you
just change the characters 'body'. =20
=09There are a few downsides.  The design, while powerful seems a bit
complex.  Of course this might be as simple as it can be (to support the
things I wish to do with it).  The persistance system is a bit brittle in
that if I change an object (in the java sense) it will refuse to load that
object.  This can be fixed by versioning when it gets a bit more stable. =
=20
=09Speed wise I think it can be very fast (on both a complexity level
and a raw speed level).  Making it into a distrubted system is an option
to get much more performance out of it.  In that case it has the same
problems as other systems.  With the event based architecture messages
could easily be passed between servers if needed.  Since objects are at
their most basic level streamable, object migration would be 'easy'[1] to
add.
=09I am currently looking to add a gaming system on top of it.  In
that regard I have not done much.  But I have realized the basic system is
fairly sound and should support one[3].  I have a simple area system setup
(one area).  You can login and talk.  Currently the system tells you the
Unique ID of the person that is talking to you.  I have considered writing
a parser to read in Diku areas and simulating some of the objects therein.
<shrug>.  I have been reading The Lord of the Rings.  Made me want a cool
RPG to go play in.

=09Oh yeah.  It is for a graphical system but will support anything.
I currently have a text based system running atop it, since that way I do
not have to develop a client right away.

=09Wow.  You read to here?  Even I fell asleep halfway through :-).

Marc Hernandez
[1] I think java makes an excellent server (and client) base.  I like
writing stuff in the language (I used to hate it).  Compiling other
languages to java byte code is not too difficult.  It is slow, but using
distribution can help relieve that (and IBM AS400's have very good
benchmarks on running java byte code due to some architectural reasons).
[2] In the 'you do not have to edit every single object in the system
sense'
[3] I got a little discouraged in february since I was the only one doing
anything with this while others that wanted to 'help make a game' did not
do anything. =20



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