Buildcraft Is a Compiler Problem

Summary

ARPG buildcraft looks like a content problem until the combinations start piling up. The examples here are excerpts from a Zig ARPG game engine where skills, supports, items, and runtime rules all need to compose. At first each rule seems harmless: this support adds damage this support makes projectiles pierce this item makes spell damage apply to melee this status adds a temporary stat this affix gives the pack more speed this unique changes a rule Then the combinations show up. Cleave with a bigger radius. Cleave with a smaller radius but more damage. Cleave with a bleed payload. Cleave with a twin flank. A projectile skill with pierce, chain, and fork. An item that says a spell stat now applies to a melee attack. A status that temporarily changes the same stat that an item and support already touched. The tempting path is a growing pile of special cases: 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. The framing that has worked better here is: Buildcraft can be treated as a small compiler pipeline. Authored content is the source input. Supports, items, statuses, affixes, and class rules emit facts. Those facts get folded into derived caches. Combat consumes the caches. In this design, skill resolution should not have to ask, "is this Cleave with Wide Sweep in support slot 3?" By the time a skill resolves, that question has become lower-level runtime data: increased_damage_bp = 500 area_radius_bonus_subunits = 1000 area_sweep_profile = default status_payload_count = 0 more_multipliers = [...] "Compiler" here doesn't mean a grand language system. It means source facts become runtime facts before the hot path has to care where they came from. Auth...