[MUD-Dev] Law of Resource Congestion

[Nathan F. Yospe]

ens017 at mizzou.edu said:

> >     I'd like to see something a bit more involved - and I'm actually
> > curious if it's possible.  I can see gaining a sword in a mud and
> > looking at it:

> > "The sword is forged of a dark metal which does not seem to reflect light. 
> > There are several engravings on the blade, along with 7 small rubies
> > arranged to appear as red stars on a night sky.  The hilt is a simple
> > affair, some hide fixed with silver wire ties."

> >     Or that bow from the elf I just slaughtered;

> > "A simple bow of pale wood.  Its string appears freshly waxed and the
> > brown cloth covering the grip has been cemented into place by time and
> > use."

> Where is Nathan Yospe when you need him?  *blink*

Getting very P.O.'ed at his computer...

Between twig's "Save draft" function being not working, and my linux box
going down every few hours (I'm sure it's hardware, but it's maddening),
this makes the fourth time I've typed this reply... fortunately, I had a
screen capture of the first time.

So, for the last time (in a vi session offline), here goes...

First off, the key to assembled descriptions on my system was my natural
language output parser.  The client constructed descriptions, based on a
data representation transmitted by the server, according to requests.  A
cache existed for already investigated items, with detail being left for
specific requests... think of it as binary XML, only more complex and as
capable of encapsulating an algorithm (in matrix extension form) as data
type/content sets.

I'll try to break it down, from memory, in text form.

  Standard data on any item:
    Assembled unit:
      Unit dimensions (typeflag radial/spherical/rectangular; r1/2/3)
      Unit shape (regular approximation, matrix superstructure)
      Primary unit identifiers
      Superstructure of primary units (displacement, relative axis, free
          dimensions/degrees of freedom)
      Visibility of primary units (albedo/reflectivity, radiation with a
          spectral mapping, including secondary unit contributions) (all
          color data where applicable can be gained from this)
      Total mass
    Primary unit:
      Unit dimensions
      Unit shape
      Secondary unit identifiers
      Superstructure of secondary units
      Visibility of Secondary units
      Unit mass
    Optional data:
      Motive (v, a, \/a, algorithmic behavior controls)
      Text tags
      Syntactic database update tags
      Graphical database update tags

It was a nice system... it showed what the client could (physically) see,
and the client decided how to describe that to the user.  Sort of a lower
level subconcious mind below the player's mind, with the hindbrain on the
server side and the subconcious on the client side and the concious mind,
of course, residing in the player.  And the world outside the body, as it
were, also being on the server.  Almost had religious connotations, being
as dualistic as it was...

One of the upsides (the downside was that few things had the desired type
of dramatic effect that the tweaked cases did, and those mainly because I
reseeded the grammar and vocabulary nets until I liked what I saw) was an
unpredictability... I once had a client tell me that there was a woman in
front of me with a gun... that player (and client) had never before seen,
or otherwise learned about, blowdriers.

> Couldn't you just say that the chance of a glass blade (no matter what the
hilt
> is) is very low (just skew the table, if glass has one entry, steel should
have
> ten or twenty)?  Or am I misunderstanding the problem? 

I think he wants to create unique looking items.  I don't find that all
that reasonable, however.  Most swords look alike.

> >     It seems easy but after about 25 I start fatiguing.  Considering
> > you're looking at just one part of just one type of item, you may get
> > frustrated quickly. 

> If you allow players to design their own items you could track item
histories
> (that sword was at the battle of Dragon Field, and it slew a Wyrm there) so
that
> when "famous" items disapear, their custom descriptions might get entered
into
> the global pool (after review, of course).  That way, certain description
parts
> (like the rubies in the night sky, above) have a chance at resurfacing later
> (kinda like JCL's ur-objects).  It is shameless, yes, but if it helps take
some
> load off of the content creators, I like it.  :)

That's something I never bothered with.  Let the players themselves learn
archaeology and history; I'll merely support preservation of state, to an
explicably reasonable degree.  That famous sword would probably not be as
recognizable after lava and rust had deformed it...
 
> >     Any other ideas out there? Something viable perhaps?  Anyone
> > actually even attempt anything like this?

> What I am considering is approaching item statistics from the opposite end:
I
> want to first come up with a decent looking description of an item (rather,
> decent looking short/one line desc), then figure out what stats it should
have
> (when I say "I", I really mean the codebase).  I have not even thought about
> anything approaching the descriptions you had above.  :)
 
> Consider a typical long sword:
 
>     > A dull steel long sword.
 
> Not very interesting; it would take on close to the basic/default stats for
long
> swords.  Consider something slightly more exotic:

> A blade of elven steel, etched with mystic runes along one edge.
 
> This should, in turn, be much more powerful than the plain sword above.  
How? 
> Basically, I will have a table for each basic item class (clothing, jewelry,
> weapons, armor, etc.  The exact table design is left as an exercise ;) that
> describes the effects of words in the description on the stats of the item. 
For
> instance, the weapon table might be:
 
> Table: Swords (Damage types: Slash, Pierce)
> Word   Weight Edge Cost Magic (Ease of enchantment, etc.)

<snip>

If you fashioned, say, a bone-club?  Sort of swordlike, but not enough to
be a sword... flexibility is something to seek out...

> What I really like about this system is that (provided you have the
appropriate
> craftsmen in the game) it allows players to create their own outfits with
> "correct" stats (I used to play on a mud were item restringing was basically
> free, and people would restring good armor into shirts and such.  The above
> system would force people who wanted to wear protective clothing to wear
> something that looked like armor).
 
> If the idea of letting your players make whatever items they want bothers
you,
> you could require that exotic words (mithril, gold, etc.) require an ore of
some
> kind (be it actual ore, or another item with the word, etc.) before the
> craftsman could make the item.  Also, you can limit the number of words an
> individual might know, and have certain words only known to guild/race
caftsmen
> (only dwarven smiths can produce mithril items).
 
> Then, what about player craftsmen...?  :)
 
> I wonder if there is a way to integrate what I have below with your system. 
It
> would be interesting to try...  I think you would end up having to let the
> players fill out at least some of your data structure by hand.  I am not
sure
> how foolproof that process could be, but I think that letting the players do
> that would really tie them to your game.

Player crafters are, of course, a given for me.  The real challenge is to
keep complex craft around.  Guns come from a factory.  That means no guns
from people.  Why?  Well, creating a gun means attaching complex programs
to the object.  Could I allow guncrafting skills to do the same?  Yes, if
I could figure out how to modifiy the initial variables... 

--
nathan.yospe at isearch.com       Born In     Don't mind me, I'm just insane
New home page TBA            The Year of       there's someone else here,
Other contact info            the Tiger                      in my brain.
available by request       Riding it Forever After               -wibble-



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev