[MUD-Dev] Item Distribution in Areas

Jim S dlur at chartermi.net
Thu Feb 22 12:54:38 CET 2001


After seeing much of the recent debate regarding 'item drops' on
Everquest myself our head coder got into a debate of our own relating
to this issue.

We operate a text MUD based off the DIKU code base which is heavily
modified.  I guess if you were looking for something to compare it to,
the Sojourn MUD of old would be comparable in some ways as to game
play and basic player-game interface.

Our current area/zone design allows for a great degree of random
placement of both mobiles and items within our areas.  The status quo
seems to be either a very difficult progression through an area
leading up to the final battle in the zone or a population of NPCs
which are rare, thus being there only part of the time depending on
values assigned to them.  The first example forces a group of players
to work their way through the zone progressively fighting difficult
battles and debugging puzzles as they go which all leads up to the
finish of the zone.  The second example is similar from what I
understand to the Everquest model of 'drops' where a certain NPC or
item may only load 1/day or 1/week.

Forcing a group(our mud relies heavily on player grouping--soloing is
not very productive, teamwork is) to work their way through a
progressive area is generally entertaining to our players if the area
is well written to provide an adequate challenge.  With a Multi-player
game you of course open yourself up to oversized groups destroying the
balance of the zone at some point, but we have had little problem with
this so far.  With the random load sequence of item gathering the
casual player is provided with a way to gather items they need to play
without spending 3-14 hours engrossed in a zone.  This also seems to
open up the issue of having campers who rush to the area to see if the
item they are wanting has popped into the game, some of which may not
even be useable by their class.

What our coder suggests is to delay the spawn of items in the zone
until the zone is entered at which point items will load which are
useable by the players who enter the zone.  For example let's say
there is one Antipaladin player in the game named Bubba.  In the zone
Bubba is wanting to go to with his companions to Boffo the
dreadknight's castle.  Now regularly the NPC Boffo wields a Sword of
Good-slaying which is only useable by dreadknights and antipaladins.
Now if Bubba and his group successfully outwit Bubba and acquire his
sword then this sword is in the game useable by Bubba.  The next time
that a group goes to the zone there may not be an antipaladin in the
group so the sword that Boffo would be wielding is useless to them.
Now if Boffo the dreadknight had a pair of steel gauntlets or iron
greaves it would be much better for the players since none of them
could wield an antipaladin only sword.  Basically the zone would
'sense' what type of group is coming at it and adjust the distribution
of its items to fit that group so that there was always something
useable by the group members.

To some extent we do this already with rotating loads where Buffy the
magister might have a wand one day and the next time she might have a
silk robe.  But this is purely random for the most part.

Now for the point(finally).  I'm of the opinion that always having
items useable by the group trying the zone will lead to having
everyone becoming 'loaded' much too easily.  The coder is of a
contrary opinion that the current state of affairs leads to a lot of
items which are unusable by the group members piling up which in turn
floods the economy and eventually devalues the items.

I'm curious if anyone has done anything like the proposed 'sensing' of
the players to modify the rewards before and how it effected both the
player economy and the overall happiness of the players.

Jim S
tempus at exilemud.com
exile.exilemud.com 6666
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list