[MUD-Dev] Re: Random Resets

[Kwon Ekstrom]

From: "John Robert Arras" <johna at wam.umd.edu>
> On Mon, 29 Apr 2002 "Kwon Ekstrom" <justice at softhome.net> wrote:

>> I've done alot of thought on handling things similar to this
>> (although not this exactly) with creating script and equipment
>> templates for creatures.  You could create alot of diversity
>> simply by allowing multiple templates to be applied to a creature
>> when it's loaded.  That'd create alot of interesting diversity
>> with a minimum of work for the builders.

> This is something I've played with a lot, too. I've got two things
> that that I've gotten a lot of mileage out of. I think I've
> mentioned them before, but not in a really detailed manner.

My templating system has a variety of similarities to what you
describe, although I'm a control freak, you have to specifically
tell things to load in a given area.

You can do this by specifying, I want x amount of y npc to be loaded
from vnum a to vnum b with z templates.  It'll then apply your
templates to the NPC's as it loads them into the game.  You can
either make new templates in your area, or call templates from
another zone.  I have an area which stores alot of generic often
used objects and has alot of basic "atmosphere" templates.  Guards
have this set of eq type deal.

For random pops, you can have equipment templates which have a list
of possible items that load on a mob, and will only load a given
amount of items from the list.  You can apply as many templates as
you want to a mob.

Some templates maintain an incremental state, so you can have a list
of names, and load 10 guards, just put their names in the template
and each guard will pop with the next name, you only use the 1 vnum
to handle them.  You can modify any stat on an npc or object that
you can set with the builder commands (I make use of an editable
interface which the editor uses to be able to modify stats).

It's a pretty advanced system.  I haven't written my prog system
yet, but I intend to allow it to apply templates to items as well.

> The first thing is to be able to put resets on everything:
> areas/rooms/objs/mobs. When things reset, they reset
> recursively. So, a room loads a guard, and the guard loads a sack,
> and some bread loads in the sack. When the reset is called on the
> room, the guard gets created, then the sack gets created, then the
> bread gets created, and the bread gets put into the sack, the sack
> is given to the guard, and the guard gets put into the room.

> Area resets are handled a little differently. If the start area in
> the MUD is the thing being reset, it first picks a random area,
> then a random room to reset the thing in. If it's another area, it
> picks a random room to reset things in.

My reset system works a bit different than ussual too.  When an NPC
dies, it checks if it was a "reset" NPC or if it was "loaded".  If
it was reset, then it puts a delayed event to wait for it's
repop... there aren't "Area wide" resets, each reset has a specific
time before the npc returns.  After setting up the event to be
handled it then applies all of it's templates to itself so that when
the reset occurs it only has to pick a room to load in.  The event
contains the mob to be loaded and what room to load it in... this
allows all of the templates to be applied before the mob is actually
"loaded".

> The second idea is what I call "randpops". Basically, these make
> it possible to reset one out of a large number of choices, and
> it's possible to put things into "tiers" so one reset can give out
> good equipment to powerful creatures, and weak equipment to wimpy.

> Randpop objects are things that store extra data on them: the vnum
> where a block of things to be resets starts, the number of things
> in a "tier" of those things, the number of tiers of things, and
> the chance to pick from a better tier. The chance to pick from a
> better tier can be either a random chance like 1/5 per tier, or it
> can be based on the level of the thing being reset, so that more
> powerful things can pick from better tiers of equipment.

Sounds interesting, creates a fairly generic atmosphere from the
sound of it, but it'd definitely get alot of standardized equipment
out there and would change the flavor of areas over time.

> Let's pretend that I'm really lazy and that I hate building. I
> want to make lots of forests on my MUD and I don't want them to be
> barren, but I also don't want to have to make 100 kinds of
> squirrels and wolves for each area and then reset them to specific
> locations.

My template system was designed to be like that, but it takes a
little more work.  You just apply templates to the area thru the use
of the provided editors (I'm currently working on a GUI builder
interface that communicates with the server via XML)

> This is repeated this N times, and the net effect is that after
> several resets, we reach the point where there are close to 2000
> forest creatures in the world. If some of the forest creatures are
> given a simple drive to find and eat other things, then we get a
> nice little ecology set up. Over time, if players attack things
> near their cities, then the mobs will appear to concentrate in
> unused areas, simply because the random resets there never get
> killed.

Definitely an interesting concept... I have an idea to use a "random
encounter" system where NPC's would get randomly loaded in an area
when a player entered it, and they'd have a timer which would slowly
decrement when there are no players in the area.  If another player
entered the area before the timer ran out, the timers would be
reset.  I figure this would be a good way to handle "generic" mobs
so they aren't constantly using up memory, and you're not constantly
loading new NPC's thus eating up cpu cycles.  I'm writing in java
and pool my NPC's so when the timer runs out they simply get dropped
back onto the pool to await being initialized again.  If the pool
grows too large, then it knocks them off the pool to await the GC.

-- Kwon J. Ekstrom

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