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 state>1 @set *weather_curse=1 A witch living nearby said there was something about seeing curses. .... @match * @compare *weather_curse>2 # 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 end > step end > message > Congratulations, you killed the evil boss! > People in town rejoice! > endmessage > reward > give exp 5000 hiding > endreward > endstep That isn't really readable at a first glance, but perhaps if indentation is used like treasurelists, that would be better. I also wonder if the transition and step are both needed - it seems somewhat redundant - something like: transition boss_killed message ... endmessage reward ... endreward endtransition _______________________________________________ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire