[crossfire] Quest management system proposal

[Mark Wedel]

Nicolas Weeger (Laposte) wrote:
>>   Looking at that, and looking at your example, it seems hardly really
>> clear to follow.
> 
> After some thinking, having a Python script handle the dialog seems the best 
> way, actually :)
> 
> This way, the whole dialog is written into the Python script, including the 
> logic.

  I'd rather not have the NPC conversation be in python.  IT has long been 
discusses that the NPC conversation needs to be improved, with things like 
conversation states, etc.  This is unrelated to quests in particular - just a 
general good thing to do.

  IMO, having some basic scripting syntax for states in the message/endmessage 
would be a good thing - after all, map makers are people that would be using 
that, and at current time, there isn't a requirement that map makers also be 
programmers.  I suppose and answer could be 'just copy the npc script from 
elsewhere' to the less technical map makers, but I'm not sure that is a good answer.

> 
>>   I think that for the NPC state data, that should probably be stored in a
>> force object that expires after some amount of time (like 1 minute
>> real-time after last update).  After all, other players may interact with
>> that NPC, and state should reset for them.
> 
> I'd say each player has his/her own state, so they don't conflict.

  OTOH, for NPCs, such conflicting/local state may make sense.  If you think of 
a case of a couple players talking to the same NPCs at the same time, it would 
make perfect sense for the NPC to progress the conversation as it perceives it - 
if the npc responds differently to 'foo' based on its state, and player a says 
foo, npc responds, then player b says foo, the npc should give its second answer 
to foo.

  This also makes sense that anything the NPC says can be heard to anyone near 
by (it isn't just at the player).  This is why I was thinking NPC's should have 
some limited state just for general conversations (the case this really covers 
is when you should be able to keep saying 'yes' to the npc to get more info, but 
the current mechanism doesn't allow that, so instead players have to start 
guessing what is the word to continue the conversation).

  There certainly should be state information for the player itself related to 
npc conversations in some cases (especially quests).


>>   I'd put using a python script near the bottom.  Not that python is
>> inherently bad, but I think for developer reasons.  In theory, the entire
>> crossfire server could be in python - that obviously won't happen.  But
>> given that the server is currently in C, it is quite reasonable to expect
>> all developers to know C.  But if there are bugs/improvements that need to
>> be done to the script, but the developer doesn't know python, not sure
>> where that really leaves things.
> 
> I'd say you underestimate developers :)
> Scripting wouldn't require many functions in Python, just basic ones, and any 
> C developer would feel at home looking at the logic imo.

  It seems like every year or so, the discussion of what should be in C and what 
should be in plugins shows up, and this is sort of one of those.  I suppose we 
really should come up with a standard and document it.

  But some also goes to above - the people who will use quests are mapmakers. 
Should it be a requirement for mapmakers to know python/have scripting skills to 
use many of the handy features of crossfire/map maker?

  If the answer there is yes, then no real issues.  If the answer is no, then we 
perhaps need to revisit if python is the best solution.

> 
>>   As a note, the ability to give such rewards just in general could be nice
>> not really related to quests.  Drop an item, get some exp reward, etc.
> 
> This can already be done, via a Python script for instance. Unless I'm 
> mistaking what you mean?

  Sort of goes to the same question above - what skills do developers need.

  That said, it may be reasonable to have some set of basic scripts that do 
basic actions (add exp, etc) - in a sense standard scripts that map makers can 
use without having to know scripting.  they just need to be well documented.

> So what I'd do is:
> * remove existing quest system, which is a bastardized version
> * write a Python "quests" command, with a few parameters (to get descriptions 
> and so on)
> * write a few Python scripts to help write quest scripts and manage quests and 
> such
> 
> Then it's just a matter of writing Python scripts to handle quests :)

  One question completely unrelated to this - would it make sense for the 
scripts themselves to be located in the same directory as the maps itself?

  For example, right now, all scripts are in python/....

  This makes it a little harder to have modularized maps (I just can't tar up 
'mwedel-newmaps' and send it out) - I also need to tar up the appropriate files 
within the python directory.

  If instead, I can have 'mwedel-newpaps/script1.py, ...' that is more 
convenient.  And I'd imagine it probably wouldn't be too hard to modify the 
python loader to look for scripts in the same directory as the map itself.