Wednesday, January 11, 2017

Building a Hex System


For those of you who are not in the know, a hex crawl is a play style in tabletop RPGs (such as D&D), in which players navigate a world symbolically by moving a token representing their group around a large map. This map represents the world as a whole, and simultaneously acts as a game board as it is divided into a hexagonal grid. Individual spaces are coded in a variety of ways; using colors, patterns, symbols, letters, and numbers. These encodings are used by the DM to modify the consequences of the party's decisions as they navigate the world between adventures. In essence, travel becomes a gamble and a puzzle to be solved, while simultaneously giving the DM and players plenty of roleplay material to tell the tale of the heroes' epic adventure through the primitive world. Compared to other playstyles, such as Theater of the Mind, a Hex Crawl is an extremely gamist oriented playstyle, with a focus on tactile elements. As such, it often pairs well with other highly gamist/tactile playstyles, such as dungeon crawls, and tactical miniatures combat. However, it is also possible to run an entirely Theater of the Mind Hex Crawl, with the DM narrating environments and events, while the players attempt to map their own progress from this limited information. There are also all sorts of hybrid variant styles which blend elements of both.

Remember back when I wrote Planning A Hex Crawl? One of the first steps I mentioned was building a hex system. It occurs to me that most people probably have no idea what a hex system is, or, even if they do, they have no idea how to go about building one. So, I'm writing a whole article dedicated as a tutorial to building a hex system for RPGs!

The Basics.

Let me just start by saying that the hex-system presented in the 5e DMG is fucking trash. Read that sentence and know it to be truth. Got it? good. Now, let's talk hexmapping. We're going to be using a lot of convoluted terminology here today, so here's what you need to know:

1. "Hex" is short for "Hexagon". We are not talking about superstitious witchcraft nonsense. Often, when something is built from hexagons, "hex" will be applied to it as a prefix to form a single word. We are gamers, and we need to make things overly complicated like this! IT'S HEXTRADITION!

2. A "grid" is just a pattern of a repeating shape with no change in orientation. For example, a hexgrid is just a repeating pattern of consistently sized and proportioned hexagons, all aligned in the same way. A square grid is probably what you're most used to seeing. In addition to these, there's also isometric grids, triangular grids, and a whole host of others. Each of these generic forms have many variations as well. Today, we're only going to talk about hexgrids- and only the variants that matter in RPGs.

3. A hexmap is a map composed of a hexgrid. A hexagonal map is a map that IS a hexagon. A hexagonal hexmap is a hexagon-shaped-map filled with a hexgrid.

4. "orientation" means the direction a thing is facing on a surface. Because we are working with maps, the directions we will use are the standard orthogonal ones we see on traditional maps; North, East, South, and West. These will be abbreviated to their first letter in all cases from this point forward. We will do this because, as I will discuss again later, your paper is orthogonal, not hexagonal.

5. "Size" refers to the actual dimensions of a thing on paper. "Scale" is the symbolic distance that thing represents. For example, a hexagon with a size of 1 inch across could represent a mile of space in the game world, making the scale 1 in = 1 mi, and therefore, 1 hex = 1 mile.


Alright, so now I'll address the question some newbie is undoubtedly asking right now: Why do we use hexmaps for RPGs? The answer is stupid: "Because Gary Gygax was a wargamer." No, I'm serious, that really is the only reason this bizarre mode of play ever made its way into this hobby. Gygax played wargames which used hexmaps for movement and terrain and enjoyed them, so he implemented hexmaps in overland travel situations, and everyone else has been aping him ever since. That said, there's a reason people want to imitate this: When you do it right, it can be damn fun! Nobody understood this better than The Judges Guild, (a third party publisher) who took the hexmap thing and ran with it so hard, they built a campaign system which revolves around overland travel. Wilderlands of High Fantasy is a published campaign setting built in the early hex crawl playstyle, making hex crawls one of the earliest distinct playstyles to appear in D&D, alongside dungeon crawls.

But that doesn't make it any less weird. Let's dive into the weirdness now.

Using Hexagons.

Before you can go planning a hex crawl, you need to have a hex system to build your maps. A hex system is a method of producing maps of areas of your world using consistently scaling hexgrids, which coordinate evenly to higher and lower scales in a series. In other words: It's a system of scales for measuring distance and pinpointing character position. Surrounding that system of scales are a myriad of other properties which must be considered in order for it to work. In particular, for the purposes of organization, precise orientation and scaling, and location pinpointing, you also need a coordinate system, which will vary significantly depending on the size of your hexes and maps, relative scales, map shape, and hex orientation- to say nothing of various nesting techniques.

Orientation

First off, you need to understand that hexagons, unlike squares, have an orthogonal orientation. If you place a hexagon with two flat edges vertically oriented on a page, (What I'd call "portrait" orientation) you will notice that its horizontal direction will have two vertices instead of flat edges. This is called the flat orientation. Gygax and the Judges Guild preferred this orientation, so it is by and large the most popular orientation, but I don't think I will ever understand why, because it is terrible. The opposite orientation is one where the pointy ends are vertically oriented, (What I would call "landscape" orientation). This is called a pointy orientation, because apparently, we gamers are a bunch of fucking two-year-olds. I'd have gone with portrait and landscape myself, but fuck it, the tradition's already been set, so I'll use the more common terms instead.


Anyways, the reason I say you want pointy orientation: Unlike with a square grid, where orthogonal movement is done by crossing a boundary, and diagonal movement can be done by crossing a vertex, (corner/point/intersection) a hex-grid actually makes movement extremely complex and confusing if you take even a moment to begin thinking about it. In either orientation, a hexmap allows you to move any of the 4 diagonal directions, but only 2 orthogonal directions. Whether those two are up/down or left/right are determined by the orientation. (Flat orientation gives up/down and pointy orientation gives left/right) You can't reclaim those lost two orthogonal directions by crossing a vertex the way you would with a grid, because there's no hex on the opposite side of that corner! Instead, you have the edges of the surrounding tiles extending radially outward from the center of your starting space. Dammit!

You're making a map but don't know your cardinal directions?

In pointy orientation, you get your east/west orthogonal directions easy. I feel this is preferable for most mapping, particularly for hex crawls, because people do not generally walk over the top or underside of a spherical planet. Instead, we travel around the warm center strip. Because east/west travel is more common and more likely, it should receive preferential treatment. But now we hit a snag: north/south travel is extremely important, even if it is less common! We have a few options for what to do about it, but the only acceptable one in a hex crawl is to just stagger the party's movement left and right as they travel North. This introduces all kinds of problems if the players are mapping their own progress on a hex grid as well, but we'll get to that issue later. Maybe I'll make a blog entry about all of the different modified hex grids people have invented to try and resolve this issue, but sadly it will have to wait for another time.

It should be noted that non-spherical worlds don't follow this trend. If your world is flat, use whichever orientation you prefer!

One other thing I should mention about hexagonal orientation, is the "arrows" of a hexagon's vertices.

As an example, let's take a look at the 6-mile hex that the 5e DMG and most other gamers encourage. This here is a 6-hex hexagonal map. (Count the whole hexes across the middle) See how you wind up with 3 corners the party could "stand on", and three which act as the intersections between hexagonal maps? I, personally, dislike these proportions because they mean extra work for me when I'm writing up coordinates.

Staggered Cardinal Direction Travel.


So, here's the weird part about using hexagons to represent overland travel: It actually doesn't do a very good job of the task. In fact, hexagons are terrible at representing any kind of movement whatsoever. Seriously! Square grids are better suited to 8-directional grid-based movement, because you can write a rule to correct diagonal time-space relationships. (So you don't travel farther in the same time by taking diagonal steps) Such a rule simply is not possible in a hexgrid, because 6 of the 8 cardinal directions are not possible in a single step.

Looking at the above example, let's start with northward travel. Let's assume the players say they want to go "North". Which path would they take? The green one? The red one? Some mixture? How do the players know whether you tracked their movement as NNE or NNW? Unless they are filling in a blank hexmap as they go, the only way would be to tell them, and that's incredibly useless information without a hexmap in front of you to work with. Also, you're going to need to remember which way they went, because from now on, North will have to be the same direction for every hex on that row, otherwise N/S travel will be random and unpredictable. Another worthy point about pointward travel, is that compared to edgeward travel, it is extremely inefficient. Even though you are ostensibly travelling in a straight path, the actual geometry of the map can not represent that. As a consequence, you are arbitrarily penalized for it.

Now take a look at the true diagonal. What a wonky mess. As with pointward travel, diagonal travel requires you to remember the row's E/W orientation. On every other alternating row, going NW is the same as travelling W, or travelling N. This creates a bizarre world, where travelling W, N, and NW, could variably take you to the same damn place. This happens along all of the true diagonals, and it is a pain in the ass if you are trying to mix a hex crawl with a theater of the mind on the player's side.

All of this is why I favor pointy orientation: E/W travel is more likely and more frequent than N/S, so in the long-run, it has the lesser penalty to the players.

OK, now we need to talk about overall map shape. When making hexmaps, we are faced with a series of confounding problems. First and foremost is that your paper is a rectangle, not a hexagon. Secondly, because hexagons are staggered along an orthogonal direction, you will always have an edge of half-hexes somewhere on your map. Thirdly, you can not fit a series of hexagons flush along the diagonal edges of a larger hexagon.

Square Paper; Hexagonal Grid.

OK, this is probably going to seem blindingly stupid to you, but it's actually a massively frustrating issue when you're trying to build a standardized system of scaling hexmaps. Basically, hexagons are not rectangles, and making a hexmap on a rectangular piece of paper means there will be a clash between the geometry at the map's borders. The main way of resolving this is to make sure that you can fit an exact number of hexagons in a linear series (along their flat edges; rows in pointy orientation, and columns in flat orientation) between the two parallel orthogonal boundaries of your map. OK. You following me so far? Good, because I'm now going to make you immensely frustrated.

Let's say, hypothetically, you decide to start with your smallest scale, and draw just one big hexagon on a rectangular piece of paper. OK, that's fine. Now, let's say you want to make a bunch of these because there's a really big city that fills multiple hexes, and you want to map it out. All fine and dandy. Even if there's some overlap on the page corners, you can just draw everything inside the hexagon and leave the corners blank. And even if your city takes up a staggered area- say, two rows- you can always just stagger the sheets if you want to lay them out and look at the whole place at once. So far, so good! Now you decide to go up a scale, to a map which is 10 hexes wide, using the previous size as being equivalent. Alright, fine and dandy, you count out your ten hexes edge to edge and start drawing your map... Wait a minute. Every other row is staggered 50% to the side. That means along the column edge, about half of the hexes extend off the side of the page! Ugly! I mean, sure, you can draw the other half on the next map over, but now it's possible for a party to be on two different maps at the same time! And if you have coordinates drawn up, the party will actually be occupying two different coordinate positions on two different maps!


So what are the solutions? One is to go with a torn-edge map. In this system, you remove all of the partial hexes from the map edges. Next, you make sure that the two column edges are asymmetrically staggered, such that they fit together, like a puzzle. The resulting zigzag pattern looks like a tear, hence the name. The best thing about these is that you can us the zigzagging as a guide to remember the cardinal directions for each row, so that they stay consistent.

Torn-edge works fine if you are only working hexes on two scales. If your higher scales are just freehand drawn maps, it's a great solution. It can also work well if your higher scale maps are drawn in a grid, as long as your torn-edge hexmaps are square at their outer rows' farthest corners. However, if your upper scales are also hexmaps, and you want to be able to transcribe your torn-edge maps to it accurately, you are in for all sorts of problems, because squares and hexes do not mix well on the same map.


The next solution is best if you want a series of scaling hexagonal maps, which is standard for hex crawls: a hexagonal map. In this solution, you draw a big hexagon on your paper. This represents your map's borders. Then you draw a hex grid inside the large hexagon, representing the hexes of the next scale down. Now, you're going to run into the same problem that you had qith a square map: the staggering of the hex grid makes it impossible to have a flush-edged series of hexes along a straight map edge. This WILL interfere with coordinates for all of the partial hexes. In order to get around this, you can do a hexagonal torn-edge hexmap! Same idea as with the square one, just remove all of the partial hexes and make sure the overall maps can tile without overlaps or gaps. The staggering will make it kind of an awkward, lumpy-looking shape; not much of a hexagon, really.

Coordinates.

Now, we need to talk about your coordinates system, which I've already mentioned a couple of times. In a hex system, you have a series of scale maps representing different levels of magnification, with each lower scale encompassing less area either in the same space or a larger space. Larger scale maps are composed of a grid of the areas of lesser scale maps. In order to keep your place in this system, you need a key which will tell you where you are, and allow you to keep all of your maps organized in your notes. The coordinates system is that key. Now, if you have a very simple hex system, with only 2 scales and a very small world, say 10-25 sheets or so, you can probably get away with not using any coordinate system at all. However, if you are building a vast, planet-sized world with elaborate geography, you're going to be in for a ride.


The above image shows how point-edge coordinates are done. Notice how every other series corresponds to either the even or odd numbered system? Keep that in mind.


OK. Now that we have the Y coordinates in there, are you starting to see the problem? Every other series is using only even or only odd coordinates. There is a way around this. Take a look...


OK, so now what we're doing is have our coordinates zigzag with the map through the series. There's a billion ways to put coordinates on to hexmaps, and I'm going to be honest: None of them are perfect the way they would be on a square grid. You are all going to have this weird wiggling pattern running through everything you do. The following picture shows you how to use the coordinates to step through scales in-play.



Now that you understand how to do this stuff the rational way, go read this blog by some other guy. That blog entry talks about how everyone else has been doing this for years. If you look closely at how the corners and edges of his nested hexes work, you'll probably start to see why I have a problem with it and felt the need to write a whole article about how to make grids with hexagons.

You might also be wondering about this "6 mile hex" thing other hex crawlers talk about. Everyone loves the 6 mile hex. I hate it. If you want to know why people like it, see this blog entry by another other guy. Just so you know, while he makes a good case, his rationalization is just as arbitrary, opinion-based, and tribal as my own. The proportions of an even hexagon stay the same, regardless of the scale. Focusing on scales which divide evenly into 6 is only useful if you plan to do some kind of mathematics regarding geometry while exploring the wilderness. Also note, his "rule of thumb" for distance to the horizon uses a square root function, and is based on faulty knowledge. Your eye can see a galaxy 2.6 million light years away, because all that matters is how much light gets to your retina. We do not shoot "vision beams" from our pupils which would somehow limit our visual range. Anything which rises above the apparent curvature of the earth will be seen by our eyes.

Once you've read all that, come back and join me for a trip through bullshit land, while I try to build usable resources from the 5e mapping standards.

Example: The 5e Hex System.



OK, Let's go through an example. Let's try and build the hex system described in the 5th edition DMG on page 14. Feel free to use the maps I make, if you plan on using this system! (would not recommend it. There is a reason I use this one instead.) Now, remember how, at the start, I told you the 5e hex system is a steaming heap of horse excrement? That's why it makes such a good example. You would go insane trying to implement this system in your games. It is ambiguous, poorly defined, ill-conceived, and one of the scales is based on a factual error! It exemplifies why you should not mix grid geometries, why you should scale evenly and consistently, and why precise tessellation is a must! Let's begin.

I always try to work with hexagonal hexmaps, because they have minimal overlapping and can be used as the hexes for the next scale up, which is simpler than mixing grid geometries. I'm going to make standard hexmaps with overlapping partial hexagons at the edges. I have my own notation for these, so that they have common coordinates on both maps, despite the overlap. No, I'm not sharing that. You need to do some things yourself.

Local Scale Map.

Our first scale is going to be the local scale. They don't mention it in the book, but it's always handy to have a single-hex map for a local area, like city road maps and whatnot. This one is simple. Draw a big blank hexagon on the page and leave a space to write coordinates. Done! OK, I like to have a little more detail than that. Let's bust it up into a smaller grid so we can have some approximate distances to base our local maps off of. It took me a bit to find a measurement that broke up nicely, but this is what I got:

1 Mile = 5280 Feet
1 Squared Square Acre Edge = ~209 Feet
If you break down a 1 mile hex into 25 sub-hexes, each of those hexes will be approximately one acre, because they'll be ~209 feet across. OK, so that'll actually be way off, but it's closer than most players will ever check. As long as the system is internally consistent, nobody will notice or care. Even if someone does, just say your fantasy people use a different acre than we do.


This is an example of a really good hexagonal map. You can walk to and stand on each corner and the center of each edge from the center space. It tessellates perfectly on all axes. I would strongly recommend a grid ratio of 25 for pretty much any hexagonal map hex system. It works very well. 4 maps in a row makes 100 hexes, so figuring approximate distances at a glance at different scales is very intuitive. For those who like to kind of keep in mind the passage of time, even when characters are just wandering about town, it takes about 1 minute to travel across an acre hex, assuming they are travelling the same normal pace as overland travel. (30/25=1.2) So, while you might not have them crawl the map like with overworld travel, you might jot down the locations of various buildings and count the hexes on the paths between them as the players carouse about town, and use that to track the passage of time in-town.

Provincial Scale Map.

A provincial-scale map has 1-mile hexes. (That means each of those hexes can be represented by 1 of our local maps. In effect, the provincial map hexes are tiny local hexagonal maps tessellated together.) The radius of the map should be the distance a party can travel in one day at a normal pace from its center. Since adventurers move 2 miles (hexes) per hour, and they can walk 8 hours a day, the radius should be 16 hexes, for a diameter of 32 hexes, +1 for the center space. OK, no problem. I can build that. So far, so good!

As a point of reference, the Canadian city of Calgary is about 17 miles across, (Jan 11, 2017) so you could fit the whole city in one of these provincial maps. Now, that's a modern city, but it should give you some idea of how big a capital city would actually be, even at this scale. Even a medieval city would still be at least half that size; a good 8 miles across. That means you actually have a high enough degree of granularity at this scale to describe the general footprint of a city, AND plan for local-area roadmaps which coordinate to the provincial map! Good stuff!

As another point of reference, everything in Skyrim would fit into a 6-mile hex. Keep in mind though, those cities and towns are extremely simplified and miniaturized for the sake of playability. Whiterun, the capital city of one of the holds, has a population of only a few dozen. This is also a side-effect of all game content being hand-crafted; you just can't create and program the lives of several thousand people per settlement in a reasonable time and produce a fun game. Still though, as far as wilderness goes, it says a lot about the degree of geographical variety you can fit into a map like this.

Finally, if even that doesn't give you a clear idea of how big these spaces really are, I have one more picture for you. This is a 1-mile flat hex drawn around some dude's house. He spent a long time getting the math right, so I hope you appreciate it.


So, when your players are wandering around the overworld, mile by mile, remember just how much variety of terrain, how much stuff, they are wandering past on their way to their destination. Never tell me the wilderness is empty again. If you think it is, you've never been there.

OK. So, maybe not great stuff. I mean, as far as hexagonal maps go, this one is pretty funky. Take a look at how the down-arrow corners are actually the intersections between partial hexes. Weird. Also a pain for coordinates. On the bright side, it tesselates just fine, so if we make a scale up from this using provincial hexagonal maps as being equivalent to one hex, they'll correlate!


Alright, that's all fine-and-dandy, but WAIT! In 5e, players don't really move over land by distance, they move by time. Many other blogs about hex crawls and overland travel will tell you everything is based on time. And, you're right, in play that is true. But when we're designing our hex system, space is king. Don't trust me? Check out what happens when we try to replace the functional 1-mile hexes with 2-mile "hour-wide" hexes.
Yeesh! Look at this poor tessellation between maps! It's a broken mess!


And, to really drive this point home, the DMG itself states that the heroes will not necessarily always move the same distance per hour. They can travel at a fast or slow pace, altering the total linear miles traveled. They could be mounted on horses, or riding in a vehicle which travels much faster. They can use spells to alter their overland travel speed. Trying to measure space AS time only makes sense in quantum mechanics and astrophysics.

Kingdom Scale.

And now we come to Kingdom scale. This is where it all comes falling apart. Reading from DMG pp.14...

A kingdom-scale map has 6-mile scale hexes. That is really random and weird, because it doesn't divide into the 16 miles per day that the adventurers are capable of, like, at all! That means, from day to day, adventurers will be moving partial hexes on the next scale up. But, fine, whatever, you only NEED to track their hourly movement on one map anyways, right? All it means is that you can't draw the kingdom-scale hexes on top of the provincial scale maps to show their correlation, nor can your draw the perimeter of provincial maps on the kingdom map to give them meaningful coordinates. because nothing about them will line up!

Oh. Wait a minute. That's kind of a bad thing isn't it? That basically means you can not make a hex system off of this. Fuck.

It gets worse.

They go on to say that a Kingdom scale map should be "the size of Great Britain or half of California". How good are you at geography? You're terrible at it too, right? Don't worry, so is the nincompoop who wrote that sentence. End-to-end, Great Britain is 874 miles long, and California is 840. Yeah, they're almost the same size! In fact, Great Britain is a bit BIGGER than California!!! Not half the size of it!!! OK, fine, whatever, I'll go with the one which looks most like a kingdom, Great Britain, and assume they wanted the whole thing to fit on one map. The average between the two lengths is 857 miles. OK, 6 doesn't divide evenly into that, so our hexgrid isn't going to fit our map at all. No number games will make that work out.

OK, let's change our assumption. Let's assume they meant half of Great Britain or half of California. OK. So I fidget with the calculator and start fudging the numbers to find something close and round, that we can base an evenly gridded map off of. 450 miles is a bit larger than half of either of the example regions, but it evenly divides by 6-mile groups into 75. So, our kingdom-scale map is a 75-hex-wide hexagonal hexmap. That makes for a pretty fine grid,. In fact, it's so fine you can't even number the axes, it's just too damn small. You can't even meaningfully draw symbols on hexes, let alone utilize any sort of encoding! And it has that fugly corner tessellation the provincial map had, too. Eeyuck.

Here's your map, you masochist.
So, fine, we were able to make our kingdom scale map, even if we had to fudge the numbers and make up a bunch of stuff for ourselves, but let me just reiterate a massive issue with this system as presented: We can not draw out a nested hexmap of our provincial hexagonal maps such that they will fit on this map, and you cannot draw a nested hexmap of the kingdom scale hexes on the provincial scale such that they will fit on that map. This means it is impossible to precisely scale by coordinate position. At this point, you are left with two options:

1. Fuck it. Make up your own system that isn't obviously retarded.

2. Don't bother with nested tessellating grids. Just draw really massive 1-mile-hex hexmaps and one world map. Leave it at that. The intermediary scales have no further use.

Continent Scale.

Alright, let's stick a fork in this bastard and call it done. This is the final scale presented in the 5e hex system. We are first told that 1 hex is 60 miles. That means every 10 kingdom scale hexes compose a content scale hex. Cool! Sounds like these two can correlate, right? Wrong. Our kingdom map is 75 hexes wide, which means only 7 and a half continental hexes would fit across! That will not tessellate properly at all. Great. Another broken scale. In fact, you can't even draw it. That's fucking pathetic. I did promise you guys some usable content, so how's about this. I give you two 6-hex hexagonal maps, at a scale of 1:1mile. One is based on my method of measuring hexes, where you count across the center, and the other is based on the traditional method of counting outward from a central hex. There both awful, but hey, if that's what you like, go for it.

6 Hex Width

6 Hex Centered

OK. I have one last thing to say:

To quote the DMG:

"Whichever scale you start with, it's easy to zoom in or out on your maps. At continent scale, 1 hex represents the same area as 10 kingdom-scale hexes. Two cities that are 3 hexes (180 miles) apart on your continent map would be 30 hexes apart on your kingdom map, and might define the opposite ends of the region you're detailing. At kingdom scale, 1 hex equals 6 province scale hexes, so it's easy to put the region covered by your province-scale map into the center of a kingdom-scale map and create interesting areas around it."

Bullshit.

Alright, in return for all of your diligence in reading this whole thing, I will present you with one genuinely useful resource. A hexkey page. See, most maps have a symbol and terrain key drawn right on them. Since players will probably want to enter hexes that would be covered by a key, you can't do that. For the purposes of sustaining your sanity, instead of memorizing every encoding you've invented for a hex, just make a separate sheet and keep it handy as a reference if you forget what an encoded symbol, number, or terrain is supposed to represent.


2 comments:

  1. Great article, sorry I am just getting to it like five years after you published it!

    ReplyDelete
  2. Your coordinates need serious help, try this instead.

    Take a hex, the six adjacent hexes, and the six diagonal hexes. This gives you 13 hexes. If you enclose these in a larger hex, you end up with six half-hexes plus the 13 in this superhex. Take three of these half hexes and associate those entire hexes with the superhex. This gives you 16 subhexes to a superhex. This method tiles perfectly.

    Additionally, number the hexes 0-15 (don't make an outer edge hex 0, or math gets wonky), then you can use base-16 numbers, known as hexadecimal and used regularly by computer programmers, and then you can number every hex uniquely on an infinite plane, each digit of the number represents the what hex at a particular scale. The neat thing is, you can scale this up or down as much as you desire without any issues, for example, if you pick a 1-mile hex as your origin point, then a 1/4 mile subhex in that 1-mile hex would be 0.1 or 0.5, or you can go up to 4-mile hexes which might be 4X or 7X (If referring to a superhex but not a specific subhex, you use X for the subhex), then you can reference specific hexes or subhexes within other hexes such as 12.7, 306, 7.04, 5.b, a7, etc. (hexadecimal is where the letters come from. If you don't know, there are plenty of programming resources explaining hexadecimal and math resources explaining different number bases)

    This addressing makes it easy to index hexes as you can just put them in numerical order. You can also have a single page template with a hex amd it's subhexes, or even three levels if you want, and it can work as your template for every map at every scale. None of that nonsense about different map templates for different scales or different rates of conversion between hexes and subhexes.

    Make that template fit on a single sheet of paper and you can fit it all in a binder and just pull out whichever one you need, all nicely ordered and easy to find and easy to index for points of interest. You can add new maps whenever you want greater detail showing a hex's subhexes, or even a larger hex containing the surrounding superhexes, etc.

    ReplyDelete