Yesterday I explored some unexpected things in my prerequisite diagrams code (short answer: I did not expect what I should have, the code was working as designed). As part of that I came up with a few things to try, to see if they could resolve the oddities.
- For prerequisites that have ‘values’ (ability scores, scores such as base attack bonus, class levels, and some class features such as sneak attack, channel energy, and bravery), when such prerequisites are present in the diagram remove them and place the details in the appropriate node.
Examining Updated Diagrams
Improved Sneak Attack Sniper
When I first looked at this diagram I thought I had a problem because there are edges from the Sneak Attack node to two feat nodes (Sneak Attack Sniper and Improved Sneak Attack Sniper). That’s not supposed to happen! I have code to cull transitive connections like this.
Turns out the code was working as intended, and would cull redundant edges if their intent could be met via other means. In this case the edges were not deemed equivalent because they took into account the number of sneak attack dice needed.
Once I moved such prerequisites into the nodes, things got a fair bit smarter, pretty quickly.
(I also doubled the pen width on the focal node of the diagram, to make life easier for myself.)
This was a good start, but I had a few concerns about doing this for all nodes. Some of the diagrams can get very tall (wide fan-out from an earlier node), and making the nodes bigger is not going to help.
Death Butterfly Style
I think I found a reasonable compromise, though. Show the detail up to the focal node (i.e. the focal node and everything to the left), which is usually a pretty constrained list. Most game objects don’t have a large number of prerequisites, even if they are prerequisite to many other objects.
Death Butterfly Style
Death Butterfly Wings
Death Butterfly Blossom
Okay, in this case I would almost certainly use only a single image for all three feats. The feat chain is exactly the same for all three, the only difference would be in the focal node. There’s no space to be saved, and in fact the three feats are likely to be close together in any book anyway, so it makes sense to use the same diagram, once.
I notice in the third diagram that Death Butterfly Wings shows there is an excluded prerequisite (the ‘1’ in the leftmost part of the node). Turns out this is a small bug: behind the scenes there are two prerequisites defined, one for ‘Dexterity 13’ (so it shows up in the node) and one for ‘Dexterity’ (to point the the Dexterity node, which is excluded from the diagram). I need to redo how I count these things.
Whirlwind Attack
I also looked at Whirlwind Attack yesterday.
Starting to get a little more complicated. This one shows more prerequisites coming in, a bigger fanout after Whirlwind Attack, and I see a couple of nodes for ability scores. This was created with the old code, which means I’m thankful there was only one value used (13) for each of them. Had the various feats had different ability score prerequisites things could’ve gotten out of hand.
Let’s see what it looks like under the new scheme.
Somewhat better, I think. Dexterity and Intelligence are both out, and I know everything I need to up to Whirlwind Attack. Everything to the right is much the same, though I notice the ‘hidden prerequisite’ counts are a little high on two of the nodes. Already described that bug, moving on.
Hurricane Slash
Because I looked at the diagram for Hurricane Slash yesterday…
… I’ll look at the new version today.
Overall, much tidier. I notice the ‘or’ node shows ‘Base Attack Bonus +6’ and ‘Monk level 6’, and still has the Monk node. I know why this happened, and in this case the Monk node should probably go.
Another thing, though, is that the Tornado Style and Squall Slash both should have the contents of the ‘or’ node in them — they both need ‘BAB +6 or Monk level 6’.
In short, ‘or node handling’ needs some work. Good to know.
Further Thoughts
After updating the code to construct diagrams under the new scheme, I was reviewing the output to see that it makes sense.
Overall, I’m pretty happy. Many, many diagrams look like they could now reasonably be automated. Considering I have 13,640 diagrams on disk right now (for the ‘full’ data set, not the smaller subsets) that is hugely valuable to me. Many of the diagrams that look like they are too large to automate still look like they can be reasonably deconstructed or rearranged to fit a page.
I ran into one that made me think. I really didn’t feel good about how it looked.
Flurry of blows, as laid out here, should fit a single page without too much worry. I see half a dozen ‘or’ nodes here though, and while as the designer I know they each represent various sets of options (i.e. different ‘flurry of blow or something‘), I’m not sure in this picture that is a valuable distinction.
Would it be enough to make a single ‘or’ node that says “flurry of blows is a way to qualify for these things, but there are other options”? Would that be throwing away too much information?
Then Rich asked me a question that kind of embarrassed me. Not because it was overly personal, but because in my day job (data warehouse architect, I work with data for a living) I encourage my business analysts to get one critical question answered, when people come to us to ask for data products:
What questions are you trying to answer with this?
As soon as I heard that question, everything fell into place. These diagrams are meant to answer two main questions.
- I want this game option (feat, rogue talent, whatever), what do I need in order to get it?
- I have this game option, what does it open up for me?
This approach is part of why the change in the diagrams work: I was showing way too much information before, now I’ve got it reduced… and can reduce it further.
- If this object is an optional prerequisite, in that there are other ways to qualify for the child object, when looking at this object I don’t need to care what the other options are, or how many sets of alternatives there are. If I look at this and think ‘Twin Thunders Flurry sounds interesting’, I will go look at that feat diagram to see what I need.
- I could drop all the ‘or’ nodes here and change the edges from Flurry of blows to the child objects to indicate this is an optional prerequisite.
- I could collapse all the ‘or’ nodes here into a single one, to do the same thing.
- Or, it occurred to me, I could drop the distinction for child objects. ‘Flurry of blows opens these options, look at them to see what else is needed or how to get there’ might be all that’s needed.
- I might also be able to drop the ‘hidden prerequisite count’. If you see a node to the right of the focal node, assume there may be other requirements and go look. This diagram is not going to tell you everything you might want to know about child objects, so perhaps the best thing I can do is stop trying. “Here’s your path, go look” might be the totally appropriate answer.
- (In the same vein as removing unneeded information, I am uncertain I still need the level markers on the nodes. Even after removing now-unneeded nodes, I could really use the space those markers would use.
- Going the other way, though, I feel more information is appropriate. In the Whirlwind Attack diagram or Hurricane Slash, I’m asking ‘what do I need, to get here?’. That needs more detail. I’d keep the more complete node structure because that’s what it’s for.
In the case of flurry of blows, I can see the following potential reductions:
- Collapsing all the ‘or’ nodes into a single one
- Reduces node count by 10% (5/49).
- Reduces edge count by 14% (7/50).
- Removes an intersecting line, making this diagram both a planarity and a proper tree (which makes me happy).
- Removing all the ‘or’ nodes altogether, whether I mark flurry of blows as optional or not
- Reduces node count by 12% (6/49).
- Reduces edge count by 16% (8/50).
- Also makes a planarity/tree.
- Lets me reduce the diagram from 5 columns to 4… which isn’t too important in this diagram, but stealing a column back in a different diagram could mean the difference between that diagram fitting on a page or not.
Perhaps this will be tomorrow’s experiment.
Addendum 1: Manual Experiment
Okay, coding the change can be tomorrow’s experiment. I just tweaked the source code manually, and I really like how it turned out.
If I were laying this out by hand I’m probably swap One-Inch Punch and Pinpoint Poisoner, just to get the edge between Pinpoint Poisoner feat and Pinpoint Poisoner mythic feat flat, but otherwise this is just about perfect for me.
(Okay, perhaps move Flurry of Blows node to the top and drop a vertical line down the left side that has branches to the various leftmost nodes, it’s tidier… but even so, that’s a small change.
Addendum 2: Mythic Feats Puzzle
Still trying to decide what to do with mythic feats. Most often in the diagrams they show only a single prerequisite (the non-mythic feat). If that were almost always true I could see making ‘mythic’ just a marker on the object saying there’s a mythic version. As it happens though, there are enough exceptions I can’t count on that, and mixing different representations would not make this easier to use.