Issues from the digests and Wout's list

[Jeff Kesselman]

I also use a hireacrhical parse with versb atatched to obejcts.
Each object has both an internal and external list.
An obejct can access its own inertnal list, its parent's inertbnal list,
its children's external lists and its neighbors' external lists.

Thsi simple mechanism turns  otu ot very effectively model a wide varitey
of decision situations for verbs. 

JK

At 12:21 PM 4/19/97 -1000, you wrote:
>On Fri, 18 Apr 1997, Shawn Halpenny wrote:
>
>:On Apr 18,  2:25am, Ling wrote:
>:> 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.
>
>:> 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.
>
>:That's what happens.  The reason the jetpack has the ability to fly is
>:because it has the "fly" verb defined and associated with it.  If the
>:player has no jetpack on, he can still type fly and if his character has an
>:inherent ability to do so, he will be able to (or try if he's a fledgling
>:at it).  Verbs are bound to the character as well, where the verbs
>:associated with objects in the character's immediate environment are
>:checked before any of the verbs the character has built in (an override).
>:Having verbs only bound to the objects you're interacting with makes things
>:like "build house" difficult since there's no "house" you're interacting
>:with.  In this case, the "build" verb is bound to the character, and it
>:does its own checking whether or not the character has what it takes to
>:build a house.  Verbs bound to a character are available in the entire
>:game.  There are cases, though, where I don't want the verb available the
>:entire time, since it won't make sense in some contexts:
>
>I do have binding of verbs to just about any object in the game, but I
>think it is vastly overused when it is used. I cannot stand tiny muds for
>exactly this reason, and LPs with a mixed system seem to be enthusiasticly
>in favor of the bound verbs, instead of the global verbs. The overwhelming
>majority of character verbs are staticly bound to the character object.
>
>:  Bubba kills a mobile and takes its biomech arm, which also happens to
>:have a flamethrower embedded.  He gets this arm attached to his body.  Now,
>:the "burn" verb is tied to the arm, and since the arm is in Bubba's
>:immediate environment, typing "burn x" will cause the "burn" code tied to
>:the arm to do its thing.  Yes, there's a sort of scope-override issue here
>:if there is an object in the environment that accepts the same verb as one
>:already defined in the player (provided one or the other is desired at a
>:given time), but I'm not bothering with that just yet.  Of course, if Bubba
>:didn't have the arm, typing "burn x" would not even prompt Bubba for what
>:he'd like to burn, since he cannot "burn" by default:  a feature of the
>:interface, because I don't want people to have a set and discoverable list
>:of verbs available to them.  I want them to find things and muck with them,
>:trying to figure out what verbs activate them.
>
>OK, say you had two arms, made by different builders, one with "torch",
>the other with "burn"... incidentally, my approach to this is:
> > define burn $target {target $target with right arm/activate cannon in 
>   right arm}
>Which makes a nice permanent alias.... it could be "x target" instead, or
>whatever else... of course, typing "kill target" will, if that arm torch
>is your prefered weapon of choice, do the same. 
>
>:> 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.
>:
>:Time systems don't matter much to me--there isn't really a distinction
>:between running and walking, insofar as "how much time does it take to
>:travel n meters" is concerned.  I'll just end up adapting my cosmology to
>:how it's done.  Less work that way, and it's believable by definition :>>
>
>My ratio is 20:1, which I find reasonable. I do have movement time...
>
>   __    _   __  _   _   ,  ,  , ,  
>  /_  / / ) /_  /_) / ) /| /| / /\            First Light of a Nova Dawn
> /   / / \ /_  /_) / \ /-|/ |/ /_/            Final Night of a World Gone
>Nathan F. Yospe - University of Hawaii Dept of Physics - yospe at hawaii.edu
>
>