We’re working on building a region in TW for a sandbox hexcrawling TTRPG. So far, TW is doing very well, but we are starting to work on making actual content for the hexes, and want a systematic way to do this.
Basic ideas
Lets us maintain a relationship between a hex in the map and the tiddler that describes it’s contents.
Displays the map image we provide it, with the ability to click on a hex and go to/open the associated tiddler.
Adjust the sizing, orientation, and offset of the grid to align it with the image.
Minimize the amount of manual interlinking we have to do.
Nice to haves.
Let Tiddlers know their coordinates, and be able to look up their neighbors, so that fields might be transcluded in automatically. (say, each hex has a ‘landmark’ field, and each hex has a list of neigboring landmarks.)
Let the hexmap declare some fields in hex tiddlers it would like to look up for a tooltip or similar display when hovering over that hex in the map.
Present Workflow
We’ve made a Hex ‘template’ and are cloning it for each new hex, then editing the title to contain the right coordinates. There is no interlinking, you must visually look up the coordinate and then search for the tiddler with that title.
There’s probably a lot we could do to improve our hex template with actual Wikitext templating, but haven’t yet as we want to make sure we have the core of the hex map in place first.
This might be more of a plugin than a workflow, but we don’t know that exact division without more experience.
I admit that I don’t know enough to be sure about this, but I’ll venture the thought:
Are you sure you need an actual tiddler per hex?
Or, can the wiki just contain all the info about what the resources, paths, landmarks are at various coordinates (etc.,) and you can then put a hex into the story river as a virtual node, which will then “see” all the info relevant to that node, including how the maps would look, centered on that hex, with neighboring info, etc.?
If you have a minimalist working demo, or even a modest sample, that could help clarify what kinds of connections need to be made, and how…
So, if we’re understanding you right, we’d have some kind of data tiddler, listing all the landmarks, a different one, (or different table in the same one) listing all the roads, etc, and then viewing a hex would be looking up that info in all relevant data tiddlers?
We don’t feel great about that, so let me lay out what I hope to keep in each hex.
In Every Hex
Coordinate.
Terrain/biome.
Neighbor descriptions for neighbors. (A sentence for each, 0-6 of them, organized by direction.)
Description of self to populate neighboring hexes with.
Full description of self, probably a paragraph or so. There might be more, as I could easily see a hex that rides the line between ‘this needs to be split out as a dungeon/settlement/whatever’ and linked in, versus keeping it in place.
Optional things
If there’s a unique monster, item or character in this hex, does it go into another tiddler? Transclusion is probably a solid answer, but there’s still a balance to be struck. The more structured/forced into a schema hex content is, the harder these questions are. Having a hex be a tiddler gives the most flexibility.
Is there a special rule to traveling this hex? An actual example I have in game is a ghost that haunts a hex at night, so night travel needs special attention.
If a hex can point to an image in a library of terrain symbols, I don’t need to draw a map to overlay the hexes onto, but can define the hexmap ‘bottom up’ and have it display the terrain symbol in the appropriate spot of the hexmap’s grid.
I don’t want to split things off by topic, because the unit of context is the hex. If I add a feature to a hex, I want to minimize how much I need to traverse to keep things consistent, as every time I do so, I risk things getting out of sync.
For example, the Dark Of Hot Springs Island, has 20 page sample. If you look at PDF page 9, you can see that HS-03-01 is four times the size of HS-03-02, and has potentially arbitrarily nested sub information.
Have you thought of using TW-Graph ? The map would be dynamically created via a list query for any tiddlers that should appear at that hex co-ordinate. If your interested I can attempt a proof of concept.
I’d recommend a separate field for the hex co-ordinates as it will make the title cleaner, make navigating the resulting tiddlers easier to (such as listing adjacent hex tiddlers)
I would not imagine “data tiddlers” per se. Just tiddlers! Tiddlers containing the info for this or that object / path, using fields for coordinates and other meaningful variables, maybe in bundles as data tiddlers if you like, but not necessarily… Being able to add features on the fly (by just adding a tiddler) strikes me as DM-friendly.
Of course, you may have good reasons for doing it with old-fashioned tiddlers, one per “tile” on the map, and “containing” all the info about what’s in that tile.
But “We don’t feel great about…” is still not something that strikes me as a clear reason.
Feel free to tell me about why you want actual granular tiddlers for each hex. Meanwhlie, I wonder whether you see what the advantages are of a more wholistic system. I’ll tell you why allowing for virtual tiddlers could be exciting. (This is not just for your benefit, but for anyone who’s thinking about how RPG wikis think about locations.)
But First: a fun and relevant (I promise!) detour: Could I invite you to check out the bingo cards by @Scott_Sauyet?
They illustrate how powerful it can be to have a very simple TiddlyWiki (with nowhere near 1000 tiddlers!) able to display 1000 unique bingo card arrangements, like this one.
When I imagine growing out an RPG map, I wonder: How many hexes would you have? Hundreds? Thousands? How many distinct kinds of features in those hexes? Probably less than the number of hexes…
So your data structure can be much simpler if the info about what’s where is not parceled out into the separate tiddlers, but rather the info about “what’s here?” in each hex is found (and displayed) through dynamic filter queries…
Benefits:
You could rescale and refactor with very little effort. Realize you wish your map were more fine-grained? You change the resolution of your hex-grid, while the coordinates of objects and paths stay the same, and you frictionlessly get (virtual) hexes at the new scale, properly reflecting adjacent-to relations, etc. Alternately, you could switch to quad-grids, or easily view rectangular parcels, etc.
You can add another dimension — like height or depth — without needing to stress out about whether stuff up in tree or under ground is or is not in the same hex as the stuff at ground level. It is where it is, in 3D coordinates, and a map-node displays whatever you want it to (Maybe one character type sees/flies/dives vertically, another doesn’t. What’s effectively “here” is responsively up to template variables.)
Coping with boundary-crossing objects will get much easier: is there a bridge that has features, as an object, but also is not contained in any particular hex? Don’t stress about which of the hexes gets which bits of info about the bridge, or what to do about the tiny corner of that hex that the bridge grazes. The bridge is an object with its own coordinates and parameters, and each hex “node” of the map recognizes its relation to that object. Is there a dustcloud that covers a region, or a foghorn that has a range of influence? Don’t hard-code within the hex tiddler that it’s within hearing-range of the foghorn; instead you can give the foghorn a strength (which can change!) and hexes will “find out” whether they’re in range, and at what perceived volume.
Might you want a long path to Rome, realizing most of the many many hexes between here and there tend to have very few features besides being traversible? Just create some features at coordinates far away, and/or a basic bezier path, and you don’t have to create all the in-between hexes as tiddlers in order to get a simple road from here to Rome; they just show up as needed.
Now, I say all this very much from the design perspective, but not as an expert on RPG maps (though I played on paper in the 1980s ) This is my TiddlyWiki curse: I have good intuitions about data structure, and not necessarily the chops to whip up a proof of concept. But these conversations are good to have early in data-design process, rather than in retrospect…
Also, I’d say you can start designing actual tiddlers for a bunch of hexes, while remaining somewhat agnostic. After a while, try adding some object or phenomenon that is “noticed” by some map-node tiddlers, based on coordinates. Learn how that relational logic works, and then see whether you want to offload more, get more holographic, less baked-in.
The Bingo Demo is very cool, thanks for linking that.
Responding to the benefits breakdown…
The re-scaling idea sounds neat, but it requires you are tracking all your feature positions with more or less sub-hex/floating point accuracy. Doable, and if your map is more physically based than iconographic, you have a basis for deciding that this item goes over this part of the drawing.
This has some merit, there’s definitely some data about hexes that could be encoded in a ‘dimensional’ way. A good example might be hex height, so a mountain top hex would show landmark data from hexes lower than it. Another aspect might be encoding pathfinding costs, even if we never implement a pathfinder, having that in a tooltip while mousing over hexes would be handy.
The bridge case seems like we’d just describe the bridge as a tiddler and then link it from both hexes. (I do note it might be only barely remarkable, in which case splitting it out clutters things… I do miss block level transclusion from Logseq.) The foghorn is a better example of the advantages dynamic content could bring. One that’s potentially more compelling is say, some creature that has an aura around it that spans several hexes, and is mobile.
Bezier roads and rapidly defining terra incognita is handy, but less so for a hexcrawl, which has as it’s core premise, ‘go anywhere’. Roads are attractive for easy travel, but players regularly leave the road to explore. Hexmaps are much more dense than they are sparse.
Overall, I do like the way you think, but for a few points.
The hex is the spatial index. Tracking the locations of objects with floating point precision is entirely possible, but the goal of a hexmap is to abstract distances and positions to something easy to handle at the table. A digital tool can make moving away from the simplifying abstraction easier, but we want to figure out how best to do a hexmap using tiddlywiki before trying to reinvent it as a whole.
how many hexes would you have? This can vary, but in general, we go for 10*12 or so, which is a significant number, but not large. Maps with larger scales exist, but they get sparser in general as they grow. Maybe if I did hexmapping at larger scales this would be more appealing, but I tend to build small, with 1 hex = 1 unique feature, in which case splitting the feature out into it’s own tiddler and linking it in virtually has minimal benefit.
Yeah, I’ll probably be starting in single tiddler per hex mode, and adding more smarts around it to the template.
A genuine thank you for the extensive response, you’ve made us think a lot more about our data model, and where we want to extend it, even if we’re still set on the core of it.
Hey @moss-system - would be cool to collaborate on this then… Here’s what i have so far that gives you a hex layout and places any existing tiddlers based on the co-ordinates stored in a given field.
Here is the test tiddler I used to make a location appear on the map grid:
[{"text":"!! This location rocks !","title":"Test Location","icon":"$:/core/images/plugin-generic-language","coords":"3-2"}]
My thoughts on next steps for this are that:
You need an edit view like above that allows the author to create and see the entire map
A player view would only expose the hex’s that player has travelled (stored as a list of co-ords in a state tiddler) and maybe the surrounding terrain.
Adding the needed actions for navigating that path either from the graph/map or as button/link after each neighbour description in the Hex tiddler
Before I start, let me say, my advice is entirely from the TW side. Not only have I never tried to build any RPG’s, I’ve never even played them!
One very useful possibility is to have the title include the coordinates. I don’t know the coordinate system you’re using, and you can do something like this with any one of them, but my favorite would be an axial grid, with three integers that sum to 0, and a center at 0,0,0
More Info
Edit: I see you link to Hexagonal Grids, so the explanation below might be redundant.
Using that, a Hex might have a title such as Hex/+2-1-1. It’s neighbors are instantly recognizable, using deltas of +1 / -1 / 0 (Northeast, if the grid is pointy-topped), +1 / 0 / -1 (E), 0 / +1 / -1 (SE), -1 / +1 / 0 (SW), -1 / 0 / +1 (W), and 0 / -1 / +1 (NW).
This would mean that the six neighbors of Hex/+2-1-1 would be
With this, the neighbors are found algorithmically just from the title. We can easily distinguish those neighbors that are actually game hexes from those that are outside its borders with [is[tiddler]]. But we can also use a template to apply to those not included, using virtual tiddler techniques described above by @Springer. For instance, just by applying an appropriate ViewTemplate, we might see something like:
Hex/+5+1-6
You’ve fallen off the edge of the world!
This tile does not exist.
If it did, it would be located 3 steps from the closest tiles:
But as soon as you add that tile, the normal Hex tile templates would take over.
This is simplest as a field on your tile tiddler. But depending on the granularity of your grid, you could consider other possibilities. For instance, imagine a large forested area that covers many tiles. You might represent that with its own tiddler:
title: Forest of Blijder
tags: Region
terrain: forest
coords: +1-1=0 +2-1-1 +2=0-2 +1+1-2 =0+2+2 -1+2-1 -1+1=0 =0+1-1
notes: ...
This would mean that to find the terrain for a tile, you’d have to figure out which Region contained it, and get the terrain from there, but it might be a useful abstraction. However if, as you mentioned, your grids are relatively small (10*12), then this might be overkill, and there are other reasonable ways to detail such regions.
Maybe I’m misunderstanding something about your game-play, but this seems a maintenance nightmare. Whatever grid system you use, you should be able to easily determine the neighbors of a tile. And if that’s not possible, then a tile can simply have a list of titles/ids of its neighbors (e.g. Hex30). Then you can get the neighbor descriptions from the neighbors’ tiddlers.
Absolutely. Follow the Philosophy of Tiddlers and create tiddlers containing “the smallest semantically meaningful units.” If you want to know where any Player/Monster/Treasure/Weapon/Whatever is, add a location field to its tiddler, pointing to one of your tiles. If the entity is restricted to staying within a single tile, make the game logic prevent its moving, but don’t try to make it somehow a direct child of that tile.
Again, I would put this in a separate tiddler, and have a field link to that
title: Hex/-2+3-1
tags: Tile
tile-id: 42
caption: The Bloody Grove
travel: TR/17 TR/46
...
title: TR/17
caption: Nighttime haunting
tags: TravelRestrictions
text: A ghost haunts this grove at night. Travel very carefully
...
title: TR/46
caption: No wands
tags: TravelRestrictions
text: Any wand-carriers must travel this tile with their wands sheathed. Powerful, destructive demons will flock to any visible wands.
I’m not sure I follow this. Are you talking about things like the encounters and terrain on that page? Those definitely belong to the hex, but they might be stored elsewhere. For instance, there might be a tiddler called Heavy Jungle, tagged Terrain, and carrying the information like “undergrowth, tangled, dim…”, and your tile tiddler might just have a terrain field with value “Heavy Jungle”. But if “undergrowth, tangled, dim, …” is not the same across every Heavy Jungle, then it would belong in the tile tiddler.
I don’t see anything that describes geographic size. Does “four times the size” refer to the amount of text used to describe them? I would suggest that if you need this sort of sub-tile location information, you make new tiddlers of them, and either extend the coordinate system to identify them, or simply add a location field to point to a tile tiddler. Trying to embed them directly in the tile tiddler will only bring heartbreak!
Coming back to this, I messed around in TW5-Graph, and am not super happy with our options.
I could not find a way to make nodes both non-physics based, and non-draggable, which is kind of necessary.
For the example purposes, I’m mucking around on TiddlyHost as Mournwood Vale
Honestly, I’m starting to look at building an SVG grid myself, starting from the double list/range filter that @Christian_Byron prompted. Need to read up a moment on SVG structure and Tiddlywiki Procedures.
Procedure to draw the points of a hexagon, given coordinates, orientation and radius.
Procedure using that one to make the hexagon a link to a tiddler
Wiring that procedure into the grid-and-lookup system, and adapting it make sure it provides any wrapping required for the svg.
Re: Terrain, right now, each hex is tagged with the region that it’s in, and I’ve not done regions that contain mixed terrains. Likely this should be a field, pointing to a tiddler with the traversal rules for that terrain, and a separate field for region.
Re: Neighbor descriptions
I want to have each hex have a description of it’s own major landmark(s), and then have them automatically fetch the neighbors descriptions. So when I narrate the players arriving in a hex, I pull it up and then I can summarize and describe the list of neighbors. ‘There’s smoke coming from somewhere southwards of you, and the breeze from the north stinks of salt and rot.’
Are you talking about things like the encounters and terrain on that page? Those definitely belong to the hex, but they might be stored elsewhere.
I was trying to say that having manually maintained references sucks, and if the system becomes too holographic/abstract, then it might struggle to represent information that varies too much from it’s assumptions without brittle, manual work.
We fully admit, that you need some schema to have anything automated, but the initial push felt like it was too complicated a schema.
Right now, the way I’m thinking of it is.
A hexmap tiddler, which filters all tiddlers tagged with Hex and having a coord field getting linked to in the Hexgrid. Any valid hex coordinate without a tiddler isn’t rendered.
If an entity has a unique location (There are daggers all over the place, but The Dagger Of Krohm is in The Barrow Of Snakes) it’s got a location field pointing to the hex.
A hex then can have an autopopulated list of all entities present inside it, probably hidden by default or if it’s too long.
Hexes would have fields or tags pointing to their terrain/region.
Hexes would also have the list of neighbors.
Also as a bonus is the partial reveal of this primitive grid using the “path” of an adventurer stored in a separate tiddler field. I can expand this to reveal neighbours as well ( ie within sight of the adventurer as they travelled the path).
I have a feeling that making the hex link to a tiddler or do other actions (like move the adventurer to a hex) will require some javascripting … will keep researching.
I’d thought I’d sent an email response, but that evidently I’d gotten distracted.
@Scott_Sauyet Yeah, we want to derive it automatically, we were speaking from a user-facing ‘what would I see working with the Tiddler’ view. Sorry for the confusion.
@Christian_Byron Wow, this is really cool seeing this come together. Had been experimenting and trying to find time to wrap our head around how to do programming in the Tiddlywiki environment. Sine saying it returns a list of Tiddlers was a shock, but it’s probably worth it avoid doing the math there and hard code in some hex positions, then think about scaling and positioning if the outer SVG wrapper can’t handle it.
I started a new physical job yesterday, and am dead on my feet or I’d have pursued this more actively. Thank you for carrying the torch.
Looking over your demo, I’ll try next to source the POI list from a filter over the tiddlywiki content, if you don’t beat us to it.
A way to handle first versus second column high maps.
Make the descriptions fetched from neighboring hexes be clickable links.
Have a virtual tiddler that lists all the hexes without accompanying tiddlers, so that the GM knows which areas need work.
A ‘bottom-up’ way to handle hexes, so that if a hex is revealed, it can display an assigned icon instead of becoming transparent. This way you don’t need an underlying map, and can do something like HexKit.
I’m working a seasonal event, and have no headspace spare, but here’s my thoughts on ways to proceed.
I’m really impressed with all you’ve done Christian. I hope to contribute more than subject matter expertise in time.
this is a very cool discussion! i have a worldbuilding project that uses a hex map, and i just use tiddlymap with nodes as labels on a background image map (made in hexkit):
would love to make it more dynamic
+1 on handling “flat-top” vs “pointy-top” hexes as unfortunately neither are standard. also the ability to add markers which can be moved around (like PC party or NPC locations which move often)
that demo @Christian_Byron put together is inspiring!
) This is my TiddlyWiki curse: I have good intuitions about data structure, and not necessarily the chops to whip up a proof of concept. But these conversations are good to have early in data-design process, rather than in retrospect…
