Re: [crossfire] Quest management system proposal
For example, if the method we decide to go for is that we will use scripts to give out exp, then it probably would make sense to have a generic script that takes some parameters on what skill and how much exp to add, so you could do something like: event_activate give_exp.pyc throwing 6000 The code I just committed will let you do just that. Example: want to give xp to player dropping item on altar, add an 'event_activate' hook, and just write: import Crossfire player = Crossfire.WhoIsActivator() player.AddExp(6000, throwing,0) Pretty easy :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote: Latex stuff could probably go away - I don't know the last time anyone updated the tex stuff (but to be fair, not sure last time any documentation has been updated). Actually, it seems to be kind of uptodate, since it generates data from archetypes and such. I'd be more inclined to keep it - spoilers, handbook and such are nice. Also a list of gods is nice to have locally. (could be used to make PDF manuals distributed with client) But there is html version of that same data. Granted, HTML doesn't print out as nicely, but I wonder how many people really print out the crossfire information (I actually rarely print out information of any sort - having it on the computer often makes it easier to search). The spoiler is pretty much completely generated from archetype data, so yes, it probably remains up to date. The handbook has a lot more static data. The reason that is probably still up to date (effectively) is that there haven't been changes made that conflict/contradict the data that is there. A lot of changes we are talking about in the future would likely make some portion of this data out of date. At some point, it is a bit of a bother to have to update 2 different files (html + latex). But more to the point, not sure how many people really use the latex data vs the html (I wonder how many people use latex in general now, given that there are lots more good free WYSIWIG editors for *nix now). OTOH, we are talking a very basic scripting language here. If we want to be technical, we could say the existing message/endmessage stuff if some very very basic scripting language - its just simple enough that it is easy to for anyone to use because it has very few options/commands. True. But at some point people will want more than what the message/endmessage offers, so we'll be back at square one - either use our own scripting language, or an existing one. Maybe. I'm not 100% sure that is a compelling argument - on that basis, anything done could be considered incomplete because it may not do something that someone may want in the future. Of course, it could be a case that you do the conversation by plugin, and people see it too cumbersome/complicated for basic conversation, and a 'conversation light' syntax is added without need for plugins. Right now of course, there is no real scripting at all for messages. So any addition, well, adds functionality, so basic scripting as I described may be enough for a large number of needs, and if it goes beyond that, then telling them to write a script would seem reasonable. If that is done, then the give_exp.pyc, and other general purpose scripts need to be well documented so people know about them Yes, but there aren't many scripts around - the IPO, a few related to guilds, casino, misc. They should probably be documented, yes. Note that right now you can't easily directly add exp to a skill, but imo that's a function to be added. Will try to do that at some point. My point for scripts is that if general purpose scripts are added, for things like adding experience, etc, then those scripts need to be documented so it is easy for people to use. But I'll also continue to say that there should be an archetype that can be used to add exp, and that it shouldn't be necessary to use a script for such a basic operation. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Mark Wedel wrote: The spoiler is pretty much completely generated from archetype data, so yes, it probably remains up to date. One little note about that, thought it's generated from archetype data, it's still rather out of date/incomplete in areas (particularly spells) because it doesn't account for new attributes and alternative attribute meanings that weren't considered. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
This is starting too look like the discussion on implimenting LUA for scripting. http://mailman.metalforge.org/pipermail/crossfire/2005-July/008844.html Also, IIRC, there is nothing stopping someone from putting scripts anywhere in the map tree. Every hook into a script that i've seen uses a full path (with the map directory as root). -- Andrew Fuchs ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Latex stuff could probably go away - I don't know the last time anyone updated the tex stuff (but to be fair, not sure last time any documentation has been updated). Actually, it seems to be kind of uptodate, since it generates data from archetypes and such. I'd be more inclined to keep it - spoilers, handbook and such are nice. Also a list of gods is nice to have locally. (could be used to make PDF manuals distributed with client) OTOH, we are talking a very basic scripting language here. If we want to be technical, we could say the existing message/endmessage stuff if some very very basic scripting language - its just simple enough that it is easy to for anyone to use because it has very few options/commands. True. But at some point people will want more than what the message/endmessage offers, so we'll be back at square one - either use our own scripting language, or an existing one. One thought I did have is that the map editor could be modified to make use of such scripting easier. Have something which says the variable name, whether that is a player persistent variable or not, what operation to use (, =, =, etc) and what value to check against. Likewise, another dialogue/option could be similarly used to set variables. Yes, if dialog is a state automate, it could be created through dialog boxes. Not sure, but one issue with the scripts right now is that they live in a separate directory, so if the map editor creates them (which would be an option), the map developer would have to know 'also include so and so script'. Scripts can be put in any directory :) But that just lists what you can use in writing a python script. It doesn't say what scripts may be available for use already and how to use them. For example, if the method we decide to go for is that we will use scripts to give out exp, then it probably would make sense to have a generic script that takes some parameters on what skill and how much exp to add, so you could do something like: event_activate give_exp.pyc throwing 6000 (no idea if that is really the correct syntax, but you get the point). If that is done, then the give_exp.pyc, and other general purpose scripts need to be well documented so people know about them Yes, but there aren't many scripts around - the IPO, a few related to guilds, casino, misc. They should probably be documented, yes. Note that right now you can't easily directly add exp to a skill, but imo that's a function to be added. Will try to do that at some point. That is one advantage of archetypes - while it may be hard to find something, they are all available in the editor, and the editor provides customized dialogues based on type. So if there was an exp giving archetype, the editor file would be modified to ask for the skill to give, how much exp to give, and perhaps some other parameters (all members of the party, etc). True. Then maybe editor could be extended to know about Python functions, and our built-in stuff :) True, but I'm not sure if that is indication of a good design/easy to use system. Most people want instant gratification - if they have to wait hours or more to get the answer for something like 'how do I give an exp reward to a character', they may get a bit discouraged. And just going forward, it doesn't seem like 'get a developer to help you write your maps' isn't really the right thing to say. This is why I push for the idea the common/general purpose operations should be in the core server with archetype attached to it, so it is easy for people to use. Of course, an archetype with a script created could be made, with certain fields of that archetype containing the skill and exp. But then you start to ask, if we're going to do that, why don't we just write the C code? But at some point there will need to have a developer involved, when the script starts to become complex. Yes a mapmaker could, with a simple script, make a quest to have a player deliver an item from one NPC to another. But to check whether 5 players do the Holy Dance of Purification correctly to finish the temple cleaning quest, you'll need more than what message/endmessage offers :) I agree though we should try to make it the easiest for mapmakers, by offering the more easy functions to access. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
I'd rather not have the NPC conversation be in python. IT has long been discusses that the NPC conversation needs to be improved, with things like conversation states, etc. This is unrelated to quests in particular - just a general good thing to do. IMO, having some basic scripting syntax for states in the message/endmessage would be a good thing - after all, map makers are people that would be using that, and at current time, there isn't a requirement that map makers also be programmers. I suppose and answer could be 'just copy the npc script from elsewhere' to the less technical map makers, but I'm not sure that is a good answer. The issue I see with this is that it adds Yet Another Scripting Language to Crossfire... Right now we're using C, autoconf/autotools, LaTeX (documentation - is it uptodate, actually??), Perl, Python, NSIS (Windows installer). Adding Crossfire's Scripting Language would add some complexity, including making sure we don't break that, add features mapmakers will want/need, and before we know we reimplemented an existing language :) What could be done, though: let mapmakers write messages with an extended syntax, like you suggested, and have a Python plugin/script handle that internally (or handle it in server core, but that's less easier to switch i think). This also makes sense that anything the NPC says can be heard to anyone near by (it isn't just at the player). This is why I was thinking NPC's should have some limited state just for general conversations (the case this really covers is when you should be able to keep saying 'yes' to the npc to get more info, but the current mechanism doesn't allow that, so instead players have to start guessing what is the word to continue the conversation). There certainly should be state information for the player itself related to npc conversations in some cases (especially quests). Well, then I guess it'll depend on the NPC considered. It seems like every year or so, the discussion of what should be in C and what should be in plugins shows up, and this is sort of one of those. I suppose we really should come up with a standard and document it. But some also goes to above - the people who will use quests are mapmakers. Should it be a requirement for mapmakers to know python/have scripting skills to use many of the handy features of crossfire/map maker? If the answer there is yes, then no real issues. If the answer is no, then we perhaps need to revisit if python is the best solution. As I said earlier, I'm not that eager to add/create a new scripting language :) That said, it may be reasonable to have some set of basic scripts that do basic actions (add exp, etc) - in a sense standard scripts that map makers can use without having to know scripting. they just need to be well documented. All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython True, it could use some examples and such. OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the list or IRC would get some help. One question completely unrelated to this - would it make sense for the scripts themselves to be located in the same directory as the maps itself? For example, right now, all scripts are in python/ Yes, it'd make sense if scripts are related to a map. Having: * mymap * mymapscripts/*py makes it easier to package the map. Note that for local events (ie related to a player's action, as opposed to a global event like time, death, kill, login/logout), you can already put scripts in such a subdirectory, you just have to put in the full filename. Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote: The issue I see with this is that it adds Yet Another Scripting Language to Crossfire... Right now we're using C, autoconf/autotools, LaTeX (documentation - is it uptodate, actually??), Perl, Python, NSIS (Windows installer). Latex stuff could probably go away - I don't know the last time anyone updated the tex stuff (but to be fair, not sure last time any documentation has been updated). Adding Crossfire's Scripting Language would add some complexity, including making sure we don't break that, add features mapmakers will want/need, and before we know we reimplemented an existing language :) OTOH, we are talking a very basic scripting language here. If we want to be technical, we could say the existing message/endmessage stuff if some very very basic scripting language - its just simple enough that it is easy to for anyone to use because it has very few options/commands. What could be done, though: let mapmakers write messages with an extended syntax, like you suggested, and have a Python plugin/script handle that internally (or handle it in server core, but that's less easier to switch i think). One thought I did have is that the map editor could be modified to make use of such scripting easier. Have something which says the variable name, whether that is a player persistent variable or not, what operation to use (, =, =, etc) and what value to check against. Likewise, another dialogue/option could be similarly used to set variables. Not sure, but one issue with the scripts right now is that they live in a separate directory, so if the map editor creates them (which would be an option), the map developer would have to know 'also include so and so script'. All methods are referenced in http://wiki.metalforge.net/doku.php/cfpython True, it could use some examples and such. But that just lists what you can use in writing a python script. It doesn't say what scripts may be available for use already and how to use them. For example, if the method we decide to go for is that we will use scripts to give out exp, then it probably would make sense to have a generic script that takes some parameters on what skill and how much exp to add, so you could do something like: event_activate give_exp.pyc throwing 6000 (no idea if that is really the correct syntax, but you get the point). If that is done, then the give_exp.pyc, and other general purpose scripts need to be well documented so people know about them That is one advantage of archetypes - while it may be hard to find something, they are all available in the editor, and the editor provides customized dialogues based on type. So if there was an exp giving archetype, the editor file would be modified to ask for the skill to give, how much exp to give, and perhaps some other parameters (all members of the party, etc). OTOH, I'm sure a mapmaker not knowing how to write scripts and asking on the list or IRC would get some help. True, but I'm not sure if that is indication of a good design/easy to use system. Most people want instant gratification - if they have to wait hours or more to get the answer for something like 'how do I give an exp reward to a character', they may get a bit discouraged. And just going forward, it doesn't seem like 'get a developer to help you write your maps' isn't really the right thing to say. This is why I push for the idea the common/general purpose operations should be in the core server with archetype attached to it, so it is easy for people to use. Of course, an archetype with a script created could be made, with certain fields of that archetype containing the skill and exp. But then you start to ask, if we're going to do that, why don't we just write the C code? ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote: Looking at that, and looking at your example, it seems hardly really clear to follow. After some thinking, having a Python script handle the dialog seems the best way, actually :) This way, the whole dialog is written into the Python script, including the logic. I'd rather not have the NPC conversation be in python. IT has long been discusses that the NPC conversation needs to be improved, with things like conversation states, etc. This is unrelated to quests in particular - just a general good thing to do. IMO, having some basic scripting syntax for states in the message/endmessage would be a good thing - after all, map makers are people that would be using that, and at current time, there isn't a requirement that map makers also be programmers. I suppose and answer could be 'just copy the npc script from elsewhere' to the less technical map makers, but I'm not sure that is a good answer. I think that for the NPC state data, that should probably be stored in a force object that expires after some amount of time (like 1 minute real-time after last update). After all, other players may interact with that NPC, and state should reset for them. I'd say each player has his/her own state, so they don't conflict. OTOH, for NPCs, such conflicting/local state may make sense. If you think of a case of a couple players talking to the same NPCs at the same time, it would make perfect sense for the NPC to progress the conversation as it perceives it - if the npc responds differently to 'foo' based on its state, and player a says foo, npc responds, then player b says foo, the npc should give its second answer to foo. This also makes sense that anything the NPC says can be heard to anyone near by (it isn't just at the player). This is why I was thinking NPC's should have some limited state just for general conversations (the case this really covers is when you should be able to keep saying 'yes' to the npc to get more info, but the current mechanism doesn't allow that, so instead players have to start guessing what is the word to continue the conversation). There certainly should be state information for the player itself related to npc conversations in some cases (especially quests). I'd put using a python script near the bottom. Not that python is inherently bad, but I think for developer reasons. In theory, the entire crossfire server could be in python - that obviously won't happen. But given that the server is currently in C, it is quite reasonable to expect all developers to know C. But if there are bugs/improvements that need to be done to the script, but the developer doesn't know python, not sure where that really leaves things. I'd say you underestimate developers :) Scripting wouldn't require many functions in Python, just basic ones, and any C developer would feel at home looking at the logic imo. It seems like every year or so, the discussion of what should be in C and what should be in plugins shows up, and this is sort of one of those. I suppose we really should come up with a standard and document it. But some also goes to above - the people who will use quests are mapmakers. Should it be a requirement for mapmakers to know python/have scripting skills to use many of the handy features of crossfire/map maker? If the answer there is yes, then no real issues. If the answer is no, then we perhaps need to revisit if python is the best solution. As a note, the ability to give such rewards just in general could be nice not really related to quests. Drop an item, get some exp reward, etc. This can already be done, via a Python script for instance. Unless I'm mistaking what you mean? Sort of goes to the same question above - what skills do developers need. That said, it may be reasonable to have some set of basic scripts that do basic actions (add exp, etc) - in a sense standard scripts that map makers can use without having to know scripting. they just need to be well documented. So what I'd do is: * remove existing quest system, which is a bastardized version * write a Python quests command, with a few parameters (to get descriptions and so on) * write a few Python scripts to help write quest scripts and manage quests and such Then it's just a matter of writing Python scripts to handle quests :) One question completely unrelated to this - would it make sense for the scripts themselves to be located in the same directory as the maps itself? For example, right now, all scripts are in python/ This makes it a little harder to have modularized maps (I just can't tar up 'mwedel-newmaps' and send it out) - I also need to tar up the appropriate files within the python directory. If instead, I can have 'mwedel-newpaps/script1.py, ...' that is more convenient. And I'd imagine it probably wouldn't be too hard to modify the
Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote: Hello. I'm resurrecting that topic :) (long mail warning) After much thinking, I've changed my mind. IMO a quest management system could very well be written in Python, with a few improvements to the plugin system. What I'd add: First, extend the NPC dialog system. To enable more interesting dialogs, add some parameters after the @match line, to build a graph-like system. Two things: * @name name which would give the step's name activated when player says the matching * @follow name which would be the required step to actually have a match name would be any arbitrary name, with an optional * in front. No star = step is NPC specific, and thus step info is stored in NPC's inventory Star = step is player specific, and thus stored in player's inventory Looking at that, and looking at your example, it seems hardly really clear to follow. It also seems like under such a system, it could be difficult for conversations/quests to skip steps. I'm not sure of where that would be used, but perhaps cases where the quest is looking for prerequsites (must have some skill, if not, tell player to get skill, if player has skill, skip to stage about telling playg about next thing to do). As such, I wonder if having a variable, or even better, multiple variables, that hold actual values instead of follows would be better. eg,: @match hello @set state=1 Hello, what bad weather, isn't it? @match weather @compare state=1 @set state=2 Yes, lately the weather's been really bad, people are starting to talk about curses and such @match curse @compare state1 @set *weather_curse=1 A witch living nearby said there was something about seeing curses. @match * @compare *weather_curse2 # this is set when player completes quest Than you for taking care of that witch I think this isn't that much complicated (limit the @set to simple syntax, limit @compare to basic set of operations) And to me, that is easier to follow/debug. I would think that internally, the name/follow would have to store some value in the variables, but if we expose that to the map maker, it gives more flexibility. Also, if we presume all of these player (*variables) are global, it means different NPC's could update quest information. I think that for the NPC state data, that should probably be stored in a force object that expires after some amount of time (like 1 minute real-time after last update). After all, other players may interact with that NPC, and state should reset for them. Also, from what I can see, these changes are actually unrelated to the quest management piece - this is just improved NPC interaction, which is needed for quests. For the quests, I'd do a plugin (or a Python script) to manage quest steps and rewards on a player-basis. My personal inclination would be the quest not to be a script - ideally a core part of the server, lesser would be a plugin. I'd put using a python script near the bottom. Not that python is inherently bad, but I think for developer reasons. In theory, the entire crossfire server could be in python - that obviously won't happen. But given that the server is currently in C, it is quite reasonable to expect all developers to know C. But if there are bugs/improvements that need to be done to the script, but the developer doesn't know python, not sure where that really leaves things. There are some caveats, though: * quest information will be dispatched between many maps, even if quest file could contain all information (duplication, in this case) * also, what should happen when players having done different steps of a quest party together and do a quests's step? All players move to new step (unless they are at a next step already), players not having done previous steps don't gain anything? That's a trickier one - especially if completing the quest requires some item. If the party has the item, but doesn't complete the quest before the party breaks up (or more importantly, one of the members log out), a player quest state could be at a point where they really can't be at. OTOH, you don't want a case where player is about to complete quest and get reward, and then have everyone join them to get that bonus exp (one question if the reward is exp, does it get divided by number of people in party? Does each player just get full reward?). I'd almost say quests can't be shared across parties. * doing quest would request Python scripting (unless we add a quest-specific basic language, like: give hiding 5000 for rewards) As a note, the ability to give such rewards just in general could be nice not really related to quests. Drop an item, get some exp reward, etc. Here's a small quest file example that could be done: quest kill_boss description You must kill the evil boss that sends minions to the town enddescription transition boss_killed
Re: [crossfire] Quest management system proposal
I won't reply (yet) too all your points, just one :) OTOH, you don't want a case where player is about to complete quest and get reward, and then have everyone join them to get that bonus exp (one question if the reward is exp, does it get divided by number of people in party? Does each player just get full reward?). I'd almost say quests can't be shared across parties. Quests should be shared across parties. It would encourage collaborative play, also enable to do fun/creative things. I for one will either work on a quest system enabling players to share quests, or won't work on it at all :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote: OTOH, you don't want a case where player is about to complete quest and get reward, and then have everyone join them to get that bonus exp (one question if the reward is exp, does it get divided by number of people in party? Does each player just get full reward?). I'd almost say quests can't be shared across parties. Quests should be shared across parties. It would encourage collaborative play, also enable to do fun/creative things. I for one will either work on a quest system enabling players to share quests, or won't work on it at all :) Nicolas I would think a good way to prevent cases of the issues Mark says, would be making it so only players who were in the party at the start of the quest, and are still in the party when the quest finished, and are on one of the maps for the quest when it finishes, should get the reward. Alex Schultz ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Alex Schultz wrote: Nicolas Weeger (Laposte) wrote: OTOH, you don't want a case where player is about to complete quest and get reward, and then have everyone join them to get that bonus exp (one question if the reward is exp, does it get divided by number of people in party? Does each player just get full reward?). I'd almost say quests can't be shared across parties. Quests should be shared across parties. It would encourage collaborative play, also enable to do fun/creative things. I for one will either work on a quest system enabling players to share quests, or won't work on it at all :) Nicolas I would think a good way to prevent cases of the issues Mark says, would be making it so only players who were in the party at the start of the quest, and are still in the party when the quest finished, and are on one of the maps for the quest when it finishes, should get the reward. Have to be careful about map requirements - don't want people to lose out because they were on the previous level of the dungeon when something happened (say healing). Some may come in how many steps are done to complete the quest. And also what is considered the critical parts of the quest - if the quest is to kill some boss, but some of the difficulty is getting to the boss, there is no way to really prevent part members from joining in near the end (talk to quest giver, join party, go help kill boss). It may just be a case of overcomplicating the problem - if there is a rash of people joining the party late just for reward, some method of correction. But as thinking about it, how to enforce these is also odd. For example, in the kill monster scenario, just giving credit to the person doing the killing blow may not work - imagine a case where the boss is fighting a character but uses an item that creates a fireball that kills him - that character he was fighting should get credit for completely the quest, even though he didn't do the killing blow (it would really suck in fact to be in such a situation) - you sort of need to do something like all players within 10 spaces get credit. Also, as I think about it, there may be need to have a flag which says which quests can be group quests and which can't be. For example, you could have some pretty basic quests - bring me a, b, c and I'll teach you about something. Such an offer should really be to a single person, not a group of people, so being in a party shouldn't have any advantage on that. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Which is still patching/modifying objects. Perhaps not in a huge way, but still, to me, it would seem better for the object in the map to be modified, and not have post processing done later. Some of this concern may be unwarranted, but I always fear the 'its only plugins now, but down the road, it could be other things modified, like say msg/endmsg data'. Well, for quest to work correctly, quest system will need to override current NPC system anyway, I think. So extend the syntax, to add quest-dependant information, probably. I still think it would be better for the script control file to mention the different objects (map, x,y) that are tied to the quest, but actually have the objects modified in the map. That is simpler (all the code to handle that already exists) and prevents possible problems. Possibly. In which case quest system should check item still exists at map loading :) I don't particularly think we should base design on having people who run a server to install some software. If they want to run a server, they should be able to go through and install that software - it shouldn't be very hard. If they don't want to, then don't run the server. True. But remember, for Windows for instance, it isn't as easy to compile the server. So people will need a specific Python version, leading to possible collisions with required versions for other things. But globally I agree. People want all features? Then install what's required :) I think someday I'll just, if I can find the willpower, start coding, keeping all that in head, and change during the course of different versions :) Nicolas ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Quest management system proposal
Nicolas Weeger (Laposte) wrote:
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.
Which is still patching/modifying objects. Perhaps not in a huge way, but
still, to me, it would seem better for the object in the map to be modified,
and
not have post processing done later.
Some of this concern may be unwarranted, but I always fear the 'its only
plugins now, but down the road, it could be other things modified, like say
msg/endmsg data'.
And even with just plugins, there is always the potential that the object
might be modified to have that event set. What happens then when the loader
wants to use that same event for a different script.
I still think it would be better for the script control file to mention the
different objects (map, x,y) that are tied to the quest, but actually have the
objects modified in the map. That is simpler (all the code to handle that
already exists) and prevents possible problems.
The only disadvantage is that if someone wants to disable a quest, there are
now a bunch of objects to modify in maps. However, that really isn't any
different than things are right now with most of the basic quests out there (to
disable them would mean removing maps, modifying them, whatever).
But one thought on this to make it eaiser - in the quest control file, you
could have some line like:
bunch of quest related to delivering a message
message_delivery_quest_enable=1 (or 0 to disable it)
So instead of having to comment a bunch of lines out, it is just one line to
change (and in fact, may make sense to have 2 files - one with all the quest
related info, and another that describes if the quests are enabled or not - in
this way, just a quick perusal of one file to decide what to enable/disable.
I think the scripts could pretty easily be modified to have something like
'if
quest_enabled(message_delivery)==0 { do nothing}'
This does mean that the scripts may be getting called unneccessary, but I
don't think that is a big deal.
As I think about it, having such checks could be really nice. I could
envision an NPC that wants a dozen things delivered. The script is in place to
handle all those different things. Instead of having an all or nothing for
that
npc, those different quests could be enabled/disabled, and the scripting
language can check for that.
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.
But if that is the issue, then requiring that python be installed I think
would be perfectly reasonable. Or if python isn't available, then of course
none of the quests are available.
I don't particularly think we should base design on having people who run a
server to install some software. If they want to run a server, they should be
able to go through and install that software - it shouldn't be very hard. If
they don't want to, then don't run the server.
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire
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
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
