[Crossfire-wiki] [Crossfire DokuWiki] page added: dev_todo:quest_management_system
no-reply_wiki at metalforge.org
no-reply_wiki at metalforge.org
Sun Jun 11 14:39:49 CDT 2006
A page in your DokuWiki was added or changed. Here are the details:
Date : 2006/06/11 19:39
User :
Edit Summary: fixing a spelling error in name
(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 :) \\
----
=== Comments ===
Umm the path for this page should probably be "dev_to**d**o:quest_manageme
nt_system" not "dev_to**t**o:quest_management_system"?
IP-Address : 24.55.181.141
Old Revision: none
New Revision: http://wiki.metalforge.net/doku.php/dev_todo:quest_managemen
t_system
--
This mail was generated by DokuWiki at
http://wiki.metalforge.net/
More information about the crossfire-wiki
mailing list