[MUD-Dev] TECH DGN: a few mud server design questions (long)

[Caliban Tiresias Darklock]

On Sat, 28 Jul 2001 03:07:45 -0500 (CDT), Robert Zubek
<rob at cs.northwestern.edu> wrote:
> Caliban Tiresias Darklock writes:

>>  The MUD-Dev search engine at kanga.nu is useful, but I really
>>  don't like search engines too much... 

> yes, a kind of 'gems of mud server design' would be very cool. i
> realize there's been quite a few of those posted on this list, but
> i agree, unless one asks explicitly, it's really difficult to find
> the particulars. but so it is with most highly specialized
> knowledge. :)

True enough. :)

>>    PRE-COMMAND SERVER (Valid command)
>>      PRE-ACTION SUBJECT (Subject adjusts it for specifics)
>>        PRE-ACTION SERVER (Server adjusts it for world effects)
>>          PRE-ACTION OBJECT (Object adjusts it for specifics)
>>            ---- ACTION ----
>>          POST-ACTION OBJECT (Object reacts to result)
>>        POST-ACTION SERVER (Server reacts to result)
>>      POST-ACTION SUBJECT (Subject reacts to result)
>>    POST-COMMAND SERVER (Ready for next command)

> so the server doesn't actually do any event processing at the
> beginning, it just parses the command, passes it to the subject,
> and then if the subject is willing to perform it, it's expected to
> send it back to the server for general processing, right?

Not exactly... each indentation level is optional and performed only
if necessary. If you type "inventory", for example, the pre-action
phase of the subject determines that this doesn't need to know
anything else from the server or from any object, so it
short-circuits straight to post-action subject and drops the
inventory list back to the server.  Likewise, a "who's online"
command doesn't need to go anywhere once the command is recognised.

> were there any specific reasons (difficulties with certain actions
> or other such) that suggested doing the server handling after the
> actor, rather than before the actor?  (just curious...)

It might be better to consider the pre-action and post-action server
commands as "world" commands. Is it a command, can the subject
perform it, does the world allow it, is the object affected. Both
the subject and the world may have "contingent" effects related to
what happens with the subject, so the object then has to let the
world know what happened, which in turn lets the subject know what
happened. Let's say Joe throws a fireball at Bob, with "CAST
FIREBALL BOB".

Pre-command server: Is CAST a valid command? Yes, it is. Pass to
subject.

Pre-action subject: Am I able to CAST? Yes. Am I able to CAST
FIREBALL?  Yes. Do the current conditions allow this (enough mana,
able to speak and move, correct spell components are in inventory,
etc.)? Yes. Pass to world.

Pre-action world: Is it permissible to CAST here? Yes. Is it
permissible to CAST FIREBALL? Yes. Is it permissible to CAST
FIREBALL BOB? Yes. Is BOB here? Yes. Pass to object.

Pre-action object: Can people CAST on me? Yes. Can they CAST
FIREBALL on me? Yes. Move to post-action phase.

Post-action object: What happens if someone does a CAST FIREBALL on
me?  Well, I take a lot of damage but can save for half. Did I make
my save?  Yes. Okay, I take half damage from this fireball. Pass to
world.

Post-action world: Bob just took 23 points from a fireball. Do I
need to do anything because of that? Yes, I need to damage everyone
else in range. So I'll do that. (This is done with other events,
incidentally.)  Pass to subject.

Post-action subject: Bob took 23 points from my fireball. Remove the
components from my inventory and decrement my mana reserves. Pass
report to server.

Post-command server: "You cast a fireball at Bob. Bob takes 23
points."

Any failures encountered will short-circuit the process. If you
don't have the mana, you're in an anti-magic zone, and Bob is immune
to fireballs, you return immediately with "not enough mana". Once
you have the mana, you come back with "no magic in this zone". Once
the anti-magic field is dispelled, you find out Bob is immune to
fireballs.

>>  Right now, these handlers are written in native C++ and handled
>>  by chaining off to functions, but I'm working on turning this
>>  into a scriptable interface. (With 600 handlers and counting, it
>>  only makes sense.) I've been toying with the idea of using
>>  Knuth's old MIX assembly language from "The Art of Computer
>>  Programming" and running the handler in a virtual machine.

> hey, good old MIX. :) although i'm curious how well an assembly
> language would deal with issues such as complex data types
> (strings, structs) getting used by the handlers, or the need to
> interface to other parts of the system...

Just as well as it always did. Some of us *do* still work in
assembler, you know.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev