[MUD-Dev] Quests [was Resets, repops and quests]

[Shawn Halpenny]

Matt Chatterley wrote:
> 
> [ def'ns of static quests ]
>  
> Dynamic quests are far harder to visualise and get into initially,
> although if the elements are assembled properly, they probably fall
> together easier. The main problem here is picking a standardised method of
> implementation. Personally I'm considering a scripting language that the
> mud can interpret via a quest engine - but it would have to be very
> complex, and very clever. These quests basically have far more potential,
> can do literally anything (in ideal). I have not yet seem them done, apart
> from some muds having a wizard actually run quests (via a sort of DM
> approach).

Perhaps we need to try looking at them a different way.  I think that if
you're considering a scripting language interpreted by a quest engine
(and I was definitely going to do this until 5 minutes ago), you're
implicitly accepting a linear flow of events leading to the goal of the
quest.  Is it possible to visualize each dynamic quest as a directed
graph?  A sort of "quest net"?  At each node is a subgoal whose
completion is required (in whole or in part) in order to complete the
entire quest.  I don't think there are definitive reasons why nodes in
one quest net cannot be part of another quest net.  Now what could be
gained by looking at it this way?  Well, if you have an event-driven
server, and all your objects interact using events (or messages), then
you no longer need a separate quest engine:  the dispatching and
processing of events will cause nodes on the quest net to register their
own completion so to speak, and the uncompleted nodes requiring others
as prerequisites can now do their thing when the time comes.  I wonder,
though, if the questor would have to begin at a particular node in order
to complete the quest (I suppose it would depend on the quest, since
quests could certainly be written such that if you solved a subgoal of
the quest, you could glean the surrounding subgoal nodes from that). The
fact that it's a net can be used to have multiple solution paths from
one node to another.  A great jump in complexity, for sure, since things
must be planned more carefully (prevention of loops and what not). 
However, if it can be set up appropriately, it would be possible to have
quests that no one actually knows the sequence of events required to
solve it, since the sequence of events isn't known until the quest is
being solved (some sort of feedback along the edges of the graph, I
suppose).

I don't really know if this is feasible (or even sensible), but it just
popped into my head and I wondered if we can't massage it into something
that would handle dynamic questing just fine.

> Another big issue surrouding quests is probably 'trigger mechanisms'. The
> stereotypical trigger is the list in the guild hall, and suchlike as
> mentioned above. I plan on having NPCs who will hand out quests to
> appropriate adventurers (and one or two more who will point them to those
> NPCs if they haven't done the quest/s), soemthing like the roguelike game
> 'ADOM' does things (and the player will have a list of quests s/he has
> undertaken available). Actually being-on-a-quest will be a recorded and
> acted upon state of being.

As for the triggers, they would be built in to the subgoals.  It could
be something as simple as picking the blue flower out of a field of red
flowers that causes a whole net of events to occur, and the resolution
of each results in completion of the quest.  Perhaps the
interconnections are the key to a dynamic quest, as opposed to the
consideration of a static goal at any given time.

> Something else to which I've given little thought is the matter of rewards
> for quests.

I think these are only limited by what you imagine and what your server
will allow you to do.

--
Shawn Halpenny

"I spilled spot remover on my dog.  Now he's gone."
                                            - Steven Wright