[MUD-Dev] MMO Quest: Why they're still lousy

Roger Hicks pidgepot at hotpop.com
Thu Jan 27 17:53:05 CET 2005


David Kennerly wrote:

> However, this cost/content ratio is a naive analysis.  What must
> be taken into account is the amount of enjoyment that has been
> produced from having this simple finite state automaton with two
> states: not stolen and stolen.  Each quest, then, may be
> represented as an arc between the two vertices of the states of
> the world.  I suspect a clever implementation of this could
> justify the additional cost/content ratio.

Lurker speaking up...

IMHO there is a more "out of the box" way of thinking. With a
slightly more advanced AI than current MMORPGs, quests could be
dynamically generated based upon the current world state. This
removes (or significantly reduces) the "cost" in your above
formula. Also, quests could be free to change the world state
without fear.

To use your example, the Ranger hires the PC to steal the Mage's
staff (state change). Once stolen, the Mage wishes to seek
retaliation on the Ranger, and hires another PC to kill him (another
state change). Then the ghost of the Ranger, or his friends, or
whatever seeks retaliation against the Mage and has him locked away
in a dungeon (state change), where he can later be rescued (yet
another state change).

Of course, it doesn't have to happen that way...the "story" could
change easily to reflect other state changes:

The Ranger steals the Mage's staff, but then is converted to a
"good" religion by a PC cleric. The Ranger feels guilt about his
actions, and hires a PC to return the staff to the Mage. The Mage,
who is being threatened by a rival mage then requests a PC recruit
the Ranger to help him defeat his opponent.

I know it sounds difficult (and for a graphical MMORPG it may very
well be), but I am in the process of implementing a system such as
this in my text MUD now.

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



More information about the mud-dev-archive mailing list