[MUD-Dev] Morphable worlds, Reset based systems revisited

John Robert Arras johna at wam.umd.edu
Sun Oct 27 00:51:41 CEST 2002


On Sat, 26 Oct 2002, Ted L. Chen wrote:

> True, you get 1000 odd zones that aren't repetitive.  But they are
> still 'generic' and at some level, the it appears to be repetitive
> to the human mind.  Walk down any street in any city and you'll
> see buildings that aren't repetitive.  If you're paying attention,
> each one has different combinations of features that set it apart
> from the one next to it.  But the end effect is that a row of
> individual buildings is a row of buildings.  Of course, there are
> exceptions to the rule and those end up as landmarks.

Absolutely. I see this as a long term project, and I don't even know
if it will work. However, this isn't all there is to it.

The zones are there mainly so that the societies have some place to
build their cities and raise their armies and so forth. I found it
impossible to get builders to help when I explained that their areas
would be (temporarily) overwritten with what looks like cities and
their mobs and objects would probably be killed and looted and
carried around by roving bands of orcs/ elves/whatnots. So, in that
sense, I am not as concerned about the areas since I know that they
won't be seen in their pristine state always. It's a tradeoff.

> Likewise, from zone generation algorithms, the usable
> distinguishable set turns out to be much less.  I'd probably say
> on the order of a dozen or so.  The more instances that a feature
> is used, the less impact it has as a distinguishing
> characteristic.

I am already putting huge restrictions on the algorithm and it does
reduce the kinds of areas that are made. The thing about the
features is that if you have hundreds of them and only use a few in
any given location, then they don't get overused too much. I expect
it to take me a long time to get a good collection of features and a
good enough representation of them that they can be generated.

This is the hardest part, I think. Coming up with interesting
features and analyzing them to the point that they can be
synthesized as ?meta objects? that allow me to generate the real
objects in as many of the reasonable ways as possible.

<snip building code example>

> Tying it back to the question at hand, I think it'd be more
> prudent to either generalize your system up to the level of
> neighborhoods (fewer nodes), or at least concentrate on providing
> game mechanics on the level of neighborhoods instead of individual
> zones.

> In Tradewars, all sectors can have some permutation of
> links/planets/starbases.  Those features are used everywhere so
> they serve as little use as differentiators; to the player, a
> sector is a sector.  The true useful information is the
> meta-layer, the link structure or neighborhood.  There were many
> user-created programs that analyzed the sector information and
> reported such things as 5-link dead-ends, 4-link dead ends, rings,
> etc.  In a way, these became the neighborhoods (the
> differentiating delta was their accessibility) and the game always
> became a grab for those rare, easily defended neighborhoods.

I am not sure that I'm following this. Are you saying design on a
general larger scale like design on the scale of a mountain range
rather than the 10 mountain areas within it individually? Or design
in such a way that those patterns become apparent?  Or, do I try to
create the best algorithms I can and then hope? ;)

Some of the code tries to draw the world so that there are some
patterns like areas with a certain overall type (like mountains or
deserts) are next to each other and that the transitions make sense,
like no snow next to swamps. But, I hadn't considered more than
trying to not make it look too bad.

Could you give me an example of what you mean in terms of placing
wilderness areas like swamps or forests into some kind of a world
map?

John


_______________________________________________
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