[CF-Devel] Crossfire Scripting language

Mark Wedel mwedel at scruz.net
Wed Apr 18 22:49:56 CDT 2001


Peter Mardahl wrote:
>
     
     
     >
     
      The consensus is that a scripting language of some sort for
     
     >
     
      crossfire would be very nice.  Beyond that, nothing's been
     
     >
     
      decided.  Furthermore, no one has volunteered to spearhead
     
     >
     
      this project, so in practice, it has gone nowhere.
     
     
 correct.  There are lots of things on the TODO list or that have otherwise been
discussed which is just waiting for someone to do them (or for one of the
current developers time to free up).

 My personal thought is that the language for the scripting isn't very important
- I don't see the actual scripts being really complicated.  What is going to be
the big issue is how the scripts can interact with the server code itself.

 For example, I see the following abilities of the scripting language to be
relevant:
 take some object
 give some object
 cast a spell
 move to some location
 say something.
 listen for something
 watch for something

 given this, I have a feeling checking status of most of these will make up the
bulk of the program.  Beyond that, I would see a pretty simple if then/else if
type structure.  ie:

 heal = listen_for_something("heal me");
 money = take_some_object("500 money")

 if (heal) {
   if (money) {
	say("I hope you feel better)"
	cast_a_spell("healing")
    }
    else {
	say("Healing will cost 500 silver");
    }
  }
  else {
   say("How can I help you?")
  }

 Now the above does get into nesting and checking, but is not so complicated
that we probably need features of most languages (ie, I doubt we will need
arrays, hashes, or many other things).

 As I was thinking about this today, I realized the other issue is how to store
these values accross map saves.  you may have something like:

 if (listen_for_something("password")) {
    if (given_away_object) { say("Sorry - I don't have that anymore") } 
    else {
	say("Use this for the betterment of good");
   	give_some_object("artifact");
	given_away_object=1;
    }
}

 now artifact would start in the npc's inventory, so once he's given it away, he
can't give it away again until the map resets.  However, between the time the
map saves and it resets, if another player visits, we probably still what
given_away_object to have the right value, so we get teh first message (I don't
have it), instead of the second (use this ...), as the player won't be able to
get the object.  so given_away_object has to be stored someplace.

 My idea would be to use just a generic object, with perhaps a type like
'npc_var_holder'.  the set and check for variables would use that object. 
Variable names would have to match the names in the structure, but using such an
approach means the state can accurately get saved, and gives a lot of variables
to play with (including some strings and floats for example).  So in my last
example, you could even set some field to the character the object was given to,
and adjust the given_Away_object case to be like 'I've given that to $name' or
the like.


 So in short summary:  I don't think the language itself will make a big
difference - what will really make the difference is how easy it can interact
with the C code.

 My personal preferance would be perl for the following reasons:
1) Perl is already required by crossfire, so if we need to link in any perl
libraries, they are already installed.  This may not be the case for python or
other scripting languages (this is not a big deal if the scipting language has
all the parts it needs with crossfire)
2) Going with #1, there may be more perl knowledge with people dealing with
crossfire.  Ie, to develop, you would only need to know C and perl, which means
that more people could potentially fix/help in scripting issues (say a broken
npc), compared to using some other language which then means the developers need
to know 3 or more languages (but this may noot be a big deal, as the scripting
language may not get complicated enough).

    
    


More information about the crossfire mailing list