Buildcraft Is a Compiler Problem

The article argues that buildcraft in action role-playing games (ARPGs) is best understood as a compiler problem rather than a content problem, as the combinatorial complexity of skills, supports, and items quickly overwhelms simple special-case logic. The proposed solution treats authored content as source input that emits facts (stat modifiers and behavior changes), which are then compiled into derived caches for combat to consume, ensuring skill resolution relies on low-level runtime data rather than checking specific combinations. This approach maintains provenance for each modifier, enabling clean updates when equipment changes and allowing the system to explain where stats come from.

Buildcraft Is a Compiler Problem 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 = ... Authoring data should stay boring A support definition is not executable gameplay code. In this design it is data with a narrow vocabulary. A support can emit stat modifiers and behavior changes. That's the box. It doesn't directly reach into projectile storage, call combat, or patch a random field in the world. Here is one support definition: Read it as content, not behavior code: - skill-scoped increased physical damage - one behavior emission - the behavior is an area-radius delta - it only applies to skills tagged melee and area The support may be socketed next to Cleave, but the emitted behavior still speaks in internal applicability tags. It says "melee + area," not "call the Cleave implementation and change its radius." Future skills can work with existing support rules without wiring every skill to every support by hand. It also keeps an important distinction visible: player-facing labels and runtime applicability tags don't have to be the same thing. Supports compile into rows When a skill slot changes, the old compiled output has to go away before new output is emitted. This pass turns an equipped skill and its active supports into rows: active skill gem + active support mask - stat modifier rows - behavior emission rows The active support mask matters because a socketed support is not always active. In this codebase, gem level controls which support slots are unlocked. I want that detail in one compiler pass, not scattered through combat code. The deletion step is just as important as the generation step. If a support is removed and its old rows survive, the build keeps power it no longer earned. Rows need provenance The pipeline keeps source identity. Small thing, lots of weight. A modifier row is more useful if it says not only "+500 damage increased," but also where that number came from: skill slot, support slot, and scope. Later systems can use that to remove the right rows, rebuild the right cache, and eventually explain the result to a test or inspector. Without provenance, the math can still add up, but the system cannot answer the more useful question: Why is this number here? Entity scope and skill scope are different channels Some supports change the whole entity. Some only change the supported skill. The distinction gets compiled into the modifier row: Boring until it is wrong. If a Cleave support says "more Cleave damage," Dash should not inherit that just because both skills are equipped. If an item says "spell damage applies to melee," that is a broader rule and flows through a different channel. So the pipeline keeps scope explicit: entity scope - affects the actor skill-specific - affects a skill identity rule emission - changes how applicability is interpreted This is where the compiler analogy keeps paying rent: scopes, namespaces, and rewrites in a very small form. Behavior emissions carry shape, not behavior code Stat rows are simple enough: add damage, increase health, apply a multiplier. Behavior changes are messier. Pierce, chain, fork, extra projectiles, area radius, conversion, status payloads, and gem-level deltas are different shapes of change. So they go through a separate emission type and fold into a skill cache: The cache entry is the runtime summary for a skill slot. It doesn't answer "which supports are socketed?" or "which item caused this?" That information exists upstream in the rows. The cache answers the question resolution cares about: damage modifiers projectile behavior counts conversion override area radius delta status payloads effective gem level That split matters. Combat consumes the summary. Inspection and cleanup can still use the source rows. Dirty domains keep rebuilds bounded The sim should not rebuild every derived fact every tick just because it can. Mutation marks dirty domains, then the rebuild pass handles the affected entities. This is incremental compilation in miniature. A support changed? Mark the skill cache dirty. A defensive stat changed? Rebuild defense. A runtime rule changed? Rebuild rules. Nothing changed? Clear stale flags and move on. Partly performance, partly ownership. Mutation says what kind of derived state it invalidated. The rebuild pass does the derived work in a known phase before intent and combat read it. The systems that use stats should not need to ask, "has anyone updated this yet?" The rebuild phase is what makes that true. Tags are an applicability filter, not a skill matrix Once rows exist, the behavior rebuild pass folds them into each skill cache. The cache is rebuilt from rows. Instead of patching one cached field because an old support used to touch it, the rebuild pass clears the summary and folds the current facts back in. Applicability is tag-based: pub fn tags match skill tags: TagMask, require: TagMask, exclude: TagMask bool { const skill bits = skill tags.bits ; const require bits = require.bits ; const exclude bits = exclude.bits ; assert require bits & exclude bits == 0 ; const has required = skill bits & require bits == require bits; const has excluded = skill bits & exclude bits = 0; return has required and has excluded; } A behavior emission applies if the runtime thing being modified has the required tags and none of the excluded tags. In the snippet above that is the skill's catalog tags. For more complicated skills, the same idea can move down a level to delivery or payload tags. That lets content say: requires melee + area requires attack + melee + physical excludes cold This avoids a giant skill/support identity matrix. It also gives me one obvious place to look when a support applies to the wrong thing: the emitted requirement is wrong, the target tags are wrong, or the applicability rule is wrong. The tricky part is tag granularity. A gem can grant a skill with multiple parts: a melee hit, a projectile, an explosion, an ailment payload. A single display tag on the gem may not be precise enough to decide every modifier interaction. The tag that matters is the one attached to the thing being modified. Still plenty of room for bugs, but at least the bug has a small vocabulary. Rule rewrites are separate from stat math Some build effects are not stats. They change how other facts should be interpreted. Example shape: "spell damage applies to melee." Not a flat damage number. It changes whether a spell-only modifier can apply to a melee skill. The behavior rebuild has a small place for that: const direct match = stat applicability matches skill tags, m.applicability ; const rewire match = entity rules.spell damage applies to melee and skill tags.melee and m.applicability == .spell only; if direct match and rewire match continue; The source fact doesn't mutate every melee skill. It doesn't clone spell modifiers into attack modifiers. It emits a rule. The cache rebuild interprets that rule while folding applicable damage modifiers. In the current codebase, this kind of rule can come from authored item effects, class-tree effects, or imprint effects. The weirdness stays in one layer instead of spreading through every skill implementation. Resolution consumes compiled facts When a skill resolves, the projectile path starts from the cache. Projectile delivery then consumes the fields it cares about: And when it allocates the projectile: Notice what is mostly missing from this layer: support IDs. Projectile delivery doesn't need to care whether pierce came from a support gem, an item, a status, or a future shrine. It gets pierce remaining . The source attribution still exists upstream for cleanup, inspection, debugging, and tests. The hot path gets the compiled facts. Bounded weirdness There are caps in the content contract: The behavior cache also has fixed payload slots, fixed more-multiplier storage, and fixed projectile behavior counts. The exact caps are game-specific. The useful part is that the limit is visible. A support can be interesting, but in this version it cannot emit an unbounded pile of behavior. A skill can carry status payloads, but only inside storage the engine knows how to resolve. If content needs more shape than the current caps allow, the content model and engine contract have to change together. I would rather make that visible than quietly grow a hidden pile of effects. Where this leaves the design The pipeline currently looks like this: authored support data - active slot mask - stat modifier rows - behavior emission rows - dirty domains - cached stats and skill cache - delivery resolution - combat/projectile/status queues Each stage has a job. Authoring data stays declarative. Stores preserve source identity. Dirty bits say what needs rebuilding. Tags decide applicability. Rules handle weird rewrites. Skill caches become compact runtime summaries. Combat reads the summaries. This feels promising because adding a support becomes adding a source fact, not negotiating with every combat system individually. The open questions are concrete: tag granularity, the behavior-emission vocabulary, the fixed caps, and how explicit rule rewrites need to become as more of them appear. I like those problems more than a pile of one-off combat branches. The current shape gives me seams to test and places to put the weirdness: express the build effect - emit rows - rebuild caches - consume facts The goal is no giant skill/support matrix, no stale support rows, and no combat archaeology unless I am debugging the compiler passes themselves. Just a small compiler with a sword.