[crossfire] Quests with multiple outcomes

[Mark Wedel]

On 03/30/10 10:20 AM, Brendan Lally wrote:

>>    Random question 2:  For repeatable quests, is there any record that
>> the character is repeating a quest vs it being their first time?
>> Likewise, would it be worth it to note how many times a character has
>> done a quest?
>>
>> I'm thinking that in some cases, one may want to make the secondary
>> reward not as good (or perhaps different).  Eg, the lord sends player
>> out to kill some boss creature.  On first attempt, they get one item,
>> on second attempt, something different, etc.
>
>
> Yes, QuestWasCompleted() is non-zero if the quest has been completed
> before, for map integration, a script can check the value of this
> before advancing the stage to determine if it has been repeated.
>
> Changing to the number of previous completions could potentially be a
> bit more powerful in terms of reward scaling (eg, have a reward of
> 500platinum/number of times completed), I haven't been looking to do
> that myself yet, so it isn't a change I've wanted, but I can see how
> someone might want to use it.

  I'd consider that a fairly low priority improvement, but one that could be 
interesting.  For quests which are really designed to be repeatable, a counter 
could also be done - on first time, you get some decent reward (item/money), for 
times 2->24 you get something not so nice, and then for time 25 you get 
something pretty nice.

  It is really up to the quest designer to figure this out.  First priority 
would be to have quests done, and have the first/secondary rewards sorted out, 
and worry less about rewards after that.

>
>>> quests:
>>> 1) ....
>>> 2) ....
>>> 3) Down to the docks:
>>> 	a) Port Pass
>>> 	b) Scorn Password
>>> 	c) The Hero of Scorn
>>> 4 ...
>>> etc
>>>
>>> and then the info section would say:
>>
>> <snip>
>>
>>    Yes, that makes a lot of sense - it sounds like the solution to
>> what I said above was to do sub quests, but I'd really not want to
>> see a huge list of quests which are really subquests and have no
>> value on their own (in my example above, fetching a baz only makes
>> sense as part of talking to foo).
>
> There is really a trade off here, the choice is between having the
> smallest possible number of really complex quests, or a greater number
> of simpler quests.
>
> My instinct is to go with the simpler individual quests, because they
> are a lot easier to build and test in isolation.

  That makes sense.  And really, single big quests vs many small quests is a 
server mechanic - if they are presented to the client in a cohesive fashion (so 
those 12 subquests appear as steps of a big quest), that is great - you don't 
need to have the big quest have those 12 individual steps.

  My main concern, beyond it being managable from a map designer standpoint, is 
also have some way to make them cohesive for the players.

  It would seem to me in such a system, you'd need the following information for 
these subquests:
- What part of quest are they (parent quest)
- what quests do these open when completed.

  For example, one could have a quest that has 6 different steps, and they have 
to be done in order (doing step 3 before step 2 doesn't make sense).  But you 
could have other quests where several of the steps could be done in parallel - a 
simple example could be alchemy quest - you may need to get 5 materials for the 
recipe, but what order you get them in doesn't matter.  I'm not sure how this 
later one is handled in the system - the step to go to alchemy master with 
cauldron shouldn't open up until all 5 of those subquests are done.

>
> Within the timescale of the next release cycle, I can't see the number
> of quests becoming unmanagable, and by the time 1.51/1.60/whatever it
> is called comes around then the interface should be there to handle it.

  yep

>
> One of the things I will be doing very shortly (ie, the next time I
> change the quest file definition after the release) will be to break
> the default.quests file into lots of smaller files. I was going to use
> the region file to specify these, so that quests then become attached
> to a region of the game world as well.

  Makes sense - ideally, .quest files could sit anywhere in the map tree, but 
that would make it trickier for the server to find them all.

  But one could imagine that in some cases, a quest may relate to a small set of 
maps (already located in its own directory in the maps tree), and keeping the 
quest near there would make sense.

  I wonder if rather than regions file, if maybe adding something like #include 
directives into the the default.quests would work?  Server would then just 
process those and load all quest files.  It should only need to do this at 
startup, so shouldn't add much to load time, but gives maximum flexibility.


>>    Yep.  Some quests may also be vague just by their very nature -
>> some locations are supposed to be somewhat hidden or not well known,
>> so at least on first pass, a detailed description of them doesn't
>> make sense.  However, as the character learns more information, maybe
>> that gets filled in.
>
> I think there are three ways that this can go:
>
> 1) add 'new_summary' as an option in the quest step which replaces the
> initial summary with a more detailed one once a certain stage is
> passed
> 2) Use the knowledge system to hold knowledge related to a
> quest, but not directly connected to the advancement of it.
> 3) Store the entire history of the quest steps that the  player has
> taken, so that the step descriptions for all of them can be made
> visible. Then any updated information can be written in one of the step
> descriptions
>
> I'd tend to favour option 3, at least for non-restartable quests, you
> can then have something of a diary style interface that the clients
> could provide:

  For complex quests, option #1 might be nice - having a quick summary of where 
you are in the quest might be desirable than reading the 15 things you have done 
so far.

  Simplest way in that case would be to have an optional summary/endsummary for 
each step - if set, then when a player reviews their quest information, it 
displays the summary of the step the player has completed the most.