Resets and repops

Adam Wiggins nightfall at inficad.com
Tue Mar 18 10:00:44 CET 1997


> [Much good example deleted - the famous 23rd platoon bites it.]
<Chris Gray:>
> I have to admit that when I first decided to write a MUD, I knew very
> little about them. Still do, actually! So, the concept of a global reset
> or repop never occurred to me. Now that I know about them, I find them
> unpleasant and unrealistic. When I came upon similar situations, where
> I wanted to replenish some monsters or prizes, what I did was to simply
> store the time that the last set had been "used up". Then, if a player
> character (I explicitly chose to not have NPC's trigger such things)
> enters the area, and the time is sufficiently later, then I will regenerate
> the stuff just before the player enters the location. So, there are small
> resets, but nothing global, and only when "needed". I like this way of
> doing it.

Not bad; my only problem with this is that if there's any sort of mechanisms
by which the player can learn about their world without actually going
places, this starts to break down.  The most obvious example is the
spell locate object.  In a similar vein I've seen many implementations of
clairvoyance/out of body experiences that allow the player to take a "peek"
at the world (ie, cast 'clairvoyance' vlad shows you the room that vlad is
in).  So I guess if you don't plan to have any of this you're in good shape,
or if you somehow make it so that any PC that "sees" into the zone (via
crystal ball or whatever) triggers a reset in the same way as walking into
it. (Of course, this doesn't solve the problem of "cast locate object sword"
not showing the magic sword that will show up in the vault as soon as the
player takes a step into the zone.)  But I guess I like to avoid doing
things this way (that is, triggered by players) because it's pretty tricky
to avoid slip-ups like I describe above.  Using the brute force method
tends to be easier all around and works more consistantly.  Having said
that...

> The problem of course, is that all of this takes code in the scenario.
> But, this probably isn't any different than global reset code - its just
> the trigger condition that changes. For the 23rd platoon, I would prefer
> the special-case regeneration. This gets rid of the problems associated
> with players who know precisely when to go back into an area, and so end
> up hogging its resources from the less experience players, especially if
> you fiddle the regen time a bit with a random number.

This is one of my main problems with repops.  (Hey, guys, it's been 29
minutes since we left zone X, which means it's gonna pop in the next minute)

> In all things, though, you have to balance the benefit actually seen by
> the players against the implementation effort. If the players can't really
> tell the difference, then I'd say don't bother. However, if you do
> everything gradually, so that rumours float around, news articles appear
> in local papers, troop movements can be observed, both directly and
> indirectly, then I'd say go for it. But then, if all of that stuff is
> there, you obviously already have a very detailed MUD!

Heh.  I *really* wanted to do some stuff like this for our reset code,
but as soon as I started thinking about the possibilities I realized that
it was gonna be a pain both to code in the first place, and then to build
areas which make use of that code.  Currently we keep it simple; when a reset
occurs, it will try to 'patch up' the zone (as long as there aren't any
player witnessing the given 'patch') by doing things like giving that dwarven
guard his axe (his got disarmed by a player), or taking the poor guy who's
bleeding half to death on the floor and assume that the bleeding is stoped
and he's now just a one-armed dwarf that lost his arm sometime in the past.

Of course, what I'd really like to see would be no zone reset at all.  It
bothers me that the dwarf who's bleeding won't get patched up until the
players standing around either leave (or, for some reason, do it themselves).
I'm thinking of - dwarf drags herself to the dwarven healer, who (if he has
time) calls upon the dwarven god or uses herbs or whatever method he has
availible to heal his fellow dwarf.  Of course, nothing would reset by
itself, and this is where it gets tricky.  Now the healer needs to get new
herbs, splints, bandages, etc from somewhere.  Dwarven guards, when they get
disarmed or their left vambrace chewed up, have to go down to the armory
and get fitted for a new one.  Of course, things in the armory don't just
appear there - they are made by the dwarven smiths.  Naturally _they_
can't just make weapons and armor from thin air, they need the ore brought up
to them from the mines.  The miners of course, need tools...etc etc.
If a player broke down a door, it wouldn't ever "reset" - the dwarven repair
crew would shop up and patch it up.
This is totaly awesome as far as I'm concerned, but implementing it would be no
small chore.  I think the main problem would just be balance - if the mithril
vein down in the mines suddenly runs dry, the dwarven keep is thrown into chaos
as their entire economy breaks down for two weeks.  While this is the intended
result, it would be easy to have this happening _all_ the time.  (Economies
are a delicate thing, especially when they involve as few people as you'd
normally find in given zone, say 100 dwarves.)
I'm hoping that builders that have the motivation to do this can code individual
mob scripts to do this sort of thing, but I'm still planning to have the game
"fudge" it a bit (having herbs just appear in the healer's chest, for example)
in order to make balance less of a nightmare.




More information about the mud-dev-archive mailing list