[Crossfire-wiki] [Crossfire DokuWiki] page changed: dev_todo:quest_management_system

[no-reply_wiki at metalforge.org]

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

Date        : 2006/11/24 22:48
User        : rednaxela
Edit Summary: Fix newlines

@@ -22,34 +22,17 @@
  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*
+   * 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 reusing 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 :)
+   * 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 reusing 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 :)
  
  ----


IP-Address  : 66.222.158.169
Old Revision: http://wiki.metalforge.net/doku.php/dev_todo:quest_management_system?rev=1164430027
New Revision: http://wiki.metalforge.net/doku.php/dev_todo:quest_management_system

-- 
This mail was generated by DokuWiki at
http://wiki.metalforge.net/