[crossfire] Quest management system proposal

[Nicolas Weeger (Laposte)]

Hello.

I'm feeling ambitious, so here's a quest management system proposal :)
Of course, whether I (or someone) will actually implement it isn't yet sure 
^_-


Quests should be finite state automates. Meaning different states, with 
transitions between states, with conditions for those transitions, etc.
Each state would specify special behaviour for NPCs, texts so the player knows 
the quest status and what to do (or at least some hints). Also there would be 
the rewards for completing that state, everything needed.
Transitions should describe what the player should do to actually change 
states.

My idea is to have quest files. Each quest would be one file, describing all 
states, transitions, including all information on what NPC's behaviour to 
change, rewards, and so on.
If required, a quest file could be accompanied by some special maps, 
archetypes, anything specific.

The quest engine would, at start time, read those files, and process them. It 
would then, at map loading time, add revelant hooks to NPCs, or track global 
events (for instance follow player movement to know if they do what is 
required to complete a task).
It would also keep, for each player, quest status, and such.

Advantages I see:
* quest's information is in one file, it's easy to see globally how it works, 
versus today's dispatched in maps, making it hard to look at, and check 
whether it's broken or not
* as a correlary, adding/turning off a quest means moving one file (or a 
directory)
* it wouldn't not rely on the hacks i did for the first basic quest system. I 
don't really like'em anyway :)
* we can think of DM commands to look at quests, know what quest a player did, 
reset quest status. Maybe even dynamically alter quests! *g*
* we can add a quest editor, probably included in the map one :)

Drawbacks, opened questions:
* one could change a map without updating a quest, thus it could be become 
broken - server should try to handle that graciously, and report it in any 
case
* to have a really powerful quest system, and fun transitions (from bashing a 
specific monster to having 3 players do a special dance at a certain time), 
the conditions / transitions will require a full scripting language. So 
either reuse an existing one (Python, maybe? Or LUA? Or anything else?), or 
make our own - I'd favor reuing existing one, to avoid making Yet Another 
Script Language. Though of course if we use Python the Python plugin would 
become mandatory.
* this quest system could be done either at server's core level, or as a 
plugin. Last option would require some changes in plugin architecture 
(basically move plugin handling from server part to common lib part, to add 
hooks at a basic level. Also add interplugin communication).
* tracking player behaviour could be resource intensive - that will need 
testing and addressing if required :)

Heck, I may just start working on that soon if I'm feeling in a good mood :)

I'll add that proposal to the wiki when it's back up, of course, so everyone 
can poke it ^_-

Nicolas