[crossfire] Quest management system proposal
Hello. I'm feeling ambitious, so here's a quest management system proposal :) Of course, whether I (or someone) will actually implement it isn't yet sure ^_- 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 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 all 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 global 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 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 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 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 :) Heck, I may just start working on that soon if I'm feeling in a good mood :) I'll add that proposal to the wiki when it's back up, of course, so everyone can poke it ^_- Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
On 6/9/06, Nicolas Weeger (Laposte) [EMAIL PROTECTED] wrote: Hello. I'm feeling ambitious, so here's a quest management system proposal :) Of course, whether I (or someone) will actually implement it isn't yet sure ^_- 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 would be the rewards for completing that state, everything needed. Transitions should describe what the player should do to actually change states. Good idea to keep branches, and subquests (which you can't do after the quest is over), etc. 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 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 global 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 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) Can get a bit wierd if done just on one server. * 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 reuing existing one, to avoid making Yet Another Script Language. Though of course if we use Python the Python plugin would become mandatory. Some sort of scripting language being mandatory on the server side will probably encourage it's use by mapers. It may be a good idea to discuss implimenting LUA, since it has a smaller footprint, over using the existing python plugin. * 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 :) I like the idea of using it as a plugin. Heck, I may just start working on that soon if I'm feeling in a good mood :) I'll add that proposal to the wiki when it's back up, of course, so everyone can poke it ^_- -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Crossfire Wiki offline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick Tanner wrote: The Crossfire Wiki will be offline for the next few days due to unplanned maintenance (AKA: borked dokuwiki upgrade) I'll post again when the wiki is back online. The wiki is back online, http://wiki.metalforge.net/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEifIqhHyvgBp+vH4RAgbBAJ9i9NI/Nq+5jYJ9lsyJyR8MHKZiCwCbBwvv 9syozTLH7JtHAvvG30h3OaM= =TgRs -END PGP SIGNATURE- ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
