[CF-Devel] Crossfire Scripting language

Mark Wedel mwedel at scruz.net
Sun Apr 22 23:07:40 CDT 2001


 I agree that we don't need a full fledged scripting language.  

 To me, the big question (which I don't know the answer for) is how hard will it
be to integate one of these other scripting languages into crossfire.  You could
very well get into some for of tradeoff, like:

roll our own basic scripting language, which is really well integrated with
crossfire (as it would use things like @apply and what not, so our interperter
would know to directly call the appropriate function with appropriate args,
which basically means we need to write the interperter, but not the item
actions)

vs:

We use some other interperter, but have to add glue so it can use the internal
crossfire objects (ie, apply, pickup, drop stuff).  This may not be too bad if
it can use an abstract interface, ie using a call that takes a generic string
command like a player may use.

 There are of course advantages and disadvantages to both beyond just the above.

 If we use someone elses, it means that there is a very powerful language (but
what exactly it can do will largely depend on how well it can access crossfire
objects.  For example, if the script can't access the map, knowing to do the
right thing about earthwalls won't help if it can't find the earthwalls).  There
is also the problem of someone potentially creating a very complicated script
which is needed (ie, key npc) but difficult for anyone else to ever modify (and
for a new map maker, who decides to look at said npc to see how to do things,
may get overly discouraged by the complexity).

 I also have some worry about the scripting language performance (just in terms
of how much cpu time we will be spending executing scripts), but more worrysome
is issues like the script getting in some infinite loop.  Granted, that means
the script is broken, but that basically means every scripted npc has to be
evaluated to make sure they don't do anything bad - this makes adding new maps a
little harder.  The advantage of using our own is that the script language could
certainly lack looping features, so other than it getting called really often,
it can't really harm the server.

 To get back to the original question, and something that may be at least
partially related here, one thing that may help determine what abilities the
scripting language needs is some idea of what people want npc's to be able to
do.  Now less keep the ideas realistic here - while theoretically possible to
write an npc scripting language so npc's could adventure on their own, I
wouldn't expect that to happen.

 While it may be nice for enemy monsters to have scripts for tactics, that may
not only get tricky (as script would need to be a lot more complicated), but it
may make just as much sense to improve hte monster movement code to look forr
some events.


 So to me, the short list of things it might be nice for npcs to do:
1) listen/talk to player.
2) give/take items from player.
3) become friendly/agressive towards player.
4) cast spells on player.
5) be able to move to specific coordinates within the same map (in this way you
could create a script such that the npc wanders around).  Currently, only
players use exits, but conceivably, we could allow npc's to use exits, so the
npc could traverse maps by going to the correct exit on one map and applying it.
6) apply and unapply items.
7) Perhaps some specials not allowed to player, like teleport to other map or
specific coordinates on same map (in this way, for example, you could have a
dragon guarding a pass, and given the right events, he 'flys' away and lets the
party pass.

    
    


More information about the crossfire mailing list