[MUD-Dev] Re: MUD Design doc (long)
Mik Clarke
mikclrk at ibm.net
Sat Jan 9 22:34:11 CET 1999
Nathan F Yospe wrote:
>
> On Fri, 8 Jan 1999, Mik Clarke wrote:
>
> :Nathan F Yospe wrote:
>
> :> On Fri, 18 Dec 1998, Mik Clarke wrote:
> :> :This can be done by adding 'smellable' objects to rooms in the same
> :> :fashion as 'examinable' objects are added. Diku/ROM uses extra
>
> :> This *should* be done by making the root object explicitely "scentless",
> :> and deriving doors and such from them, and by actually having props when
>
> :Yes and no. Props take more resources (and more builder time) than 2 or
> :3 line extra descriptions tagged onto a room. Using the descriptions
> :you can make a detailed (and explorable) description for a room or an
> :area that is much more efficient than one that has 5 or 6 props standing
> :around in each room just to add background flavour. I tend to use props
> :only for game significant items.
>
> Like I said, props are all that can be done with my design.
I've implemented the detailed descriptions as chains of keywords,
conditions and descriptions attached to rooms and objects. (Extending
the Diku/ROM Extra Descriptions). It makes the search for the target of
a look/examine command a bit more complicated, but lets me play tricks
with conditional descriptions and lets me record the fact that someone
has seen a particular description.
An example might be a mage examining a sword:
>examine sword
A fine blade of polished steel.
It looks quite sharp.
...and a warrior examining the same blade...
>examine sword
A fine blade of polished steel.
It has a razor honed edge and is undoubtably the work of the weapon
smiths of FooBar. This is a rare and valuable blade.
...likewise other characters may be able to see other things. This
helps create a need for teamwork, as few characters will have all of the
skills to perceive all of the clues.
Recording that someone has seen a particular description is usful for
subsequently modifying the world - completing quest stages or making
secret exits usable.
Consider someone entering a temple...
>north
Temple of Empark (indoors)
You are standing in the main chamber of the Temple of Empark. A pool
of swirling green fluid sits in the center of the floor, before the
statue of the majestic Empark.
>examine statue
It stands 60' tall and portrays a sensative young man reclining on an
elegant throne. The gods face looks very peaceful and serene.
>examine pool
A 30' wide pool containing a swirling green flid. As you watch the
ripples form strange, abstract patterns.
The innkeeper told you that the locals send young girls into the pool
where they journey to the side of Lord Empark to aid him as he looks
over the town.
...and a while later they are in the lair of an evil wizard...
>examine crystal ball
A solid sphere of rock crystal. There is a swirl of smoke in its center.
Looking into the crystal ball you see the hideous visage of Toumar,
the god of evil and destruction.
...if they later return to the first temple...
>examine pool
A 30' wide pool containing a swirling green flid. As you watch the
ripples form strange, abstract patterns.
Suddenly the visage of evil Toumar becomes apparent amongst the
swirling ripples! As you keep watching the image fades and then
returns!
The innkeeper told you that the locals send young girls into the pool
where they journey to the side of Lord Empark to aid him as he looks
over the town.
This is a somewhat more subtle role-playing effect than most Diku
derivatives aspire to, but I quite like it.
> On the other
> hand, comparing the sizes of a (mostly inherited) prop and a description
> from a DIKU (probably unfair, as any other codebase would probably use a
> text compression scheme), I don't see a lot of difference... and any use
> of a previously defined prop is going to use up one 64 bit long, until a
> player alters the prop... and even then, there will be a cost of at most
> 64 bits per alteration.
Hmmm. So your entire world looks like it was furnished by Habitat? The
same pine tables and wooden chairs everywhere? Now Diku (or at least my
Rom->Sunder based derivative) has a restriction that you can only repop
objects from the same area. So let's see what I need if I want to model
an old house - carpets (3 or 4), several different tables (5), dinner
chairs (2x6), sideboards (2), a stove (1), a sink (1), a double bed (1),
single beds (3), wardrobes (2), chests of draws (4) - that's somewhere
around 25 objects, most of which are used only one or two times and
which don't play any significant game role. As soon as I want one to do
something useful (like having a clue carved or woven into it) I have to
create another object. I suspect the overhead works out at something
more than just 64 bits per prop instance.
Mik
--
http://www.geocities.com/SoHo/Cafe/2260
More information about the mud-dev-archive
mailing list