As mentioned in a recent post, the Seek Earth spell is great for treasure-hunting wizards but can be hard on the GM, especially in a megadungeon with hundreds or thousands of locations. "Which of these 117 rooms with gold is the closest, and what's the direction and distance to it?" is a hard question to answer in realtime. And you really don't want to bog down play while you dig through the adventure trying to guess.
But this is the kind of thing computers are good at. I have complete maps of the dungeon, and I have a room key. So in theory I should be able to look at the room key to find all the rooms with gold, then compute the distance from the current room to each of them, and return the direction and distance to the closest. So I decided to automate this.
I figured the coding would be pretty easy and the data entry would be a pain. I was half right. It turned out that tagging which rooms had which metals, which I thought would be annoying, was actually pretty quick. Finding the global (x,y,z) coordinates of each room, which I thought would be pretty quick, was actually annoying. Once those were done, though, finding the closest room with the target metal was easy.
The first bit of annoying data entry was condensing a list of about 1000 full room descriptions to a text file of one line per room: the global room label, then a colon, then a comma-separated list of metals. A sample line:
4-6: silver, copper
This is saying that room "4-6" (level 4, room 6) contains silver and copper. Pretty straightforward. Also entirely manual; one could in theory do some intelligent parsing of the PDF, but I think that process would be tricky and error prone, because of overloaded terms, like "g.p." in OSRIC sometimes meaning a literal gold piece coin, and sometimes being a unit of account like "a 500 g.p. diamond."
The manual data gathering was not exactly fun, but I had already dug through the adventure and converted treasure from OSRIC to GURPS (which is easy for stuff like coins and gems where I just made up a mechanical formula, sometimes not so easy for magic items), so it was really just looking at my existing room conversions, finding the rooms with treasure, and copying just the types to another file.
The next part was creating a file of global room label to (x, y, z) coordinates. I picked a spot at ground level northwest of the dungeon as my (0, 0, 0) basis point, and then the x coordinate of a room was yards east of the basis, the y coordinate was yards south of the basis, and the z coordinate was yards above the basis. (The basis point was chosen so that x and y were always positive and z was always negative.)
I thought I would be able to automate this with OCR (optical character recognition). People have been telling me for 30 years that OCR is a solved problem now. Unfortunately, people are often wrong, and OCR is still a pain. I tried several different OCR tools, handing them images of individual dungeon level maps from the adventure PDF and asking to get all the room labels back, along with their (x,y) pixel coordinates in the map image. I got some of the room labels back, with the correct locations. I also got some partial room labels back, like "4" instead of "41". And a bunch were missing. After a couple of hours I concluded the off-the-shelf OCR software wouldn't cut it. It was entirely possible that I could train my own custom AI model to do OCR specifically on dungeon maps and I could get it good enough to work, but that would require generating a bunch of correct training data, which reduced to the original problem I was trying to solve.
However, I had another source of room data that didn't need general purpose OCR: the room labels on my Foundry VTT maps. For convenience I put labels (visible to the GM only) in or near every room on the Foundry maps, so I don't have to flip back to the original PDF maps to see which room the PCs are in. Foundry has an API that lets you see all the "drawings" on in a scene, with their X and Y coordinates and any text. So in theory you could write a short macro in JavaScript to find all the labels, then filter to only the ones that started with a digit (which were more likely to be room numbers). I didn't know the Foundry API, so I didn't know if this would be a 10-minute task or a few hours of ripping my hair out. It turned out it was actually easy enough that I got an LLM to write the script for me in a couple of minutes. AI is oversold and overhyped (see: OCR in previous paragraph), but when it works it saves time. Now I could paste the script into Foundry, paste it to a function key, and hit that key on any map to spit out a tab with text containing a line like this for every room:
Here the map title is "Basement", the text of the label (the room number within the level) is "8", and the x,y pixel coordinates of the label within this image are 3460,2671. Initially I just had the last 3 fields, but I found that putting the map names in there as well let me easily combine all the output into a single file, rather than needing one file per map and manually ensuring that the filenames were the correct map names.
One annoyance here is that some of the levels in Arden Vul are big and (for performance reasons) need to be split up into multiple maps in Foundry. Let's say a level is 4 maps (NE, NW, SE, SW). Now I need to have x and y offsets per map to specify the global x,y coordinates of the top left corner of the map. I also need a z offset per map to specify its global z coordinate (I made this fixed per map rather than varying by room, which is wrong but probably close enough.) Finally not all maps are at the same scale, so I also needed a pixels per yard scale value for each map. (I went with separate x and y scales just in case, though I think for sane maps you could get away with one scale for both.) I ended up shoving all this data into a single file I called map_xyz.txt, which was full of numbers that were kind of painful to compute, but it was only one line per Foundry map so not a ton of work. A sample looks like:
#map,x0,y0,z,x_scale,y_scale
Arden_Vul_Ruins,0,0,0,0.0638,0.110
I also needed a mapping between my Foundry map names (designed to be player-visible) and the level numbers used in the adventure's map key. For example:
(This is a simple case of a 1:1 mapping, but the hypothetical large level I mentioned earlier that needed 4 Foundry maps would have 4 different Foundry map titles all mapping to the same adventure level prefix.)
Finally, with all the data files completed, the actual code to parse them and spit out the closest gold was mostly a matter of coordinate conversion (x,y in pixels within a single map to x,y,z in yards in the game world). Once everything was in nice coordinates, you can use high school trigonometry to find the distance between any two points (square root of the sum of the squares of the differences between the x, y, and z coordinates). A couple thousand rooms is huge for a megadungeon, but it's tiny for a computer, so no real cleverness is needed in the algorithm: just find the distance from the caster's current room to every other room in the dungeon that has the material they're searching for, sort the distances in ascending order, and return the first one. (I actually return the first several, in case the caster has marked the first hit or three as already known and to be ignored.) The spell is supposed to tell the caster the distance and direction, so I return the distance along with the delta_x, delta_y, delta_z, and room name. Then the GM can lookup the room name in the adventure and confirm it's a good hit, then fuzzify the distance and direction numbers as much as they want, and tell the player the results in game terms.
A sample run and output line is:
./seekearth.py -t treasures.txt -p map_prefix.txt -x map_xyz.txt -r rooms.txt -f silver -s 3-2 -n 1
distance x_dir y_dir z_dir room
29 -28 4 0 3-17
This is saying that the wizard in room 3-2 is casting Seek Earth for silver, and the program should only return the nearest hit. The program said there is silver 29 yards away, x_dir -28 (so 28 yards west), y_dir 4 (4 yards south), z_dir 0 (same elevation), in room 3-17. As a GM I'd fuzz this to "you sense some silver about 30 yards to the west."
This is definitely programmer-friendly UI not enduser-friendly UI, but as I'm the only user right now, it's fine. I don't have any plans to turn this into a scratch-and-sniff turnkey Foundry macro, as the GM still needs to check the PC's spell roll, apply correct distance modifiers, lie about the results on a critical failure, possibly provide better results on a critical success than a regular success, etc. My philosophy is to only automate things that benefit from automation and go back to doing something more important, not try to create a perfect jewel of software. As a result this whole project took a couple of hours. (Trying and rejecting OCR solutions was actually the part that took the most time.)
Anyway, the code is up
on my GitHub. The Arden Vul data files are not, but I'll post them eventually, along with the rest of my conversion notes, after I'm done running the megadungeon.
No comments:
Post a Comment