Re: [crossfire] Quest management system proposal
You need to also consider inter-quest relationships. Completion of one quest may be necessary pre-condition for starting another quest, or could deny you a quest alltogether. You could make all related quests fit into one file I guess as one big quest, or add a way to add FA links across quests, which would be nicer. Another proposal related to quests I was thinking of for some time now is randomly generated quests (dynamic quests?). A random map generator is already present, so it is possible to produce random dungeons. An interesting extension to that would be to produce random quests. They would hugely extend the size of CF, and overcome the map contention issue, since there would be an almost limitless supply of maps and quests of all kinds and levels open to players. Random quests would work by linking the to several NPCs (in taverns, inns, etc. throughout the world), and by talking to an NPC a random quest gets generated on big world suitable for the player level, with an appropriate reward item at the end, and a randomly generated storyline. The players are told by the NPC how to find the entrance. To control access the NPC would give player(s) taking part the key(s) to the entrance. Quest types I can think of right now are: - Kill something - powerful boss at the end, drops the reward loot - Find something - useless (randomly generated?) item somewhere in the dungeon, need to find and bring back to NPC to get the quest reward item or experience. You can also have non-fighting oriented quests, but ones encouraging exploration, by making the player go to a remote part of the world. - Deliver something - give item (letter) to another NPC somewhere in CF - Deliver something and bring back something else - extension of previous one Another quest class could be quests that develop secondary skills: - Sneak into a dungeon and steal something (NPC awards stealing/hiding xp) - Bring back a rare useless item (NPC awards some alchemy-like xp) - Get an item from a dungeon full of traps (NPC awards finding and disarming traps xp) Finally you can have thinking (puzzle solving) oriented quests: - Move the boulders to get past and get to the item - Arrange boulders in the right places to open the door to the item - Pull the right levers - similar to above - Step on the right floor tiles ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
I don't really have time to go into all the details, but have some quick thoughts: Having the server of a plugin 'patch' objects loaded from the map itself seems to me to be a pretty horrible hack. I know from a debugging side of thing, having a bug with an object in some odd state, and not even being sure how it got that way is a pain. This also seems to be pretty problematic in terms of specific objects on specific maps (the NPC that gives out the quest info, for example). but I do then wonder if some hybrid approach could work better. For objects that need to be modified, have them modified in the map. But that doesn't prevent the use of a quest file like: bunch of question info # # npc A,B on map ... will say blah blah to the player, and will update # the quest state # .. .. So that one file will show all the details of the quest info without needing to try and patch the objects. I personally don't think the ability to turn on/off quests should really be a design concern right now - or if so, this is a bigger project in terms of map options - there is no convenient way to change passwords, disable some set of maps, etc right now. My thought is that if we want to do that, we should perhaps look into some macro processing language - as an example, with C preprocessor, you'd do something like: #ifdef QUEST_ENABLE .. #endif (not saying CPP should be used, but there are numerous macro processing languages that would probably do the job) In terms of script language, I think that is almost a different discussion - if python isn't sufficient or overly bloated, and we should move to something else, we should do that, but I don't think that should be an immediate design concern either. I forsee that if lua (or other language) is added as a quest specific script language, it wouldn't be long before it probably would turn into a full blown scripting language. I do think that we should find one (or worse case, a very select few) scripting language and stick with it - having a bunch of different script languages is just going to make things harder to maintain (now have several plugins codewise to support, and also harder from a script writer point of view - if all the scripts are in the same language, I can look at any of them to see how to do something, etc. If they are in a mix of different languages, that makes things more difficult. while I'm not that familiar with python, we already have it, and it seems to be a pretty widely used language. I normally can't envision the heaviness of the scripting language causing many problems as most plugins are not getting called enough that this should be a big issue. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Having the server of a plugin 'patch' objects loaded from the map itself seems to me to be a pretty horrible hack. I know from a debugging side of thing, having a bug with an object in some odd state, and not even being sure how it got that way is a pain. This also seems to be pretty problematic in terms of specific objects on specific maps (the NPC that gives out the quest info, for example). Just a precision: not talking about patching / modifying objects, just adding event handlers in inventory. In terms of script language, I think that is almost a different discussion - if python isn't sufficient or overly bloated, and we should move to something else, we should do that, but I don't think that should be an immediate design concern either. I forsee that if lua (or other language) is added as a quest specific script language, it wouldn't be long before it probably would turn into a full blown scripting language. Yes, that's another discussion :) But for instance Windows users don't always have Python installed, thus requiring it needs adding and maintaining links to Python packages, things like that. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Copied my proposal to http://wiki.metalforge.net/doku.php/dev_toto:quest_management_system *does the wiki back up dance* :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
