[MUD-Dev] Re: DBMS in MU*'s

quzah quzah at geocities.com
Mon Jul 20 13:39:29 CEST 1998


-----Original Message-----
From: s001gmu at nova.wright.edu <s001gmu at nova.wright.edu>
To: mud-dev at kanga.nu <mud-dev at kanga.nu>
Date: Monday, July 20, 1998 12:51 PM
Subject: [MUD-Dev] Re: DBMS in MU*'s

[Snipped comments from quzah (me) about material types, and objects
 made up of more than one thing]

>I like this idea better.  Instead of making the matieral the parent class,
>make it a property of the class.  This way, it can be changed on the fly,
>and you can get away with smaller code (think static instances).  You can
>also create a linked list and have multiple material properties.  If I'd
>read the Design Patterns book more thuroughly, I do believe I could name
>the pattern this fits, but I have had insufficeint time to absorb it
>(alas).
>
>I don't see how building objects out of component's answers his question..
>what components would you build a crystal goblet of?  How does that
>address breaking it?

That's one of the things I have yet to decide on. I am not sure how to
do something like:

Bubba has a bronze longsword. Bubba hears that werewolves can only be
wounded by silver weapons. Bubba, being the kind who does not want to
be killed by a werewolf, goes to the silversmith.

%hold longsword with tongs
You grasp your longsword with some iron tongs.

%dip longsword into vat
You dip the longsword into a vat of molten silver, thus coating it
with said material.

Now what? Ok, sure I could just let people not silvercoat their items,
but that'd be no fun. (Yeah, it's not something that happens every day
but my *ideal* mud is a place where you can attempt almost anything.)

So, so the longsword now has the characteristic of being silver coated.
Its core is bronze, however the outside (visible portions) are covered
in silver, and you would have no way of seeing the bronze.


As for the goblet. It would just be a "goblet-item", made up of one 
piece, which is composed solely of crystal. Crystal would have a tensil
strength of X, and each action would need to do something like:

/* pretend code :) */
void break( object &o ) {
   ...
   effect o.tensilstrength by some damage formula;
   // if the formula results in a number greater than tensil strength
   // then the object is broken. -- each element needs a break message
   // ie: crystal can melt or shater, wood can burn, splinter, etc
   ...
};

Something like that. You'd need to find some way to determine your noise
factor, ie: if it is made of glas primarily, then you would hear more of
a shattering sound than you would a splintering sound from the wooden part
of whatever.

One piece items would be by far the easiest to deal with, as you wouldn't
have to thread through the linked list of item pieces (or however you had
it set up) to determine the resulting sound/effect of the object breaking.

My idea is to give every action effects, picking up something would have a
a very tiny effect on its tensil strength applied to a do_break type of
thing, it would also have some effect on its contents, [shaken not stirred]
and so on, depending on each action. -- For every action, there is an...

[snip]
>composite objects would simply implement a 'dissasemble' verb, which
>allows you to (with sufficeint means) break a composite into its
>components.  'Normal' verbs would simply be passed onto each component:

[snip]

Yes, and above, the silver coating on the bronze longsword would not
be able to be disasembled -- So I guess you would need to decide at
what point in creating/modifying an object, the object no longer is
able to be disassembled. Also, some commands such as:

%pry gem from goblet
You pry a small gem from the silver gem encrusted goblet.

%look goblet
The silver goblet is ..blah blah.. however, it seems to be missing one
of its gems.

I haven't quite decided on how to work with broken objects either.
Perhaps I'd just create X number of "pieces" from the object. So, an
axe handle broken in two pieces would produce two small pieces. shrug.
-Q-






More information about the mud-dev-archive mailing list