[MUD-Dev] ramblings on resets and other random things

Adam Wiggins nightfall at user2.inficad.com
Sun Sep 7 20:23:55 CEST 1997


[Travis C:]
> There's been a bit of talk in other threads about long-term player
> goals, allowing players to have a permanent effect on the game world,
> and other such things.  These are all good things to have, IMHO.  The
> major obstacle to these things is resets; if parts of the mud keep
> resetting themselves back to a base point, how can you have long-term
> continuity?

You can't, of course.

> The primary reason to have resets is because of the coder-player
> time disparity; that is, it generally takes a lot longer to set up an 
> area/quest than to explore/solve it.  Coders are therefore averse to
> setting up things that will only be used once, or even a few times;
> spending weeks of your life to set up the quest to destroy the evil
> wizard Fribozz only to have it be experienced by one player for a 
> couple of hours seems like a huge waste.

This is a question about what kind of game you actually want.  Do you
desire hand-crafted quests at the expense of there being fewer of them,
and having them be more repetitious?  Or are you willing do eschew these
in order to get greater world variety, but at the same time loosing the
hand-written story effect which we associate with muds and RPGs in general?

> There is, however, another option -- reusing old pieces of several 
> adventures to make a new one.  I think that this option is very
> applicable to muds.  Many builders routinely create a new area every
> time they come up with a new quest or adventure idea.  However, that's 
> not really necessary -- there's no reason why areas, NPCs, items, 
> and other things can't be reused, possibly with modifications.

No kidding.  This goes back to what I was saying to Brian about making
a bunch of different 'stock' models of space stations, various sorts of
of spacecraft, etc, and then making use of those over and over.  Normal
mud builders wince at this idea, but it's really perfectly practical -
most of the places we go in RL are fairly 'stock'.  It's the stuff that's
in them that make them interesting.  The idea would be, then, to cut down
the actual amount of builder time while simutaneously increasing consistancy
of the world by making them use larger building blocks rather than everyone
just creating from scratch.  Thus area creation is more like: "Okay, I'll
start with a Genjuran medium cruiser.  Throw in a Genjuran mercenary
for the captain, a human first officer, and a standard randomized crew
complement.  Now set the captain to be wanted by the Krakon empire for
royal abduction.  Add Krakon first princess as a willing passanger whose
target is to reach the planet Andra to reunite with her secret lover.  Create
secret lover, an age 28 male Illian, on planet Andra."
Here the only 'hard' parts should be the specifics - setting up small scripts
or goals for the various actors to do whatever it is they are going to do.
The builder simply creates a person of a given race for each actor.  If
the builder desires more detail, they can specify age, gender, appearance (like
making the mercenary captain be unshaven, or the princess be particularly
beautiful) or whatever else they like, but if they don't specify, they just
get a random person of the selected race.  Same thing for the ships - if
they desire to name the ships, or give them certain mechanical problems or
paintjobs or whatever else they can, but otherwise they get a slightly
randomized version of the 'stock' model.  Making the captain wanted by
a given faction is simply a matter of placing an entry in that faction's
criminal log; the code for that empire should take whatever measures necessary
to track down the accused.

> To take the famous(?) "rescue the princesses from the orcs" 
> quest -- why not use the same orc tribe in other quests from time
> to time?  For example, maybe an evil wizard who wants to conquer
> the area charms the orc chieftain into helping him.  Or a plague
> could break out, but rumor has it that the orc's shaman has been
> able to cure orcs who get it -- can you find out his cure?

Absolutely.  This is another (related) option - making a small number of highly
detailed factions, and then having quest-writers (as opposed to traditional
builders) who just take existing people, places, and things and give them
agendas.  Make this process easy enough and you can make quests which are
only solved once - you just need some skilled admin folks to go in and create
a quest every so often (driven by the player base, of course).  It's not
the way I'd want to go, but if you desire constant hand-crafted quests and you
(or some other person on your admin team) don't mind doing this on a regular
basis, it could work well.  It's actually no different than being a DM for
a D&D group that meets every couple of days; you just have to keep plenty of
quest ideas flowing.

> Of course, individual NPCs can be reused as well -- does the princess
> ever do anything *besides* getting captured by the orcs?  Maybe she's
> going off to finishing school, and the king needs someone to escort
> her safely there.  The same goes for locations; ever notice how many
> muds seem to have forty or fifty different inns, in each of which you
> can hear about exactly one quest?  Why not just take an existing inn,
> and add a new script to the barkeeper's repetoire to describe the new
> quest and how to get there?

Ya.  Ideally you could log on, see what everyone's up to, notice that the
unsolved quest count is a bit low, grabbing a few unused objects/people,
and shoving them around in such a way so as to create a simple quest.

> The muds I've been on have seemed to have little of this kind of 
> cooperation -- not because builders were hostile to each other, but
> because no one seemed to even think of it.  IMHO, it makes good sense
> for creating a changing world.

Builders get pretty uppity about sharing their stuff - they tend to think
of things they create as being only theirs, and wouldn't even consider
using someone else's stuff when they could make their own from scratch.
I guess the idea would be to set things up so that it doesn't work
this way in the first place.




More information about the mud-dev-archive mailing list