Issues from the digests and Wout's list

[clawrenc at cup.hp.com]

In <199704181454.OAA453910 at out1.ibm.net>, on 04/18/97 
   at 02:25 AM, Ling <K.L.Lo-94 at student.lut.ac.uk> said:
>On Wed, 16 Apr 1997, Shawn Halpenny wrote:
>> On Apr 10,  6:57pm, clawrenc at cup.hp.com wrote:

>> ...For example:  the only people who can attempt to fly are people
>> who have wings or a rocket pack.  The reason they can attempt it is
>> because the "fly" command is built into the wings/rocket pack, which, when
>> added to the immediate environment, bestow the "skill" on the character by
>> giving them the fly command in this case.  No one has to go "buy" their
>> flying skill, they just acquire the means to make it possible. Then as
>> they attempt to use the command, the code for the command is responsible
>> for handling all the variables used to fly.  I don't know if that was very
>> clear...

>Erm, that's icky.  That's the way the original LPs (and many current
>ones) do it.  A verb is, by default, associated with an object. 
>Drink would be associated with a glass.  The glass checks it's own
>state and etc.  It's been dropped in favour of a universal parser,
>the underlining concept being that a player typing 'drink' will get: 
>Drink from what?  as the error message and know that the verb can be
>used in the entire game.

Actually I understand current LP's do a mix of a global parser (drink
is avilable everywhere), and verbs bound to unique objects, but that's
another matter.

I'm a big fan of having verbs bound directly to their target objects. 
It works, its simple, its efficient, and it allows useful pre-parsing
by template ala ColdX.  The disadvantage as you write is the lack of
global defaults for common verbs like "drink".  

Happily this can be fixed with a touch of LP's parser layer concepts. 
Have the same verbs-on-objects that MOO, ColdX, and old LP's use, use
ColdX's template concept (a grown up version of MOO's), and then given
such template value weightings.  In my case I assign a weighting to
templates from 0 - 255.  Matching verbs/templates are searched for in
the normal manner (player, inventory, room etc), with the first
matching template which weight is over 128 accepted.  If no matching
templates are found with weights over 128, then the heaviest template
(largest weight) closest (least removed ala player/inventory/room) to
the player is taken instead.

This allows a drink verb to be directly and usefully bound to the cup
while still allowing a semi-intelligent default "Huh?" drink verb to
be bound to the player, master object, or similar for a global sense.

>I think it would be better to define that the jetpack has the ability
>to fly and has n units of fuel with an efficiency of so and so
>percent, etc.

And thus you get state flags and all the endless horrors and nastiness
that they bring.  No thanks.

>In the spirit of random thoughts attached to the end of the message,
>given that I have a 3D environment, should I treat time as real time? 
>That is, my characters can move at 10 metres a second (they're all
>good sprinters) and I have a field 500 metres across.  Do I have the
>players run at real time?  A mere 50 seconds to leg it across, in
>fact, what speed should I run my mud at?  I've been toying with the
>idea of multipling the gametime by a single digit number like 6. 
>That would reduce the 50 second sprint down to 8 seconds. 
>Alternatively, I could have my characters move 'instantly', if the
>player hasn't moved recently, then she travels the first 30 metres
>without any time delay...  It all gets terribly messie.

I don't attempt to resolve time much at all as far as player events
are concerned.  I don't do things like enforcing the speed of walking
etc.  If the player can etner twenty "north" commands in 2 seconds,
and get the server to compleat those commands as well, well, it will
work.  The exceptions are certain commands whose compleation is
inherently timed.  How long "Dig panama canal" takes etc.  These
things are measured diurectly in MUD time.

>Btw, just thought of something:  If a character executes time
>consuming action like trying to debug a program, the player could
>type: 'then buy a can of coke'  which would be queued and executed
>later.  Imagine this for the above system, someone would have to be
>insane to type:  'run to the house and slam the door' when under
>pressure, typing 'run to the house' would set the action off and get
>the character legging it for cover and 'then slam the door' would
>make the character flick round, slam the door immediately after.  A
>sort of primitive combat script.

I also allow player commands to not be required to be executed in
sequence.  Thus the player can do:

  > run to house
  You begin running to the house.
  > shut door               // Command will be executed after "run"
  Okay.
  > !shoot at bad guys      // Command will be executed asynchronously
  You shoot at the bad huys.
  You have reached the house.
  You shut the door.

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...