[crossfire] Quests with multiple outcomes

[Brendan Lally]

On Mon, 29 Mar 2010 20:49:23 -0700
Mark Wedel <mwedel at sonic.net> wrote:

> On 03/29/10 10:25 AM, Brendan Lally wrote:
> <snip>
> > The design of quests as things stand assumes:
> > * Quests only progress forwards, not backwards
> 
>   Random question - is that a fair assumption?
> 
>   I could imagine cases where there are many steps, and there could
> be cases where due to use of items (which are consumed) that a quest
> could go back a step.
> 
> Something like:
> 
> 1 I need to talk to foo about X.
> 2 I found that foos lives in scorn in soandso house.
> 3 I need a baz to get into soandso house.
> 4 I'm in soandso house - now I need to find foo.
> 5 I found foo and talked about X (quest completed)
> 
>   If one got to step 4 (using up baz to do so), and then for some
> reason left, they may now be back to step 3 (need to find baz
> again).  This itself may not be a perfect example, as baz may be
> something with a known location.
> 
>   But one could imagine alchemy quests, where the quest is to
> properly make some recipe.  And parts of that quest are to find the
> necessary ingredients, and for some things (like orc livers) it may
> just be random luck.
> 
>   If after getting all the ingredients, the actual alchemy failed
> (bad roll), it may be that the quest goes back to finding ingredients
> if the character doesn't have any extra.
> 
>   Now I don't consider this a big deal, but it just seems to me that
> there may be many quests (especially those related to items) where
> the character may take a step backward by selling/trading/whatever
> the item needed.
 
A restartable subquest would cover both cases, there is a case to be
made for having restartable steps (as opposed to the entire quest being
either restartable or not),
 
> > * Once a quest is completed, then it is not un-completed (although
> > may be restarted).
> 
>   That makes sense - completed is completed.  And I'd imagine that
> for restartable quests, the state would revert.
> 
>   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.

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

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.

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.

Creating a default.quests file for the old servers to use is fairly
trivial, but for new servers, the number of quests in each file would
be fairly limited. - An extra couple of subquests used for
administrative purposes shouldn't make too much difference then.

(the other advantage of that approach is that creating a list of quests
in each town for the wiki is just 'grep ^title quest_file', although
it'd probably be worth excluding subquests from that list)

> > All of the wording, etc is up for debate, as well as things like the
> > level of detail in the quest texts (my inclination has been to go
> > for lots of detail in the text for the low level quests in scorn
> > because these are probably the ones that will be played within the
> > first couple of hours of picking up the game - I'd be more inclined
> > to have vaguer descriptions of high level quests that players won't
> > find until they have played the game for a few hours - but this is
> > a discussion for the maps list)
> 
>   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:

eg:

Custom Armour

Morning of 15th Winter, season of new year, year 12:
I have placed an order with the smith in Scorn Armour Shop for a custom
eyeshield. He promised it would be ready by this time tomorrow.

Evening of 17th Winter, season of new year, year 12:
I have collected my new armour from the smith.

Quest Complete (may be restarted)

This may not be the best example, but it is the one that is least
likely to be a spoiler.

Obviously there is a whole discussion about how to represent server's
game time to the player, but it isn't difficult to store. (just
a list of date/times and the stage numbers they correspond to).

Brendan.