[crossfire] Quest management system proposal

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:

> The issue I see with this is that it adds Yet Another Scripting Language to 
> Crossfire...
> Right now we're using C, autoconf/autotools, LaTeX (documentation - is it 
> uptodate, actually??), Perl, Python, NSIS (Windows installer).

  Latex stuff could probably go away - I don't know the last time anyone updated 
the tex stuff (but to be fair, not sure last time any documentation has been 
updated).

> 
> Adding Crossfire's Scripting Language would add some complexity, including 
> making sure we don't break that, add features mapmakers will want/need, and 
> before we know we reimplemented an existing language :)

  OTOH, we are talking a very basic scripting language here.  If we want to be 
technical, we could say the existing message/endmessage stuff if some very very 
basic scripting language - its just simple enough that it is easy to for anyone 
to use because it has very few options/commands.

> 
> What could be done, though: let mapmakers write messages with an extended 
> syntax, like you suggested, and have a Python plugin/script handle that 
> internally (or handle it in server core, but that's less easier to switch i 
> think).

  One thought I did have is that the map editor could be modified to make use of 
such scripting easier.  Have something which says the variable name, whether 
that is a player persistent variable or not, what operation to use (<>, =, >=, 
etc) and what value to check against.

  Likewise, another dialogue/option could be similarly used to set variables.

  Not sure, but one issue with the scripts right now is that they live in a 
separate directory, so if the map editor creates them (which would be an 
option), the map developer would have to know 'also include so and so script'.


> All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython
> True, it could use some examples and such.

  But that just lists what you can use in writing a python script.

  It doesn't say what scripts may be available for use already and how to use them.

  For example, if the method we decide to go for is that we will use scripts to 
give out exp, then it probably would make sense to have a generic script that 
takes some parameters on what skill and how much exp to add, so you could do 
something like:

event_activate give_exp.pyc throwing 6000

  (no idea if that is really the correct syntax, but you get the point).

  If that is done, then the give_exp.pyc, and other general purpose scripts need 
to be well documented so people know about them

  That is one advantage of archetypes - while it may be hard to find something, 
they are all available in the editor, and the editor provides customized 
dialogues based on type.  So if there was an exp giving archetype, the editor 
file would be modified to ask for the skill to give, how much exp to give, and 
perhaps some other parameters (all members of the party, etc).

> 
> OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the 
> list or IRC would get some help.

  True, but I'm not sure if that is indication of a good design/easy to use system.

  Most people want instant gratification - if they have to wait hours or more to 
get the answer for something like 'how do I give an exp reward to a character', 
they may get a bit discouraged.

  And just going forward, it doesn't seem like 'get a developer to help you 
write your maps' isn't really the right thing to say.  This is why I push for 
the idea the common/general purpose operations should be in the core server with 
archetype attached to it, so it is easy for people to use.

  Of course, an archetype with a script created could be made, with certain 
fields of that archetype containing the skill and exp.  But then you start to 
ask, if we're going to do that, why don't we just write the C code?