[MUD-Dev] Congratulations Horizons...

Marian Griffith gryphon at iaehv.nl
Sun Jan 25 19:09:39 New Zealand Daylight Time 2004

In <URL:/archives/meow?group+local.muddev> on Sat 10 Jan, Brad McQuaid wrote:
> From: Marian Griffith [gryphon at iaehv.nl]
>> From: Brad McQuaid [bmcquaid at cox.net]

>> In my opinion you are generalising beyond the point where it is
>> useful, or at least to how a designer may look at it, and not how
>> a player would. To many (!) players the story and setting ARE all
>> that the quest is about. Or at least part of its appeal.

> I respect your opinion, but an analysis of the mechanics behind
> what really makes a 'quest' tick is what game designers should be
> doing.  I'm unclear why you feel such analysis of MUD/MMOG game
> mechanics somehow threatens the awesome story and setting and
> ideas that can then be built on top of that foundation.

I am not threatened by this,  I just think that  reducing quests to
something that abstract takes away the things that really make them
differ in the eyes of the player.  I also do think that between the
trappings of the backstory and the way it is programmed  there is a
layer where, for lack of a better word, a quest comes to 'life'.

Personally I think that nothing in the few games I have played  de-
serves to be called quest. Task or even job might be more accurate.

>> From a literary point of view a quest is a journey into the
>> unknown to achieve a goal of great value or importance and one
>> that will cause the quester to grow or transcend.  E.g. the
>> knights of the round table's quest to find the holy grail, or
>> Frodo's quest to destroy the one ring.

> Yes.  And then our job is to figure out how to map what is
> interesting and compelling in literature to game systems that can
> entertain hundreds or thousands of people in a virtual and dynamic
> (e.g. non-linear and pre-determined, unlike literature) world.

I admit that my interest ends well before thinking about how to ac-
tually make a quest work in a game.  I understand that it is impor-
tant, and that you need to abstract things to make it work somehow,
but I can not agree that this would be the 'truth' about quests

> So, we come up with combat formulae, quest mechanics, character
> attributes, etc., that are not necessarily important when writing
> literature.

And I would think they ought not be all that important when setting
up a quest in a game either.  What makes a quest 'relevant'  is not
in those mechanics, but in how it engages the player, and makes her
grow in some way. My experience with quests in text muds is limited
but  there is one cute little quest in Everquest  where you have to
accompany a little girl as she walks through town.  I will immedia-
tely admit that this is hardly a life altering experience  and that
most players will treat it as a quick and safe way to earn some ex-
perience and money,  but the fact remains  that it is more engaging
than most other 'quests',  even to the cynically inclined  (despite
it being an almost archetypical fed-ex quest).

>> In games this is not so easily captured. The travel itself is not
>> effectively possible, given that game worlds generally are very
>> small and instant travel is widely available.

> A generalization of where we've seen some games fail.  I've played
> MUDs and MMOGs where travel still takes time, is interesting, and
> doesn't require egregious teleportation.  The current trend to
> trivialize travel to make a game more 'accessible' is both
> unnecessary and damaging to the genre; but, I suppose, that's a
> different topic.

It probably is, but I tend to feel it is entirely the wrong direct-
ion to take a game in.  Players may hate and bitch about the travel
times,  but they do serve important social functions in the game by
localising players.  However, it boils down to a choice whether you
look at the game world as a challenge or as a theme park.  Recently
we have had a heated discussion if, and how many,  obstructions you
can put in a player's path,  and I have a strong feeling  that some
of the participants of that discussion would strongly object to any
suggestion  to actually make it (very) difficult to players to tra-
vel to other parts of the game world.  My personal opinion is  that
in the long run it would be better for both game and players to put
in that hurdle, but I am not going to argue my point again.

>> Also the sense of urgency is very difficult to achieve, unless the
>> player wishes to suspend disbelief and submerges in the game world
>> (and even then) Finally, the 'unknown' is currently next to

>> impossible given the proliferation of 'quest guides' as soon as
>> the first players solves the 'puzzle'.

> Call me a nutty idealist, but I also refuse to retreat in this case
> too -- even given the proliferation of 'quest guides' or spoiler
> sites or whatever, I think we MUD/MMOG designers just have to accept
> that as an 'evil' we cannot avoid and work around it.  This calls
> for innovation such that we can recapture the 'unknown' many of us
> experienced either early in an MMOG before such proliferation or way
> back in MUDs with smaller populations and before 'spoilers' could be
> so easily disseminated.

I would not call you either nutty  nor idealist.  To me it is vital
that this problem is somehow solved if games are to be appealing in
the long run. However, I can only point at what I see as a problem,
and must leave it to you to actually do something about it :)

>> So, the fed-ex that you seem to despise so are really one of the
>> few ways the game designer has to partition the quest, give it a
>> certain sense of travel and allows him or her to actually advance
>> the storyline.  If you want to treat the quest as a checklist of
>> actions to do to finally obtain the reward, then yes, everything
>> is a fed-ex, and big quests are just strings of them.

> Exactly my point, except the assertion that I 'despise' questing.
> The opposite is actually the case; rather, I think it was Lee who
> seemed to have an issue with recognizing fundamental quest
> mechanisms, and perhaps some emotional need to 'snipe' me with an
> out-of-context quote-fragment.

My appoligies for inferring intention from a very short and clipped

> For the record, I love quests, always have, but I also think they
> need to be better and better.  And one of the ways to make them
> better is to understand what really makes them tick and then design
> a flexible quest system around those core mechanics so we can make
> the compelling story that surrounds them.

As long as you do not start to belief that moving objects and flags
and everything is what makes a quest 'tick' then I will be happy ;)

Really though, it is not the mechanism here that is important,  but
the compelling story and relevance to the player.  I do not believe
you can understand quests by looking at the mechanics  anymore than
you can understand literature  by partitioning stories into  start,
middle and end.

>> What would be welcome is a way to preserve the 'unknown' part of
>> the quest between various takers. And perhaps rather than relying
>> on persistence make it quite possible to actually fail.

> Yes, putting in a random factor and/or decisions that can lead to
> failure or some other event is interesting, as long as some caution
> is applied such that the player doesn't feel 'screwed' when he
> 'fails' the quest he thought he'd earned the right to succeed at.

I entirely agree that  if you put in the chance of failure then you
also have to increase  the control the player has  over the context
of the quest and its encounters. If you give them only one shot and
one that can fail, you also must give them both chance to study and
prepare, and must not make the success based on the roll of a dice.

>> The first would make it impossible to hand out a checklist of
>> actions once the first player finishes it.  The second would make
>> taking the quest, and completing it, really meaningful.  You can
>> have time to prepare for each stage, but you get only one shot at
>> it.

> 'One shot' content is generally something used rarely in MUDs/MMOGs
> because of the challenge of building enough content into the game.

I do not mean to imply that there should be only one attempt at all
just that a particular player can do it only once,  and then either
succeeds or fails. This is of course coupled with ample opportunity
to prepare for the attempt, and several early points to retreat for
a while before making the final attempt.
A good example would be a 'smuggle operation'. The player must get
something into, or out of, a heavily guarded area. How this is ac-
complished is entirely up to her. She may try to sneak past guards
and detectors,  or she can try to use disguises, or perhaps enlist
the aid of many friends to attack the perimeter at another part to
draw off guards.  She can even retreat  if something unexpected is
encountered that she had not prepared for.  However if she ever is
caught, then the quest fails and there will be no retry. And in an
ideal situation,  having failed the quest would be as widely known
as having succeeded at it, with all the consequences of that.

> This doesn't mean I'm against 'do it once' content; rather, it
> should be used sparingly.

I do not agree with you here. Each and every quest could easily be
made 'do it once'. The solution is to make the quest really invol-
ved and requiring a lot of preparation.

> A greater challenge than merely adding
> randomization (which, if there's too much, disempowers the player
> because he feels his fate is too much a 'roll of the dice')

Randomisation is a poor solution regardless. Even if it is done, I
think it should be hidden *much* better than it generally is.  But
then,  I always felt that the 'hitpoint attrition' that most games
rely on is not particularly entertaining.

In the thread 'Crafting systems' Bjorn Moren argued that combat in
most games was well developed, but I do not agree with that. Quite
the opposite in fact. Mostly it comes down to a few 'tricks' and a
lot of hitpoint attrition.  Too much randomness and far too little
skill, either player or character.

>> And of course once you completed the quest the game should
>> recognise that fact and treat your character differently from
>> others.  If you have become the champion of the gods, you should
>> not then (have to) return to exterminating mice.

> Again, what you describe is very 'low content'.  One can't have many
> of these quests, and then, with what you described, you not only
> couldn't have many of them, but you'd have to limit how many people
> could become the champion of the gods, lest everyone is eventually a
> god, leading to godhood becoming trivial.  Putting a lot of effort
> into this kind of content is simply a poor use of your designer's
> time.

Of course not all quest should result in the players becoming 'the
champion of the Gods'.  In fact  it should be quite an accomplish-
ment if somebody manages to succeed at that. But at a smaller sca-
le saving the town from the orcs  should actually be recognised by
the inhabitants of the town. It could be as simple as a random non
player walking up to the character and saying  'thank you from de-
livering us from the orcs',  and perhaps  have the shopkeepers say
'nothing is too good for the hero of littletown, you can have any-
thing in my shop for half the price'. Just a few small things that
make the player feel that the task he completed actually meant

About the feasibility of doing quests only once, there is a strong
suggestion in the warcraft interview that most, if not all, of the
quests there are of the 'do it once' variety.  While it may take a
lot more effort by the developers,  I think that  it will create a
much greater emotional involvement of the players in both the game
and their character; something that in the end will be more profi-
table to the developers as players will keep on playing longer.

Yes - at last - You. I Choose you. Out of all the world,
out of all the seeking, I have found you, young sister of
my heart! You are mine and I am yours - and never again
will there be loneliness ...

Rolan Choosing Talia,
Arrows of the Queen, by Mercedes Lackey
MUD-Dev mailing list
MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list