I’m not generating code for this, at least not currently. It’s more like lowering authored content into fixed-size runtime data that the hot path can consume.
The animation graph example feels like the same general shape.
I agree, “derived facts with provenance” is probably the cleaner way to describe it.
What I have right now is much less formal than Datalog: supports/items/statuses emit rows, rebuild passes fold those rows into skill/entity caches, and combat reads the cached facts.
But the shape I care about is the same: I don’t just want to know “what is the damage number?” I want to know “why is this number here?” and “which source facts need to go away when equipment changes?”
Good point on performance too. The dirty domains are mostly there to make invalidation and phase ownership explicit, not because I’m convinced the first version needs clever incremental updates. Full clear-and-rebuild is probably the right baseline, and then we can add incremental paths only where profiling proves they’re needed.
Small clarification: I don’t mean optimizing buildcraft in the Path of Building sense, as in searching the space of possible gear/tree/support setups and finding the best upgrade.
I mean the engine-side representation problem after the player already has a concrete setup.
The output is not “the optimal build.” The output is things like increased damage, more multipliers, pierce count, area radius delta, conversion rules, status payloads, etc.
I agree that global build optimization quickly becomes a much harder and more human-guided problem. I’m mostly interested in how to keep normal runtime resolution from becoming a giant matrix of skill/support/item/status branches.
Yeah, I think this is the real danger with this kind of approach: mistaking a useful pipeline for a universal mechanic language.
I’m not trying to build a PoE solver or make every future mechanic fit a clean algebra. The compiler analogy is smaller: authored content emits facts, rows keep provenance, caches are rebuilt in a known phase, and combat consumes the resulting runtime data.
The part I want to avoid is common mechanics becoming direct skill/support/item/status branches inside every skill implementation.
But I agree the weird cases need escape hatches. Some rules should probably be explicit hooks, and some unique mechanics may just deserve custom resolution code.
The interesting design question to me is where to draw that line: what belongs in the boring fact pipeline, and what should stay as hand-written mechanic code?
I’m not generating code for this, at least not currently. It’s more like lowering authored content into fixed-size runtime data that the hot path can consume.
The animation graph example feels like the same general shape.
reply