Comment by well_ackshually
13 hours ago
>if skill == cleave and support == wide_sweep: make cleave radius bigger
if skill == cleave and support == focused_edge: make cleave smaller but stronger
if skill == cleave and support == twin_cleave and rule == guarded_arc: quietly move to the woods
>That can work for a demo. It gets rough once the game has lots of skills, supports, items, statuses, and encounter rules.
Laughs in path of building : https://github.com/PathOfBuildingCommunity/PathOfBuilding-Po...
Path of Exile has deeper mechanics than pretty much every other ARPGs out there, PoB covers the vast majority of them, in a beautiful mess of about 20k lines of calculations in various files.
Making it a "Compiler problem" makes it an unsolvable one in acceptable time.
Fun fact: it directly parses mods from their ingame description into a mod database that is basically a stringly typed list of whatever increases also. : https://github.com/PathOfBuildingCommunity/PathOfBuilding-Po...
Second fun fact: that's the one for Path of Exile 2, that has different mechanics. The PoE1 version is the same thing, except even larger.
So yeah, don't bother about making a compiler. Your compiler will figure out micro upgrades and die in three months when the game adds incompatible mechanics. Stay agile and on your feet.
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?
> Making it a "Compiler problem" makes it an unsolvable one in acceptable time.
If I understand correctly, "compilation" is needed only on equipment change. I remember some FPS drop in PoE when changing the gear too.
>in a beautiful mess of about 20k lines of calculations in various files.
And is it actually suitable for realtime? PoB is not a realtime application.
Stat recalculations are pretty much immediate, yes. The only thing that takes a while is calculating the nodes with the most potential gains, since you're in effect calculating reachability, combined stat increases, etc, which is a few thousands to millions of calculations depending on how far you look.
FPS drops in PoE would not be caused by damage recalc: this is done entirely server side and on application of the damage/dot tick. That drop you're seeing is just loading the assets and recompiling some shaders, if anything.
But also: it doesn't need to be realtime. Your damage is a simple math formula, applied against another for enemy defense, for each hit instance. There are definitely some builds that stress servers due to the sheer amount of hits/tick, but that's a matter of optimisation. PoE lowers server ticks when it can't follow.
The post is talking about optimizing for build damage/resistance/etc, crafting a build. Which probably doesn't even take into account conversion shenanigans, over time things like wardloop that requires setup, cwdt and a load of other things. This is not an optimizable thing in any reasonable time, and human application of logic is pretty much faster.
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.
So the “compiler” part is closer to:
equipped skills/supports/items/statuses -> emitted modifier/behavior rows -> dirty derived caches -> runtime facts consumed by combat
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.