This is something I’ve been working on over the past few days. This is just the first part - the part that generates the terrain itself. I’ll also be adding generation of settlements, roads, lairs, etc - but for now, I’m looking for feedback on the following terrain generation system.
Hexmap generator
This procedure can be used to create a hexmap as it is traversed - that is, it doesn’t have to be generated before the adventure starts, it is generated on the fly at the table as the adventure progresses.
The generator is based on five different terrain types, listed in order of general elevation above sea level:
Water
Plains
Forest
Hills
Mountains
Procedure for generating a hex
When a PC explores a new hex, go through the following procedure to generate its terrain.
Step 1: Look at adjacent hexes to get a modifier sum
Add upp all the modifier from the following table for the terrain type for each of the adjacent hexes, ignoring any empty ones.
Water: -3
Plains: 0
Forest: +1
Hills: +2
Mountains: +3
Example: Let’s say there are three adjacent hexes that aren’t empty. One of them is a plain (modifier 0), the other two are forests (modifier +1 for each one), so the sum of those three terrain modifiers are 0 + 1 + 1 = 2.
Step 2: Roll 2d10 and add the modifier sum
Roll 2d10 and add the sum of the terrain modifiers from Step 1, and look up the result in the table below.
7 or less: Water
8-11: Plains
12-15: Forest
16-17: Hills
18 or more: Mountains
Example: If the terrain modifiers from Step 1 was +2 and we roll 2d10 and get an 11 on 2d6, then 11 + 2 = 13, which is Forest on the table above - and there’s your new hex terrain.
Yes, I do intend to extend these rules. The problem with that kind of rule though is that since I’m generating hexes on the fly, a new plains might only have one known neighbor at the time of generation. If I through further exploration “discover” (read: generate) other water hexes next to it, it makes no sense to alter the plains after it’s already been visited.
But I suppose you could have a rule that says “if you generate a plains that has two known water hexes as neighbors at the time of generation, then turn it into wetlands.”
This is a problem for me since I want to be able to generate on the fly - I don’t have all the info about adjacent hexes when I generate. So I have to try to take that into account when I’m designing the rules. This also makes it difficult for me to generate rivers on the fly, because I don’t know if they will ever reach water - they might end up in a previously generated plains hex surrounded by hills. Logically, then, that plains hex should be turned into a water hex instead. But by that time, I might already have had entire adventures in that plains hex, so it makes no sense for it to be turned into water after the fact.
Thanks Bryansmiff! Yeah, I don’t want totally random terrain, that wouldn’t be very good. Hexflowers, if you’re familiar with them, partly solve the problem - they make sure that you never end up with a desert next to wetlands - as long as you don’t double back, because hexflowers only take the most recently generated hex into account when determining terrain type. That means if you later walk next to old terrain, you could very well end up with deserts next to wetlands.
That problem is what my system is designed to solve, by taking all existing adjacent terrain into account.
Makes total sense and seems to be a good solution to give each generation role context!
Why 2d10 instead of 1d20? Just for the different average curve?
Right, 2d10 gives you (sort of) a bell curve, so that the most likely outcome is in the middle of the range. And using the modifiers from the adjacent hexes, I move the most likely outcome up or down in the table, to make it more likely to get similar hexes next to each other.
That’s a good point, and I’ve thought of that too - perhaps generate adjacent hexes to the one visited, etc. But the problem remains - then those hexes, which we are now generating, still have unknown neigbors. We’ve just moved the “problem border” one step away. Even if we generate more, there will always be a border between generated and ungenerated.
So I think there are should be two version of the rules:
The version where you generate a complete hexmap at the outset. That one won’t have these problems, because then you can generate all the terrain first, and then you add rivers in a second pass.
The other version, is the one above - the one where you generate on the fly, and you simply live with the fact that there are no rivers. I’m okay with that. The rules can easily accomodate these two parallel versions.
I’ve been thinking about this and I wonder if generating your hexmap as you crawl is worth the trouble. Is there an advantage there to doing it that way as opposed to created a hex region before jumping in to play?
That’s a good point! I suppose it’s best to have both options, then you can choose which one to use on a case by case basis.
I suppose that for me, the primary reason for being able to create it on the fly at the table is solo play. If you generate it on the fly when you play solo, then there’s a chance of feeling like you’re actually exploring something that you haven’t seen before - because you haven’t. You won’t know where the secrets are, because they haven’t been generated yet, etc.
I can certainly empathize with this! HOWEVER, I think you can have both. Generating the overall hex terrain doesn’t reveal all the secrets, just the very basic shape of the land. All the details are still free to be invented in the moment. You don’t even have to generate a huge map all at once, just build out some perimeter around wherever you are. This way you can enforce geographic consistency without creating a laborious procedure.
That’s true - you make another good point. Yeah, I don’t see why that wouldn’t work with the rules as I had envisioned them. You can pre-generate hexes with rivers when you want in a certain area, and you can generate on the fly at a different session if you wish. I mean, as the game starts, it makes sense for the immediate area around the starting town to be known (read: pre-generated). Then, once you go a bit further out and you reach uncharted territory, then you can decide on the spot if you want to pre-generate an area in that direction or if you want to do it on the fly hex by hex.
I ran a small test using some of my own generator procedures and I ended up with this;
Here’s the method I used in terms of moving from hex to hex:
I didn’t factor in a step for water. Otherwise, it’s 2 rolls after choosing a general climate zone.
Here’s the same map (different icons), same generation, but adding a water check. I think it worked out okay-- there’s probably always going to be some cases that need some type of manual intervention or, alternatively, an open mind for some (un)natural oddities occurring now and again.
Came across this concept and it seemed to be in line with this concept of propagating one hex outwards to nearby ones.
I’m sure it’s just a fancy mathematical way to describe what you’ve more naturally all figured out
The video title sounds complicated but I’ll give it a watch! I do think that I would probably personally use a tool to create a hexmap that can do a bunch of math or run a set of algorithms that I wouldn’t be able to or want to do myself.
(Not that I think mine are anything special.)
