[MUD-Dev] Describe module
Vadim Tkachenko
vadimt at 4cs.com
Thu Dec 18 13:15:37 CET 1997
This is a multi-part message in MIME format.
--------------4AE11D7F03AB60D2E8AD6CF3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Stephen Zepp wrote:
>
> DEFINITION:
> module to describe an object to a player dynamically based on features of the object, illumination, perception of the
> viewer, and knowledge of the user, taking into acount actual features and any "spoof", or disguised features.
>
> features_type:
> {
> string_array * format[MAX_ILLUM_LEVEL];/* X amount of char * format, allowing for different
> * illumination levels.
> * format[ILLUM_BRIGHT].msg = "$n $d.#P $e, and $s.#-P #M $a $m.#-M #S"\ * armourer $q #-S."
> * etc., one format string for each illum level */
> feature_val base;
> feature_val encrusted;
> feature_val engraved;
> };
>
> feature_val is your storage method of values of various things relating to the object:
> base : material, general obvious info like stained, damaged, broken, pointy, etc.
> encrusted: things that are "attached" to the object...gems, wrappings, glued on, whatever.
> engraved: sigils, runes, names, whatever might be written on an object.
> format strings:
> how the info is presented for this object. $ values are textual conversions of feature_vals, and # values are
> character specific checks:
> $n name ( namespace or item class type if not named )
> $d general obvious description stuff
> $e encrusted descriptions
> $s sigils, engravings, runes
> $a magical auras
> $m other magical "spells" embedded in the object
> $q quality of the object
>
> #P check char perception
> #M check char magical sight
> #S check specific player skill named in next keyword
> #-<X> close specific check.
>
> END DEFINITION
>
> Okay, now an explanation :) This is a first run design, trying to get some
> brainstorming going, so a lot of things haven't been thought out.
> First of all, an object has a set of real features, and a set
> of "disguise" features. Perception is automatically
> checked for each $ val to determine which to use, and different features
> from each may be noticed ( disguised and real ).
I'de recommend to generalize abovesaid as follows (once again, the
details are on the project pages :-):
- All objects may have several layers of functionality. For example, you
may be able to recognize the computer, as your experience grows, as a:
- box
- humming box
- thinking humming box
- pseudo-thinking humming box
- computer
- computer running, say, Unix
- computer running Solaris 2.5.1
- etc.
Or, as a different example,
- a stone
- a gemstone
- a diamond
- a diamond of unsurpassed magical power
And, your ability to recognize/use the object depends not only on your
perception, but on arbitrary values, different for every type of that
object.
In my implementation, I differentiate such an objects as:
- classes (diamond is a subclass of gemstone is a subclass of stone)
- special objects (diamond of unsurpassed magical power is a special
instance, not class, of a diamond).
Now, the next question is: how would you differentiate the cases:
- when the object with unrecognizable by you features works regardless
of your knowledge;
- when you have to be able to identify the object before you'd be able
to use it.
?
> Zoran
--
Still alive and smile stays on,
Vadim Tkachenko <VadimT at 4CS.Com>
Gradient MUD: http://206.139.13.63/~vt/gradient (URL HAS CHANGED, you
may not be able to see it at all)
--
UNIX _is_ user friendly, he's just very picky about who his friends are
--------------4AE11D7F03AB60D2E8AD6CF3
Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Vadim Tkachenko
Content-Disposition: attachment; filename="vcard.vcf"
begin: vcard
fn: Vadim Tkachenko
n: Tkachenko;Vadim
org: 4C Solutions, Inc.
email;internet: vadimt at 4cs.com
title: Web Developer
x-mozilla-cpt: ;0
x-mozilla-html: TRUE
version: 2.1
end: vcard
--------------4AE11D7F03AB60D2E8AD6CF3--
More information about the mud-dev-archive
mailing list