[MUD-Dev] Re: MUD Design doc (long)
Emil Eifrem
emil at prophecy.lu
Mon Jan 4 02:42:04 CET 1999
At 06:13 PM 1/3/99 , Chris Gray wrote:
>[Emil Eifrem:]
> >The most reasonable thing is probably to have some kind of 'default
> >function' (be it via inheritance or some other construction) that handles
> >everything but the 'unusual case,' where the builder overloads this
> >'default function' with his scripting code. This should probably be done
> >regardless of whether you implement all your commands in the scripting
> >language or in your static server.
>
>If your system allows dynamic procs and the controlled calling of them,
>there are further twists that you can do to make things easier and more
>consistent. Have your 'default function' always run, and perform all
>of the checks that need to be done before anything specific to the
>object in question needs to be tested. At that point, check for the
>existence of a special processing function for this verb on that object,
>and call it if found. Otherwise do the normal default processing. In
>either case, you may or may not want to do common 'after-special-case'
>processing, depending on the result of that special case. In fact, all
>the real work may be done there, and 'normal default processing' consists
>of nothing at all.
Yes, I've had thoughts of special always-executed 'pre-' and
'post-handlers.' The advantages are obvious: you have a uniform generic
function that is always called before any actual command processing is
done. The 'prehandler' for example, could perform a lot of sanity checks
and similar stuff which would generally remove a lot of code duplication.
Same goes for the 'posthandler.'
The problem is that I just don't think it would work in practice. I mean,
the preprocessing for 'get' and 'drop' is pretty similar (is the object
there? can it be manipulated by the character?) but what about 'dodge',
'who', 'say' and 'cast'? -shrug-
I know there are people out there who have implemented or are considering
implementing this -- how did you set it up?
-EE [emil at prophecy.lu]
More information about the mud-dev-archive
mailing list