Issues from the digests and Wout's list

[Shawn Halpenny]

On Apr 18,  2:25am, Ling wrote:
> Subject: Re: Issues from the digests and Wout's list
> On Wed, 16 Apr 1997, Shawn Halpenny wrote:
>
> > On Apr 10,  6:57pm, clawrenc at cup.hp.com wrote:
> > JCL> >3) Skills and skill trees.
> > JCL>
> > JCL> Nathan: I like your recent comment on flat trees without
> > JCL> pre-requisites (eg anyone can *try* to fly, it just won't work if you
> > JCL> don't have wings/rocket assist etc)  Care to expand?
> >
> > Related to this vein, I'm moving towards a model where there are no skill
> > sets, really, just commands bound to particular objects which can be added
> > or removed from a character's immediate environment (inventory, equipment,
> > body).	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.	How I'll determine how good the person is at flying, I haven't
> > explored to much detail (yet)--suffice it to say though that it could get
> > interesting since my "skill" system is a loose, mutated thing that I'm not
> > entirely convinced will do what I want.
>
> 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:
  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.

> 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 :>>

--
Shawn Halpenny