[MUD-Dev] Re: Levels versus Skills, who uses them and when.

[J C Lawrence]

On Thu, 14 Jan 1999 20:36:54 -0800 (PST) 
Matt Wallace<matt at ender.com> wrote:

> Incidentally, we also use this for a great deal of permanent
> memory features, allowing our builders to (as part of builder
> defined mob/obj progs) set, clear, and check bits from another 8k
> (they get those bits matching their vnums), which is "remembered"
> between sessions, they can use for various purposes. Quest
> results, whether a player has assaulted a certain race of mobiles,
> perhaps -- whatever strikes their fancy.

I have a concept I call "probability fields".  In essence these are
arbitrary collections of weights attached to objects or areas
(bounded volumes of space) which are applied to probability
computations.

  Translation: An object, or an area (part of the game) can change
the balance of "luck" for anything relating to it.  There are many
flavours of "luck" (eg combat strike, combat defend, injury,
lottery, etc), each of which can be affected by this "change" in a
positive or negative manner.  Additionally such luck may be tied
very specifically to particular forms of actions or those involving
particular objects ("You will be lucky with XXX.").

Thus, for instance a "lucky sword" could increase the players chance 
of getting good strikes, etc.  

The intended use of this is to create "lucky areas" and "lucky days"
for players.  On some days it would seem that nothing could go wrong
for a given character.  On other days it might seem that nothing
could go right.  The underlieing intention was to track player
behaviour against an "desirable play style" scale, and thus move
their luck modifiers about accordingly.  Further, the underlieing
base field monitors practiced limited positive feedback -- good luck
(positive returns from probability computations) tended to feed back
into higher luck field weights, with bad luck similarly feeding on
itself (the positive feedback is needed to make sure the pendulum
swings and never really rests; other factors are used to damp the
rate of swing (mainly trigger values)).

  Player does something an admin really doesn't like, but the admin
can't be seen to be intervening?  No problem: Just touch the guy's
probability fields and give him a hard time in such areas in future.

It doesn't handle the problem, it just influences the default.  The
other big part of the intention was to make luck, and the perception
of luck, something that players could be indirectly aware of,
influence, and attempt to (poorly) control, thus adding a silent
third handl to most interactions:

  > i
  You are wearing impenetrable ultimate armour and are wielding 
  the sword of insta-kill.
  > stats
  You are feeling pretty unlucky.
  > l 
  Bubba is here.
  > l at bubba
  Bubba looks like an utter wimp and is carring a rutsy butter
  knife.
  > look at bubba's luck
  Bubba looks incredibly lucky.
  > say, "Oh shit!
  > flee!

Anyway, to get back to the point, the problem of course is storage.
There are several dozen different probability fields.  Additionally
some affects on probability fields are temporary (eg a player can
cast a luck spell on himself or another, giving the target an extra
dose of good/bad luck of a particular type for a defined period), or
are subject to or otherwise affected by external influences ("You
are lucky with women as long as they don't have red hair.").  The
result is that I need dozens of values stored, each of which is
supported by a database of potentially active calculations (ie
volatile values which need to be re-computed on every query) etc etc
etc.  Ugly.  Expensive.

Final implementation:

  Probability fields are stored in the following structures which
are attached to objects or bounded spaces:

    1) A tuple which contains two lists and a timestamp as to the
last time the list in #1b was updated:

      a) A list of records, each containing a list of tuples each of
which contains a probability field name, a qualifying call, and
either an absolute weight or a call that reutrns a weight.

      b) A list of tuples, hashed by probability field name.

        i) Each tuple stores its name, the current summated weight
for that field (last query), and a list of references to entries in
the #1a list.

Originally this was all accomplished via spoofs and having the
spoofs mutate the probability calculations on the way thru to the
base object.  That proved extremely expensive at runtime as well as
exposing horrible potential leaks in spoofs which failed to clean up
after themselves when they fell out of scope/validity.

Using the above dynamic database approach is more complex and far
less generic, but also works.  Further, as repeated and rapid
probability calculations can be expensive due to the many qualifying
and/or weight calls (#1a), the timestamp in #1 is used to have #1a
and its supported #1bi only recalculated periodically (I think I'm
using 50 seconds as my current cap) or upon significant state change
in the object the whole mess is hung off (currently not
implemented).  The result is that most probability chekcs of course
only reference #1bi, which is pretty cheap.

--
J C Lawrence                              Internet: claw at kanga.nu
(Contractor)                             Internet: coder at kanga.nu
---------(*)                    Internet: claw at under.engr.sgi.com
...Honorary Member of Clan McFud -- Teamer's Avenging Monolith...