NPC scripting language (again), was Re: CF: BUG: Morks Tower

[Mark Wedel <>]

Jan Echternach wrote:
> 
> '@connected' would allow proper implementation of #1, and map desingers
> could better restrict the possible ways if they want to.  It doesn't
> remove any alternatives.

 Neither does using magic ears, which is currently done.  Using magic ears also
doesn't have any problem with map locality, as the ear is not going to move.

 I will note that adding connected values to monsters only reduces the effect of
the original bug (can't be standing too far away) but a minor amount - monsters
have the same listen range as the magic ear does.  In fact, you could just put a
magic ear under the monster and it really works out OK.


> An action like '@pull_lever <number>' could even cause the NPC to
> trigger a handle with the specified 'connected' value only if it is
> standing on it, which would be the ideal solution for Mork - if Mork
> has left the place where he was standing, because he tried to kill a
> player or because he was frightened, he doesn't open the door anymore,
> and the player must take alternative #3.
> 
> A real script would be better, of course.  ;-)

 Of course.  However, I would much rather add the @pull_lever code than
@connected code - the former doesn't have any problems and I think is the right
way to go into the future.

 What has been a problem for crossfire in the past is an implementation that
adds some desired functionality but not in the right way - something that fixes
the immediate problem but down the road will have to get redone/pulled out.

 At the current developement time in crossfire, I would much rather things be
implemented in the correct way off the bat.  Several reasons for this:

 1) In the long run, it reduces work as the code is only written once.
 2) It does not introduce incompatibilites down the road - for example in the
@connected - down the road that would get changed to @pull_lever and/or @give,
and if that breaks anything, you can be sure people will complain.
 3) It gets the functionality in sooner - if someone sees code that sort of does
the job, they are not likely to improve it, where if the code just doesn't exist
at all, it is more likely to get written.

 This goes back to many discussions on a better scripting language for npc's
(and whether to go to something really sophisticated or not).

 However, in my book, a fairly simple language would do.  A simple outline of
what would probably be enough for most cases currently in the game and add
more.  This is roughly in order of importance (IMHO) that they should be done
in.

 @match:  Matches a phrase, and executes the command that follows it.  Perhaps
an @endmatch is needed so that something can do multiple options, although and
easier way might just to have @match matching multiple things.
@say - remains as is.
@pull_lever (number/name)- pulls the lever below the monster.
@give (object name) - gives (drops it in a free space adjacent to the monster)
the given object.  Useful for giving keys (or other quest items) to players
@clone (object name) - like give above, but instead makes a copy of the object
and gives it to the player (inserts in inventory).  This could be useful for
things like experience rewards and skills - instead of having @grant_exp or
@give_spell, this just gives any arbitrary object type.
@take (ojbect name) - like @match above, this then activates an action below
it.  If a matching object is dropped next to the npc, it takes the object and
falls through.  However, I can't think of a really efficient way to implement
this - we probably don't want the npc to be examing all the spaces around it for
any object each time they change.  This could perhaps be limited to only
checking actions on the monsters turn, which could reduce frequency.
@set <val>, @match=<val>, @take=<val> - add states to the engine.  Set sets some
value, while the @match= and @take= only match when the state value is the same
and the other parameter (match words or item) are also proper.  This allows for
much more intelligent npc conversations - for example, and npc could be telling
a long tale, and ask 'do you want me to continue', and you say yes, he continues
along, and then asks 'do you want to here more', and player says yes and gets
more new text.  There is certainly npc in the main inn where the conversation is
hard to progress because you have to try and pick the keyword that will keep the
conversation going.

 That above is a pretty simple system yet covers most needed actions.  I guess
you could add @cast <spellname> so that you could have NPC clerics cast spells
and the like.

 There has been talk about having npcs move around, walk town to town, etc. 
While that may be nice, I think it adds a lot of complexity to the scripting
language and really doesn't add much unless you have a really good script.  In
some of the computer games I play, there are npc's that wander around, and it
becomes apparantly pretty quickly that it is a simple movement script and isn't
really that interesting to watch.  You could add some simple move types that
would be much more interesting.  ie:

1) move 4-16 spaces in direction X.
2a) If make contact with NPC, both pause for 4-16 actions.
2b) see if there is anything on ground to pick up or anything interesting
immediately around (hostile monster or treasure) - if so, change course in that
direction
3) goto 1

 That is more intelligent than many of the games I play, and could be
implemented within the game pretty easily.  One problem with any scipting
language is that it would really need access to the internal server structures,
and if you are going to do that, it probably makes just as much sense to make
some native functions for various actions - at least some of the interesting
npcs.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]