[Crossfire-wiki] [Crossfire DokuWiki] page changed: 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/11 19:42

User        : 

Edit Summary: moved content to "dev_todo" not "dev_toto"



@@ -1,59 +1,3 @@

- (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
 knows 

- the quest status and what to do (or at least some hints). Also there wou
ld 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 t
o 

- 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 the
m. It 

- would then, at map loading time, add revelant hooks to NPCs, or track gl
obal 

- 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 w
orks, 

- 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 syst
em. I 

- don't really like'em anyway :) \\

- * we can think of DM commands to look at quests, know what quest a playe
r 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 beco
me 

- broken - server should try to handle that graciously, and report it in a
ny 

- case \\

- * to have a really powerful quest system, and fun transitions (from bash
ing a 

- specific monster to having 3 players do a special dance at a certain tim
e), 

- 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 Anothe
r 

- Script Language. Though of course if we use Python the Python plugin wou
ld 

- 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 :) \\

- 

- ----

- === Comments ===

- Umm the path for this page should probably be "dev_to**d**o:quest_manage
ment_system" not "dev_to**t**o:quest_management_system"

- 

+ ====== Page Moved ======

+ Because of a spelling error in the title, this page has been moved to [[
dev_todo:quest_management_system|dev_todo:quest_management_system]].

  





IP-Address  : 24.55.181.141

Old Revision: http://wiki.metalforge.net/doku.php/dev_toto:quest_managemen
t_system?rev=1150054567

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/