Recently I wanted to create a little hex map and I wanted to do it on an iPad, I wanted to eventually integrate it into my campaign wiki, I wanted it to be SVG based, and so on. All that meant, Hexographer wasn’t the appropriate tool. I needed to cook something up myself. Based on code I wrote nearly five years ago—the Old School Hex Mapper—I wrote up a little something.
I’m calling it the Text Mapper because it takes text input. No interactive fiddling with the map.
There are various sections of the input.
This is simple. Coordinates, terrain.
# map definition 0101 mountain 0102 mountain 0103 hill 0104 forest 0201 mountain 0202 hill 0203 coast 0204 empty 0301 mountain 0302 mountain 0303 plain 0304 sea 0401 hill 0402 sand 0403 forest
The rest of the input determines how things look: what colors to use, what icons to display. When you start the Text Mapper, the input area already contains an example. Start with that before doing anything else.
Now it gets tricky. For every terrain we used, the script will generate a hex. We need to provide some SVG attributes! Need documentation? Check out the polygon in the SVG specification and click on show next to presentation attributes. That’s what you should be looking at.
# attributes empty attributes fill="#ffffff" stroke="black" stroke-width="3" plain attributes fill="#7cfc00" stroke="black" stroke-width="3" forest attributes fill="#228b22" stroke="black" stroke-width="3" hill attributes fill="#daa520" stroke="black" stroke-width="3" mountain attributes fill="#708090" stroke="black" stroke-width="3" sand attributes fill="#eedd82" stroke="black" stroke-width="3" coast attributes fill="#7fffd4" stroke="black" stroke-width="3" sea attributes fill="#4169e1" stroke="black" stroke-width="3"
In order to add little icons, you can specify a path per terrain.
plain path M -18,-13 C -13,-6 -13,4 -8,12 C -11,14 -15,21 -18,26 C -20,17 -22,4 -28,0 C -26,-4 -21,-9 -18,-13 z M 5,-31 C 4,-19 3,-6 6,5 C 1,10 -0,14 -3,19 C -2,6 -3,-4 -4,-16 C -4,-21 2,-26 5,-31 z M 26,-1 C 16,6 19,5 9,18 C 12,3 21,-8 34,-17 C 32,-12 29,-6 27,-1 z
If you don’t want this path to be black, you need to specify attributes for the path element.
plain path attributes fill="#76ee00" hill path attributes fill="#b8860b"
And finally, the coordinates are simple text elements.
text font-size="20pt" dy="15px"
If you wanted a black and white map, for example, you could use different strokes…
empty attributes fill="white" stroke="#b3b3ff" stroke-width="3" mountain attributes fill="white" stroke="#b3b3ff" stroke-width="3" hill attributes fill="white" stroke="#b3b3ff" stroke-width="3" forest attributes fill="white" stroke="#b3b3ff" stroke-width="3"
If you want to create new path elements yourself in Inkscape, you should draw them in a rectangle from (-100,-100) to (100,100) and extract the the path info from the SVG. Yeah, adding new icons isn’t easy.
I need to add more icons. I’d also like to add multiple icons for the same terrain such that the code will pick one at random.
I wonder how easy it’s be to add text labels, roads, rivers and borders.
The result of the above:
(Also on GitHub.)
Zak thinks about hexcrawling and asks: do you just sort of write a few bits about each place and wing the details when the players get there, or what? Brian adds that most of his hexes are empty (about one in ten has interesting stuff). That density certainly looks similar to the Wilderlands of High Fantasy maps such as the Lenap map that I started with.
For my own Alder King game, I decided to take the advice found in one of the books saying that there was much more to be found in each hex. I started out with the original hex and the six surrounding hexes à la M20 – a true Microlite Campaign:
As time passed and my players started to explore, the map started to grow.
The current player map is even bigger, now.
The things I do between sessions:
- Make sure the hexes around the player’s current hex and any long range goals they want to pursue are on the map with at least a paragraph of notes for each.
- Grow the map if I feel like it.
- Add notes for hexes on the map that don’t have any.
- Add more notes to hexes in order to interlink the various locations.
Also, How to make a Fantasy Sandbox by Rob Conley is the best advice on the topic I’ve seen.
- Packing stuff inside the Hex by Rob Conley
- Wilderland Demographics by by Rob Conley
- Medieval Demographics Made Easy by S. John Ross [via Rob Conley]
- Hexcrawls (how to stock a map like a dungeon) by P. Armstrong
- Finding things in a 5 mile hex by Chgowiz
- How I Handle Hexcrawling by Blair of Planet Algol
- Hexcrawls: Worldbuilding vs. Microlite vs. HexKit by Zak S. (full circle!)
- Building a Wilderness Hex for a Sandbox Campaign by Tim Shorts
There is an amazing Traveller Map API available out there. Specifically, there’s a service that will produce a PDF based on your UWP list. But you know how it is. I bet half the Traveller referees are trying to code up subsector generators and mappers. Me too!
Here’s my SVG Mapper for Traveller. It comes with example data so you can figure out what format it expects by looking at it. Just klick the Submit button! Remember, you need a browser that knows how to deal with SVG files – Firefox will do.
So I’m trying to build mkhexgrid.
- libpng :ok:
- ignore libjpg for the moment :ok:
- FreeType 2 :ok:
- libgd :sucks: – I had to configure and build this inside a X11 session!
- fortunately I already have libz!
- and I need the Boost C++ Libraries – I had too add
CPPFLAGSin the Makefile
- mkhexgrid :ok:
The X11 dependency was surprising. I assume there’s a better way to do it, but I don’t know what it is. The error I got without X11:
Pyrobombus:~/Source/gd-2.0.36RC1 alex$ gcc -DHAVE_CONFIG_H -I. -I/usr/local/include/freetype2 -I/usr/local/include -I/usr/local/include/libpng12 -g -O2 -MT gdft.lo -MD -MP -MF .deps/gdft.Tpo -c gdft.c -fno-common -DPIC -o .libs/gdft.o gdft.c:1405:35: error: fontconfig/fontconfig.h: No such file or directory gdft.c:1468: error: parse error before '*' token gdft.c:1468: error: parse error before '*' token
I also noticed that SVG output required px units, which is not true. I submitted the following patch to version 0.1.1:
diff -c /Users/alex/Source/mkhexgrid-0.1.1/grid.cpp\~ /Users/alex/Source/mkhexgrid-0.1.1/grid.cpp *** /Users/alex/Source/mkhexgrid-0.1.1/grid.cpp~ Wed Jan 10 14:37:42 2007 --- /Users/alex/Source/mkhexgrid-0.1.1/grid.cpp Thu Jun 26 14:06:37 2008 *************** *** 646,652 **** throw runtime_error(string(o) + " is not in px"); break; case SVG: ! if (u != "px") throw runtime_error(string(o) + " is not in px"); break; case PS: if (u == "pt") ; // 1 point per point :) --- 646,657 ---- throw runtime_error(string(o) + " is not in px"); break; case SVG: ! if (u == "pt") ; // 1 point per point :) ! else if (u == "cm") d *= 72/2.54; // ~28.35 points per cm ! else if (u == "mm") d *= 72/25.4; // ~2.835 points per mm ! else if (u == "in") d *= 72; // 72 points per inch ! else throw runtime_error(string(o) + ! " has unrecognized unit `" + u + "'"); break; case PS: if (u == "pt") ; // 1 point per point :) Diff finished. Thu Jun 26 14:08:15 2008
I just used copy & paste to use the same code that was available for PS output.
And finally this is the specfile I used for my map:
output=svg outfile=hex-layer.svg hex-side=1in rows=8 columns=5 grid-color=B3B3FF coord-color=B3B3FF coord-size=10pt coord-distance=0.7in coord-column-start=21 coord-row-start=11
The Old School Hex Mapper is getting better. Notice how it creates the loop at the bottom using a very small number of simple rules. I have the feeling that it should be possible to formulate the rules required for a decent layouting of roads.
Funny how some skills thought long lost are coming back. 90° – a² + b² = c². 90° & 60° – ½ : √3 : 1.
(Also on GitHub.)
I worked some more on the “Old School Hex Mapper” I mentioned before (2007-06-02 Hex Mapping). It does roads! Well, it does them in a crummy way. Basically there’s a road-segment connecting the center of a hex with the edge, which I then copy, rotate, and translate as necessary.
Check out this map with a road. (You need a SVG enabled browser.)
Notice how the ASCII input starts to show limitations when there are more possiblities. Look at this unintended (?) three-way crossing near the city.
The ugly part is that the roads go right through the icons. In fact, they have to, because every road segment has one of its ends in the center of the hex.
So that’s what I’ll try to work on next. I think what I’ll do is have four road tiles, one connecting two adjacent sides (60°), one connecting roads at an angle (120°), and one connecting two opposite sides (180°). Then I can have the connecting parts avoid the center of the hex.
And I’ll get rid of extra three-way crossings near cities and towns. That should be easy to do.
In the mean time, feel free to experiment:
To be honest, I still don’t know whether this is worth pursuing. My hand-drawn hex maps look much better! (My players are not supposed to click the link. )
I’ve always wanted to produce good-looking old-school black-on-white hex maps for my roleplaying games. But I didn’t want to use Windows.
- Update: Now available as a CGI script! You can also link to your maps directly. Check out the Perl sources of the script.
I broke down and wrote a prototype. Behold my awesome SVG powah!
The input file is plain text! Behold my awesome ASCII art powah, too!!
The output is SVG, which I then convert via EPS to PDF. Check out the PDF result.
I found that the best solution was to convert from SVG to EPS using InkScape, and from EPS to PDF using ps2pdf or the OSX Viewer. In my particular case, I just used the following Makefile:
%.eps: %.svg echo Ignore Gdk-CRITICAL and WARNING messages /Applications/Inkscape.app/Contents/Resources/bin/inkscape \ --without-gui --export-area-drawing --export-eps $@ $^ %.pdf: %.eps ps2pdf $^ $@
Producing the SVG was the tricky part. I used a little Perl script called old-school-hex.pl.
What next? Add more “tiles”, obviously!
Here’s how to do it. First, produce a SVG file using a single dot as the map. This gives you the empty hex.
echo . | perl old-school-hex.pl > empty.svg
Then fill it with some strokes, simplify them, delete a few extra points on the paths, and save. Open the file in you favorite editor and extract the stuff you added, move it into the script data at the beginning, in the defs element, following the grass example. Add an appropriate character mapping to the
%char table and you’re done!
That’s what I’ll do right now.
I’m not yet sure how to add roads and rivers.
I’m already starting to wonder… would it make more sense to have all the hex types in the current directory, and use their filename as the reference, and include them as necessary? Maybe if this turns out to be the greatest thing since sliced bread. Perhaps I should turn this into a CGI script…