[MUD-Dev] MMO Simulations (was Re: MMO Communities)

[John Arras]

On Mon, 2 Aug 2004, Douglas Goodall wrote:

> I think some problems are unsolvable. For instance:

>   1) Players want to find good mobs to kill quickly.

>   2) Players want to change the world.

> I don't see how these can be reconciled. My system allowed mobs of
> various kinds and levels to spawn in different places and move
> around. Mobs reacted to the players, both directly and indirectly
> (i.e. kill rabbits and there are less rabbits... and there are
> also less wolves and more grass).

>>From what I gather you were running the simulation with explicit
monsters and objects. I don't think it's possible to get enough
creatures in the world to run the simulation. The other issue is
whether or not you were using ecologically/mathemtatically correct
algorithms or you were trying to make a fun game.

So, instead of explicit spawns and creatures all over, divide the
world into a grid and within each block keep track of various
populations like maybe the numbers of plants, and the numbers of
herbivores and carnivores of various sizes. Run your simulation on
these numbers by modifying them occasionally, and having the kinds
of spillovers you talk about below (but only in the numbers).

As the players walk around, occassionally a monster or some monsters
will appear near the players. The number and types are dependent
upon the population densities for the area. The monsters that get
instantiated get subtracted from the population amounts for that
region. If the monsters are killed, their counts don't get added
back into the region, but if they're not killed, then after players
aren't near them for a couple of minutes, they disappear and get
reabsorbed back into the population numbers. That way there's a
larger "pool" of monsters to pick from and players will have a
harder time changing things, although they will be able to clean out
an area eventually.

Also, the populations shouldn't follow an "S-shaped" growth curve
because this isn't the real world with a balanced ecology. This is a
world with hundreds or thousands of superpredators (players) that
kill everything in their path. The goal of the simulation isn't to
simulate a world completely correctly, but to make it fun for the
predators, which means that the population growth algorithms will
have to be different.

> This did, indeed, give the world a very dynamic feel. Yesterday's
> hunting grounds were often barren.

As above, I think that's because you weren't solving the correct
problem: "Making a fun game."

> Instead of just having the travel time from a meeting place to a
> well known camp, players had to spend most of their time looking
> for a camp.

<snip>

> Fighting mobs can be fun. Hunting for mobs can be fun. But
> wandering around aimlessly (at typical MMORPG travel speeds...) is
> never fun.

Ok, so why not let players talk to villagers in local villages and
let them ask the villagers if there are monsters of type X
around. The villagers could then call code that scans the regions
nearby and sees if any are likely to spawn creatures of type X. So,
the villager gives a direction or some name of a region or
something. Perhaps, if this is the case, then that region gets a
temporary bonus to spawning that kind of creature to make it worth
the player's time to talk to a villager.

> This could be solved with some kind of "hunting" skill that gave
> clues, but that's Yet Another Skill that a group (or solo player)
> requires.

Or, you just let everyone "hunt" something and it just increases the
chance that monsters with that name appear when they are spawned
from the regions the player is going through.

> It could be solved with stricter limits on the population sim, but
> that makes the world less dynamic and begs the question of using a
> population sim in the first place.

I don't agree. The problem to solve is "Make a fun game." Not "Make
a sim."  The sim is a means to an end which means that you can and
should do whatever you need to the sim to try to make it fun. That
also means you will probably have to do a lot of work to get it
right. This is what I mean by having to get something that works
then improve it a bit then test, then repeat. Starting with an
off-the-shelf idea is good, but I think it has to be changed a lot
to try to make it into a fun game.

> There was also the problem of skill... Zones could contain any
> type of mob and therefore any difficulty of mob. Players could
> walk out of town and get one-shotted or they could go to the
> furthest dungeon and find it full of rats. Again, this made the
> world very dynamic. It also made it No Fun. Again, this could be
> solved by limiting what kind of mobs can go where... But then
> you're back to a non-dynamic world that happens to have a really
> inefficient spawn algorithm.

That's not true. There's still a huge amount of dynamicism, and
again, the point of the dynamicism isn't to make something correct,
it's to try to make a fun game. That means the simulation and the
dynamics are shaped by what's fun, not by their intrinsic
properties.

> I did solve one (mostly aesthetic) problem of randomness... There
> were "types" of zones which had a list of "themes," which had a
> list of allowed mobs. For instance: A Dungeon is a type of Zone.

>   Cave is a type of Dungeon.

>   A Cave can be a Hideout, a Dragon's Den, or a Necromancer Lair.

>   A Hideout contains at least one Bandit, and may also contain
>   Bandits, Vermin, Slaves, and Treasure Chests.

<snip>

This I really like. I've worked with things that are really random
like wilderness, and heavily controlled things like villages, but
not things in between, but not little minizones that can be cleared
out over and over again and they change. Given enough types and
enough variation, this could be a really cool intermediate step
between large fixed cities and very statistical wilderness.

> It was very cool to watch a population build up and spread out. To
> use another fantasy example (the original game was space-based):
> players aren't killing enough Orcs in the Mountain of Doom. Once
> the Orc population is higher than what the region can support, it
> triggers an event. The type of event depends on the theme. Some
> creatures might suicide or fight each other or generate a plague,
> etc. The Orc theme says to form a Horde, choose a direction, and
> begin ravaging the countryside. If the Orc theme gains enough
> zones from other creatures (including players), they settle down
> again until the population density goes back up... But this is a
> ton of work just to see an Orc Horde, which could have easily been
> done with random() or a GM command, and I doubt many players care
> about the difference.

I think they might care about the difference. If they see a random
orc horde, then who cares about it. If they know that orc hordes are
only created when the population is huge, that might give them an
incentive to go kill orcs or something or find out why they're
spawning so quickly.

> Even worse: If players really like hunting Orcs, they'd never see
> a Horde because the population would always be low. And if players
> don't like hunting Orcs, they'll be forced to fight alot of them.

I think this could be solved by having orc spawning locations that
aren't easy to stay in for very long. That way, the players could
occasionally attack the orc homelands, but it would be difficult to
keep the orcs down for long. There are lots of things that can be
done here, but there are ways to make sure that there will be
occasional orc hordes even if players like killing them.

 I suspect I'm not allowed to do anything with the code (or > even
 have it). Or reason #230 for leaving the game industry: all my >
 good ideas now belong to lawyers.

Oh well. :(

> If I could do it over again, I wouldn't use any dynamics and would
> make everything instanced. Dull. Unambitious. No illusion of
> changing the world. But it's easy and less likely to cause all
> kinds of social problems.

I'm still not willing to give up. I am too stubborn, I guess.

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