Resets and repops

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Mon Mar 17 18:48:33 CET 1997


:Hoped you had a gorgeous weekend!  Right, I was thinking about the concept
:of resets (LP) and repops (dikus)...

[Much good example deleted - the famous 23rd platoon bites it.]

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.

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.

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!

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA



More information about the mud-dev-archive mailing list