Arcanum

Player-authored combat identity

Arcanum began with a simple question: what makes a fireball a fireball? I decomposed abilities into reusable behaviours—a delivery method such as a projectile, an effect such as flame, and modifiers that change targeting, timing, scale, or repetition. That lets players build around a preferred combat identity instead of replacing one authored spell with a numerically stronger version.

• Offensive, defensive, mobility, summon, and area-control roles can be expressed through the same node vocabulary.
• Impulse strength can be positive or negative, allowing the same behaviour to create pushes, pulls, movement tools, or crowd control.
• Summons act as mobile spell payloads rather than isolated pets, so their role comes from the spell logic attached to them.

Commitment, counterplay, and readable power

The goal was to prevent the largest spell or strongest defence from automatically deciding combat. More complex spells require greater commitment, and defensive tools create windows that opponents can exploit rather than permanent safety.

• Spell complexity influences cast time, making powerful constructions easier to interrupt and forcing players to choose when to commit.
• Shields gained a break cooldown after testing showed that instant recasting removed meaningful punish windows.
• Arcane Dominion creates a contestable area barrier: opponents can pressure the caster, damage the structure, or force a collapse that temporarily increases the caster's spell timings.

Progression through new possibilities

Progression is built around expanding what the player can construct rather than only increasing damage. PvE activities award codexes containing spell nodes, while CAD equipment determines how much complexity and potency a build can support.

• Randomised codex rewards encourage experimentation without prescribing a single build order.
• CADs constrain grid space, complexity, and potency, creating equipment decisions that affect how a spell is authored.
• Adding potency and grid growth solved an early problem where complexity-only upgrades felt abstract and gave players little reason to revisit existing spells.

A system that can become encounter content

Because spells compile into a shared action model, the same pieces used by players can be authored into enemy attacks, summoned behaviours, hazards, and boss phases. That allows progression rewards and encounter mechanics to teach the same systemic language from different directions.

Spell language and compiler

The node editor is backed by a domain-specific gameplay language that validates spell graphs and compiles them into executable actions. The compiler separates what the player authored from how the runtime schedules and resolves it, making new nodes composable instead of requiring bespoke spell classes.

• Typed spell pieces define delivery, effects, modifiers, branching, looping, scheduling, and construct behaviour.
• Compilation resolves graph structure into a bounded action plan before runtime execution.
• The architecture supports importing and iterating on player-authored spells without hardcoding complete abilities.

Deterministic runtime and ECS composition

SpellVM executes compiled actions through ECS-driven runtime systems. Projectiles, zones, delays, channels, summons, and deferred effects can continue over multiple ticks while preserving the context and funding lineage of the original cast.

• Deferred actions inherit the correct caster, target, spell data, and resource ownership.
• Shared execution paths keep direct, wrapped, scheduled, and construct-driven actions consistent.
• The runtime is structured so player, NPC, summon, and boss abilities can reuse the same mechanics.

Costing and deferred execution

Spell affordability is calculated before execution through bounded cost expressions rather than draining energy independently at every node. Deferred actions inherit the cast's funding lineage, preventing projectiles, delays, zones, or summons from escaping the cost model after the original cast.

• Mutually exclusive branches reserve the maximum possible cost; independent effects are summed.
• Channelled and repeated effects pay according to their execution semantics rather than a flat arbitrary surcharge.
• Scheduled and construct-driven actions preserve resource ownership as they execute over later ticks.

From exact spawning to readable casting

Early versions could spawn an effect at an exact location immediately. Although functional, the action lacked anticipation and magical identity. I evolved it into a gate with a visible charge-up, giving opponents information and making the same mechanic feel deliberate rather than arbitrary.

Breaking the permanent-shield loop

The first shield implementation was too dependable: once broken, it could be recast before an opponent gained anything from the interaction. Introducing a break cooldown converted shield failure into a punish window and made defensive timing matter.

Making equipment progression tangible

CAD upgrades originally increased only the permitted spell complexity. Players gained capacity, but the reward was difficult to feel. Adding potency and usable grid space made upgrades immediately legible and encouraged players to return to old spells with new constraints and opportunities.