[MUD-Dev] Logical MUD Areas

Scion Altera keeler at teleport.com
Thu May 3 00:41:38 CEST 2001


Wednesday, May 02, 2001, 12:01:01 PM, Lynx wrote:

> I was wondering what thoughts the others on this list had as far as
> making areas and quests logical in that players can do them more
> than once without it being absurd. (for instance, the ever repoping
> king that people kill for his sword, etc.)

The answer for the vast majority of stock diku-derivative games is to
be very careful when you build, so that all your mobs are generic, all
the eq is generic, and to put in clues that indicate that the goblin
village gets raided every so often, and the local garrison is full of
soldiers who are experienced in the ways of goblin killing.

This, however, is not my preferred solution to the problem. Being a
coder working on a custom codebase as well as an AI enthusiast, here's
the long version:

Ditch the human built areas and go for generated ones. Seperate the
mobs from the areas entirely: create groups of mobs that go together,
for instance "a goblin village" and "a human village". Then, your
group of goblins can be loaded in a suitable area chosen by the mud,
and they can form a village.

The human village that happened to load nearby them should be full of
humans that have needs, such as money and food. The soldier mobs form
a group and walk over to the goblins, beat them up, steal their money,
eat their food, then return to the human village.

The goblins, fed up about being attacked and killed so much, check out
the humans and decide they are outmatched, so the village is unloaded
and the game picks another suitable location to put it. Now.. this
process could involve making the mobs actually pick up their stuff and
walk over to the new spot, or they could simply teleport at a
convenient time when no players were watching. Doesn't matter too much
on a grand scale.

I mentioned above that you need to ditch human built areas. This is
purely for the sake of not hurting anyones' feelings, and not because
the code somehow requires it. Having been a builder myself long ago
and far away, I know I would be very upset if I built an area and some
yahoo player came along and set it all on fire... destroying the whole
zone permanently. If the mud itself generated the area, nobody will
care if it gets ruined. Therefore you have much greater flexibility in
what you can let the players do.

As for quests, there plenty of ways to make them only possible to
achieve once. It is, however, difficult to make a quest that isn't odd
when multiple players all do it once each. My solution is, of course,
dynamic quests :)

Very simply, the mud tracks the needs of various large groups of mobs.
When one group has a need and another group has what they need, the
mud decides what the first group intends to do about it, based on a
set of rules.. possible factors could be race, military strength, and
money. The first group could attack, try to purchase, spirit away with
magic, or steal what they want.

All of these things can potentially involve players as well. Imagine a
player walking through a city, when he walks in on a few mobs that
approach him and ask if he could do them a favor by killing a few
dwarves in the nearby mine and bringing back their gold? Or even
better, the mobs ask the player to talk to the other mobs as a
negotiator, and offer them some trade goods they have in exchange for
the desired goods. There are many possibilities.

Finally, for the specific example of the king with the sword, the
quick and easy solution is to randomly generate a name for the king
every time he loads into the game... maybe let the mud fudge the stats
on the sword too. Presto... it's not the same king anymore ;)

-- Scion

"In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move." -- Douglas Adams

-- keeler at teleport.com -- peter.keeler at brokat.com -- ICQ: 1824934 --


_______________________________________________
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