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