[MUD-Dev] Re: MUD Design doc (long)

[Caliban Tiresias Darklock]

-----Original Message-----
From: Travis S. Casey <efindel at io.com>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Monday, January 04, 1999 11:18 AM
Subject: [MUD-Dev] Re: MUD Design doc (long)


>To put it another way, you *can* follow good practice when defining
>commands in objects, but you're not forced to.  From my own experiences
>with builders, I'd prefer a system where they're forced to follow good
>practice.  (Especially if a lot of your builders aren't going to be CS
>types -- in my experience, most CS people don't follow good coding
>practices as much as they should, and non-CS people are generally even
>worse about it.)


Bondage and discipline languages? Eugh. I detest those. However, I have to
admit that your rationale is sound... I've had similar problems.

One of the things I've seriously thought about is implementing my user
scripting language as a sort of high-level wrapper for an assembly language;
the existing script language as designed by my predecessor has only two
storage registers and very few potential operations. One of them supports
read, write, add, and subtract; the other supports only read, user-input,
and increment -- no subtraction, no addition of anything more than 1, and no
setting without the direct input of an interactive user... note that the
first doesn't support user-input, either, so you actually have to overwrite
the second with the intended contents of the first, assign it, and then get
new user input for the second.

Now, given this sort of heinously broken design, anything I may choose to do
instead is likely to be an improvement. So I was considering creating a
general sort of "virtual machine" architecture where each user gets like an
8K memory space; the upper 4K forms a data segment (partially pre-populated
with information on his surroundings), and he has the lower 4K to write code
in some proprietary machine language. This way, I can give the user a LOT of
power in terms of the language itself, and maintain some serious state from
command to command. (This also creates the idea of being able to infect some
other player's macro computer with a virus or trojan somehow.) Has anyone
else thought about this sort of thing? I've been considering using Knuth's
MIX as a sort of blueprint for the language itself, which ought to cover
just about everything.

| Caliban Tiresias Darklock            caliban at darklock.com
| Darklock Communications          http://www.darklock.com/
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=-