[crossfire] Quest management system proposal
Mark Wedel
mwedel at sonic.net
Mon Aug 7 02:11:17 CDT 2006
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.
More information about the crossfire
mailing list