[crossfire] Quest management system proposal

[Nicolas Weeger (Laposte)]

>   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).

Actually, it seems to be kind of uptodate, since it generates data from 
archetypes and such.
I'd be more inclined to keep it - spoilers, handbook and such are nice. Also a 
list of gods is nice to have locally.
(could be used to make PDF manuals distributed with client)

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

True. But at some point people will want more than what the message/endmessage 
offers, so we'll be back at square one - either use our own scripting 
language, or an existing one.

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

Yes, if dialog is a state automate, it could be created through dialog boxes.

>   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'.

Scripts can be put in any directory :)

>   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

Yes, but there aren't many scripts around - the IPO, a few related to guilds, 
casino, misc. They should probably be documented, yes.

Note that right now you can't easily directly add exp to a skill, but imo 
that's a function to be added. Will try to do that at some point.

>   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).

True. Then maybe editor could be extended to know about Python functions, and 
our built-in stuff :)

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

But at some point there will need to have a developer involved, when the 
script starts to become complex.

Yes a mapmaker could, with a simple script, make a quest to have a player 
deliver an item from one NPC to another. But to check whether 5 players do 
the Holy Dance of Purification correctly to finish the temple cleaning quest, 
you'll need more than what message/endmessage offers :)

I agree though we should try to make it the easiest for mapmakers, by offering 
the more easy functions to access.

Nicolas