[crossfire] Quest management system proposal

[Nicolas Weeger (Laposte)]

Hello.

I'm resurrecting that topic :)
(long mail warning)

After much thinking, I've changed my mind. IMO a quest management system could 
very well be written in Python, with a few improvements to the plugin system.

What I'd add:

First, extend the NPC dialog system.
To enable more interesting dialogs, add some "parameters" after the @match 
line, to build a graph-like system.
Two things:
* @name <name> which would give the step's name "activated" when player says 
the matching
* @follow <name> which would be the required step to actually have a match

<name> would be any arbitrary name, with an optional * in front.
No star => step is NPC specific, and thus step info is stored in NPC's 
inventory
Star => step is player specific, and thus stored in player's inventory


Let's illustrate that:

--------------------------------
Random NPC:

@match hello|Hello
@name h
Hello, what a bad weather, isn't it?
@match weather
@name w
@follow h
Yes, lately the weather's been really bad, people are starting to talk about 
curses and such
@match curse|curses
@name *weather_curse
@follow w
A witch living nearby said there was something about seeing curses.
---------------------------------

For the witch:

@match hello|Hello
Hello stranger
@match curse|curses
@name c
@follow *weather_curse
Yes, my crystall ball shows me curses around this area
@match can I help?
@follow c
If you find the source of the curses, everyone will be very glad!

--------------------------------

This way, player must talk in a certain order to NPC before having the witch 
reply to "curse".
And of course you activate the quest when player asks if she can help ;)




For the quests, I'd do a plugin (or a Python script) to manage quest steps and 
rewards on a player-basis.
The quest description file would include much information, but individual 
conditions to change steps would be in the maps themselves, through the 
events system.

Something like:
arch npc
x 10
y 10
arch event_kill
title Python
slaying /python/quests/myquest/boss_dead.py
end
end

and boss_dead.py would be approx:

import Crossfire
Crossfire.QuestStep( "kill_boss" "boss_killed" )


the quest system would look for step "boss_dead", and update player's status, 
give rewards, and such.



Using the Python/plugin system to specify transitions is imo powerful, you can 
write pretty complex things with scripts (trace player position through time, 
things like that).



I would personally include some Python scripts themselves in the quest file, 
for instance a script giving reward at quest end (Player.GiveExp hiding, 
5000), again to be able to do complex things.


The quest system will be responsible for ensuring player hasn't done the 
quest, and is doing steps in the right order, things like that. Would also 
manage party (so when a player starts a quest, all party members on same map 
start too, for instance).


There are some caveats, though:
* quest information will be dispatched between many maps, even if quest file 
could contain all information (duplication, in this case)
* also, what should happen when players having done different steps of a quest 
party together and do a quests's step? All players move to new step (unless 
they are at a next step already), players not having done previous steps 
don't gain anything?
* doing quest would request Python scripting (unless we add a quest-specific 
basic language, like: "give hiding 5000" for rewards)


Here's a small quest file example that could be done:

quest kill_boss
description
You must kill the evil boss that sends minions to the town
enddescription
transition boss_killed end
step end
message
Congratulations, you killed the evil boss!
People in town rejoice!
endmessage
reward
give exp 5000 hiding
endreward
endstep



For some NPC add an event in Python saying:
import Crossfire
Quests.Start( "kill_boss")

and add a event_kill to the boss (see above)

Ok, this probably needs formalizing, but I'm sending to have preliminary 
opinions :)