Tuesday, December 27, 2011

Beating The Generic Out Of Generated

This is a continuation of yesterday's post, Groups.  I suggest having a look at it before continuing here.

In the comments section, Pavel Berlin made reference to using a senior hex with 19 junior hexes, such as this:


And I've been thinking all day of how it would work with the H/non-H concept I proposed, along with other things about generating hex content and watching the predictably piss-poor Sherlock Holmes movie - which I went to see mostly for Noomi Rapace, whom I loved in Men Who Hate Women, and whose talent I knew wouldn't be used even that much - and I was right ... but I digress.

Up front, the problem with 19-hex groups should be immediately obvious to anyone familiar with permeatations and combinations.  What happens is that the bell curve becomes so dominant, virtually every hex winds up looking something like this:

In effect, spackled.  Forget having a senior hex where every junior hex is habitable ... that chance just dropped to 1 in 524,288.  If we consider 20-mile diameter senior hexes, the land surface of the actual world is just large enough to allow 9 or 10 such hexes, total, on average.  But of course we know that a 20-mile diameter hex where every square inch is habitable occurs very frequently, everywhere.

The reason is plain: actual topography does not occur randomly.

The more random you make your options, the more generic you make your results.  A 7-hex group allows for some 26 possibilities, each of which look somewhat unique.  A 19-hex group has hundreds of possibilities (I can't be bothered to work them out, sorry) ... but most of them look very much alike.  The difference becomes immaterial.

I meant what I said at the end of the last post.  What's needed is a unifying approach.  If the idea is to create a desirable world, then it isn't enough just to fill the contents of each hex one at a time.  What you'll get if you do it that way is a lot of disconnected results, with mountain ranges popping up in the middle of plains and deserts stretching alongside jungles.  And oh yes, I know, blah blah fantasy world blah blah, but just for a moment consider something.

If you use any ordinary terrain generator, it is a guarantee that your randomly created world will lack any kind of sense, and in precisely the same way.  It will be a generic fantasy world, with mountains popping up illogically in exactly the same way in every case.  One might as well generate your world by taking a screen shot of a Civ IV game and going with that - it will be about as creative and unique.

I mean, if you don't care, why not just generate your world like that?  Pick the distribution of land that most interests you, accept the gold mines and silver mines and beaver as they're spackled over the splattered topography and stop worrying?

On some level I am making a presumption.  I began thinking along this path because, even though I have this massive world based on Earth, where it comes to knowing just what is in a hex is somewhat catch-as-catch-can.  Oh, sure, I can pack a castle in there, and some meadows, and a guy named Joe who poaches swine that wander too far from the sleepy herder Phil, whose chased by Ralph the warden and who has a little hovel by a stream that has trout in it ... I can ramble on like that all day.  What I can't do, however, is really mark one hex as unique from another.  I mean, the above could apply to virtually every hex in France, couldn't it?  What makes one hex different from another?  How do you generate hexes that aren't generic?

The reason, I think, that my character generator worked was because, although the result are random, they are random only to a point.  You couldn't get some results if your strength was high, or low, or in the middle.  Each different point of ability produced a unique pattern of possible results, so that the chances were that you'd get something commensurate with your abilities.  What's needed is a hex-filler that does something of the same thing.

In conjecturing about the whole problem, I've come to the conclusion that there are certain things a hex-generator shouldn't be allowed to generate:  the location of rivers and mountains, for instance, or coastlines, or even prevailing vegetation.  Oh, special qualities of a forest might be generated, but I think it should be established by the DM where the forests ought to be.  This helps create a cohesiveness to the whole world.  The DM could begin the process by making broad creationist strokes, thus allowing a cohesive world.  If you generate everything, you just get that generic world I've mentioned.  This cohesion will then provide structure for the characters.

Afterwards, the individual hexes could be filled, in accordance with the grand scheme.  The DM propositions a forest covering ten hexes.  The generator then determines the details of that hex ... offering hopefully enough levels and combinations of details as to make each hex as unique as possible - and at the same time designating where the party could find an inn, or any other service, feature, cultural icon, etc.

This doesn't seem important, but it is.  Of course the DM can say, "Yes, there's an inn here."  He can also say, "Nope, there's no inn."  If, however, you follow this sort of decision making, the DM is being quite a schnook if the party is half dead and sick when they finally stumble into a civilized hex they don't happen to know well.  If a player is going to die because there's no small hamlet in the hex to offer shelter, the DM is going to feel a bit pressured to put a hamlet there.

But if the generation is accepted, and understood to be the ruling factor here, the DM can firmly state that no, there is NO inn, or even a hamlet, and tough luck.  The players just happened to run across the only junior hex in this civilized area that isn't so equipped.  Oh well, so sad, I guess Johnny dies.  Life is a bitch sometimes.

Having that absolute authority - the table says so, sorry - in your pocket is a remarkably freeing tool for a DM to have.  It ends arguments absolutely at the table.  It forces the party not to rely on they're good ol' soft-hearted DM (who can be talked into anything).  It makes the game hard.

But hard is good.  I've always said so.

10 comments:

Pavel Berlin said...

One the solutions could be that the patterns generated do not represent actual terrain.

As you've said the DM paints a big picture marking for example the senior hex as forest or mountain or plains. And then the generated junior hexes form a kind of "invisible pattern" over that terrain. The DM sees the established "clasters" (2 white + 1 black; 3 black in a row; 1 black circled by 6 whites; etc) and has ways to interpert them, seeing different details over the broad terrain.

I see it to be close to Taro deck or rune casting - finite number of components with guidelines to interpret the pattern they make.

Anyway I hope to see more posts on this topic here. You are definitely on something.

scottsz said...

Not sure of the applications for 'on the fly' or 'prewritten' terrain DM use, but I know computer games use algorithms/fractals. Perhaps this page could yield some leads:

vterrain.org/Elevation/Artificial/

For something simpler using the superhexes that you've shown, could weights/bonuses to hexes around the core shift probabilities (i.e. some of the hexes around a 'mountain' hex would be much more likely to be mountains, etc.)

Alexis said...

Thanks for the links, scottsz, but there isn't much chance of my using them - way over my head, I'm afraid.

It does confirm, however, that the big-picture generation is something that must be done in large terrain blocks (planet-sized, or island continents) if any cohesiveness is to be obtained ... and that was the point of this post.

What is lacking, as far as I can tell, is any gritty on-the-ground flavour ... something along the lines of this for scope, but where the results actually mean something as opposed to things like "Popular Entertainment: Athletics" ... ooo, really precise there.

I'm pretty sure in that department I can do better.

scottsz said...

Are you looking for (a) a kind of hex generator/populator mashup based on static tables of data, or (b) a system of hexes where each hex's table of data is influenced by the surrounding hexes.

The first can probably be done in a simple way, but I think the second would require a database to compile accumulations into.

Alexis said...

Up front, a mashup based on static tables ... but in turn influenced by the data confirmed for a particular hex.

So, if you have a hex that is of a certain elevation, is upon a border, has a given vegetation, a known approximate population, defined hydrographic properties, cultural influences and so on and so forth, how do those known properties affect the 'static' table so as to give results which fit into the cohesive whole?

scottsz said...

OK.

Unfortunately, computing is still primitive in that it requires boundaries and parameters, but this seems possible.

Off the top of my head, I'm picturing a database that begins with all zeroes (flat and featureless). Each record represents a hex with fields depicting elevation and such. The more fields used, the more accurate.

Population of this is where the other parts factor in - more collections of fields that represent your flat possibility tables. When these are triggered, they adjust the values in the records for the hex journeyed into.

Once the first hex is populated, the probability tables would be adjusted - and would have to store those adjustments.

It's the adjustments and how they're recorded/used that is probably the keystone to the cohesiveness you're looking for.

I'm not sure what the initial trigger - the DM 'big bang' so to speak - would be and if that would pollute the purity of the generated results. It might be useful to take one of your Earth hex conversions drawn from real geography as a starting area (the idea is that the data and algrorithms are responding to natural 'data' right from the start).

Kaspar said...

I am actually working on something like this. A program that will generate a world from the ground up. It will work like this:

A. Terrain
1. Create continents by a growth algorithm
2. Rise elevation as it goes inland
3. Create mountain chains
4. Add some random noise to elevation
5. “Smoothe out” the terrain by averaging nearby scores
6. Erosion- rivers must reach seas

B. Climate
Distance from equator, distance from coast, rain shadows from mountains- gives average temperature and humidity in each hex. Now assign biomes (desert, jungle, tundra, etc.) and create weather tables.

C. Economy
Put down villages and towns in appropriate places, have them harvest nearby resources, then trade with other settlements.

D. Culture
Assign randomly generated cultures various regions- all down to names of individual NPCs.
Various nations cal influence each other, wage wars, etc.

Currently I am stuck at Erosion- the rivers all stop in dead ends

Alexis said...

I slammed into the rivers last night.

Not being a programmer, and having to work in just excel, it began to dawn on me last night that just tracing a river course through a 7-hex field, even knowing the entrance and exit sides, is going to be a major pain in the ass. As will doing the same for roads, and then the task of comparing those roads and rivers to the previously generated "wild" and "settled" areas (I decided that sounded better than H and non-H).

What a headache.

Alexis said...

Also, Kaspar, though I don't know if you'll see this comment, you might want to check out this bit about rivers and elevation.

Sigilic said...

All "random numbers" are deterministic given full knowledge of the gener#trix. In other words whether it's a rolled die or excel's Rand(), it all starts from a seed value.

My approach to random terrain has been to start from PC "base" and spiral out to the visual horizon, using d6 to modify elevation up/down and to shift moisture levels at ridgelines. From that set of continuously varying data it is not too hard to fill in the scenery.

I will have to dig up the details. I did a blog post on this some time ago but haven't used it since about 1998. :-/