I am having no fun at all in programming river courses with excel, but then I am not a programmer. I successfully worked out a method of determining the river's path through a seven-hex group. Then I worked out a second river's path, entering the same hex, as obviously river confluences do occur. Now I am working out the circumstance of a river originating in a hex. This is all as dull as it sounds, but it's necessary, so I plod on.
I'm in a position, however, to show a little of my work, so I'm going to do that. But first, I need to discuss a problem with hexes inside of hexes.
They are, to say the least, annoying as hell. The main problem, the one no one talks about, is that you are left with partial hexes around the outside, as shown:
figure 1 |
This is all well and good if you're scratching out your world on pen and paper, but if you want to generate the contents of the larger hex, how do you handle those six 1/3rd hexes around the outside? Ignore them? Assume the internal hexes actually account for all the space, because they is a simulation? Or do you accept that what's show above is the equivalent of 9 hexes, instead of 7, and write your programming to suit. If you're going to do that, it would be easier to consider the whole representing 13 parts ... but let me tell you, when you are working out the path of a river, or where things might be place, you would rather work with 7 options rather than 13. Trust me.
I've decided not to recognize those hexes for the moment, with an expectation that I will account for them in the future. In the meantime, I'm going to assign each 'diamond' to the hex immediately counter-clockwise to it, and move ahead from there. I hope the gentle reader can forgive my laziness.
Okay, let's take the seven hexes inside the map I posted of southern Russia last week:
figure 2 |
There's clearly not a lot of detail there. I don't propose at the moment to add a lot. Instead, I want to show generally the positioning of just two things: the rivers in hex, and those hexes which would be settled and those that are not, as shown below.
figure 3 |
There the reader can see the similarities, the one with the other. Now of course this is drawn by hand, from the data created on the hex generation excel file I've built up so far. I'm not such a programmer that I can concoct images ... I leave that to some bright entity a lot smarter than me. The location of the town of Luka, moreover, has been determined by plotting it in place at approximately the same position that it appears in relation to the figure 2 above. It's position was not generated.
To bring new readers up to date, if they haven't read these posts yet, the white hexes indicate settled lands. The shaded hexes, wild lands. We find we have four different kinds of small hex - apart from the one containing the town, of course: river settled, river wild, highland settled and highland wild. Without having any other kind of information, we can already conjecture the sort of thing these four hex-types ought to contain.
To begin with, the heaviest rural settlement will absolutely be located in the river settled hexes. We can posit that at every point where a river crosses a hex side between two settled hexes, we have a significant settlement - probably not a village, as those have been designated on the map already, but likely a manor house of some kind, occupied by a minor local lord, plus a hamlet of 5-20 houses, along with a mill of some kind. Since a lot of this particular area is wild country, we see there are only two such places.
However, we can alternatively surmise that any settled hex containing a river might have such a settlement, and devise a random chance for that accordingly. We can also suppose that any settled highland hex might have a thorp, a small collection of 3-12 houses, probably without a local lord, but made up of independent cotters or villeins. The existence of the river, then, determines the size of the settlement, and settlements can only occur in settled hexes.
The country around the rivers is undoubtedly planted; the highland hexes, on the other hand, would be covered with herders. If a party moved away from the river, they wouldn't find farms ... unless you also incorporated a chance for the incorporation of natural springs - not large enough to initiate a river, but with a promise for irrigation. The highland hex's available water supply could thus be determined first ... and then if it was there, the chance for a thorp could hinge upon that. Things thus following one after another, and making sense. It also leaves the possibility open that, if the party should control the hex, they could identify those water supplies without thorps, and make haste to move people onto those lands and start them farming.
Now, wild lands with rivers would probably be overgrown areas, with various marshes or soft ground. They may also be canyons, with rocky ground and waterfalls ... that would be determined by the overall elevation of the hex, something I haven't yet incorporated. It stands to reason that a river wild hex suggests the river drops significantly below any settled hexes (the settled hexes around rivers would feature flat country good for crops), but if the river doesn't drop at all, that would indicate swamps.
It also stands to reason that highland wild hexes would be higher than settled highland hexes - the tops of hills, mountains, ridges and so on would be less likely to be settled. Thus, at the upper centre of figure three, where you see a patch of settled high country, the wild country all around would probably be hills and scrub. It helps that I know already that this is on the border between modern day Russia and Ukraine, and that I know any wild highland is simply too dry to sustain herding (but a wild area might also have an untapped spring, and that might prove very important for monsters and the like). And that probably, yes, the wild river valleys would be rocky places unsuitable for farming.
Inserting this information into a hex generation table is a monumental task, but that's the one I have before me. I can see from just the start of it how it promises to better define my world, even those remote areas where nothing on the map or in wikipedia is recorded. If I can tell where the monsters ought to be, and where the people are, and how the lay of the land creates ebb and flow, with patterns, for the manner in which those things group together and clash, I can really feel the life of the world beginning to bubble up from the cracks.
I don't really understand why this hasn't been tackled by some entity with a lot more money and creative firepower than just little ol' me.
I've always wondered about that sort of thing myself.
ReplyDeleteWhat I suppose it comes down to is that the programmers who would have grown up on the game would also have grown up on TSR/WOTCs vision of where the game could go.
I.E: nowhere beyond a few DTER tables.
Even then, I think it's only been quite recently, with the dawn of cheap wireless/broadband and smaller netbooks, that something like this would have even occured to anyone.
Did you, for instance, think of something like this when you were 15?
Beyond that of course, it -is- a monumental task. Anyone capable of doing it would likely have a job, and a family (like yourself), and so relegate the time that might otherwise be spent of this sort of thing towards other pursuits.
With all that said though, I'm glad it's being done now, and by someone who doesn't belong to any of the shortsighted businesses that purport to drive this hobby's direction. You may not be a programmer, but from what I've seen of your work, as a subscriber, I have no doubts this will be an extremely excellent endeavor of quality.
Alex,
ReplyDeleteI've been reading all your posts about the habitable vs non habitable junior hex idea quite avidly and I think your on to something really quite useful. I will be using it to help generate terrain on a much smaller scale than the normal macro/kingdom level mapping I do for my campaigns using pen and paper (and I don't even normally use hexes, but rather hand drawn maps layered onto googleearth, which I will one day write a post about on my very humble blog).
The issue is of course, as Arduin identifies, the amount of man power required to create the excel programming to generate logical terrain and settlements based on real world data.
I think that perhaps the reason no one with the money and skills to do this has done it is also because, particularly for the big rpg companies, they are focused on producing material that competes the experiences found in many video games. In the most recent WotC material they don't really print statistics for prominent npcs or your average town guards, just monsters and adventure locaion, which is i think indicative of where the commerical focus is. This is sad because the strength of pen and paper games is the capacity for free form adventure and the creation of a living world (though feel free to ignore these thoughts because I have only a year or so of dm experience).
I reckon you could also hack together something similar for working out dangerous and non dangerous areas of cities, and thereby where major buildings and locations are, using the same junior senior hex idea. Though this is just a thought.
Thank you Sententa and Arduin, I much appreciate the encouragement.
ReplyDeleteSententa, for the record, my name is still Alexis. It's quibbling, and no harm done, but we cranks, we love our names.
Apologies Alexis, I realised my mistake well after I posted.
ReplyDelete