[MUD-Dev] Thought Experiment: Permanent Monster Death
Sean Middleditch
elanthis at awesomeplay.com
Tue Dec 16 11:33:37 CET 2003
On Tue, 2003-12-16 at 07:01, Ben Kirman wrote:
> ghovs wrote:
>>> monsters can only be added to the game if the admins
>>> explicitly add them.
>> What would a game look like, if monsters stayed dead? E.g.,
>> All in all, I find the idea of DM-spawned monsters unworkable, no
>> matter how poetic the idea might seem. Either you'll have an
>> empty, boring world, or you'll have a DM spawning monsters all
>> the time, which is not materially different from timed respawns,
>> except that the person doing it might feel quite bored doing what
>> might as well be automated.
> How about looking at it from another perspective. The single GM
> created monster could actually be a band or tribe of smaller,
> respawning mobs, that have taken over a region of the
> gameworld. Players could skirmish all they liked with the
> respawning scout units, but with concerted effort a group of
> players could recapture significant objectives. For example,
> clearing and defending an infested farm could reduce the respawn
> rate of the creatures due to lack of food. This is the equivalent
> of chopping off an arm of the larger GM mob. With enough effort
> and battling, the players could eventually kill the last unit,
> essentially perma-killing that particular enemy(the whole mob
> collective).
This does sound like an interesting mode of play. The thing to be
careful of, however, is the work-vs-reward for not only the players,
but also the GMs. Say I spend some time making a nice little goblin
tribe, setting it up in/near a village, etc. Then a couple
high-level players come in, kill them all, and they are perma-dead.
Drat.
The reward system for the players needs to be adjusted of course,
too. Killing those goblins should be a complete waste of time for
the high-level players, so they shouldn't be even trying.
This is a problem with, say, EQ, where high-level players wipe out
even the enemies intended for much lower-level players, because
there is some sort of reward that is valued by the high level
players (in the case of EQ, quest items).
> I wouldn't say this eliminates all the problems with perma-death
> monsters, but it spreads the focus of the players in that there is
> more than one target and some over-arching battle strategy will
> help in fighting it. One of the problems I can foresee is that
> this, as it includes respawning, would inevitably lead to large
> guilds farming the area, essentially protecting the mob collective
> from other players who seek to destroy the fountain of
> exp/items. A bit like that old cliche when the hero saves the life
> of the villain, because without an enemy his life is meaningless
> (or just empty of ph4t l3wt).
Right. But, since we're talking about a system that already needs a
lot of GM intervention, this problem is perhaps also solvable.
Dynamically tweaking rewards for a certain guild could help, for
starts. The monsters could, as well as having less respawns, have
less treasure if they have been killed a lot (all their loot has
already been stolen), the monsters could migrate, the GM could
change the situation to something unfavorable for the guild (perhaps
throw in some "random" high-level monsters if the area is being
farmed), etc.
The idea of letting the game world automate itself for the whole
player base is what stinks so much about most MMORPGS, and makes
them so incredibly boring and repetitive - the GMs need to work to
make the game run. As is now, most games simply have GMs for
rules-lawyering (because rules aren't hard-coded into the game) and
a player help-desk. If GMs act more like they would in a table-top
game, they'd be capable of managing much more dynamic and
interesting worlds, such as having the mini-plot monster groups
we're talking about here.
--
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.
_______________________________________________
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