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 :) _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire