[Crossfire-wiki] [Crossfire DokuWiki] page added: dev_toto:quest_management_system

[no-reply_wiki at metalforge.org]

A page in your DokuWiki was added or changed. Here are the details:



Date        : 2006/06/10 07:59

User        : ryo

Edit Summary: copy of mail to list



(copy of a mail sent to CF  --- //[[nicolas.weeger at laposte.net|Ryo Saeba]]
 2006/06/10 07:58//)



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 k
nows 

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 a
ll 

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 glob
al 

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 wor
ks, 

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 bashin
g 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?), o
r 

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 ad
d 

hooks at a basic level. Also add interplugin communication).

* tracking player behaviour could be resource intensive - that will need
 

testing and addressing if required :)





IP-Address  : 82.236.87.204

Old Revision: none

New Revision: http://wiki.metalforge.net/doku.php/dev_toto:quest_managemen
t_system



-- 

This mail was generated by DokuWiki at

http://wiki.metalforge.net/