[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 00:34

User        : 

Edit Summary: Added line breaks to match the original email



@@ -4,14 +4,16 @@

  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 

@@ -19,34 +21,34 @@

  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:

+ 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

+ whether it's broken or not\\

  * as a correlary, adding/turning off a quest means moving one file (or a
 

- directory)

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

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

+ reset quest status. Maybe even dynamically alter quests! *g* \\

+ * we can add a quest editor, probably included in the map one :) \\

  

- Drawbacks, opened questions:

+ 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

+ 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.

+ 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).

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

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

- testing and addressing if required :)

+ testing and addressing if required :) \\

  





IP-Address  : 65.165.40.73

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

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/