[crossfire] Quests with multiple outcomes

[Brendan Lally]

On Tue, 30 Mar 2010 20:55:36 -0700
Mark Wedel <mwedel at sonic.net> wrote:

> On 03/30/10 10:20 AM, Brendan Lally wrote:
> 
> >>> 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.

In terms of what the player sees, I think it will suffice to show them
a two level hierarchy. The subquests would probably be called
'objectives' or something similar in the client. The default behaviour
then would be to only show the active subquests, not the completed ones

Any occasion where there are more than two or three nested layers of
subquests for one quest probably indicates a need to rethink how the
quest is defined, or to split it up into a 'chain' of top-level quests.

One thing I do want is hidden quests and quest steps, simply because
for many quests, it will be easier to change the state of the quest
rather than use markers, and there is a value to suppressing some
status changes. (eg, there is one I am looking at where there are a
number of monsters around a leader, if one of the monsters is killed, I
want to close off a peaceful resolution with the leader, so easier to
set the queststate to $bignum rather than track a marker in the
dialogue).

I think the generic thing to do this is to have a 'parent' marker
in the child quest file, and allow each stage of any quest to
conditionally advance any other.

ie,
quest scorn/TerrysFarm
....
step 30
advancetarget scorn/DisputedFarm
advanceif 0-5
advanceto 10

so that setting the terry's farm quest to state 30 should advance the
disputed farm quest to step 10, but only if it is already between steps
0 and 5 (so if it is at step 7, or 20, nothing happens)

Obviously, it would be considered bad form to update another quest
without there being some story-line reason for doing so.

>   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.

This could be done with a hidden quest and lots of combinations of
steps, but I think the more sensible solution would be to check the 5
subquests for completion in a dialogue. (so the dialogue script would
check all 5 quests are completed before causing the connection on the
map to be triggered. 

> >
> > 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.
>

The reason to want to tie them to regions, is to give an idea of where
quests are. If a point is reached where there are hundreds of quests,
then one player might have a score or more active at one time. Being
able to show only 'local' quests in the interface would help answer the
question 'what should I be doing here?'

an #include -type system could work for this too, in that case, the
quests in the #included files would be in the same region as the quests
in the file they were included from.

Server side, it just involves a bit of recursion (and maybe a check
that files aren't mutually including each other...)
 
> >>    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.
 
It may even be worth having a hybrid approach, so change the summary
and allow more detail to be shown about the quest in the interface so
that information the player should remember can be looked up by
referring to old updates. - I think this is something that should
become more apparent with playtesting.

Brendan.