[MUD-Dev] Quests

[Raph Koster]

On Saturday, April 15, 2000 11:11 AM Madrona Tree said:

> ----- Original Message -----
> From: "Raph Koster" <rkoster at austin.rr.com>
> To: <mud-dev at kanga.nu>
> Sent: Thursday, April 13, 2000 9:40 PM
> Subject: RE: [MUD-Dev] Spawning and quests (was Sony ban)

> > Players quickly see it as football and not as an epic quest.
>
> Do you think this is because of the players, or the quest?  Do you think
> that if UO was not a mass market game where people weren't really 'in the
> mood' in the first place, people would have different attitudes toward
> large-scale, capture-the-flag type quests?  Do you think they would work
> better on a more enthusiastic population, that was maybe smaller?

Well, I've seen it be treated as football on small-scale hobbyist muds too.
The key factors seem to be:

- does it happen over and over again? If it does, players quickly ascribe
futility to the activity, deeming it a game.
- does the event have serious consequences on the mud as a whole? If it
doesn't, then the players will again be more inclined to consider it a
diversion.

Obviously, these two are related, but can in fact be distinct. An event that
happens over and over could in fact radically alter the mud somehow with
each victory.

So in the example given, if there's an ongoing battle for "who has the One
Ring" and the mud is centered around it, then players will see it as a game
of football. If perhaps the event ran ONCE, and the result was that Sauron
actually conquered the entire world and next time something else entirely
needed to be done, then maybe players would give it significance.

I've always considered the events run on Achaea to be a model for how it
should be done, but I don't know how much time investment is required.
Asheron's Call is doing something similar, and they tell me that it IS a
huge amount of effort to carry off one large-scale, non-repeating,
consequential event every month.

> > I've written very epic, narratively based quests for Legend.
> > They take a long time to craft, aren't repeatable, and get
> > reduced to walkthroughs no matter how compellingly written.
>
> You sound a little bitter about this.  Are you discouraged to the point
> where you no longer want to do write them?

No, I do want to write them. But I want to find a way to write them (or
rather, provide that experience to players) that is scaleable. If I were
doing smaller games, then I'd definitely be doing narratively based quests.
But that's not the sort of game I am doing right now.

Lee Sheldon of the Gryphon Tapestry has some very interesting ideas
regarding using modular storytelling to provide this experience. Whereas the
typical mud quest works thus (where every link is a puzzle or combat
sequence):

         |
         |
         |
         |
         |
        / \
       |   |
good end   bad end

and whereas typical branching plot structures found in standalone games work
like this:

                   |
                  / \
                 /   \
                |     |
               / \   / \
              /   \ /   \
             |     |     |
         bad end  good   bad end
                   end

he argues for something that looks more like this:

              _ | _
             / /|\ \
             \_\|/_/
                |

meaning that each step has a number (I think he said at least 8) of
variations, each hand-crafted, enough so that in a chain of events long
enough, two players getting the same sequence of events leading up to the
ending is very rare. Then he doesn't care that the ending is known, because
the sequence of events required to get there is different from time to time.

The problems I see with Lee's approach for the larger games are that there's
still way too much handcrafted data for the average mud builder (commercial
or hobbyist), and that the solution doesn't scale very well to larger
populations. We've seen much tougher mathematical problems solved using
empirical data by the players... the number of permutations is low enough
(and the number of *significant* deviations from the base plotline low
enough) that the playerbase as a whole will quickly arrive at the blueprint
for the whole thing. Those are both forgivable issues with the system--a
long-running game could keep adding permutations until the problem space was
pretty large--and it's certainly more interesting than the current baseline
mud quest design.

But there are challenges: making it epic is one such. How do you make the
outcome of this feel consequential? Some things which add fictional weight
to a narrative are difficult choices (often the surrender of something
dearly loved), self-sacrifice, and high stakes. It's pretty rare in ANY
computer games to develop a strong enough sense of empathy that we regret
sacrificing something (Floyd the robot in Infocom's PLANETFALL is considered
the classic example), and it takes time; most mud quests are significantly
shorter than a standalone game. High stakes is also very difficult to carry
off in a mud environment.

Self-sacrifice, however, may be easy: maybe all you need to do is say, "to
fulfill this quest, you have to give up a level or two, or stats." Of
course, then you have the question of how to reward them sufficiently that
they will do it.

An ideal mud quest: Some large event occurs damaging enough people that it
feels like a significant change in the world. Quests are offered to players
to try to solve this problem. Every quest is different. Many of them solve
sub-problems or other problems, without fixing the situation. Enormous
sacrifices are required of those who take on the quests. And finally, when
the problem is solved, the entire world is changed. And then that situation
never actually occurs again.

But how to do that? I don't know. I can write ONE. But it would take a lot
more time to write it than to play it. I can see a way to do them
periodically, with a largish staff, to a lesser level of complexity. I don't
know how to weave it into the fabric of the world. Anyone?

-Raph






_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev