[crossfire] Quest management system proposal

[Mark Wedel]

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