[MUD-Dev] Re: Random Quest Generation

Michael.Willey at abnamro.com Michael.Willey at abnamro.com
Fri Nov 6 17:16:13 CET 1998


chris at realm.zfn.uni-bremen.de wrote:
>Greetings people,
>
>  For like three days now, the MUD I code for benefits
>from a Random Quest Generator, which I have been designing
>and implementing for some weeks now.
>What I would like to hear, are comments on it's
>implementation, and maybe suggestions for improvements; and
>of course I would like to hear experiences of other
>implementations of random quest generators.
>
>  The Random Quest Engine (RQE in short) is placed on top
>of a database, which contains references to special
>landmark rooms, NPCs, monsters, objects, and question-
>answer pairs (riddles). Hard-coded are various 'mission-
>types' (the engine was inspired by the Wing Commander
>series), where each type takes the elements from the
>database needed for 'filling' the quest. The mission type
>also determines the 'quest final state' which the player
>must reach in order to be rewarded.
>
[SNIP]
>
>  Now, if anyone out there has a different approach...I'd
>like to discuss models of random quest generation; also (of
>course as creator of the above model I'm sort of 'blind' to
>its flaws :) ), I'd be happy if people could point out
>possible flaws of the above system.
>
>Regards,
>- Chris

I've been brewing a similar "mission-type" system in the back of my head
for some time now, so I hope my own observations on it would be on
interest.  I'll just touch on shortcomings and potential tweaks as I think
of them:

Probably the biggest problem is that random generators can spit out really
stupid ideas.  Before putting the generator in play, I'd ask it to spit out
a list of a few hundred missions at me, then go through that list and see
how many of the missions just don't make sense.  If a large percentage
strike you as not being right, you need to examine how you're fitting
random pieces together, or what you're filling your database with.  If just
a small percentage are odd, you're probably on the right track.

My very similar plan involves the same kind of random generation, with an
extra step of a query to the objects selected to give them a chance to veto
a potential quest.  If Bubba would never go to the Fire Swamps, and the
proposed quest is "escort Bubba to the Fire Swamps", then Bubba would veto
that quest and a new one would be generated.  Basically it's a means to
allow special case exceptions without having to hard code them into the
generator.

Another potential pitfall is generating the same quest multiple times.  I'm
sure you have your own view on when this is a problem - the two points
where people are likely to see it as a problem is when quest A is generated
twice *ever*, or when quest A is generated twice for a particular player.
Either way, I'd suggest that tracking the quests (either in the generator
or on the player) and vetoing quests that have already appeared should fix
that.

I think it's also important to note the basic limitations of this system:
These aren't world-shattering, life-altering quests from on high.  That
kind of thing requires a bit more care and planning than you can get from a
random engine.  It will probably fit best in the background, generating
missions that keep players from getting bored while you're working on major
stuff.

Other observations:  We had a thread on this topic about a month or two ago
- You might want to reference that.  My observation was that giving
opposing missions to different players might stretch out the enjoyment
factor a bit.  Another interesting idea went along the lines of 'nesting'
missions to form quests of the type you see in most CRPGs - Quest: Get X
from person A, but before A will give you X, you have to get Y from B, but
before B will give you Y, you have to get C from Z, etc, etc.






More information about the mud-dev-archive mailing list