Even when there is no actual narrative, a picture can make something clear that might have been easily overlooked.
Yesterday’s build showed me I’d made at least one unfortunate assumption that could lead to incorrect search results. After fixing this I examined some diagrams I knew would be affected, and saw an oddity.
Narrowed down to a minimal version, the Improved Sneak Attack Sniper feat shows a transitive link. I would expect Sneak Attack to have an edge only to Sneak Attack Sniper, not one to Improved Sneak Attack Sniper. Both feats require Sneak Attack, so once you get Sneak Attack Sniper the requirement is met.
Normally, that would be so. If I were looking at something like evasion or improved evasion, it would work as expected.
Instead, this worked as I should have expected. There are a few things off about this.
- I was looking at sneak attack as a class feature, only. I had overlooked that sneak attack is a class feature with a ‘value’ (how many dice of bonus damage you do). As it happens, Sneak Attack Sniper has a ‘sneak attack +2d6’ requirement and Improved Sneak Attack Sniper has a ‘sneak attack +4d6’ requirement.
- When I normalized prerequisites, I also considered values (how much of the element is needed) or options (‘which thing’ the element applies to, such as Spell Focus applied to a specific school) in doing so. That is, ‘sneak attack +2d6’ and ‘sneak attack +4d6’ are different prerequisites.
- In other words, having two edges here is ‘correct’. Inconvenient and I might do something about that.
- When drawing the diagrams, I don’t take values and options into consideration. This gave me one node for Sneak Attack (fair enough, it’s a single class feature) but I didn’t show the values in any way. This led me to think I had an error in my data preparation stage, when instead it’s a diagramming limitation.
There are at least two ways to address this. The first might be to put the value on the edge. This… works, after a fashion, in smaller diagrams such as this.
I can’t say I really like it, though. On a diagram this small it’s workable, and for a machine-generated diagram like this I can accept what it does to the line shapes — I use the machine-generated diagrams to get me started, they get rendered differently for the books.
For example, in this diagram for Basilisk Stare (taken from Echelon Reference Series: Monk) I show the number of ranks in the Heal skill are needed for each feat. I think it looks pretty okay.
This can be workable for smaller diagrams, but bigger diagrams can quickly become difficult to read.
I am surprised and amused that the new version of Improved Unarmed Strike diagram actually doesn’t exhibit these things. It turns out that while many of the feats in that diagram do have score- and skill-based prerequisites, none of those prerequisites are children of Improved Unarmed Strike, and thus are excluded from the diagram.
There needs to be a different approach for these things. I don’t yet know what that will be. Maybe when a prerequisite has a value, add a small bit of information to the nodes in the diagram and where the prerequisite object becomes relevant.
In this case you can see how much sneak attack is needed for each feat, but there is only one edge shown.
What happens if we look at some other examples? Whirlwind Attack might be interesting.
Let’s see… actually, as it happens it isn’t interesting to me here. I see Dexterity, Intelligence, and Base Attack Bonus (all scores) and I expect they would have different values in various feats. However, because I’m looking at them only as prerequisites of Whirlwind Attack, they are ignored by the other feats to the right of Whirlwind Attack. This diagram might have no change.
Let’s look at Hurricane Slash, I expect that will be a better example.
Okay, much better for my purpose. Spring Attack needs BAB +4, Tornado Style needs Monk level 6 or BAB +6 (as does Squall Slash, but that’s already handled by having Tornado style), and Hurricane Slash needs BAB +8. Dexterity 13 and Intelligence 13 are needed only by Dodge and Combat Expertise respectively.
I’m… not sure this is helping me much. Three things jump out at me.
- The ability score prerequisites still apply to feats after the place they are introduced, but it’s not as obvious. Should I add them each to where they apply? Those could get pretty long.
- The ‘or’ node in the middle makes life a little more interesting for me if I go that route, because I would need to show the ‘or’ relationship in Tornado Style and Squall Slash.
- (Minor, but I’ll mention it) I accidentally trimmed the ‘level marker’ off Combat Expertise. It’s late at night, I’ll live with it because I’ve already started the edits for the next version of the diagram.
Hmm. This has some potential. It’s not my ideal, I have the sense that making the nodes so big could prove to be a problem later… but I see a couple more tweaks I could make.
Huh. This really doesn’t take up much more space than the original version. Each node is taller, but folding the requirements into the nodes themselves lets me get rid of quite a few of the nodes (Dexterity, Intelligence, Base Attack Bonus, Monk, and the original ‘or’ node). It’s clear — explicit — at each stage exactly what each feat needs.
(Incidentally, I presented Hurricane Slash like this to show I will likely have cases that still need manual intervention. Here, ‘Base Attack Bonus +8’ actually satisfies the ‘Monk 6 or Base Attack Bonus +6’ requirement, and thus can supersede it. I don’t know that I can reliably capture that case in code, so it may need manual intervention.)
This one looks pretty decent like this, but how do I practically apply it to other diagrams?
I’m not going to do this one tonight, but if I bring down the Whirlwind Attack diagram again…
I’m not sure how I want to handle it. What would it look like if I all the nodes were as fulsome as the final version of the Hurricane Slash diagram? I’m sure that would cause many diagrams to no longer fit the page, and need to be broken up.
Would it be weird to show fulsome detail of the nodes up to and including the focal node, then leave the rest minimal? That would probably minimize the diagram heights because the big ones in this model are mostly due to a big fanout at some point — in this case, at Whirlwind Attack.
I’d thought this would be a simple post, “picture showed me I’ve got an oddity, here’s how I’ll fix it”, but digging into the problem highlighted more things than I’d expected.
I don’t know how I’m going to handle this. I don’t have answers.
Yet.