a327ex.com

Orblike Orb System Design

Summary

A comprehensive session designing the ORBS (Orthogonal Rule Binding System) ability system for Orblike, working from a massive reference corpus of ~360 abilities across 5 games to extract orthogonal building blocks, then designing a composition model based on orbiting orbs connected by trigger-event links.

Project Acquaintance and Initial Direction:

Building the Ability Reference Corpus (orbs/ability_reference.md):

Designing the Ability Design Reference (orbs/ability_design_reference.md):

Carrier Analysis — Fundamental Objects of Abilities:

Modifier Brainstorm (120 modifiers):

Meta-Modifier Discovery — Trigger Bridges:

System Design Document (orbs/system_design.md):

Files Created/Modified:

We have the basics needed to start work on the abilities for Orblike. Get acquainted with the project first.

Reading the Orblike project files now.

Read (E:\a327ex\Orblike\ORBS.md)

     1→# ORBS — Orthogonal Rule Binding System
     2→
     3→## What ORBS Is
     4→
     5→ORBS is a general ability system designed to describe, generate, and implement abilities across all build-heavy games — League of Legends, DoTA, Path of Exile, The Binding of Isaac, Risk of Rain 2, SNKRX, and any game with abilities, heroes, items, synergies, etc.
     6→
     7→The name captures the core design philosophy: abilities are **orthogonal** — they compose independently without needing to know about each other. A freeze effect, a damage-on-hit proc, and a projectile-splitting modifier should all work together without any of them being written with the others in mind.
     8→
     9→## Goals
    10→
    11→1. **Universal coverage.** ORBS should be able to describe every possible ability in any game. Not "most abilities" — every one.
    12→
    13→2. **LLM-optimized.** The system has two layers: a description layer (interpreted by an LLM) and an implementation layer (actual code). The description format should be learnable enough that an LLM reading the ORBS documentation can convert a designer's intent into correct, working ability code without supervision.
    14→
    15→3. **Purely functional.** "Functional" not in the programming sense, but meaning ORBS concerns itself only with the logical/mechanical work needed to make abilities function. No visuals, no effects, no sounds. These are handled through hooks/events that the gameplay coder attaches to externally.
    16→
    17→4. **Incremental discovery.** We build bottom-up: implement real abilities, notice patterns, extract primitives, document everything. Every addition to the system is documented thoroughly so that past pieces are understood and reused. New abstractions are added only when existing ones don't cover a use case.
    18→
    19→## Architecture
    20→
    21→### Two Layers
    22→
    23→**Description layer** — How the designer/LLM thinks about an ability. The format for this layer will be discovered as we implement abilities. It should map cleanly to the implementation layer.
    24→
    25→**Implementation layer** — Actual Lua code using ORBS primitives. This runs on the Anchor engine.
    26→
    27→### What ORBS Handles
    28→
    29→- **Ability logic** — triggers, timing, targeting, conditions, sequencing
    30→- **Execution** — cooldowns, charges, channels, state machines
... [60 more lines]

Read (E:\a327ex\Anchor\docs\FRAMEWORK_API_QUICK.md)

     1→# Framework API Quick Reference
     2→
     3→Function signatures for Lua framework classes. See `FRAMEWORK_API.md` for detailed documentation with examples.
     4→
     5→## Initialization
     6→
     7→```
     8→require('anchor') {
     9→  width = 640,        -- game resolution width (default: 480)
    10→  height = 360,       -- game resolution height (default: 270)
    11→  title = "My Game",  -- window title (default: "Anchor")
    12→  scale = 2,          -- initial window scale (default: 3)
    13→  vsync = true,       -- vertical sync (default: true)
    14→  fullscreen = false,  -- start fullscreen (default: false)
    15→  resizable = true,   -- window resizable (default: true)
    16→  filter = "rough",   -- "rough" or "smooth" (default: "rough")
    17→}
    18→```
    19→
    20→## Root Object (an)
    21→
    22→### Engine State (Static)
    23→```
    24→an.width -> int           -- game resolution width
    25→an.height -> int          -- game resolution height
    26→an.dt -> number           -- fixed delta time (1/120)
    27→an.platform -> string     -- "web" or "windows"
    28→```
    29→
    30→### Engine State (Dynamic - updated every frame)
... [610 more lines]

Read (E:\a327ex\Orblike\main.lua)

     1→require('anchor')({ width = 480, height = 270, scale = 3 })
     2→
     3→gw, gh = an.width, an.height
     4→
     5→-- SNKRX palette
     6→bg_color = color(48, 48, 48)
     7→bg_off = color(46, 46, 46)
     8→fg_color = color(218, 218, 218)
     9→fg_alt = color(176, 168, 159)
    10→yellow = color(250, 207, 0)
    11→orange = color(240, 112, 33)
    12→blue = color(1, 155, 214)
    13→green = color(139, 191, 64)
    14→red = color(233, 29, 57)
    15→purple = color(142, 85, 158)
    16→blue2 = color(71, 120, 186)
    17→yellow2 = color(245, 159, 16)
    18→
    19→palette = {fg_color, fg_alt, yellow, orange, blue, green, red, purple, blue2, yellow2}
    20→
    21→-- Physics
    22→an:physics_init()
    23→an:physics_set_gravity(0, 0)
    24→an:physics_tag('player')
    25→an:physics_tag('enemy')
    26→an:physics_tag('projectile')
    27→an:physics_collision('player', 'enemy')
    28→an:physics_sensor('projectile', 'enemy')
    29→
    30→-- Input
... [885 more lines]

All read. Here's what I see in the current state of Orblike:

Current codebase (~915 lines): A working prototype with a player, a seeker enemy, and five attack types — all with polished SNKRX-style visual feedback (springs, flash, hit_circles, hit_particles, hit_effects). The attacks are:

  1. Projectile (key 1) — directional bullet, hits one enemy on contact
  2. Single target (key 2) — crosshair at mouse, hits closest enemy within radius
  3. Area rect (key 3) — rectangular AoE at mouse with bracket corners
  4. Area circle (key 4) — circular AoE at mouse with rotating arc segments
  5. Line attack (key 5) — instant piercing ray, hits all enemies along the line

What exists: All five attack archetypes are implemented as standalone objects with hardcoded values. Each has its own cooldown on the player, its own visual style, and its own hit detection. There's one enemy type (seeker) with HP, knockback, and death effects.

What doesn't exist yet: No orbs/ directory, no ORBS primitives, no ability descriptions. The attacks are baked directly into main.lua as individual classes. There's no stat system, no buff/debuff system, no composition model.

The ORBS design doc envisions a bottom-up process: implement real abilities, notice patterns, extract primitives. The current attacks are essentially the first batch of "real abilities" — they already demonstrate several patterns worth extracting (cooldown management, hit detection, visual feedback hooks, expand-flash-blink-die lifecycle).

What ability do you want to start with? Some options:

Each game that implements the ORBS system will essentially be tasked with implements the events it generates per ability. Let's imagine the 4 abilities we have now. Actually, only the first:

  1. Projectile. On click, it generates a projectile towards the direction of the mouse. The ability should capture, "click", "spawn projectile", "mouse direction/angle", right?

Right, and I think the interesting question is where the boundary falls. Let me think through what's actually in the projectile ability:

What the ability "decides":

What the projectile "decides":

What the game decides (visual/feel):

So "click, spawn projectile, mouse direction" captures the trigger and targeting, but there's also the projectile's own behavior — speed, what it collides with, what happens on hit, when it dies. That's a second layer of description nested inside the first.

The question this raises: does ORBS treat "projectile" as a primitive with parameters (speed, pierce count, lifetime, hit behavior), or does ORBS just say "spawn an entity" and the projectile's behavior is described as its own separate set of rules?

The first approach is more like a data-driven ability system (LoL/Dota style — "spawn projectile, speed 190, hits first enemy, deals 1 damage"). The second is more compositional — the projectile itself could have abilities/rules attached to it.

What's your instinct? Is a projectile a built-in ORBS spatial primitive, or is it an entity that happens to have "move forward" + "die on hit" + "deal damage on hit" rules composed onto it?

Hmmm, let's try a different approach. Let's try creating something similar to the ATTACK DESIGN REFERENCE document in EBB, where we divide the design by sections that can have multiple types to them. Can you see that document?

Grep (ATTACK DESIGN REFERENCE)

No files found

Glob (emoji-ball-battles//ATTACK)

E:\a327ex\emoji-ball-battles\docs\ATTACK_REFERENCE.md

Glob (emoji-ball-battles/reference/*)

E:\a327ex\emoji-ball-battles\reference\.gitkeep
E:\a327ex\emoji-ball-battles\reference\earclacks-attribute-analysis.md
E:\a327ex\emoji-ball-battles\reference\basic-emoji-anchor-game.md
E:\a327ex\emoji-ball-battles\reference\effects_api_gaps.md
E:\a327ex\emoji-ball-battles\reference\emoji_effects_documentation.md
E:\a327ex\emoji-ball-battles\reference\sound_mapping.md
E:\a327ex\emoji-ball-battles\reference\status-effects-research.md
E:\a327ex\emoji-ball-battles\reference\bow-reference.md
E:\a327ex\emoji-ball-battles\reference\headless-playthrough-plan.md
E:\a327ex\emoji-ball-battles\reference\attack-design-space.md
E:\a327ex\emoji-ball-battles\reference\headless-usage.md

Found it — ATTACK_REFERENCE.md and also attack-design-space.md. Let me read both.

Read (E:\a327ex\emoji-ball-battles\docs\ATTACK_REFERENCE.md)

     1→# Attack Design Reference
     2→
     3→Quick-reference for designing weapons. Pick one from each column, check the scaling is visual.
     4→
     5→Detailed exploration and rationale: `reference/attack-design-space.md`
     6→
     7→---
     8→
     9→## Building Blocks
    10→
    11→### Shapes — What the attack looks like in the arena
    12→
    13→| ID | Shape | Description | Example |
    14→|----|-------|-------------|---------|
    15→| S1 | Point/Contact | Weapon tip hitbox | Dagger |
    16→| S2 | Forward Line | Line extending from weapon tip | Sword thrust, beam |
    17→| S3 | Forward Cone | Fan/wedge from weapon tip | Flashlight, shotgun |
    18→| S4 | Arc/Sweep | Partial rotation (90°–180°) | Cleave, wide swing |
    19→| S5 | Full Circle | Omnidirectional around ball | Pulse, aura |
    20→| S6 | Expanding Ring | Ring that radiates outward | Shockwave |
    21→| S7 | Cross/Star Burst | Multiple lines from ball at fixed angles | Nova burst in 4/8 dirs |
    22→| S8 | Orbital | Entities revolving at fixed radius | Temporary shards |
    23→| S9 | Straight Projectile | Travels in a line | Arrow |
    24→| S10 | Bouncing Projectile | Reflects off walls | Gun bullet |
    25→| S11 | Gravity-Arc Projectile | Parabolic/lobbed trajectory | Rock |
    26→| S12 | Returning Projectile | Goes out, comes back | Boomerang |
    27→| S13 | Spiral Projectile | Spirals outward from ball | Lollipop |
    28→| S14 | Zigzag Projectile | Bounces at fixed angles (e.g. 45°) | CD |
    29→| S15 | Homing Projectile | Curves toward enemy | Spoon |
    30→| S16 | Zone/Pool | Persistent circle at a location | Acid pool, paint splat |
... [107 more lines]

Read (E:\a327ex\emoji-ball-battles\reference\attack-design-space.md)

<persisted-output>
Output too large (56.6KB). Full output saved to: C:\Users\adn\.claude\projects\E--a327ex\ee3e2eaa-a459-4dc8-9749-c859da57ef1d\tool-results\toolu_01XPcuqjQxgZfXzcXiW6PMth.txt

Preview (first 2KB):
     1→# Attack Design Space Exploration
     2→
     3→## Context & Constraints
     4→
     5→The arena is a 200x200 bouncy box with gravity. Two balls bounce around, each with an attached weapon that rotates with the ball. Good scaling is **visual** — more stuff on screen, more chaos, more compelling to watch — without making fights one-sided numerically.
     6→
     7→Existing weapons establish the baseline:
     8→- **Dagger**: rotation (continuous area sweep around ball), scales via rotation speed
     9→- **Gun**: raycast-aligned projectiles that bounce, scales via burst fire (more bullets)
    10→- **Bow**: raycast-aligned projectiles that stick, scales via arrow count per shot
    11→- **Sword**: raycast-aligned melee thrust, scales via thrust damage (this one's actually the weakest visual scaler — damage is invisible)
    12→
    13→---
    14→
    15→## Part 1: Shape Vocabulary
    16→
    17→These are the spatial patterns an attack can take, grounded in what makes sense in the arena.
    18→
    19→### Shapes Originating From The Ball
    20→
    21→**1. Point / Contact**
    22→The weapon tip itself is the damage zone. Dagger does this — the hitbox is a small rectangle at the weapon's end. Requires the weapon to physically overlap the enemy.
    23→
    24→**2. Forward Line**
    25→A line extending from the weapon tip in the direction it points. Sword thrust is a short version. A beam would be a long version that reaches across the arena. Visually, it's a ray or a extending rectangle.
    26→
... [6 more lines]

Yes, I see it. The EBB ATTACK_REFERENCE.md breaks every weapon into four orthogonal dimensions — Shape (spatial pattern), Behavior (temporal pattern), Trigger (what causes firing), and Scaling (what changes as it powers up). Each dimension has a typed menu. You pick one from each column, and that describes your weapon.

So you want to do something similar for ORBS — break abilities into sections where each section has a set of types, and you compose an ability by picking one from each. But ORBS is more general than EBB (not just weapons on bouncing balls), so the sections would be different.

For the projectile ability in Orblike, the EBB-style decomposition might look something like:

And then something like the area_circle would be:

Should I draft a full reference document like this, mapping out what sections/types we'd need to cover all five current attacks plus the kinds of abilities you'd want ORBS to eventually describe (DoTs, buffs, channels, chains, etc.)? Or do you want to work through the sections together first?

Yes, but first, can we figure out if you can generate a text version of ALL abilities in a single game? I believe the wikis for the most popular games must contain descriptions of all their abilities, so we can probably get the abilities for a few game that matter and that I care about in a full way, and then design the system slowly by picking a few specific abilities at a time and making sure that it can be described properly at this high level. Imagine you wanted to do this for Path of Exile, how would you go about it?

Good question. Let me check what's actually available on the PoE wiki — it's one of the most thoroughly documented games out there.

WebFetch (https://www.poewiki.net/wiki/Skill_gem)

# Active Skill Gems Overview

## Structure & Organization

Active skill gems are organized in a table format with the following structure:

- **Gem Name** - Links to individual skill pages
- **Gem Tags** - Categorical labels (e.g., "Spell," "Attack," "Melee," "AoE")
- **Requirements** - Character level and attribute needs (Strength, Dexterity, Intelligence)
- **Stats** - Mana costs, cooldowns, damage values, and unique mechanics

The page notes that "gem tags are not intended to indicate whether a skill gem can be supported by other gems or whether specific stats apply."

## Skills Listed (Partial)

The visible portion includes approximately 50+ active skill gems, including:

Absolution, Ancestral Cry, Anger, Animate Guardian, Autoexertion, Battlemage's Cry, Berserk, Bladestorm, Blood and Sand, Boneshatter, Chain Hook, Cleave, Consecrated Path, Corrupting Fever, Crushing Fist, Decoy Totem, Defiance Banner, Determination, Devouring Totem, Dominating Blow, Dread Banner, Earthquake, Earthshatter, Enduring Cry, Eviscerate, Exsanguinate, Flame Link, Flesh and Stone, Frozen Legion, General's Cry, Glacial Hammer, Ground Slam, Heavy Strike, Herald of Ash, Herald of Purity, Holy Flame Totem, Ice Crash, Immortal Call, Infernal Blow, Infernal Cry, Intimidating Cry, Leap Slam, Molten Shell, Molten Strike, Perforate, Petrified Blood, Pride, Protective Link, Punishment, Purity of Fire, Rage Vortex, Rallying Cry, Reap, Rejuvenation Totem, Searing Bond, Seismic Cry.

**Total count** is not explicitly stated in the visible content.

That gives me a partial list with tags but not the mechanical descriptions. The wiki has individual pages per skill with full details. The challenge is PoE has probably 200-300+ active skill gems, and fetching each one individually would be slow.

Let me think about more practical approaches:

Option A: Wiki list pages. Fetch the full skill gem list, then batch-fetch individual pages. Doable but tedious — hundreds of fetches. The descriptions would be thorough though.

Option B: Community data dumps. PoE's data gets mined regularly. There might be JSON/CSV exports of all skill gems with their mechanical descriptions already compiled.

Option C: Use the wiki's category/table pages that sometimes have condensed descriptions.

Option D: Use an LLM's existing knowledge. I already know PoE's skill gems fairly well from training data. I could generate descriptions from memory, but they'd be from PoE 1 circa early 2025 and might miss recent additions or get details wrong. Still, for the purpose of designing ORBS categories (not building a PoE clone), approximate descriptions might be sufficient.

Given your goal of creating a single .md file with all abilities — which games do you actually want? PoE has the most complex ability system but also the most abilities. League, Dota, Isaac, and Risk of Rain 2 are also mentioned in ORBS.md.

My honest take: for designing ORBS's category system, you probably want breadth across games more than perfect completeness in one game. A file with ~50 PoE skills + ~30 LoL champions + ~20 Isaac items would stress-test the category system better than 300 PoE skills alone. But you know your priorities better — which games matter most to you for this?

Start with PoE and use your knowledge. However, give me 10 abilities first from your knowledge base and how you plan on adding them to the document so I can see if its good.

Here's a sample of 10, covering diverse mechanics:

Fireball Spell, Projectile, AoE, Fire Fires a projectile in the targeted direction. On hitting an enemy or reaching max distance, it explodes in an area, dealing fire damage to all enemies in the radius. Can ignite.

Arc Spell, Chaining, Lightning Fires a bolt of lightning at the nearest enemy. The bolt then chains to additional nearby enemies, dealing reduced damage per chain. Each chain must find a new target within range. Can shock.

Cyclone Attack, Melee, Channelled, AoE While channelling, the character spins in place (or while moving), hitting all enemies in a radius around them repeatedly at a fixed rate. Movement speed is reduced while channelling. Can be sustained indefinitely.

Raise Zombie Spell, Minion Cast on a corpse to raise it as a zombie minion that follows the player and attacks nearby enemies with melee. Zombies persist until killed. Has a maximum count.

Blade Vortex Spell, AoE, Duration Each cast adds a spinning blade that orbits the caster. Blades hit enemies they pass through. Up to a maximum number of blades can be active. Each blade has its own duration, hitting enemies repeatedly as it circles.

Essence Drain Spell, Projectile, DoT, Chaos Fires a projectile that applies a chaos damage-over-time debuff to the first enemy hit. While the debuff is active, the caster regenerates life based on the DoT damage. If the target dies, the debuff spreads to a nearby enemy.

Flicker Strike Attack, Melee, Movement Teleports to a nearby enemy and strikes them. Consumes a frenzy charge to bypass the cooldown, allowing rapid repeated use. Without charges, has a cooldown between uses.

Rain of Arrows Attack, AoE, Projectile Fires arrows into the air that rain down on a targeted area after a short delay. Each arrow hits independently in a small radius within the targeted area. Enemies in the area can be hit by multiple arrows.

Righteous Fire Spell, AoE, Fire, Duration Engulfs the caster in fire, dealing burning damage per second to nearby enemies in a radius. Also burns the caster, draining a percentage of life and energy shield per second. Persists until cancelled or the caster dies.

Molten Strike Attack, Melee, Projectile, Fire, AoE Strikes an enemy with melee, then generates a number of molten projectiles that launch from the point of impact in an arc, landing nearby and dealing AoE fire damage on landing. The melee hit and projectile hits are independent.

Format is: Name, tags on the next line, then a mechanical description focused on what it does — trigger, delivery, targeting, hit behavior, special mechanics. No numbers, just the logic.

Does this level of detail work? Too much, too little? Should I add or remove anything from the format?

I think this level of detail is perfect and focusing on the logic like this works well. If you had to go for 10 support gems instead, what would they look like?

Greater Multiple Projectiles Projectile Modifies a projectile skill to fire additional projectiles simultaneously, spread in a fan pattern. Each projectile deals less damage. Does not affect non-projectile parts of a skill.

Chain Chaining, Projectile Projectiles that hit an enemy will chain to another nearby enemy instead of being destroyed. Adds a set number of additional chains. Each chain reduces damage. The projectile must find a valid target within chain range.

Fork Projectile Projectiles that hit an enemy split into two projectiles that continue in a V-pattern. Each forked projectile can hit other enemies but cannot fork again. Does not work on projectiles that pierce or chain from that hit.

Spell Echo Spell After casting a linked spell, the spell is automatically repeated once (or more) with no additional mana cost and a shorter cast time. The repeat targets the same location/direction as the original cast.

Multistrike Attack, Melee Each use of a linked melee attack performs the attack multiple times in rapid succession. The repeats are faster than the original. The second and third strikes automatically target nearby enemies, potentially different from the first.

Concentrated Effect AoE Reduces the area of effect of a linked skill but increases its area damage. Pure tradeoff — smaller but harder hitting AoE.

Cast on Critical Strike Trigger, Spell When the linked attack skill scores a critical strike, it automatically casts a linked spell at the target. The spell is cast without spending mana and has its own cooldown. The caster does not need to cast the spell manually.

Melee Splash Melee, AoE Converts a single-target melee attack into an AoE attack. The primary target takes full damage; nearby enemies take a percentage of the damage. Does not affect skills that are already AoE.

Combustion Fire Linked skill's fire hits apply a debuff that lowers the target's fire resistance. If the linked skill ignites, the ignite chance is also increased. The resistance reduction is a debuff on the enemy, not a stat on the player.

Lifetap Makes the linked skill cost life instead of mana. While the skill has spent enough life recently, the caster gains a buff that increases life regeneration. Changes the resource economy of the linked skill entirely.

These are interesting for ORBS because they're essentially ability modifiers — they take an existing ability and change one axis of it. GMP/Chain/Fork all modify the "what happens after the projectile" step. Spell Echo/Multistrike modify the "how many times does the action repeat" step. Concentrated Effect modifies spatial parameters. Cast on Crit changes the trigger entirely. Melee Splash changes the hit behavior from single to AoE. Lifetap changes the resource cost.

This is basically the composition problem from ORBS.md — "your projectiles now split on hit" — and PoE's answer is that support gems modify specific axes of an active skill's behavior. Same format work here?

Yes, this level of detail is perfect. Let's go for 30 skill gems and 30 support gems. Try to focus on the most iconic ones that also cover the most design ground when all taken together. Save this to a file in orbs/, this file will contain all skill descriptions for all games like this, divided by sections (game name).

Let me check the directory structure first, then write the file.

Bash (ls E:/a327ex/Orblike/orbs/ 2>/dev/null || echo "directory does not exist")

Bash (mkdir -p E:/a327ex/Orblike/orbs)

Write (E:\a327ex\Orblike\orbs\ability_reference.md)

File created successfully at: E:\a327ex\Orblike\orbs\ability_reference.md

Done. Written to Orblike/orbs/ability_reference.md.

Active skills (30) — picked to maximize design coverage:

Support gems (30) — organized by what axis of the ability they modify:

Want to move on to another game next, or start working with this PoE set to sketch out the ORBS category system?

Open the document for me please.

Bash (~/bin/neovim.exe E:/a327ex/Orblike/orbs/ability_reference.md -- -c "MarkdownPrev...)

Command running in background with ID: bolnxt01d. Output is being written to: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bolnxt01d.output

Opened in NeoVim with MarkdownPreview.

<task-notification> <task-id>bolnxt01d</task-id> <tool-use-id>toolu_01UEfMUZqf4nEqZHfKNZ1KdH</tool-use-id> <output-file>C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bolnxt01d.output</output-file> completed

Background command "Open ability reference in NeoVim with MarkdownPreview" completed (exit code 0) </task-notification> Read the output file to retrieve the result: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bolnxt01d.output

NeoVim closed. Ready to continue — want to add another game to the reference, or start working on the ORBS categories from the PoE set?

Sure, do league next. 60 champion abilities. Similarly, try to pick iconic ones that cover the most design ground. You can pick multiple from the same champion if you want. Do not compare design ground covered with previous games, treat the design ground from each game individually according to itself only, if that makes sense.

Read (E:\a327ex\Orblike\orbs\ability_reference.md)

     1→# Ability Reference
     2→
     3→Mechanical descriptions of abilities across games, for ORBS system design. Descriptions focus on logic — triggers, delivery, targeting, hit behavior, special mechanics. No numbers, just how things work.
     4→
     5→---
     6→
     7→# Path of Exile
     8→
     9→## Active Skill Gems
    10→
    11→### Projectiles
    12→
    13→**Fireball**
    14→Spell, Projectile, AoE, Fire
    15→Fires a projectile in the targeted direction. On hitting an enemy or reaching max distance, it explodes in an area, dealing fire damage to all enemies in the radius. Can ignite.
    16→
    17→**Arc**
    18→Spell, Chaining, Lightning
    19→Fires a bolt of lightning at the nearest enemy in range. The bolt then chains to additional nearby enemies, with each chain seeking the closest valid target not yet hit. Damage reduces per chain. Can shock.
    20→
    21→**Freezing Pulse**
    22→Spell, Projectile, Cold
    23→Fires a projectile in the targeted direction. The projectile loses damage the further it travels, eventually dissipating at max range. Wider hitbox up close, narrower at range. Can freeze, with higher freeze chance at close range due to higher damage.
    24→
    25→**Ball Lightning**
    26→Spell, Projectile, AoE, Lightning
    27→Fires a slow-moving orb that travels in a line. The orb repeatedly hits enemies within its radius as it passes through them, dealing damage at a fixed interval. Each enemy can be hit multiple times by the same orb. Pierces all enemies — never consumed by hits.
    28→
    29→**Ethereal Knives**
    30→Spell, Projectile, Physical
... [253 more lines]

Now I'll append the League section.

Edit (E:\a327ex\Orblike\orbs\ability_reference.md)

The file E:\a327ex\Orblike\orbs\ability_reference.md has been updated successfully.

Done — 60 League abilities appended. Let me open it for you.

Bash (~/bin/neovim.exe E:/a327ex/Orblike/orbs/ability_reference.md -- -c "MarkdownPrev...)

Command running in background with ID: bkce34wv9. Output is being written to: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bkce34wv9.output

The League section covers these mechanical categories:

Do items in League, Dota, Risk of Rain and other games serve the same design purpose as support gems in PoE? Or should we consider these differently? Are item effects in PoE (in gear) in the same category as items in those games? How would you separate these things?

Good question, and I think the answer is that they're actually several different things mixed together, and conflating them would lose information that matters for ORBS.

Let me break down what "items" actually do across these games:

1. Ability Modifiers (closest to PoE support gems) Things that change how an existing ability works. PoE support gems are the purest form — Chain makes projectiles chain, Melee Splash makes single-target hit in AoE, Spell Totem changes who casts. In Isaac, Parasite (tears split on hit) is basically Fork. In RoR2, Brilliant Behemoth (all attacks explode) is basically adding AoE to your hits. These modify the mechanics of something you already have.

2. Triggered Effects / On-Event Effects Things that add a new effect that fires on an event. RoR2's ATG Missile (on hit → fire homing missile), Ukulele (on hit → chain lightning), Will-o'-the-Wisp (on kill → AoE explosion). League's Liandry's (on ability hit → burn DoT). These aren't modifying an ability — they're attaching a new ability to an event from an existing one. This is the composition layer.

3. Active Abilities from Items Items that simply are abilities. Dota's Blink Dagger is a movement ability. League's Zhonya's is a stasis ability. Dota's Orchid is a targeted silence + delayed burst (mechanically identical to Zed R's mark). These should just be catalogued as abilities — the fact that they come from items rather than a kit is an inventory system distinction, not a mechanical one.

4. Ability Replacements Isaac's Brimstone replaces your tears with a charged laser beam. Dr. Fetus replaces tears with bombs. Mom's Knife replaces them with a thrown knife. These aren't modifiers — they substitute your entire attack pattern. A different operation than "modify."

5. Stat Modifiers Attack speed, damage, health, resistances. Every game has these. Not interesting for ORBS — they're just numbers.

6. Meta-Modifiers / Rule Changers RoR2's 57 Leaf Clover (all random effects reroll in your favor), Shaped Glass (double damage, half health). These change the rules of the game itself rather than any specific ability.

So PoE support gems are really just category 1. Items across other games span categories 1-6, and mashing them all together would be messy. For the reference document, I'd propose:

This means for a game like Risk of Rain 2, the items would get split across sections rather than listed as one flat list. Same for Isaac. Does that decomposition feel right, or do you see it differently?

Let's focus on abilities and ability modifiers only. If the abilities/ability modifiers appear in characters or items it's irrelevant. Makes sense? So Blink Dagger in DoTA should count as one out of the 60, if you happen to choose it. In light of this, are there any other things in League you'd add, or replace existing abilities for things that appear in items?

Thinking about it honestly — no, I don't think League items add much that the champion abilities don't already cover. League's item actives are mostly simpler versions of champion mechanics:

The design space in League really lives in the champion kits, not the items. Items are mostly stat bundles with a mechanical hook that's usually a stripped-down version of something a champion does more interestingly.

The one area I might be missing is runes — things like Electrocute (3 hits within a window → bonus burst) or Phase Rush (3 ability hits → movement speed). But those are triggered effects more than abilities or modifiers, and the "hit N times → trigger bonus" pattern is already covered by Annie passive and Vayne W.

I think the 60 champion abilities are solid as the League section. The more interesting next step would be a game where items ARE the design space — Risk of Rain 2 or Isaac, where the items are the whole point and the "base ability" is simple.

Want me to move on to one of those? Or Dota, where items like Blink Dagger, Force Staff, and Orchid are genuinely ability-grade mechanics that would earn spots alongside hero abilities?

<task-notification> <task-id>bkce34wv9</task-id> <tool-use-id>toolu_015G826TMwA79DSA6o2Lty94</tool-use-id> <output-file>C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bkce34wv9.output</output-file> completed

Background command "Open updated ability reference in NeoVim with MarkdownPreview" completed (exit code 0) </task-notification> Read the output file to retrieve the result: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bkce34wv9.output

NeoVim closed. Waiting on your call — Dota, Risk of Rain 2, Isaac, or something else next?

OK, let's do DoTA. 60 abilities/ability modifiers, regardless where they come from.

Read (E:\a327ex\Orblike\orbs\ability_reference.md)

     1→# Ability Reference
     2→
     3→Mechanical descriptions of abilities across games, for ORBS system design. Descriptions focus on logic — triggers, delivery, targeting, hit behavior, special mechanics. No numbers, just how things work.
     4→
     5→---

Let me find the end of the file to append.

Bash (wc -l E:/a327ex/Orblike/orbs/ability_reference.md)

513 E:/a327ex/Orblike/orbs/ability_reference.md

Read (E:\a327ex\Orblike\orbs\ability_reference.md)

   510→**Illaoi E — Test of Spirit** (covered above in Ally Interaction)
   511→
   512→**Kalista passive — Martial Poise**
   513→Every auto-attack, after the projectile launches, causes Kalista to perform a short dash in her current movement direction. She cannot cancel auto-attack animations — once the wind-up starts, the attack must complete before the dash. Creates a character whose auto-attacking and movement are fused — attacking IS moving. Orbwalking built into the kit.
   514→

Edit (E:\a327ex\Orblike\orbs\ability_reference.md)

The file E:\a327ex\Orblike\orbs\ability_reference.md has been updated successfully.

Done. 60 Dota abilities appended. Here's the coverage:

Want to continue with another game? Risk of Rain 2 and Isaac would cover the "items as the entire ability system" territory well.

Do some simpler abilities in DoTA as well? Like beams, projectiles, simple are effects, etc. 20 more.

Bash (wc -l E:/a327ex/Orblike/orbs/ability_reference.md)

731 E:/a327ex/Orblike/orbs/ability_reference.md

Read (E:\a327ex\Orblike\orbs\ability_reference.md)

   728→Active: for a short duration, all damage dealt to the user is reflected back to the attacker. The reflected damage is the same type and amount as the incoming damage. Does not reduce the damage taken — the user still takes full damage, they just return it. Creates a "hit me and you hurt yourself" situation. Most effective against heroes that deal high burst damage, turning their own damage against them.
   729→
   730→**Orchid Malevolence**
   731→Active: targets an enemy hero, silencing them for a duration. At the end of the silence, the target takes bonus damage equal to a percentage of all damage they received during the silenced duration. Combines a disable (silence) with a damage amplification window — all damage dealt while silenced is "stored" and a portion is dealt again as a burst when the silence ends. Rewards focusing a target during the silence duration.
   732→

Edit (E:\a327ex\Orblike\orbs\ability_reference.md)

The file E:\a327ex\Orblike\orbs\ability_reference.md has been updated successfully.

Done — 20 simple abilities added under a "Bread and Butter" section. Covers the foundational types:

These are the building blocks the complex abilities are built from. Ready for the next game whenever you are.

Isaac now, do 80 too.

Bash (wc -l E:/a327ex/Orblike/orbs/ability_reference.md)

793 E:/a327ex/Orblike/orbs/ability_reference.md

Read (E:\a327ex\Orblike\orbs\ability_reference.md)

   790→Targets an allied unit (or self). Grants bonus attack speed and movement speed for a duration. A simple single-target ally buff — make one unit faster and hit harder. Can be multicast (via Ogre's passive) to apply to nearby allies as well.
   791→
   792→**Slardar R — Corrosive Haze**
   793→Targets an enemy unit. Applies a long-duration debuff that reduces the target's armor and grants true sight of them (reveals invisible units). Point-and-click, no damage. A simple targeted debuff — the target takes more physical damage and can't hide. The armor reduction makes them vulnerable, the vision makes them trackable.
   794→

Edit (E:\a327ex\Orblike\orbs\ability_reference.md)

The file E:\a327ex\Orblike\orbs\ability_reference.md has been updated successfully.

Done — 80 Isaac items appended. Here's the breakdown:

Isaac is particularly interesting for ORBS because the modifier system is almost entirely compositional — items stack on top of each other and the combinations create emergent behavior (homing + split + Brimstone = homing splitting laser beams). Want to continue with Risk of Rain 2, or start working with what we have?

Do Risk of Rain 2 next, 80.

Bash (wc -l E:/a327ex/Orblike/orbs/ability_reference.md)

1076 E:/a327ex/Orblike/orbs/ability_reference.md

Read (E:\a327ex\Orblike\orbs\ability_reference.md)

  1073→While Isaac stands completely still and does not fire, he becomes invulnerable. Any movement, firing, or item use removes the invulnerability instantly. Rewards total inaction with total defense. Powerful with familiars and orbitals that deal damage without Isaac needing to act.
  1074→
  1075→**Crown of Light**
  1076→While Isaac has no damaged red hearts (all heart containers are full), tears deal double damage and gain a diamond visual. Taking any damage to red hearts removes the bonus until fully healed. A conditional damage multiplier that rewards not getting hit — high upside with a fragile condition.
  1077→

Edit (E:\a327ex\Orblike\orbs\ability_reference.md)

The file E:\a327ex\Orblike\orbs\ability_reference.md has been updated successfully.

Done — 80 Risk of Rain 2 entries appended. Here's the coverage:

Survivor Abilities (25):

On-Hit Items (12): delayed bomb, homing missile, chain lightning, bleed DoT, damage-threshold ice/fire procs, enemy clustering hook, crit→bleed→death explosion chain, permanent armor shred, kill-charge→hit-discharge, universal AoE explosion, delayed void burst

On-Kill Items (7): lava pillar, spreading fire + burning ground, chaining homing daggers, ghost ally spawning, orbiting ice storm, temporary barrier, elite-only execute

On-Damage-Taken (4): delayed heal, probabilistic block, rechargeable shield, debuff immunity charges

Attack Modifiers (8): first-hit bonus, proximity bonus, boss-only bonus, crit chance, crit→speed loop, crit→heal, extra ability charges, kill→cooldown reset

Equipment/Active (10): lightning strike, pulling+exploding orb, missile barrage, gravity well, drone summons, debuff cleanse+detonation, returning saw blade, portal pair, voodoo doll (fake kill trigger), team buff

Lunar (6): 2x damage / 0.5x HP, auto-activating equipment, HP→shields conversion, doubled but rate-limited healing, cooldowns vs luck tradeoff, ability replacement

Void (4): on-kill→on-hit conversion, threshold→black hole, revive consuming random item, ability charge for HP

Meta (4): universal luck amplifier, permanent HP from kills, conditional sprint-jump boost, single-use revive

Want to add another game, or is this corpus sufficient to start designing the ORBS category system?

Are there any other important build heavy action games missed? Just like the ones that come to mind and I'll pick if I agree that they could be useful.

Games that come to mind with build-heavy ability systems we're missing:

Which of these (if any) feel worth adding to the reference?

Noita would be interesting and I've played it passingly, and SNKRX would be interesting since I made it. I think the other games cover all aspects of gameplay that SNKRX covers though, tell me if you agree or disagree. And as for Noita, do you think everything is covered or that it has unique enough ideas in it that other games missed?

SNKRX: I agree. The individual unit abilities (projectiles, AoEs, buffs, heals, summons) are all covered by the other games. What's unique about SNKRX is the composition meta-layer — "collect 3 rogues to activate crit synergy" — but that's a build/team-composition system, not an ability system. ORBS would describe the abilities themselves, and those mechanics are already in the reference.

Noita: The individual spell effects (fireball, lightning bolt, explosion, heal) are covered. But Noita's composition model is genuinely unique and very relevant to ORBS. Specifically:

  1. Sequential ordering — Modifiers apply to "the next spell in the wand," not to "all spells." Position matters. [Heavy Shot → Fireball] is a heavy fireball. [Fireball → Heavy Shot] is an unmodified fireball followed by a heavy nothing. No other game we've covered has positional/ordered composition like this.

  2. Trigger nesting — "On hit, cast the next spell at the impact point." And you can chain them: [Trigger Bolt → Trigger Bolt → Nuke] fires a bolt that on hit fires another bolt that on hit detonates a nuke. Arbitrary nesting depth. PoE's Cast on Crit is a flat version of this, but Noita's is recursive.

  3. Heterogeneous multicast — "Fire the next N spells simultaneously." Unlike GMP (which duplicates the same projectile), Noita's multicast fires different spells at once. [Double Cast → Fireball → Lightning] fires both simultaneously.

  4. Timer as a composable element — Add a delay to any spell. The spell fires, waits, then the payload activates.

These are composition primitives — ways of connecting abilities together — rather than abilities themselves. They're directly relevant to ORBS's core "orthogonal composition" problem. I'd suggest documenting Noita not as 80 individual spells, but focused specifically on the composition mechanics: the modifiers, triggers, multicasts, timers, and how ordering works. Maybe 30-40 entries, weighted toward the connective tissue rather than the payloads. Sound right?

Let's not do that. I've decided to implement abilities first before focusing on the system itself. Plus, Noita's system is constrained in an important way I don't like which is that position matters in unintuitive ways.

Fair point — Noita's ordering is clever but often feels like a puzzle you solve by trial and error rather than intuitive composition. And the bottom-up approach makes sense: implement abilities, notice patterns, then extract the system. That's what ORBS.md prescribes anyway.

So we have ~360 ability descriptions across 5 games as reference material. What ability do you want to implement first in Orblike?

No, first, now let's do the ATTACK DESIGN REFERENCE-like approach. You'll look at all the abilities and extract similar tables to that of that document for them. Does it make sense? Before you do it, ask me any questions for further clarifications.

Makes sense — decompose all ~360 abilities into orthogonal dimensions, each with a typed menu, EBB-style tables. A few questions before I start:

  1. Modifiers as a separate set of tables or integrated? EBB only has "attacks." But our reference includes ability modifiers (PoE support gems, Isaac tear modifiers, RoR2 on-hit items). Should modifiers get their own tables describing what axis of an ability they change (e.g., "changes delivery from single-target to AoE," "changes trigger from manual to on-crit")? Or should everything be in one unified set of tables?

  2. Multi-phase abilities — Some abilities have distinct phases: Zed R is dash → mark → delayed detonation based on damage-during-window. Sand King R is channel → expanding pulses. Should the system support describing phases/sequences, or should we treat each ability as a single entry picking from each column (with some column entries being "compound" types like "channel-then-release")?

  3. Completeness goal — Should every single ability in the reference be describable by the tables? Or is it OK if some outliers (Invoker's 10-spell combinatorial system, Aphelios's 5-weapon cycling) are flagged as "meta/system-level" and fall outside the table structure?

  4. Scaling column — EBB has a "Scaling" dimension (what visually changes as weapon powers up). Should ORBS have an equivalent, or is scaling too game-specific to be universal? I lean toward dropping it since what scales depends on the game's progression system.

  1. Let's discuss this further after my other answers.
  2. Each phase should be described as its own ability, and then we should have a "staged" subtype that allows for such abilities in some detail. However, because the tables have low detail in general we don't need to dwell on this that much. The goal of the tables is describing how abilities work at a high-level primarily, so I think going for individual + staged is a good level of abstraction. Although your idea of doing it specific, like channel-then-release types, is interesting too. Maybe you should give me an example of 10 such abilities and how you'd classify them so I can see in more detail.
  3. Yes. For the outliers they should be noted as such, but there should also be an attempt to classify their workings. Invokers, for example, uses a charge-like system, right? Many abilities use things like charges, his is just a variation of that, if I remember correctly.
  4. No scaling or damage for now, this is very high level.

Here are 10 multi-phase abilities with proposed classifications. I'll show two approaches side by side for each — a compound type (one entry per ability) and a staged decomposition (phases as separate entries) — so you can see which feels right.

1. Varus Q — Piercing Arrow (charge increases range+damage, release fires)

Compound: Trigger: Hold-to-charge / Delivery: Line — the charge-and-release IS the behavior Staged: Phase 1 = Channel (self-root, accumulate range+damage), Phase 2 = Release (line skillshot, piercing)

2. Sand King R — Epicenter (channel, then expanding pulses on release)

Compound: Trigger: Channel-then-release / Delivery: Expanding ring (multiple) Staged: Phase 1 = Channel (stationary, interruptible), Phase 2 = Expanding pulses (auto, can't be stopped once released)

3. Brimstone (Isaac) (hold fire to charge, release fires beam)

Compound: Trigger: Hold-to-charge / Delivery: Beam (piercing) Staged: Phase 1 = Charge (self-root), Phase 2 = Beam (line, piercing, brief)

4. Lee Sin Q — Sonic Wave / Resonating Strike (skillshot, then recast to dash to marked)

Compound: Trigger: Manual / Behavior: Mark-then-recast / Delivery: Projectile → Dash-to-mark Staged: Phase 1 = Projectile (line skillshot, marks first enemy hit), Phase 2 = Recast: Dash (to marked target, deals damage)

5. Zed R — Death Mark (dash to target, mark tracks damage, detonates after delay)

Compound: Hard to fit cleanly — three distinct phases with different mechanics Staged: Phase 1 = Dash (to target, untargetable during), Phase 2 = Mark (debuff: tracks all damage dealt for 3 seconds), Phase 3 = Detonation (burst damage = % of tracked damage)

6. Oracle R — False Promise (buff ally, delay all damage/healing, resolve at end)

Compound: Trigger: Manual / Targeting: Ally / Behavior: Delayed-resolution — maybe a single compound type Staged: Phase 1 = Buff (target becomes invisible, all incoming damage/healing hidden), Phase 2 = Resolution (all accumulated damage and healing applied at once, healing doubled)

7. Winter Orb (PoE) (channel builds stages, then auto-fires projectiles while stages last)

Compound: Behavior: Channel-to-charge, auto-fire-on-release — getting unwieldy as a single type Staged: Phase 1 = Channel (build stages on orb), Phase 2 = Auto-fire (orb fires homing projectiles at rate proportional to stages, stages decay over time)

8. Anti-Gravity (Isaac) (tears hover in place, launch forward when fire key released)

Compound: Behavior: Accumulate-then-release / Delivery: Projectile (delayed launch) Staged: Phase 1 = Place (tears hover at fire positions, accumulating), Phase 2 = Release (all accumulated tears launch forward simultaneously)

9. Blade Flurry (PoE) (channel rapid strikes building stages, release for AoE burst)

Compound: Behavior: Channel-then-release — but the channel itself deals damage AND builds stages, and the release is a different shape Staged: Phase 1 = Channel (rapid melee strikes in aimed direction, build stages), Phase 2 = Release (AoE burst centered on self, damage scales with stages)

10. Preon Accumulator (RoR2) (charge briefly, fire ball that pulls enemies, ball detonates)

Compound: Behavior: Charge → Projectile → Detonation — three distinct phases again Staged: Phase 1 = Charge (brief windup), Phase 2 = Projectile (slow-moving, pulls nearby enemies toward it), Phase 3 = Detonation (AoE explosion at final position)

What I notice:

Abilities 1-3 (Varus Q, Sand King R, Brimstone) fit cleanly as compound types — "hold-to-charge" and "channel-then-release" are common enough patterns that they work as single behavior types.

Abilities 4 and 8 (Lee Sin Q, Anti-Gravity) fit as compound types too — "mark-then-recast" and "accumulate-then-release" are clean patterns.

Abilities 5, 6, 7, 9, 10 (Zed R, Oracle R, Winter Orb, Blade Flurry, Preon Accumulator) are where compound types get strained — the phases have genuinely different mechanics (different deliveries, different targeting, different effects).

My instinct: use compound types for the common patterns (channel-then-release, hold-to-charge, mark-then-recast, accumulate-then-release) and staged decomposition for abilities where the phases are mechanically distinct enough that a compound type would be misleading. Maybe 70% of multi-phase abilities fit a compound type and 30% need staging.

Does this help clarify the direction, or would you rather go all-in on one approach?

Yes, this makes sense. As for 1, can you explain your question in more detail, perhaps with examples?

Sure. The question is about how to handle things like PoE's GMP, Chain, Spell Totem, RoR2's Ukulele, Isaac's Spoon Bender, etc. — things that modify existing abilities rather than being abilities themselves.

Example: the Delivery column. Say it has entries like:

ID Delivery Description
D1 Single projectile One projectile in a line
D2 Multi-projectile (fan) Multiple projectiles in a spread
D3 Beam Instant line, no travel time
D4 Projectile (homing) Projectile curves toward target

PoE's Fireball is D1 by default. With GMP, it becomes D2. With Spoon Bender in Isaac, tears become D4. The modifier's job is to move an ability from one entry to another within a column.

That's straightforward — modifiers just reference the same tables. But there are three different kinds of modification happening:

Kind 1: Swap within a column. GMP changes Delivery from D1→D2. Isaac's Rubber Cement changes Hit Behavior from "destroyed on hit" to "bounces off walls." These fit naturally in the existing tables — the modifier says "change column X from type A to type B."

Kind 2: Add a new triggered ability. RoR2's Ukulele adds "on hit → chain lightning." PoE's Combustion adds "on fire hit → apply fire resistance debuff." These aren't changing the original ability's classification — they're attaching a new ability triggered by an event from the original. Ukulele is itself an ability (chain lightning) with a trigger (on hit).

Kind 3: Change the fundamental frame. PoE's Spell Totem changes "player casts spell" to "deployable entity casts spell autonomously." Trap changes "direct cast" to "placed on ground, proximity triggered." These change who performs the ability and how it's activated — potentially moving entries across multiple columns at once.

So the question is:

Integrated approach: The tables have all possible states. Modifiers are just described as "moves from X to Y in column Z." No separate modifier tables needed. Kind 2 modifiers (add triggered effects) are just new abilities with trigger type "on hit" or "on kill."

Separate approach: Abilities get one set of tables. Modifiers get their own table listing what axis they modify and how. This makes the modifier-as-a-concept explicit — you can look at the modifier table and see "here are all the ways abilities can be changed."

Concrete example to show the difference:

Integrated: Fireball = Trigger: Manual, Delivery: Single Projectile, Hit: AoE Explosion. Fireball+GMP = Trigger: Manual, Delivery: Multi Projectile (fan), Hit: AoE Explosion. GMP doesn't appear in any table — it's just the act of changing D1 to D2.

Separate: Fireball is classified in the ability tables. GMP appears in a modifier table: Axis: Delivery, Change: Single → Multi (fan), Constraint: Projectile abilities only. The modifier table is its own reference.

Which feels more useful to you?

Let's have a separate table. But due to the nature of modifiers, we'll be able to come up with new ones pretty easily ourselves, I think, once we have all the tables for most effects. So the modifier table should be framed more as an (exhaustive) instruction manual for the creation of further modifiers. Makes sense?

Yes, that makes sense. The modifier table would document all the axes along which abilities can be modified exhaustively — every knob you can turn, every dimension you can swap. Then creating a new specific modifier is just "pick an axis, define the from→to change." The table is the grammar, specific modifiers are sentences.

So something like:

Axis Modification Type Description Examples from reference
Delivery Single → Multi (fan) One projectile becomes several in a spread GMP, 20/20, Inner Eye
Delivery Single → Multi (nova) One projectile becomes many in all directions Ethereal Knives-style
Hit Behavior Consumed → Pierce Projectile passes through instead of stopping Pierce support, Spectral Throw
Hit Behavior Consumed → Chain Projectile jumps to next target Chain support, Ukulele
Hit Behavior Consumed → Split Projectile spawns new projectiles on hit Fork, Cricket's Body, Parasite
Trigger Manual → On-event Ability fires automatically on a game event Cast on Crit, Cast when Damage Taken
Caster Self → Deployable A placed entity performs the ability instead of the player Spell Totem, Engineer turrets
...etc

And because it's exhaustive, you could look at any axis and ask "what else could we change here?" to invent new modifiers. Ready for me to build the full tables now?

Not exhaustive in the sense that you should pre-emptively try for all types of modifications ever possible, but exhaustive in that it covers every one of the modifiers that exist in the example games. So the right-most colums, examples from reference, should never be empty.

Makes perfect sense. The modifier table documents every observed modification type with grounded examples — it's a reference for what has been done, which naturally becomes a generative tool for what could be done since you can see the patterns.

Let me build the full tables now. I'll save it as a separate document.

This session is being continued from a previous conversation that ran out of context. The summary below covers the earlier portion of the conversation.

Analysis: Let me go through the conversation chronologically:

  1. Opening: User says "We have the basics needed to start work on the abilities for Orblike. Get acquainted with the project first." Per CLAUDE.md instructions, I read three files: Orblike/ORBS.md, Anchor/docs/FRAMEWORK_API_QUICK.md, and Orblike/main.lua.

  2. User's first design discussion: User wants to discuss what ORBS should capture for the projectile ability. They mention "click", "spawn projectile", "mouse direction/angle". I analyzed what the ability decides vs what the game decides (visual/feel).

  3. User redirects approach: "Let's try a different approach. Let's try creating something similar to the ATTACK DESIGN REFERENCE document in EBB." I found and read emoji-ball-battles/docs/ATTACK_REFERENCE.md and emoji-ball-battles/reference/attack-design-space.md. The EBB reference breaks weapons into 4 orthogonal dimensions: Shape, Behavior, Trigger, Scaling.

  4. User wants ability corpus first: "Can we figure out if you can generate a text version of ALL abilities in a single game?" Wants to use wiki/knowledge to get abilities from games, then design the system by picking specific abilities and ensuring they can be described. Starts with PoE.

  5. 10 PoE active skills sample: User approves the format — name, tags, mechanical description focusing on logic.

  6. 10 PoE support gems sample: User approves this too.

  7. 30+30 PoE skills: User asks for 30 active + 30 support, saved to orbs/ability_reference.md.

  8. User asks to open document: I open it in NeoVim with MarkdownPreview.

  9. 60 LoL champion abilities: User says "Do league next. 60 champion abilities." Specified: "Do not compare design ground covered with previous games, treat the design ground from each game individually."

  10. Discussion about items vs support gems: User asks if items in League/Dota/RoR2 serve same purpose as PoE support gems. I broke down into 6 categories: ability modifiers, triggered effects, active abilities from items, ability replacements, stat modifiers, meta-modifiers.

  11. User narrows focus: "Let's focus on abilities and ability modifiers only. If the abilities/ability modifiers appear in characters or items it's irrelevant." Asks if LoL items would add anything — I say no, champion abilities cover LoL's design space well.

  12. Dota 2 — 60 abilities: Including items like Blink Dagger as abilities. User then asks for 20 more simpler "bread and butter" abilities (beams, projectiles, simple AoEs).

  13. Isaac — 80 items: Covering tear replacements, path modifiers, on-hit modifiers, pattern modifiers, familiars, orbitals, on-kill effects, on-hit-taken effects, actives, death prevention, conditional.

  14. RoR2 — 80 abilities/items: Covering survivor abilities, on-hit items, on-kill items, on-damage-taken items, attack modifiers, equipment, lunar items, void items, meta modifiers.

  15. Other games discussion: I suggest Hades, Vampire Survivors, Noita, Diablo 3/4, Slay the Spire, SNKRX, Enter the Gungeon. User asks about SNKRX and Noita specifically.

  16. SNKRX: User asks if other games cover SNKRX's mechanics. I agree they do — SNKRX's unique contribution is the composition meta-layer, not individual ability mechanics.

  17. Noita: I identify unique composition mechanics (sequential ordering, trigger nesting, heterogeneous multicast, timer as composable). User decides NOT to do Noita — "I've decided to implement abilities first before focusing on the system itself. Plus, Noita's system is constrained in an important way I don't like which is that position matters in unintuitive ways."

  18. ATTACK DESIGN REFERENCE creation: User says "now let's do the ATTACK DESIGN REFERENCE-like approach. You'll look at all the abilities and extract similar tables." Before proceeding, I ask clarification questions.

  19. User answers to my questions:

  20. Q1 (modifiers integrated or separate): "Let's discuss this further after my other answers"
  21. Q2 (multi-phase): "Each phase should be described as its own ability, and then we should have a 'staged' subtype" — asks for 10 examples first
  22. Q3 (completeness): "Yes. For the outliers they should be noted as such, but there should also be an attempt to classify their workings."

  23. Q4 (scaling): "No scaling or damage for now, this is very high level."

  24. 10 multi-phase ability examples: I show compound type vs staged decomposition for 10 abilities. User agrees with the hybrid approach.

  25. Modifier table discussion: User asks me to explain Q1 in more detail. I give concrete examples of Kind 1 (swap within column), Kind 2 (add triggered ability), Kind 3 (change fundamental frame). User says: "Let's have a separate table" and importantly: "the modifier table should be framed more as an (exhaustive) instruction manual for the creation of further modifiers."

  26. Clarification on exhaustive: User corrects: "Not exhaustive in the sense that you should pre-emptively try for all types of modifications ever possible, but exhaustive in that it covers every one of the modifiers that exist in the example games. So the right-most columns, examples from reference, should never be empty."

  27. I create ability_design_reference.md: With 6 ability tables (Trigger, Targeting, Delivery, Behavior, Hit Behavior, Effect), a Modifier Reference with sub-tables (Delivery Modifiers, Hit Behavior Modifiers, Trigger Modifiers, Behavior Modifiers, Effect Modifiers, Area Modifiers, Resource Modifiers, Speed Modifiers, Caster Modifiers), Classification Examples showing how abilities map to the tables, and a Design Checklist.

Files created/modified: - E:\a327ex\Orblike\orbs\ability_reference.md — ~360 ability descriptions across 5 games - E:\a327ex\Orblike\orbs\ability_design_reference.md — the ORBS design reference tables

The user has NOT yet reviewed the ability_design_reference.md document. I wrote it and the conversation ends with me having just created it. I didn't open it for the user to review yet.

Summary: 1. Primary Request and Intent: The user wants to build the ORBS (Orthogonal Rule Binding System) ability system for Orblike, a game using the Anchor engine with SNKRX visual style. The approach is bottom-up: first build a comprehensive reference corpus of abilities across major build-heavy games, then extract orthogonal dimensions (like the EBB ATTACK_REFERENCE.md pattern) that can describe any ability by picking one entry from each table. The user explicitly decided to implement abilities first before focusing on the system itself — the tables are meant to guide ability design, not be a formal system yet. A separate modifier table was requested, framed as an instruction manual for creating modifiers — exhaustive in covering every modifier observed in the reference games (every row must have concrete examples), but not speculative.

  1. Key Technical Concepts:

    • ORBS: Orthogonal Rule Binding System — abilities compose independently without knowing about each other
    • Two-layer architecture: description layer (how designer/LLM thinks) and implementation layer (Lua code)
    • EBB-style design reference: orthogonal dimensions with typed menus (Shape, Behavior, Trigger, Scaling in EBB)
    • For ORBS, 6 ability dimensions: Trigger, Targeting, Delivery, Behavior, Hit Behavior, Effect
    • Modifier table separate from ability tables, organized by which axis is modified
    • Multi-phase abilities: use compound types for common patterns (channel-then-release, mark-then-recast, hold-to-charge), staged decomposition for complex multi-phase abilities
    • Outlier abilities (Invoker, Aphelios) should be classified as best as possible, noted as outliers
    • No scaling or damage columns — high-level only
    • Abilities from items are treated the same as abilities from characters/kits
    • ~360 ability descriptions across 5 games serve as the reference corpus

  2. Files and Code Sections:

    • E:\a327ex\Orblike\ORBS.md

      • Design document for the ORBS system: goals, architecture, open questions, development process
      • Read for project acquaintance; not modified

    • E:\a327ex\Anchor\docs\FRAMEWORK_API_QUICK.md

      • Compact function signatures for the Anchor framework
      • Read for project acquaintance; not modified

    • E:\a327ex\Orblike\main.lua (~915 lines)

      • The current Orblike game code with player, seeker enemy, 5 attack types (projectile, single_target, area_rect, area_circle, line_attack), visual effects (hit_circle, hit_particle, hit_effect)
      • Read for project acquaintance; not modified

    • E:\a327ex\emoji-ball-battles\docs\ATTACK_REFERENCE.md

      • EBB's attack design reference with tables for Shape (19 types), Behavior (9 types), Trigger (8 types), Scaling (9 types)
      • Read as the template for the ORBS design reference

    • E:\a327ex\emoji-ball-battles\reference\attack-design-space.md

      • Detailed exploration and rationale behind EBB's attack design space
      • Read for additional context

    • E:\a327ex\Orblike\orbs\ability_reference.md (CREATED, ~1076+ lines after all edits)

      • Comprehensive ability descriptions across 5 games for ORBS system design
      • Sections: Path of Exile (30 active skills + 30 support gems), League of Legends (60 champion abilities), Dota 2 (80 abilities: 60 complex + 20 simple bread-and-butter), The Binding of Isaac (80 items), Risk of Rain 2 (80 abilities/items)
      • Format per ability: Name, tags line, mechanical description focusing on logic (triggers, delivery, targeting, hit behavior, special mechanics, no numbers)

    • E:\a327ex\Orblike\orbs\ability_design_reference.md (CREATED)

      • The ORBS equivalent of EBB's ATTACK_REFERENCE.md
      • Contains 6 ability building block tables:
        • Trigger (T1-T12): Manual, On-hit, On-kill, On-crit, On-damage-taken, Periodic, Proximity, Conditional, Accumulation, On-death, Reactive, Passive
        • Targeting (A1-A9): Aimed direction, Aimed point, Targeted enemy, Targeted ally, Targeted any, Self, Auto-target, Global, None
        • Delivery (D1-D28): Projectile (+ arcing, homing, returning, orbiting, slow), Multi-projectile (fan, nova, rain), Beam, Cone, Circle AoE, Expanding ring, Rectangle AoE, Line AoE, Ground zone, Melee, Chain, Dash, Teleport, Deployable, Summon, Tether, Aura, Attached, Hook, Terrain, Wall/Shield
        • Behavior (B1-B13): Instant, Duration, Permanent, Channelled, Hold-to-charge, Channel-then-release, Mark-then-recast, Accumulate-then-release, Staged, Toggle, Decaying, Delayed, Recurring
        • Hit Behavior (H1-H12): Consumed, Pierce, Chain, Split, Bounce (terrain), Bounce (ground), Explode, Stick, Displace, Block, Screen-wrap, Persistent contact
        • Effect (E1-E25): Damage, DoT, Heal, Shield, Buff, Debuff, Hard CC, Soft CC, Forced action, Displacement, Summon, Terrain creation, Death prevention, Damage reflection, Invulnerability, Stealth, Reveal, Ability copy, Transform, Cooldown reset, Permanent scaling, Resource drain, Damage delay, Execute, Damage amplification
      • Modifier Reference with sub-tables: Delivery Modifiers (MD1-MD17), Hit Behavior Modifiers (MH1-MH10), Trigger Modifiers (MT1-MT5), Behavior Modifiers (MB1-MB4), Effect Modifiers (ME1-ME10), Area Modifiers (MAr1-MAr2), Resource Modifiers (MR1-MR4), Speed Modifiers (MS1), Caster Modifiers (MC1-MC3)
      • Classification Examples table showing ~25 abilities mapped to the tables
      • Design Checklist (6 items)

  3. Errors and fixes:

    • No code errors occurred. Key user corrections/redirections:
      • User redirected from discussing what ORBS should capture for individual abilities to the EBB ATTACK_REFERENCE approach: "Let's try a different approach"
      • User redirected from designing the system first to building a reference corpus first: "Can we figure out if you can generate a text version of ALL abilities in a single game?"
      • User clarified "exhaustive" for the modifier table: "Not exhaustive in the sense that you should pre-emptively try for all types of modifications ever possible, but exhaustive in that it covers every one of the modifiers that exist in the example games. So the right-most columns, examples from reference, should never be empty."
      • User decided against Noita: "Noita's system is constrained in an important way I don't like which is that position matters in unintuitive ways"
      • User decided against SNKRX (agreed it's covered by other games)
      • User decided to implement abilities first before focusing on the system: "I've decided to implement abilities first before focusing on the system itself"

  4. Problem Solving:

    • Solved the question of how to categorize items across games (LoL, Dota, RoR2, Isaac) vs PoE support gems by breaking them into 6 functional categories (ability modifiers, triggered effects, active abilities from items, ability replacements, stat modifiers, meta-modifiers), then focusing only on abilities and ability modifiers
    • Solved the multi-phase ability classification problem by proposing a hybrid: compound types for common patterns (channel-then-release, hold-to-charge, mark-then-recast) and staged decomposition for complex multi-phase abilities
    • Established that abilities from items should be treated identically to abilities from character kits

  5. All user messages:

    • "We have the basics needed to start work on the abilities for Orblike. Get acquainted with the project first."
    • "Each game that implements the ORBS system will essentially be tasked with implements the events it generates per ability. Let's imagine the 4 abilities we have now. Actually, only the first: 1. Projectile. On click, it generates a projectile towards the direction of the mouse. The ability should capture, 'click', 'spawn projectile', 'mouse direction/angle', right?"
    • "Hmmm, let's try a different approach. Let's try creating something similar to the ATTACK DESIGN REFERENCE document in EBB, where we divide the design by sections that can have multiple types to them. Can you see that document?"
    • "Yes, but first, can we figure out if you can generate a text version of ALL abilities in a single game? I believe the wikis for the most popular games must contain descriptions of all their abilities, so we can probably get the abilities for a few game that matter and that I care about in a full way, and then design the system slowly by picking a few specific abilities at a time and making sure that it can be described properly at this high level. Imagine you wanted to do this for Path of Exile, how would you go about it?"
    • "The goal is creating a single md file that contains a description of all abilities in the game." (sent while I was working)
    • "Start with PoE and use your knowledge. However, give me 10 abilities first from your knowledge base and how you plan on adding them to the document so I can see if its good."
    • "I think this level of detail is perfect and focusing on the logic like this works well. If you had to go for 10 support gems instead, what would they look like?"
    • "Yes, this level of detail is perfect. Let's go for 30 skill gems and 30 support gems. Try to focus on the most iconic ones that also cover the most design ground when all taken together. Save this to a file in orbs/, this file will contain all skill descriptions for all games like this, divided by sections (game name)."
    • "Open the document for me please."
    • "Sure, do league next. 60 champion abilities. Similarly, try to pick iconic ones that cover the most design ground. You can pick multiple from the same champion if you want. Do not compare design ground covered with previous games, treat the design ground from each game individually according to itself only, if that makes sense."
    • "Do items in League, Dota, Risk of Rain and other games serve the same design purpose as support gems in PoE? Or should we consider these differently? Are item effects in PoE (in gear) in the same category as items in those games? How would you separate these things?"
    • "Let's focus on abilities and ability modifiers only. If the abilities/ability modifiers appear in characters or items it's irrelevant. Makes sense? So Blink Dagger in DoTA should count as one out of the 60, if you happen to choose it. In light of this, are there any other things in League you'd add, or replace existing abilities for things that appear in items?"
    • "OK, let's do DoTA. 60 abilities/ability modifiers, regardless where they come from."
    • "Do some simpler abilities in DoTA as well? Like beams, projectiles, simple are effects, etc. 20 more."
    • "Isaac now, do 80 too."
    • "Do Risk of Rain 2 next, 80."
    • "Are there any other important build heavy action games missed? Just like the ones that come to mind and I'll pick if I agree that they could be useful."
    • "Noita would be interesting and I've played it passingly, and SNKRX would be interesting since I made it. I think the other games cover all aspects of gameplay that SNKRX covers though, tell me if you agree or disagree. And as for Noita, do you think everything is covered or that it has unique enough ideas in it that other games missed?"
    • "Let's not do that. I've decided to implement abilities first before focusing on the system itself. Plus, Noita's system is constrained in an important way I don't like which is that position matters in unintuitive ways."
    • "No, first, now let's do the ATTACK DESIGN REFERENCE-like approach. You'll look at all the abilities and extract similar tables to that of that document for them. Does it make sense? Before you do it, ask me any questions for further clarifications."
    • "1. Let's discuss this further after my other answers. 2. Each phase should be described as its own ability, and then we should have a 'staged' subtype that allows for such abilities in some detail. However, because the tables have low detail in general we don't need to dwell on this that much. The goal of the tables is describing how abilities work at a high-level primarily, so I think going for individual + staged is a good level of abstraction. Although your idea of doing it specific, like channel-then-release types, is interesting too. Maybe you should give me an example of 10 such abilities and how you'd classify them so I can see in more detail. 3. Yes. For the outliers they should be noted as such, but there should also be an attempt to classify their workings. Invokers, for example, uses a charge-like system, right? Many abilities use things like charges, his is just a variation of that, if I remember correctly. 4. No scaling or damage for now, this is very high level."
    • "Yes, this makes sense. As for 1, can you explain your question in more detail, perhaps with examples?"
    • "Let's have a separate table. But due to the nature of modifiers, we'll be able to come up with new ones pretty easily ourselves, I think, once we have all the tables for most effects. So the modifier table should be framed more as an (exhaustive) instruction manual for the creation of further modifiers. Makes sense?"
    • "Not exhaustive in the sense that you should pre-emptively try for all types of modifications ever possible, but exhaustive in that it covers every one of the modifiers that exist in the example games. So the right-most colums, examples from reference, should never be empty."

  6. Pending Tasks:

    • The user has not yet reviewed the ability_design_reference.md document — it was just created but not opened for them
    • After review, the user plans to implement abilities in Orblike (they said "I've decided to implement abilities first before focusing on the system itself")
    • The overall ORBS development process: implement real abilities → notice patterns → extract primitives → document

  7. Current Work: I just finished creating E:\a327ex\Orblike\orbs\ability_design_reference.md — the ORBS Ability Design Reference with 6 ability building block tables (Trigger, Targeting, Delivery, Behavior, Hit Behavior, Effect), a Modifier Reference with 9 sub-tables, classification examples, and a design checklist. The user confirmed the approach ("Makes sense?") and I wrote the file, but have not yet opened it for the user to review.

  8. Optional Next Step: Open the ability_design_reference.md in NeoVim with MarkdownPreview for the user to review, since it was just created and the user hasn't seen it yet. Previous pattern in this conversation: after creating/updating the file, I open it for the user. The user may then want to refine the tables or move on to implementing abilities in Orblike.

If you need specific details from before compaction (like exact code snippets, error messages, or content you generated), read the full transcript at: C:\Users\adn.claude\projects\E--a327ex\ee3e2eaa-a459-4dc8-9749-c859da57ef1d.jsonl Please continue the conversation from where we left off without asking the user any further questions. Continue with the last task that you were asked to work on.

I just finished creating the ability design reference document. Let me open it for you to review.

Bash (~/bin/neovim.exe "E:/a327ex/Orblike/orbs/ability_design_reference.md" -- -c "Mar...)

Command running in background with ID: bxyko5g1f. Output is being written to: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\bxyko5g1f.output

The document is open. Here's a quick overview of what's in there:

6 Ability Building Block Tables:

Modifier Reference (9 sub-tables): Delivery Modifiers, Hit Behavior Modifiers, Trigger Modifiers, Behavior Modifiers, Effect Modifiers, Area Modifiers, Resource Modifiers, Speed Modifiers, Caster Modifiers — each with concrete examples from the reference games.

Classification Examples: ~25 abilities mapped to the tables showing how the system describes real abilities.

Design Checklist: 6-item checklist for designing new abilities.

Take a look and let me know what you think — what needs changing, what's missing, what feels off.

OK, let's test a few abilities. A projectile that chains to nearby enemies on hit. It chains N times and then once that's done it does on the last enemy hit.

Let me pull up the tables to classify this precisely.

Read (E:\a327ex\Orblike\orbs\ability_design_reference.md)

     1→# ORBS Ability Design Reference
     2→
     3→High-level building blocks for describing abilities. Pick one from each table to classify an ability. Some abilities combine multiple entries from a table (noted with +).
     4→
     5→Detailed ability descriptions: `ability_reference.md`
     6→
     7→---
     8→
     9→## Building Blocks
    10→
    11→### Trigger — What activates the ability
    12→
    13→| ID | Trigger | Description | Examples |
    14→|----|---------|-------------|---------|
    15→| T1 | Manual | Player activates via input | Fireball, Ezreal Q, Cyclone, Brimstone |
    16→| T2 | On-hit | Triggers when dealing damage to an enemy | Ukulele, ATG Missile, Sticky Bomb, Brilliant Behemoth, Needletick |
    17→| T3 | On-kill | Triggers when an enemy dies | Will-o'-the-Wisp, Gasoline, Ceremonial Dagger, Guppy, Athame, Frost Relic |
    18→| T4 | On-crit | Triggers on critical strike | Predatory Instincts, Harvester's Scythe, Cast on Critical Strike |
    19→| T5 | On-damage-taken | Triggers when receiving damage | Cast when Damage Taken, Medkit, Holy Mantle, Tougher Times, The Polaroid |
    20→| T6 | Periodic | Fires automatically on a fixed timer | Storm Brand pulses, Engineer turrets auto-fire, Lil Brimstone charge cycle |
    21→| T7 | Proximity | Triggers when an enemy enters a range/area | Bear Trap, Teemo mushrooms, Techies mines, Engineer Pressure Mines |
    22→| T8 | Conditional | Triggers when a game state meets a threshold | Runald's/Kjaro's Band (damage threshold), Abaddon R (HP threshold), Crown of Light (HP full), Rengar (in brush) |
    23→| T9 | Accumulation | Triggers when a counter of events reaches a value | Annie passive (4 spells), Yasuo Q (3rd hit), Jhin passive (4th shot), Lead Pencil (every 15 tears), Discharge (consume all charges) |
    24→| T10 | On-death | Triggers when the ability holder dies | Dead Cat, 1UP, Dio's Best Friend, Zilean R buff, Lazarus' Rags |
    25→| T11 | Reactive | Triggers in direct response to an incoming attack | Fiora Riposte, Sivir Spell Shield, Nyx Spiked Carapace, Blade Mail, Bot Fly |
    26→| T12 | Passive | Always in effect with no activation | Vayne W, Bloodseeker Thirst, Kalista Martial Poise, Drow Frost Arrows, Gnawed Leaf |
    27→
    28→### Targeting — How the ability selects its target(s)
    29→
    30→| ID | Targeting | Description | Examples |
... [265 more lines]

Here's the classification:

Chaining projectile (N chains, dies on last hit)

Axis Entry Notes
Trigger T1 Manual Player fires it
Targeting A1 Aimed direction Aimed at initial target
Delivery D1 Projectile Travels as a projectile initially
Behavior B1 Instant No duration/channel, fires and goes
Hit Behavior H3 Chain (N times) → H1 Consumed Chains N times, then consumed on final hit
Effect E1 Damage Deals damage each chain + final hit

The interesting part is Hit Behavior — it's a compound: H3 Chain with a count parameter, followed by H1 Consumed as the terminal condition. The tables handle this naturally since the Classification Examples already show H1+H7 style combinations (Fireball: consumed + explodes).

One thing worth noting: the chain count N is a parameter on H3, not a separate axis. The tables don't currently have a "parameters" column — things like chain count, projectile count, duration length are all implicit. That's probably fine at this level of abstraction, but it's worth flagging: if you wanted to say "chains 5 times" vs "chains 3 times," that distinction lives outside the tables right now.

The H1 consumed thing and how it combines with H1 -> H7 is interesting... What we want is that compositional ability. But now that we have the tables, how might we derive from it practices for generating abilities that increase our compositional ability? How can we tell that the abilities we're generating are prone to interesting changes and thus will lead to potentially interesting builds, vs. when they're not?

This is a really good question, and I think the tables actually reveal the answer pretty clearly once you look at them through the right lens.

The core observation: compositionality comes from an ability having "standard" axis values that modifiers can grab onto. Look at the modifier table — the vast majority of modifiers target specific axis values:

So there's a "default template" that maximizes modifier surface area:

T1 Manual, A1 Aimed direction, D1 Projectile, B1 Instant, H1 Consumed, E1 Damage

That's PoE's Fireball. And Fireball is famously one of the most compositionally rich abilities in PoE — you can support it with GMP, Chain, Pierce, Fork, Spell Echo, Trap, Mine, Spell Totem, Cast on Crit, Combustion, Added Fire... practically the entire support gem pool applies.

Now compare to Dota's Blink Dagger: T1 Manual, A2 Aimed point, D20 Teleport, B1 Instant, —, —. How many modifiers apply? Almost none. There's no projectile to make homing, no hit behavior to replace, no effect to add DoT to. It's compositionally inert. Still a great ability — but it doesn't participate in the build ecosystem.

This suggests a practical principle:

An ability's compositional richness ≈ how many modifier table entries apply to its current axis values.

And from that, a few derived rules:

1. The "one deviation" sweet spot

The most compositionally interesting abilities deviate from the default template on 1–2 axes and stay standard on the rest. The deviation is what makes the ability feel unique; the standard axes are where modifiers attach.

Each deviation on one axis closes some modifier doors but opens new interaction doors. Arc's H3 Chain means on-hit triggers fire N times per cast — that's a multiplicative interaction that H1 Consumed doesn't have.

2. Event multiplication is the engine of builds

The reason the H1 → H3/H4/H2 modifications are so powerful isn't just that they change what happens on contact — it's that they multiply the number of hit events per activation. And hit events feed the entire T2–T5 trigger ecosystem.

One projectile with H1 Consumed generates 1 hit event. Add H3 Chain (5 times) and it generates 6. Add H7 Explode on each chain and each explosion hits 3 enemies — now it's 18+ hit events from one button press. Each of those events can proc Ukulele, ATG Missile, Tri-Tip Dagger...

This is the RoR2 design insight: the game is fundamentally about hit count × on-hit item stacking. Abilities that generate many hit events (Huntress Laser Glaive, Engineer turrets, MUL-T nailgun) become exponentially stronger with items.

So a useful question for any ability: how many hit events does this generate per activation, and how does that number grow with modifiers?

3. Compositional poverty has recognizable signatures

Red flags that an ability won't compose well:

4. The practical design heuristic

When designing an ability for Orblike, you could literally count modifier applicability:

Template axis Applicable modifier count
D1 Projectile ~17 delivery modifiers
H1 Consumed ~10 hit behavior modifiers
T1 Manual ~5 trigger modifiers
B1 Instant ~4 behavior modifiers
E1 Damage ~10 effect modifiers
Total ~46 possible modifications

Then for your chaining projectile:

Axis Value Applicable modifiers
D1 Projectile ~17 (still a projectile, all delivery mods apply)
H3 Chain → H1 Consumed ~5-ish (already chain, so MH2 is used up, but MH6 add-explosion, MH3 split-on-final-hit, etc. still work)
T1 Manual ~5
B1 Instant ~4
E1 Damage ~10
Total ~41

You traded ~5 hit behavior modifier slots for the chain mechanic — but gained multiplicative hit-event generation. That's a good trade. The ability is compositionally rich AND has a distinctive identity.

Compare to if you designed: "a teleport that creates terrain at the departure point that stealths allies inside it." That's D20 + E12 + E16 — three exotic axis values, almost zero modifier surface area. Cool ability, but it lives alone. It doesn't get better with items/supports, and it doesn't create build-defining choices.

The meta-principle, I think, is this: abilities should be "boring" on most axes so they can be "interesting" via modification. The compositional richness of a game comes not from each ability being unique on every axis, but from each ability being a simple base with many attachment points. The builds are where complexity emerges, not the individual abilities.

This is exactly why PoE's system works so well and why Isaac's works so well — the base tears/skills are deliberately simple (projectile, consumed, aimed, instant), and the modifier ecosystem is enormous. The interesting stuff happens in the combination space, not in any individual node.

What about areas? I can see how projectiles are highly modifiable, but does the same apply to areas or are they inherently less verstabile than projectiles?

Honestly, I think areas ARE inherently less versatile than projectiles, but the gap is larger in our current tables than it needs to be. There are two things going on:

The inherent gap. Projectiles are parametrically rich — they have position, velocity, direction, lifetime, and a discrete hit moment, each of which is an independent knob a modifier can turn. That's why the delivery modifier table has trajectory changes (straight → homing, → returning, → orbiting, → arcing), count changes (single → fan, → nova), and behavior changes (→ spectral, → screen-wrapping, → controllable). Each of those operates on a different parameter of the projectile.

Areas have: position, shape, size, duration. Fewer independent parameters, so fewer knobs for modifiers to grab. And crucially, areas lack a trajectory — the entire MD4–MD9 block (6 modifiers) is "change how the projectile travels," which is a dimension areas simply don't have.

Areas also have a weaker hit event story. A projectile hits something at a specific moment — that's a clean, discrete event that feeds H1–H12 and the on-hit trigger ecosystem. An area... things are just "inside" it. The contact is continuous, not discrete. So areas naturally generate fewer clean events, which means they interact less with the T2–T5 trigger layer.

The table gap (bigger than the inherent gap). Our modifier table is heavily biased by its source material. PoE and Isaac are projectile-centric games — their modifier ecosystems evolved around projectiles. But there ARE area modifications in these games that we haven't fully captured:

So if we added area-specific modifiers, the table might grow by something like:

ID Modification Description Examples
MAr3 Single → Multi-zone (cascade) One AoE becomes several at offset positions Spell Cascade (PoE)
MAr4 Static → Moving Zone gains a movement vector Rumble R, Lissandra glacial path
MAr5 Fixed size → Growing Zone expands over its duration Nunu R, Sand King Epicenter
MAr6 Instant → Residue Instant AoE leaves a persistent ground zone Vaal Fireball burning ground, Gasoline (RoR2)
MAr7 Single → Segmented One zone fragments into smaller zones (theoretical, but follows from projectile Split logic)

That closes the gap somewhat — but even with these additions, areas top out around ~7 area-specific modifiers vs. ~14 projectile trajectory/count modifiers. The inherent gap is real.

But there's a counterpoint. Areas have a compositional advantage that projectiles don't: they're inherently multi-hit. A projectile with H1 Consumed hits one enemy. You need to ADD chain/pierce/split to make it hit more. An area hits everything inside it by default. So areas start at a higher baseline of event generation even if they have fewer modifier attachment points.

And areas compose well on the Behavior axis in ways projectiles often don't. A projectile's behavior is usually B1 Instant — it fires and it's done. Areas naturally support B2 Duration, B4 Channelled, B13 Recurring (ticking zones), B11 Decaying, B12 Delayed. That's 5-6 behavior entries that feel natural on areas vs. 1-2 on projectiles. So the behavior modifier space (MB1–MB4) might actually be MORE applicable to areas than to projectiles.

The honest summary:

Modifier space Projectiles Areas
Delivery/trajectory mods ~14 ~5-7
Hit behavior mods ~10 ~3-4 (less clean hit events)
Behavior mods ~2-3 ~4-5 (duration/tick natural)
Effect mods ~10 ~10 (same)
Trigger mods ~5 ~5 (same)
Area mods ~0 ~5-7
Total ~41-42 ~27-33

Areas are less versatile, but not drastically so. The gap is maybe 70-80% of projectile versatility, not 30%. And the character of the versatility is different — projectiles compose through trajectory and hit-event multiplication, areas compose through temporal behavior and spatial manipulation.

The design implication for Orblike: if you want maximum build diversity, projectile-base abilities will generate more modifier interactions by default. But area abilities aren't dead weight — they just need their own modifier ecosystem that the current tables underrepresent. And mixing both types in a build is where things get really interesting, because on-hit triggers from a projectile could spawn areas, and area ticks could trigger more projectiles.

What about beams, summons, single target, and other "base", uh, what should we even call these, fundamental objects of an ability? Try to come up with a decent name for it and then do this same analysis for them as well. And try to list all the ones that you think apply that I may have not noticed.

Good question on naming. A few candidates:

I'd go with carrier. It captures the functional role (carries effects to targets) and implies the compositionality story (things attach to it, ride on it).

Now, the full enumeration. Some of these are in the Delivery table already, some are buried as subtypes, some aren't there at all. The test for whether something is a distinct carrier: does it have a different modifier surface area than its nearest neighbor? If the set of applicable modifiers changes, it's a different carrier.

The full carrier list:

  1. Projectile — discrete entity moving through space (Fireball, Ezreal Q)
  2. Beam — instant or persistent line, no travel time (Brimstone, Lux R, Technology)
  3. Area — instant region of effect at a point (Crystal Nova, Centaur Stomp)
  4. Zone — persistent region at a location, ticks over time (Caustic Arrow, Teemo mushroom)
  5. Aura — persistent region attached to a unit, moves with it (Righteous Fire, Frost Relic)
  6. Orbit — entities circling a unit at fixed radius (Blade Vortex, Sacrificial Dagger, Pretty Fly)
  7. Trail — effect along the caster's movement path (Pencil from EBB, conceptually)
  8. Melee — close-range hit or swing (Nasus Q, Loader punch, Spirit Sword)
  9. Targeted — point-and-click effect on a unit, no spatial object (Doom, Hex, Orchid)
  10. Chain — effect jumping between nearby targets (Arc, Lich Chain Frost, Ukulele)
  11. Summon — autonomous mobile entity with its own behavior (Raise Zombie, The Backup drones)
  12. Deployable — autonomous stationary entity (Heimerdinger turret, Engineer turret, Sprinkler)
  13. Tether — persistent connection between two entities (Io Tether, Morgana R)
  14. Attached — effect stuck to a target, pulses autonomously (Storm Brand, Explosivo)
  15. Movement — caster's body IS the ability, repositioning (Blink Dagger, Flicker Strike, dash)
  16. Terrain — created impassable geometry (Anivia wall, Fissure, Mars Arena)
  17. Trap — dormant zone that activates on a condition (Techies mines, Teemo shrooms pre-trigger, PoE traps)

A few I debated including but didn't:

Compositionality analysis per carrier:

1. Projectile — the gold standard

Already analyzed. Maximum parameter space: position, velocity, direction, speed, lifetime, size. Every parameter is an independent knob.

Modifier surface:

Compositional character: Discrete hit events × trajectory diversity × count multiplication. The richest build-defining carrier.

2. Beam

Parameters: origin, direction, length, width, duration (if persistent), tick rate (if channelled).

What applies:

Compositional character: Beams trade trajectory diversity for reliability — they can't miss (instant hit along a line), and they inherently hit everything in a line. They compose primarily through duration × tick rate (a persistent beam generates many hit events over time) and through width/length scaling. Beams are the "steady DPS" carrier — fewer burst interactions, more sustained pressure.

Unique compositional property: Beams can SWEEP, hitting a changing set of targets as the caster rotates. No other carrier has this "aim-dependent persistent hit zone" property.

3. Area (instant)

Already analyzed in the previous message. ~27-33 modifiers.

Compositional character: Inherently multi-target but one-shot per cast. Composes through spatial modifiers (size, cascade/multi-zone) and effect stacking (what each target receives). The main compositional weakness is that one activation = one set of hits, so event generation is bounded per cast.

4. Zone (persistent area)

Parameters: position, shape, size, duration, tick rate.

What applies:

Compositional character: Zones are the "set it and forget it" carrier. They generate events passively over time, which means they multiply well with on-hit triggers. The main compositional lever is tick rate × duration × overlap potential. PoE's design leans heavily on this — Caustic Arrow, Vortex, Consecrated Ground stacking.

Versus Area: Strictly more composable than instant Area because it has all the same modifiers plus temporal ones. The tradeoff is gameplay feel — zones are passive/strategic, areas are active/reactive.

5. Aura

Parameters: radius, tick rate, attached-to-unit, move-with-source.

What applies:

Compositional character: Auras compose through "I am the zone." The caster's positioning and movement speed become damage variables. This creates a unique build archetype — Righteous Fire builds in PoE stack aura size, movement speed, and survivability rather than traditional offensive stats. Compositionally niche but deep within that niche.

6. Orbit

Parameters: orbit radius, orbit speed, entity count, entity size, direction (CW/CCW).

This is the one the tables currently bury as D5 (Projectile, orbiting), but I think it's a distinct carrier because the modifier surface is quite different from a projectile.

What applies:

Compositional character: Orbits are the "passive offense" carrier — you don't aim them, they just hit whatever's near you. They compose through count × orbit speed × radius. More orbitals + faster rotation = more hits per second. They create the same "I am the weapon" build archetype as auras, but with discrete hit events (which interacts with on-hit triggers better than auras do).

Orbits vs Auras: Orbits generate discrete hits at the rotation frequency. Auras generate continuous ticks at the tick rate. Orbits favor on-hit interactions; auras favor sustained damage. Two paths to the same "walk into enemies" archetype.

7. Trail

Parameters: trail width, trail duration, damage tick rate, shape-follows-movement.

Not in most games' ability ecosystems — the EBB Pencil is the clearest example. PoE's Toxic Trail (from a lab enchant), certain Isaac familiar trails.

What applies:

Compositional character: Trail is the most movement-dependent carrier. Its effective area is entirely determined by how the player moves. This creates a unique skill expression axis (pathing becomes a damage variable) but very few modifier attachment points. Compositionally narrow.

Key insight: Trails are probably best as secondary effects or modifiers on other abilities rather than primary carriers. "Your dash leaves a damaging trail" (movement + trail) is more interesting than "you have a trail ability."

8. Melee

Parameters: range, arc, attack speed, hit count.

What applies:

Compositional character: Melee's core compositional challenge is "how do I hit more things." By default it's single-target, so modifiers that add splash, chain, or cleave are transformative rather than incremental. Melee composes heavily through attack speed × on-hit effects — fast melee with on-hit procs is a classic archetype (PoE melee builds, RoR2 Mercenary/Loader). The compositional bottleneck is range — melee requires being in danger, so survivability modifiers become part of the build equation in a way they don't for projectiles.

9. Targeted (point-and-click)

Parameters: range, target selection.

The "invisible" carrier — no spatial object exists. You click, the target receives an effect.

What applies:

Compositional character: Targeted abilities trade spatial richness for reliability — they can't miss, can't be dodged. Their compositional space is almost entirely in the Effect and Trigger axes. "What does it do to the target" and "when does it fire" carry all the build diversity, because "how does it get there" is trivially answered.

Interesting property: Targeted abilities compose well as secondary triggered effects (T2–T5). "On hit, apply Doom to the target" doesn't need a projectile — it's a targeted effect piggybacking on another ability's hit event. Many on-hit items in RoR2/Isaac are effectively targeted carriers fired by a trigger.

10. Chain

Parameters: jump range, jump count, damage falloff per jump.

Currently in the tables as both a Delivery (D18) and a Hit Behavior (H3). It could be a carrier in its own right OR a hit behavior modifier on a targeted/projectile carrier. This ambiguity is interesting.

What applies:

Compositional character: Chain is the event multiplication carrier. N chain targets = N hit events per activation. Each hit event can proc on-hit triggers, and if those triggers are ALSO chains... exponential scaling. PoE's Arc + Chain support + on-hit triggers is a canonical example. The compositional value of chain isn't in the chain itself — it's in how it multiplies everything else.

11. Summon

Parameters: unit stats, unit AI, unit abilities, duration, unit count.

What applies:

Compositional character: Summons are compositionally recursive. They don't compose well as a modifier target, but they compose infinitely as a modifier VEHICLE. The build question isn't "how do I modify my summon ability" — it's "what abilities/modifiers does my summon carry?" This makes summon-centric builds deeply compositional, but through a different mechanism than projectile builds.

12. Deployable

Parameters: placement, health/duration, fire rate, targeting AI, abilities.

What applies:

Compositional character: Same recursive compositionality as summons. The key difference is that deployables create spatial commitment — you choose where they go, and that choice persists. This adds a strategic layer that summons (which follow you) don't have. Multiple deployables with overlapping fire zones = multiplicative damage on that area.

13. Tether

Parameters: two anchors, max range, break condition, duration, tick rate.

What applies:

Compositional character: Tethers are relationally composable — they care about the RELATIONSHIP between two entities, not spatial patterns. "Tether to ally → share damage taken" (Io) or "Tether to enemy → if they break range, stun" (Morgana R) creates conditional interactions. Narrow modifier surface but unique strategic space.

14. Attached (Brand)

Parameters: attached-to target, tick rate, duration, detach behavior.

What applies:

Compositional character: Attached is the "fire and forget" carrier. You cast it once, it does work for its duration. Composes through tick rate × chain behavior × duration. Multiple brands on different targets create distributed autonomous damage. The compositional uniqueness is that the brand is attached to a MOVING target — the damage follows the enemy, unlike a zone which the enemy can walk out of.

15. Movement (dash/teleport)

Parameters: distance, speed, destination, path.

What applies:

Compositional character: Movement is the least composable as a damage carrier, but it uniquely composes as a build enabler. Blink Dagger doesn't interact with on-hit items, but it lets you position for abilities that DO. The compositional role is indirect — movement carriers make other carriers more effective. They also compose with: trails (leave damage along path), auras (reposition your aura), melee (close distance to hit).

16. Terrain

Parameters: shape, size, duration, solidity.

What applies:

Compositional character: Terrain is compositionally unique because it changes THE ARENA, not the enemy. It composes through spatial control — funneling enemies into zones, blocking escape routes, protecting allies. The interactions are strategic, not statistical. Terrain + zone (block enemies inside your damage zone) or terrain + beam (funnel enemies into a line) are the compositional patterns.

17. Trap

Parameters: placement, activation trigger, activation delay, zone properties.

What applies:

Compositional character: Trap is Zone with a conditional activation, which adds the information/prediction game. You're composing spatially (where to put it) AND temporally (when will it trigger). Traps compose well with terrain (force enemies onto traps) and with count multiplication (more traps = more coverage). The dormant phase also means traps don't waste their effects on empty space — they wait for a valid target, making each trap more valuable than a zone of equal power.

Summary ranking:

Carrier ~Modifier Surface Compositional Character
Projectile ~46 Maximum versatility, trajectory × count × hit events
Zone ~32 Passive ticking, stacking, set-and-forget
Trap ~30 Zone + conditional activation, prediction layer
Area (instant) ~30 Inherent multi-hit, spatial modifiers
Melee ~27 Attack speed × on-hit, splash as transformative mod
Orbit ~27 Passive offense, count × speed, "I am the weapon"
Beam ~27 Sustained pierce, sweep, tick rate, reliable
Chain ~24 Event multiplication engine, compounds with on-hit
Attached ~24 Fire-and-forget, tick × chain × duration
Aura ~24 Movement = coverage, "I am the zone"
Targeted ~22 Reliable, no spatial mods, effect/trigger space
Trail ~20 Movement-dependent, narrow but unique
Tether ~20 Relational, conditional, niche strategic
Movement ~15 Build enabler, not damage carrier
Terrain ~10 Arena manipulation, strategic not statistical
Summon/Deployable ~12 act, ~40+ inherited Recursively compositional, carries other modifiers

The big takeaway: there's a clear tier structure. Projectile is king (~46), then a cluster of spatial carriers at ~27-32 (zone, trap, area, melee, orbit, beam), then targeted/relational carriers at ~20-24, then utility carriers at ~10-15. And summons are the weird outlier — low direct composability but meta-composable through inheritance.

One thing this reveals: the modifier table is projectile-biased. If Orblike wants diverse build archetypes, it probably needs to flesh out the modifier sub-tables for the ~27 tier carriers — give beams, orbits, and melee their own modifier ecosystems comparable to what projectiles have. Otherwise builds will always gravitate toward projectile-based abilities as the most interesting carrier to build around.

OK, let's change the document to take these into account, and also to not use abbreviation for the names of things. SO MD1 or whatever shouldn't be used, because I don't have the table always available to me. Just use the actual name of the thing when talking, so remove all abreviations. So the document should now have carriers, the main tables, the modifier tables.

Let me rewrite the document with carriers as a first-class table, all abbreviations removed, and the new area modifiers we discussed.

Read (E:\a327ex\Orblike\orbs\ability_design_reference.md)

     1→# ORBS Ability Design Reference
     2→
     3→High-level building blocks for describing abilities. Pick one from each table to classify an ability. Some abilities combine multiple entries from a table (noted with +).
     4→
     5→Detailed ability descriptions: `ability_reference.md`
     6→
     7→---
     8→
     9→## Building Blocks
    10→
    11→### Trigger — What activates the ability
    12→
    13→| ID | Trigger | Description | Examples |
    14→|----|---------|-------------|---------|
    15→| T1 | Manual | Player activates via input | Fireball, Ezreal Q, Cyclone, Brimstone |
    16→| T2 | On-hit | Triggers when dealing damage to an enemy | Ukulele, ATG Missile, Sticky Bomb, Brilliant Behemoth, Needletick |
    17→| T3 | On-kill | Triggers when an enemy dies | Will-o'-the-Wisp, Gasoline, Ceremonial Dagger, Guppy, Athame, Frost Relic |
    18→| T4 | On-crit | Triggers on critical strike | Predatory Instincts, Harvester's Scythe, Cast on Critical Strike |
    19→| T5 | On-damage-taken | Triggers when receiving damage | Cast when Damage Taken, Medkit, Holy Mantle, Tougher Times, The Polaroid |
    20→| T6 | Periodic | Fires automatically on a fixed timer | Storm Brand pulses, Engineer turrets auto-fire, Lil Brimstone charge cycle |
    21→| T7 | Proximity | Triggers when an enemy enters a range/area | Bear Trap, Teemo mushrooms, Techies mines, Engineer Pressure Mines |
    22→| T8 | Conditional | Triggers when a game state meets a threshold | Runald's/Kjaro's Band (damage threshold), Abaddon R (HP threshold), Crown of Light (HP full), Rengar (in brush) |
    23→| T9 | Accumulation | Triggers when a counter of events reaches a value | Annie passive (4 spells), Yasuo Q (3rd hit), Jhin passive (4th shot), Lead Pencil (every 15 tears), Discharge (consume all charges) |
    24→| T10 | On-death | Triggers when the ability holder dies | Dead Cat, 1UP, Dio's Best Friend, Zilean R buff, Lazarus' Rags |
    25→| T11 | Reactive | Triggers in direct response to an incoming attack | Fiora Riposte, Sivir Spell Shield, Nyx Spiked Carapace, Blade Mail, Bot Fly |
    26→| T12 | Passive | Always in effect with no activation | Vayne W, Bloodseeker Thirst, Kalista Martial Poise, Drow Frost Arrows, Gnawed Leaf |
    27→
    28→### Targeting — How the ability selects its target(s)
    29→
    30→| ID | Targeting | Description | Examples |
... [265 more lines]

Now let me write the updated document.

Write (E:\a327ex\Orblike\orbs\ability_design_reference.md)

The file E:\a327ex\Orblike\orbs\ability_design_reference.md has been updated successfully.

Bash (~/bin/neovim.exe "E:/a327ex/Orblike/orbs/ability_design_reference.md" -- -c "Mar...)

Command running in background with ID: b18rox3wz. Output is being written to: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\b18rox3wz.output

Done. Key changes:

Structural:

Formatting:

Design guidance:

Go wild and create as many modifiers as you can think of for as many carriers, triggers, etc you can think of. Show them to me here before adding them to the file. Just a flat list with each modifier in a line, explaining what it does, what it affects, etc. Obviously, avoid ones that already exist. After, I'll filter those based on which ones I think are good to add to the file. Prefix each one by a number (1, 2, 3, etc) so I can refer to them easily later.

Here's the brainstorm. Each line is self-contained — what it modifies, what it does, and context where applicable.

Projectile carrier mods:

  1. Straight → Zigzag/Sine wave — Projectile oscillates side-to-side as it travels. Distinct from bouncing (doesn't need walls) and homing (doesn't seek targets). Think Touhou-style wave bullets.

  2. Straight → Spiral — Projectile spirals outward from the caster in an expanding helix. Covers a wide area over time but takes longer to reach distant targets. Lollipop from EBB.

  3. Straight → Accelerating — Projectile starts slow and speeds up over distance (or vice versa: starts fast, decelerates). Changes the effective range/timing profile.

  4. Straight → Boomerang — Differs from Returning in that the projectile travels in a curved arc (like a real boomerang), not straight-out-and-back. Covers a wider lateral area.

  5. Single → Volley (sequential) — One projectile becomes several fired one-after-another in rapid sequence (not simultaneously like fan). Each projectile can be aimed slightly differently during the burst. Think Jhin R shots or semi-auto fire.

  6. Single → Shotgun (converging) — Multiple projectiles that start in a spread but converge at a point. Inverse of fan — rewards range-specific positioning. Close = fewer hits, sweet spot = all hit, far = spread out again.

  7. Aimed → Backward — Fires in the opposite direction of aim. Sounds useless alone, but composes with homing, or enables kiting patterns where you run away and shoot behind you.

  8. Normal → Phasing — Projectiles ignore allies and friendly entities, passing through them. Relevant in games with friendly fire or crowded ally units.

  9. Projectile → Growing — Projectile increases in size as it travels, gaining a larger hitbox over distance. Tradeoff: harder to land up close, easier at range.

  10. Projectile → Shrinking — Opposite of above. Starts large, shrinks over distance. Easier to land close, harder far.

  11. Normal → Terrain-creating — Projectile leaves impassable terrain along its path or at its endpoint. Bridges the Projectile and Terrain carriers.

  12. Projectile → Lingering — Projectile stops at max range and persists as a zone for a duration instead of disappearing. Bridges Projectile and Zone carriers. Toxic Rain pods in PoE do something similar.

Beam carrier mods:

  1. Single beam → Multi beam (fan) — One beam becomes several in a spread. The beam equivalent of the projectile fan modifier. Diablo 3 Disintegrate with certain runes.

  2. Fixed beam → Sweeping — Beam automatically rotates/sweeps rather than staying in a fixed direction. Changes from precision tool to area-clearing tool.

  3. Beam → Bouncing (reflects off walls) — Beam reflects off terrain surfaces, potentially hitting enemies around corners. Gives beams a spatial puzzle element.

  4. Beam → Forking — Beam splits into multiple beams when it hits a target, continuing outward in new directions. The beam equivalent of Split.

  5. Beam → Pulsing — Beam flickers on/off at a fixed interval rather than being continuous. Reduces total damage but creates periodic hit events that interact better with on-hit triggers than persistent contact does.

  6. Thin beam → Wide beam — Increases beam width. Simple but compositionally meaningful — wider beam hits more targets, interacts with sweep speed differently.

Orbit carrier mods:

  1. Fixed radius → Expanding/Contracting — Orbitals spiral outward over time (or inward). Changes the effective threat zone dynamically. Expanding = area denial that grows; contracting = pulls damage inward.

  2. Orbit → Detach on command — Orbitals can be launched outward as projectiles on a second activation. Converts Orbit carrier into Projectile carrier mid-ability. Gives orbits a "release" moment.

  3. Orbit → Erratic/Random radius — Orbitals wobble unpredictably in their orbit rather than following a perfect circle. Increases effective coverage area at the cost of reliability.

  4. Single orbit ring → Multiple concentric rings — Adds a second (or third) ring of orbitals at a different radius. Layered defense/offense.

Chain carrier mods:

  1. Chain → Forking chain — Each chain hop splits into 2+ chains to different targets, like a tree branching. Exponential target growth instead of linear.

  2. Chain → Return chain — After reaching max chains, the effect chains back along the same path to the caster. Each enemy gets hit twice. Medusa Mystic Snake already does something like this (returns mana).

  3. Chain → Priority targeting — Chains prefer specific targets: lowest HP, highest HP, most debuffs, unmarked enemies. Adds strategic depth to an otherwise random-feeling mechanic.

  4. Chain → Increasing chain — Each subsequent chain hop deals more damage (or has a larger effect) than the last. Rewards abilities that reach many targets — the last target in the chain is the most punished.

  5. Chain → Decreasing chain — Opposite: each hop is weaker. More standard/realistic falloff. Makes chain count a tradeoff (more targets but diminishing returns).

Melee carrier mods:

  1. Single hit → Cleave arc — Melee hit becomes a sweeping arc that hits everything in a cone. Different from Splash (which is centered on the target) — Cleave is centered on the attacker.

  2. Melee → Extended reach (whip) — Increases melee range significantly, turning it into a mid-range carrier while keeping the melee "feel" (no projectile, instant hit in a direction).

  3. Melee → Afterimage — Each swing leaves a damaging ghost of the swing arc that persists briefly. Subsequent swings stack ghosts. Rewards attack speed differently than raw on-hit.

  4. Melee → Lunge — Melee attack causes the caster to dash a short distance toward the target before hitting. Bridges Melee and Movement carriers. Removes the "I have to walk to them first" weakness.

Zone carrier mods:

  1. Zone → Magnetic/Pulling — Zone slowly pulls enemies toward its center. Doesn't deal damage itself but keeps enemies inside for longer, amplifying any zone damage. Composes with other zones.

  2. Zone → Linked — When two or more zones are placed near each other, they connect with a damaging bridge between them. Rewards deliberate zone placement. Creates geometric combat patterns.

  3. Zone → Stacking — Overlapping zones compound their effects multiplicatively rather than additively. Makes precise zone placement exponentially rewarding.

  4. Zone → Detonatable — Zones can be manually detonated, consuming them for an instant burst of damage. Trades sustained damage for burst. Gives zones an "exit" option.

  5. Zone → Decaying center — Zone damage is strongest at the edge and weakest at the center (or vice versa). Creates spatial nuance within the zone.

  6. Zone → Migrating — Zone slowly drifts toward the nearest enemy. Not as direct as homing projectile — more like a slow creep. Between Static and Moving.

Aura carrier mods:

  1. Aura → Pulsing — Aura oscillates between active and inactive states. During active: full effect. During inactive: charges up for a stronger next pulse. Creates rhythmic gameplay.

  2. Aura → Expanding on kill — Aura radius temporarily increases when the caster kills an enemy. Snowball mechanic — the more you kill, the more area you cover, the more you can kill.

  3. Aura → Inverting — Aura effect flips: what hurts enemies heals allies in range (or vice versa). A single aura becomes dual-purpose based on who's inside it.

Attached (Brand) carrier mods:

  1. Attached → Spreading — Brand copies itself to nearby enemies over time, like a contagion. Slow initially, but in dense packs the spread accelerates exponentially.

  2. Attached → Detonatable — Brands can be manually triggered for a burst, consuming them. Like zone detonation but on mobile targets. Allows setting up many brands then detonating simultaneously.

  3. Attached → Feeding — Each tick of the brand makes the next tick stronger. Rewards leaving brands on tanky enemies rather than popping them early.

  4. Attached → Sympathetic — When a branded target takes damage from any source, nearby branded targets also take a portion of that damage. Creates "linked" groups of enemies.

Tether carrier mods:

  1. Single tether → Multi-tether — Tether connects to multiple targets simultaneously. Creates a web rather than a line.

  2. Tether → Damaging line — The tether line itself damages or impedes enemies that cross it. The connection becomes terrain-like. Composes with displacement (knock enemies through the line).

  3. Tether → Transferring — When one tethered target dies, the tether jumps to the nearest untethered enemy. Persistent until no valid targets remain.

Summon/Deployable carrier mods:

  1. Summon → Sacrificial — Summons can be detonated, dealing AoE damage based on their remaining HP. Creates a "do I keep the sustained DPS or cash it in for burst" decision.

  2. Summon → Tethered — Summons are connected to the caster by a tether with a max range. If they'd go too far, they're pulled back. Creates a formation rather than free-roaming chaos.

  3. Deployable → Mobile (on trigger) — Deployable can be repositioned by recasting, or it slowly migrates toward enemies. Bridges Deployable and Summon carriers.

  4. Summon → Inheriting — Summons inherit the caster's on-hit effects, triggered abilities, etc. The RoR2 Engineer design as a modifier rather than a fixed property. Could apply to any summon build.

  5. Summon → Explosive death — When a summon dies (naturally or killed), it triggers an on-death effect (explosion, zone, debuff). Makes summon death meaningful, not just a loss.

Movement carrier mods:

  1. Dash → Damaging trail — Leaves a damaging zone along the dash path. Bridges Movement and Trail carriers. Flame Dash in PoE does this.

  2. Dash → Collecting — Enemies along the dash path are scooped up and deposited at the endpoint. Like a snowplow. Bridges Movement and Displacement.

  3. Teleport → Swap — Instead of teleporting to a point, you swap positions with a target (ally or enemy). Vengeful Spirit Nether Swap as a modifier rather than a distinct ability.

  4. Movement → Aftershock — Arriving at the destination creates an AoE impact. The faster/farther you traveled, the bigger the impact.

  5. Dash → Phasing — Caster is invulnerable/untargetable during the dash. Bridges Movement and Invulnerability effect.

Trail carrier mods:

  1. Trail → Wider — Trail width increases, covering more area. Simple scaling.

  2. Trail → Persistent — Trail lasts much longer (or permanently until a cap). Allows "painting" the arena with damage.

  3. Trail → Trapping — Trail applies slow or root to enemies that touch it, rather than (or in addition to) damage. Trail becomes area denial.

  4. Trail → Detonatable — Entire trail can be detonated at once for burst damage, consuming it. The longer the trail, the more total damage. Rewards movement before detonation.

Terrain carrier mods:

  1. Terrain → Damaging — Created walls/geometry deal damage to enemies that touch them. Terrain becomes both spatial control and damage source.

  2. Terrain → Crushing — When terrain is created, enemies caught inside the wall's footprint take heavy damage or are displaced. Fissure stun is an example. Makes placement offensive, not just defensive.

  3. Terrain → Temporary with collapse — When the terrain expires, it collapses and deals AoE damage or applies a debuff in the area it occupied.

Trap carrier mods:

  1. Trap → Rearmable — After triggering, the trap recharges and can trigger again after a delay. Turns single-use into recurring. Like a turret with a proximity trigger.

  2. Trap → Sympathetic detonation — When one trap triggers, nearby traps also trigger simultaneously. Chain reaction of traps. Rewards clustering.

  3. Trap → Bait — Trap actively attracts enemies toward it, making triggering more likely. The trap has a "pull" aura before detonation.

Hit behavior mods:

  1. Hit → Leave residue zone — Each hit leaves a small damaging ground zone at the impact point. Like Add Explosion but persistent rather than instant. Every hit paints the battlefield.

  2. Hit → Mark target — Hitting marks the target; other abilities or subsequent hits on marked targets deal bonus damage or trigger special effects. Generic "mark" mechanic as a modifier.

  3. Hit → Tether on hit — Hitting a target creates a tether between the caster and the target. Bridges hit behavior with Tether carrier.

  4. Hit → Absorb — Projectile gains damage/size/speed from each enemy it hits. Rewards pierce and chain — the more things it hits, the stronger it gets.

  5. Pierce → Diminishing — Projectile passes through but loses a percentage of damage/effect per target hit. More realistic pierce with inherent falloff.

  6. Split → Split on expire — Instead of splitting on hit, projectile splits when it reaches max range or times out. Covers a different spatial pattern than hit-splitting.

  7. Bounce → Accelerating bounce — Projectile gains speed (and optionally damage) on each wall bounce. Turns arena geometry into a damage multiplier.

  8. Chain → Expanding chain — Each chain hop creates a small AoE at the landing point. AoE grows with each hop. Final hop has the biggest explosion.

  9. Hit → Fragile on hit — Target becomes "fragile" — the next hit from any source deals bonus damage. One-stack mark that's consumed on next hit. Encourages alternating abilities.

Trigger mods:

  1. Manual → On-ability-use — Fires automatically whenever any other ability is used. Piggybacks on the caster's general activity. Weaker per-cast but fires very frequently.

  2. Manual → Periodic — Manual ability becomes timer-based, firing automatically on a fixed cooldown. Removes player agency but guarantees consistent output.

  3. On-hit → On-kill — Opposite of existing On-kill → On-hit. A frequent, weaker triggered effect becomes a rare, stronger one. Concentrates power into kill moments.

  4. Add secondary trigger — Ability keeps its primary trigger AND gains a secondary one. "This ability fires on Manual AND on On-crit." Dual-trigger increases activation frequency without replacing the original.

  5. Trigger delay — Adds a fixed delay between the trigger condition being met and the ability actually firing. Storm Call does this inherently; this makes it a modifier applicable to any trigger.

  6. Trigger on CC — Fires when the caster applies any crowd control effect. Rewards CC-heavy builds with bonus damage/effects.

  7. Trigger on dodge/evade — Fires when the caster successfully avoids an attack. Defensive trigger that rewards evasion builds.

  8. Accumulation threshold change — Lowers or raises the counter needed for accumulation triggers. "Every 3rd hit" becomes "every 2nd hit." Direct scaling of accumulation-based abilities.

Behavior mods:

  1. Instant → Lingering — Instant ability's effect persists for a brief duration after cast. An instant AoE becomes a short-lived zone. Bridges Instant and Duration behaviors.

  2. Duration → Permanent — Removes the duration cap; effect persists until killed or cancelled. Blade Vortex lasting forever would be absurd — which is exactly why this is interesting as a rare/powerful modifier.

  3. Channelled → Set-and-forget — Channel becomes a fire-and-forget duration ability. You cast it, it channels itself. Frees the caster to do other things. Major playstyle shift.

  4. Duration extended on hit — Each time the ability deals damage, its remaining duration is refreshed or extended. Rewards aggressive play — the ability stays up as long as you keep hitting things.

  5. Duration extended on kill — Similar but on kill. Less frequent extension but bigger reward per event. Encourages chaining kills to maintain uptime.

  6. Instant → Delayed — Adds a delay between cast and effect. Like Storm Call as a modifier. Delay could come with a damage/area bonus to compensate.

  7. Single → Stacking recast — Recasting the ability adds a stack instead of refreshing. Each stack increases the effect. Creates a "ramp up" pattern over multiple casts.

  8. Channelled → Pulsing — Instead of continuous effect while channelled, the channel emits periodic pulses with gaps between them. Each pulse is stronger than the continuous version would be per tick. Trades consistency for burst-per-tick.

Effect mods:

  1. Add lifesteal on hit — Portion of damage dealt is returned as healing to the caster. The universal sustain modifier.

  2. Add shield on hit — Hits grant a temporary shield to the caster. Unlike lifesteal, shields stack and have their own duration. Rewards rapid hits.

  3. Add resource on hit — Hits restore mana/energy/cooldown to the caster. Sustains ability usage — hitting things lets you cast more.

  4. Damage → Heal (ally conversion) — Offensive ability becomes a healing ability when it hits allies instead of enemies. Single ability, dual purpose based on target. Like Targeted Any but as a modifier.

  5. Add stacking debuff — Each hit on the same target increases the debuff intensity. First hit: 5% slow. Second: 10%. Third: 15%. Rewards focusing fire on one target.

  6. Add damage sharing (linked) — A percentage of damage dealt to any affected target is also dealt to all other affected targets. If you hit 3 enemies with debuff, hitting one damages all three.

  7. Add chain reaction on kill — If the ability kills a target, the effect (or a portion of it) automatically applies to a nearby enemy. Kill-propagation without being a full Chain carrier.

  8. Add conditional bonus — Effect has a bonus if a condition is met at time of hit. "Deal 50% more damage to slowed enemies." Encourages combining abilities.

  9. Effect → Delayed detonation — Damage/effect doesn't apply immediately; instead it accumulates on the target and resolves all at once after a delay. Zed R mark as a modifier. Massive burst potential.

  10. Add friendly fire — Ability can hit allies (or the caster) in addition to enemies. Dangerous modifier that could be a downside or used creatively with damage→heal conversion.

  11. Status spread on death — When a target with debuffs/DoTs from this ability dies, those effects spread to nearby enemies. Plague-like propagation.

  12. Add damage-to-self on cast — Each cast hurts the caster. Powerful ability with a health cost. Like Lifetap but as lost HP rather than replaced mana cost.

Targeting mods:

  1. Aimed direction → Auto-target nearest — Removes aiming; ability automatically fires at the nearest valid target. Reduces skill expression but increases consistency. Think auto-attack vs. skillshot.

  2. Aimed point → Random point in range — Removes precise targeting; ability lands at a random location within range. Higher variance, potentially wider coverage.

  3. Targeted enemy → AoE around target — Point-and-click single-target becomes an AoE centered on the clicked target. Like Single-target → Splash but for targeted (non-melee) abilities.

  4. Self → Targeted ally — Self-buff becomes castable on an ally instead. Righteous Fire on an ally? Blade Vortex on a summon?

  5. Single-target → Multi-target — Ability that targets one enemy now targets N enemies simultaneously. Like chain but without the sequential hop — all hit at once.

  6. Add secondary target — Primary effect on the targeted entity, weaker secondary effect on enemies near the target. Built-in splash without changing the carrier.

  7. Aimed → Reversed (backward fire) — Ability fires in the opposite direction from aim. Strange alone, composes with movement abilities (dash forward, fire backward) or with clone firing.

  8. Self → At cursor — Self-centered effect instead originates at the cursor position. Cyclone at a distance. Blade Vortex at the aimed point.

  9. Global → Zone-limited — Global effect is restricted to an area but with increased power within that area. Trades guaranteed-hit-everything for concentrated force.

Cross-carrier mods (change one carrier into another):

  1. Projectile → Zone on expire — Projectile that doesn't hit anything becomes a zone at its max range. Failed shots still contribute area denial. Already partially captured by "Projectile → Lingering" (#12) but this is specifically on miss/expire, not always.

  2. Area → Projectile (shrapnel) — AoE burst also fires projectiles outward from the detonation point. Area that feeds into the projectile ecosystem. Fireball kinda does this implicitly.

  3. Melee → Projectile on hit — Each melee hit releases a projectile. Bridges melee into the ranged modifier ecosystem. Titanic Hydra wave in LoL.

  4. Beam → Zone at terminus — Beam creates a damaging zone at whatever point it stops (max range or wall). Sustained aim = sustained zone.

  5. Summon → On-death zone — When summons die, they leave a zone on the ground. Death becomes area denial. Composes with sacrificial summon mod.

  6. Chain → Projectile per hop — Each chain hop spawns an additional projectile in a random direction. Chain becomes a projectile-spawning engine.

  7. Orbit → Zone on detach — When orbital entities expire or are detached, they become zones at their current position. Orbit "seeds" zones around the caster.

1, 2, 3, 4

  1. There's Volley from Path of Exile which is like LMP/GMP, except the projectiles are parallel to each other in numbers of 3, 5. We should have similar distinction here. And then what you called Volley here should be Burst instead.

  2. Isn't shotgun the opposite of what you described? Starts in a point and diverges? Unless that's already described and you're trying to describe a Reverse Shotgun, but then it should be named that.

7

  1. Phasing should be friendlies, enemies, terrain, walls, etc. Related to this, some games might benefit from a Warping modifier which allows the projectile to warp across the screen.

9, 10, 11, 12

  1. We could have a LMP/GMP/Volley that also applies to beams, orbits and any others where it makes sense. So we could have individual modifiers for each, but also these more general ones that would be more valuable.

14, 15, 16. Same as mentioned in 13 applies to the fork/chain/etc that applies to beams and projectiles.

18

Important thing about beams, you mentioned how the projectile pathing options don't apply to them, but they do. In Isaac Brimstone pathing modifiers are a common source of fun, they use Bezier curves to make it work.

19

  1. "on command" should have a way of being linked/modified further by things like "when damage taken" and other types of triggers. This implies a modifier -> modifier type of thing too, I guess?

21, 22, 23, 24, 25, 26, 27, 29, 30, 31, 32, 33, 34, 35, 36, 37

38, 39 - these should be general area modifiers, I believe the first even is a PoE elementalist node, or something like that.

41, 42, 43, 44, 45, 46, 47

A few other tether options: pull tethered enemies towards position, detonate tethered enemies, tethered enemies share damage/debuffs

48, 49, 50, 51, 52, 53, 54, 55, 56, 57

48, 52 -- note how much "detonate" appears across the modifiers, this goes back to what i mentioned earlier, where there are a few hooks for modifier -> modifier types. Liek if we were imagining PoE links, we could imagine Summon Skeleton -> Cast on Death -> Detonate, right? So these meta modifiers like Cast on Death, When Damage Taken, and various others, can act as bridges that allow for more specificity. After I finish doing the analysis on all modifiers, run one of your own with special attention for these kinds of modifiers. For every modifier we have, think, could this be made more modular with other "meta/trigger" modifiers like Cast on X? Or other types of meta modifiers I haven't imagined, because "Cast on" might not be the only one that fits. The same idea applies to 56, for instance, doesn't have to be an aftershock, could be anything, Teleport -> Cast on Movement -> Earthquake and then cast on movement can be like when damage taken, where every distance covered it goes up and casts after some distance has been covered. if you have low level cast on movement, youll trigger many spells as you move, but for a long range teleport you want max level so that once the teleport goes off you cast the linked spell at maximum potency, makes sense? Try to think of many things like that.

58 - this can be collapse into area modifiers

59 - this can be collapsed into duration omdifiers

60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75

77, 78, 79, 81, , 82, 83, 84

85, 86, 87, 88, 89, 90, 91, 92

95 - previous two can be collapsed here 97, 98 - collapsed by tether, 99, 100, 101, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113

115, 116, 117, 118, 119, 120

Rememebr what I said, a lot of these can be simplified by assuming we have trigger modifiers, or that we have a more general modifier that applies to multiple things, for instance, 117, 120 are the same thing essentially, just with different carriers. Any numbers I mentioned should go into the document, unless I explicitly say that can be collapsed into something else. And then you may decide to collapse any numbers I mention if you find a way to express that in more general terms. Make sure that your general modifier modifiers also take into account the modifiers that are already in the document and not only the new ones you generated.

If you have any questions before proceeding please ask

Before I update the document, let me present the meta-modifier analysis you asked for — the "Cast on X" and other bridge patterns.

Meta-Modifier Analysis: Trigger Bridges

Looking at every modifier (existing + new), many specific modifiers decompose into two independent pieces: a trigger condition and a payload. If we make these composable, a small set of bridges replaces dozens of hardcoded modifiers.

Identified trigger bridges:

Cast on Hit — When the carrier hits a target, fire linked effect at hit location

Cast on Expire — When the carrier reaches end of life (max range, duration end)

Cast on Death — When a carrier entity is destroyed prematurely (killed by enemies)

Detonate — Manual trigger that consumes a carrier for burst

Cast on Movement — When caster covers X distance, fire linked effect

Cast on Transition — When a carrier changes state (channel ends, tether breaks, toggle off)

Cast on Kill — Already exists as a trigger (On-kill), but as a bridge it's: when THIS ability kills → fire linked effect

Which EXISTING modifiers also decompose:

What DOESN'T decompose into bridges:

The big design implication: If you implement trigger bridges as a first-class concept, then many "specific" modifiers become compositions. Summon → Cast on Death → Explode replaces "Sacrificial Summon." Projectile → Cast on Expire → Zone replaces "Lingering Projectile." You get the specific modifiers for free, PLUS combinations nobody designed: Tether → Cast on Transition (break) → Nova projectiles. Zone → Cast on Expire → Summon. Beam → Cast on Hit → Attached Brand. The combinatorial explosion is exactly what ORBS wants.

Now let me update the document with everything — all approved modifiers, generalizations, the trigger bridge section, and the targeting modifiers.

Write (E:\a327ex\Orblike\orbs\ability_design_reference.md)

The file E:\a327ex\Orblike\orbs\ability_design_reference.md has been updated successfully.

Bash (~/bin/neovim.exe "E:/a327ex/Orblike/orbs/ability_design_reference.md" -- -c "Mar...)

Done. Here's a summary of what changed:

New sections:

Carrier Modifiers restructured into sub-categories:

Hit Behavior Modifiers expanded from 10 to 22 — added mark, absorb, diminishing pierce, accelerating bounce, forking/return/priority/increasing/decreasing/expanding chain, beam forking, split on expire

Trigger Modifiers expanded from 5 to 12 — added on-ability-use, periodic, on-hit→on-kill, trigger delay, trigger on CC, trigger on dodge, accumulation threshold

Behavior Modifiers expanded from 4 to 12 — added lingering, permanent, set-and-forget, duration-on-hit/kill, delayed, stacking recast, pulsing channel

Effect Modifiers expanded from 10 to 18 — added resource-on-hit, stacking debuff, damage sharing, chain reaction, conditional bonus, delayed detonation, status spread, damage-to-self

Design Checklist item 9 added: Bridge potential

Let's look at PoE 1 + PoE 2 + Noita for extra meta modifiers that we might have missed.

Let me think through each game's meta-modifier systems carefully.

Task (Research Noita wand meta-modifiers)

[
  {
    "type": "text",
    "text": "The reference document has been written to `E:/a327ex/reference/noita-wand-composition-system.md` and opened in NeoVim with MarkdownPreview.\n\nHere is the complete breakdown of every meta-modifier pattern I found:\n\n---\n\n## The Foundational Data Model\n\nBefore anything else: spells do not modify other spells. They all modify a **shot state** \u2014 a property bag (damage, spread, cast delay, projectile list, etc.). All projectiles spawned in one casting block share a shot state and inherit all accumulated modifications. This is the core of why modifier stacking works at all.\n\nThe wand operates like a card game: **Deck \u2192 Hand \u2192 Discard**. The **draw counter** is what creates chains \u2014 modifiers draw one more spell, multicasts draw N more, triggers draw their payload count. When the Deck empties and a draw is attempted, **wrapping** occurs: Discard \u2192 Deck, cast continues. This forces a reload after completion (unless Wand Refresh triggered the wrap).\n\n---\n\n## Pattern 1: Modifier Accumulation\n\nModifiers accumulate into the shot state. Multiple modifiers before a multicast all apply to all projectiles in that multicast for the price of one draw each. The modifier chain terminates when it reaches a projectile (the first non-modifier, non-multicast spell).\n\n## Pattern 2: Multicast \u2014 Grouping\n\nDouble/Triple/Quadruple Cast expand the draw count for a single shot state. Multicasts can nest: `Triple Cast \u2192 Double Cast` draws 5 spells total into one block. The wand's Spells/Cast stat is functionally an invisible multicast at position zero.\n\n## Pattern 3: Formation \u2014 Spatial Arrangement\n\nFormation spells are multicasts that distribute projectiles at fixed evenly-spaced angular intervals over a predetermined arc (deterministic, unlike scatter). Key: when multiple formations appear in one cast, **the last one evaluated wins** \u2014 its arc overrides earlier ones. Behind Your Back (180\u00b0), Pentagon (180\u00b0/5), Hexagon (180\u00b0/6), Bifurcated (90\u00b0/2), Trifurcated (40\u00b0/3), Above and Below (90\u00b0/3). They share the internal `shot_pattern_angle` variable with Divide By spells.\n\n## Pattern 4: Triggers \u2014 Projectiles as Miniature Wands\n\nA trigger packages subsequent drawn spells as a payload in an isolated shot state. Three trigger types: **On-Hit** (fires on collision), **Timer** (fires after interval, also fires on hit), **Expiration/Death Trigger** (fires when lifetime expires from any cause, or when destroyed by Spells to Power/Explosive Detonator).\n\nCritical: the payload's shot state is completely isolated. Modifiers outside the trigger don't affect the payload; modifiers inside don't affect the trigger carrier. Cast delay inside the payload is ignored. Recharge time modifications inside the payload DO stack globally.\n\nThe placement boundary is everything: modifiers before the trigger modify the carrier projectile; spells inside the payload affect the delivered spell. You can independently customize how the trigger flies and what it delivers.\n\n**Expiration triggers** ignore cast delay for their contained spells, making them useful for zero-delay delivery.\n\n## Pattern 5: Add Trigger Series \u2014 Retrofitting Triggers\n\nAdd Trigger/Add Timer/Add Expiration Trigger do a two-pass deck scan: first find a target projectile (discard everything up to it), then find a payload projectile (attach it as trigger payload). Any modifiers between Add Trigger and the target are called **for free** (no mana) because Add Trigger disables draw on them before calling them. The base projectile inherits none of the original spell's cast delay, recharge time, or mana cost.\n\n## Pattern 6: Divide By \u2014 N Copies of Next Spell\n\nDivide By 2/3/4/10 copy the next spell N times instead of casting it once. All set `shot_pattern_angle` to 5 degrees (10-degree distribution arc). Divide chains work by incrementing an iteration counter \u2014 when a Divide copies another Divide, it targets the Nth card in the deck. The root Divide handles the final discard. Chains are capped at 800 copies. Divide By spells are NOT marked recursive, so they don't increment the recursion level.\n\n## Pattern 7: Greek Letter Spells \u2014 Position and Category-Based Copying\n\nAll Greek spells ignore mana drain and charges of copied spells (enabling infinite copies of limited-use spells):\n\n- **Alpha**: copies first spell in wand (cannot cross Wand Refresh)\n- **Gamma**: copies last spell in deck (or last in hand if deck empty)\n- **Tau**: copies the two spells directly after it (memorizes them, calls them; no special cases)\n- **Mu**: copies every modifier-type spell in the wand\n- **Phi**: copies every projectile-type spell in the wand\n- **Sigma**: copies every static projectile in the wand\n- **Zeta**: copies a random spell from another held wand (cross-wand composition)\n- **Omega**: copies every spell in the wand (scans discard \u2192 hand \u2192 deck, skips Wand Refresh)\n\nPhi/Sigma/Mu save and restore cast delay, recharge time, and mana around their scan (so their call doesn't leak timing side effects). Sigma and Mu draw an extra spell after execution.\n\n## Pattern 8: Wand Refresh \u2014 Infinite Cast Enabler\n\nResets the deck without triggering recharge. Enables infinite casting of limited-charge spells (charges don't decrement on refreshed draws). Partitions wands into active and storage sections (spells after Wand Refresh never fire). Casting it exactly once per cycle bypasses recharge; casting it twice forces normal recharge.\n\n## Pattern 9: Chainsaw \u2014 Cast Delay Zeroing\n\nSets cast delay to **exactly zero** at evaluation time \u2014 not a subtraction, a hard zero. Only affects delay accumulated before it in the same sequence. Spells after it can re-add delay from zero. Also reduces Recharge Time by 0.17s per instance. If delay was already below zero from Nolla/other reducers, Chainsaw paradoxically increases it.\n\n## Pattern 10: Lifetime Modifiers \u2014 Controlling Expiration Timing\n\nLifetime is an additive property. The magic number is exactly **-1** = infinite lifetime (a wisp). Below -1 = single frame. Above 0 = normal duration. This makes lifetime modifiers precision tools for timing expiration triggers. Delayed Spellcast (100-frame lifetime) + Expiration Trigger = 1.67-second delayed spell delivery.\n\n## Pattern 11: Terrain Interaction \u2014 Drilling vs Phasing vs Bouncing\n\nThree distinct terrain-relationship properties that compose differently:\n\n- **Drilling**: passes through terrain, carves path, disables bouncing, high cost\n- **Phasing**: teleports past terrain in jumps (every 12 frames), stacks linearly, adds lifetime\n- **Bouncing**: reflects off terrain instead of colliding; trigger projectiles still only fire payload once even while bouncing\n\nAlso: **Piercing** (Piercing Shot modifier) = hits same entity multiple times. **Penetrating** (intrinsic to specific spells) = hits multiple entities but only once each. Only Piercing enables trigger loops.\n\n## Pattern 12: Mana as Composable Resource\n\nAdd Mana (negative mana cost) replenishes the pool mid-cast. Mana can exceed max cap during casting; it's recapped at cast start. **Mana to Damage** converts current mana level into bonus damage \u2014 mana regeneration rate directly scales weapon output.\n\n## Pattern 13: Spells to Power \u2014 Projectile Absorption as Amplification\n\nStP absorbs nearby caster-owned projectiles and converts their damage into additive bonuses on the absorbing projectile. Multiple StP instances multiply damage absorbed from the same \"food\" projectile. Anti-loop tag prevents self-referential absorption, except via Tentacle (which enables exponential scaling via tag transfer).\n\n## Pattern 14: Passive Spells \u2014 Extra Draw at End\n\n5 passive-type spells each add one extra draw. At the wand's end, this extra draw is against an empty deck, triggering wrapping \u2014 re-reading the wand from start mid-cast.\n\n## Pattern 15: Spell Duplication \u2014 Clone the Hand\n\nDuplicates all spells currently in the Hand at evaluation time (excluding other Spell Duplication instances). Memorizes hand size at start so newly drawn spells during duplication don't get duplicated again. Behaves as an N-multicast if N modifiers are in the Hand when it fires.\n\n## Pattern 16: Trigger Loops \u2014 Self-Sustaining Payload Cycles\n\nPiercing trigger projectile + a hittable payload projectile = closed loop. Trigger hits payload \u2192 fires payload \u2192 new hittable projectile appears \u2192 trigger hits it again \u2192 infinite cycle until trigger expires. 1 projectile/cycle = stable loop; 2+/cycle = exponential growth (crash risk). Speed = trigger's `damage_every_x_frames` (default: 60 activations/sec).\n\n## Pattern 17: Wrapping \u2014 Multiple Wand Passes\n\nWhen any draw attempt hits an empty Deck, the Discard moves to the Deck and the cast continues from the start (forces reload after cast, unless Wand Refresh caused it). Powers modifier recycling (modifier at wand end wraps and applies to spells at wand start) and the Add Trigger multi-modifier exploit (Add Trigger reads modifiers a second time for free on wrap).\n\n## Pattern 18: Always Cast \u2014 Per-Cast Injection\n\nRare wand property. Injects specified spells into every manually-fired cast for free (zero mana, infinite charges). Effectively pre-loads every cast with those effects.\n\n## Pattern 19: Extra Modifiers \u2014 Perk-Based Multiplicative Injection\n\nPerk-granted effects inserted into every projectile-type spell evaluation. Unlike slot modifiers (apply once to shot state), extra modifiers apply once per projectile in a multicast \u2014 N projectiles = N\u00d7 bonus. Bypassable by casting projectiles via Greek copies instead of directly.\n\n## Pattern 20: Velocity \u2192 Damage Conversion\n\nFive spells (Bouncing Burst, Arrow, Disc Projectile, Energy Sphere, Infestation) scale damage with velocity squared. Heavy Shot + Accelerating Shot = projectile accelerates over time to 200\u00d7 damage multiplier at extreme velocity.\n\n## Pattern 21: Path Modifiers \u2014 Trajectory Composition\n\nOrbiting Arc (circular), Ping-Pong (oscillating), Spiral (expanding), Phasing Arc (teleporting), Boomerang (return curve), True Orbit (fixed-distance orbit). Compose with homing (homing force overrides circular paths at close range), with lifetime (most add lifetime, enabling longer-range use), and with trigger placement (Orbiting Arc enables stationary trigger loops).\n\n## Pattern 22: Recursion System \u2014 Self-Reference Limits\n\nRecursion level increments when recursive spells call other recursive spells. Limit: 2. Greek letters, Spell Duplication, Wand Refresh are recursive. Divide By is NOT recursive (maintains caller level). Used intentionally to stop Greek spells from disrupting Divide chains.\n\n## Pattern 23: Delayed Spellcast \u2014 Fixed 100-Frame Expiration Trigger\n\nCreates an almost-invisible slow projectile with a built-in expiration trigger and precise 100-frame lifetime. Draws **three** payload spells (unusual). Acts as a timing precision tool for deferred spell delivery.\n\n---\n\nThe taxonomy at the end of the document groups all 23 patterns into seven categories: Grouping, Splitting, Sequencing, Reference, Resource-to-Property Conversion, Temporal Manipulation, Spatial Manipulation, and Terrain Relationship.\n\nSources:\n- [Guide: Wand Mechanics - The Noita Wiki](https://noita.wiki.gg/wiki/Guide:_Wand_Mechanics)\n- [Expert Guide: Draw - The Noita Wiki](https://noita.wiki.gg/wiki/Expert_Guide:_Draw)\n- [Expert Guide: Add Trigger Series - The Noita Wiki](https://noita.wiki.gg/wiki/Expert_Guide:_Add_Trigger_Series)\n- [Expert Guide: Divide By Spells - The Noita Wiki](https://noita.wiki.gg/wiki/Expert_Guide:_Divide_By_Spells)\n- [Expert Guide: Calling and Recursion - The Noita Wiki](https://noita.wiki.gg/wiki/Expert_Guide:_Calling_and_Recursion)\n- [Advanced Guide: Introduction to Greek Letter Spells - The Noita Wiki](https://noita.wiki.gg/wiki/Advanced_Guide:_Introduction_to_Greek_Letter_Spells)\n- [Trigger Loop - The Noita Wiki](https://noita.wiki.gg/wiki/Trigger_Loop)\n- [Extra modifiers - The Noita Wiki](https://noita.wiki.gg/wiki/Extra_modifiers)\n- [Piercing and Penetrating - The Noita Wiki](https://noita.wiki.gg/wiki/Piercing_and_Penetrating)"
  },
  {
    "type": "text",
    "text": "agentId: a85b504a3ae9c424c (for resuming to continue this agent's work if needed)\n<usage>total_tokens: 66466\ntool_uses: 57\nduration_ms: 642135</usage>"
  }
]

Excellent research from both agents. Let me synthesize what's genuinely new — meta-modifier patterns we haven't captured. I'll present them numbered so you can filter.

Trigger bridge refinements — ways our existing bridges are too simple:

  1. Trigger accumulation / energy model — Our trigger bridges are binary: condition met → fire. PoE 2 makes them accumulative: trigger events build energy, payload fires when energy reaches threshold. Crucially, the threshold scales with payload cost — linking a heavy spell to Cast on Crit means it fires less often than linking a light spell. The trigger bridge has a RATE parameter. This turns trigger bridges from "on/off" into "how often" decisions.

  2. Invocation (stored trigger release) — Same energy accumulation, but it does NOT auto-fire. Energy stores up, player manually releases as a proportional burst — 500 stored energy with a 100-cost spell = 5 rapid casts. This is a hybrid: accumulation happens passively through a trigger condition, but release is manual. The bridge becomes a capacitor, not a wire.

  3. Cast while Channelling — Continuous trigger that fires linked spells while channelling a DIFFERENT ability. Different from our "Cast on Ability Use" (which fires once per cast) — this fires repeatedly throughout the entire channel duration. Channel Ability A → repeatedly triggers Ability B. Creates a "primary + secondary" rhythm.

  4. Cast on Entity Death — Our "Cast on Death" is when the ability holder dies. PoE 2 has Cast on Minion Death — triggers when an OWNED entity dies (summon, deployable). The trigger source is a different entity than the caster. Generalizes to: Cast on [owned entity event]. This connects the Summon carrier ecosystem to the trigger bridge ecosystem.

  5. Timer trigger (during lifetime) — Noita has Timer triggers that fire payload after N seconds while the carrier CONTINUES EXISTING. Different from Cast on Expire where the carrier dies. Timer fires, carrier keeps going, timer can fire again. This creates a carrier that periodically spawns payloads along its flight path. A projectile with a 0.5s timer that fires explosions becomes a flying bomber.

  6. Filtered triggers — Trigger bridge only accepts specific payload types. PoE 1's Mjolnir: "Cast on Hit, but only lightning spells." Cospri's: "Cast on Crit, but only cold spells." The bridge has a FILTER parameter that restricts what can be linked. This creates build constraints that force thematic coherence.

  7. Proximity-based cross-ability trigger — PoE 2's Orb of Storms fires a bolt whenever you cast ANY spell within its radius. No explicit linking — the spatial relationship IS the composition mechanism. Cast a deployed entity, then cast other spells near it, and the deployed entity reacts. Implicit linking through space rather than explicit linking through slots.

Cross-ability composition — abilities that modify or interact with OTHER abilities:

  1. Cross-ability targeting — Ability A's carriers become Ability B's cast locations. PoE 1's Ice Nova on Frostbolt: if Frostbolts exist, Ice Nova casts centered on EACH Frostbolt instead of on the caster. One ability's carriers become another ability's targeting points. This is a targeting modifier we completely missed: "Self → At each instance of another ability's carrier."

  2. Exert / Charge buffering — PoE 2's Warcries store a modifier that is consumed by the NEXT N attacks. Use Warcry A, your next 5 melee attacks gain fire damage. Multiple Warcries can stack on the same future attack. This is time-shifted cross-ability composition — the modifier is applied NOW but consumed LATER. A temporal buffer between abilities.

  3. Shared state / Charges as communication — Abilities communicate through shared resources. Ability A generates Power Charges on crit; Ability B consumes Power Charges for bonus projectiles. Charges are a shared communication channel between otherwise independent abilities. No explicit linking — they communicate through the shared state. Any ability that generates charges implicitly powers any ability that consumes them.

  4. Resource reservation as trigger enabler — PoE 2's Spirit system: pay a permanent resource reservation to enable automatic triggers. You don't spend Spirit per cast — you permanently reserve it. The more trigger bridges you want active simultaneously, the more Spirit you need. This creates a meta-resource that gates how many bridge chains can be active at once.

Grouping, arrangement, and splitting — ways to compose GROUPS of abilities:

  1. Multicast (group different abilities) — Fire N DIFFERENT abilities simultaneously. Noita's Double/Triple/Quad Cast. Different from our "Single → Multi" which duplicates ONE ability. Multicast fires Fireball AND Ice Nova AND Lightning Bolt in one action. All share one modifier state — a speed modifier before the multicast applies to all three. Multicasts can NEST: Triple Cast → Double Cast = 5 abilities in one shot.

  2. Formation — Spatial arrangement of a multicasted group. Noita's formation spells: Pentagon, Hexagon, Bifurcated, Trifurcated, Behind Your Back. Instead of all N abilities firing in the same direction, they're distributed in fixed angular patterns. This is a spatial meta-modifier that applies to the GROUP, not individual abilities.

  3. Divide (split with conservation) — N copies of the next ability at 1/N power each, with a fixed spread angle. Total damage conserved. Different from Multi (fan) which MULTIPLIES damage. Divide is "same total damage, more instances" — better with on-hit effects, worse for raw damage. Divide can chain: Divide By 3 → Divide By 3 = 9 copies. Capped to prevent exponential explosion (Noita caps at 800).

Composition mechanics — how modifier chains are structured:

  1. Trigger carrier independence — In Noita, the trigger spell itself is a full carrier. "Spark Bolt with Trigger" is a spark bolt (with its own speed, damage, lifetime, pathing) that fires a payload on hit. Modifiers BEFORE the trigger modify the carrier; the payload has its own isolated modifier scope. You can make the trigger carrier homing and fast while the payload is slow and exploding. Our trigger bridges are abstract ("Cast on Hit → Area") — this makes the bridge itself a modifiable entity.

  2. Payload isolation / scoping — Modifiers inside a trigger payload are scoped SEPARATELY from modifiers outside. Speed Up before the trigger makes the trigger carrier fast. Speed Up inside the payload makes the payload fast. They don't bleed into each other. This is a SCOPING mechanism that prevents modifier composition from becoming incoherent as chains get deep.

  3. Retrofit trigger — Noita's "Add Trigger" attaches a trigger bridge to an EXISTING carrier after the fact. Instead of the carrier being born as a trigger spell, you take a normal projectile and bolt a trigger onto it. This means any carrier can become a trigger carrier as a modifier, not just specially-designed trigger spells.

  4. Copying by reference — Noita's Greek letter spells copy abilities by position (Alpha = first in sequence, Gamma = last) or by type (Phi = all projectiles, Mu = all modifiers). This creates self-referential compositions. Also: copies ignore the original's mana cost and charges. The pattern: reference another ability and duplicate it, potentially with different modifiers applied.

  5. Always-inject — Certain modifiers are injected into every cast for free. Noita's "Always Cast" wand property adds specific spells to every activation with zero mana cost. A permanent per-cast modifier layer. PoE 2's Elemental Expression (Invoker Monk) does something similar: every melee crit automatically fires elemental spells with no setup.

Resource conversions:

  1. Resource → Damage conversion — Noita's Mana to Damage: current mana level converts directly to bonus damage. Resource management becomes a damage variable — high mana = high damage, so mana regeneration rate becomes a damage stat. PoE 2's Minion Pact is similar: drain minion HP → your damage.

  2. Mana injection (negative cost) — Noita's Add Mana reduces or reverses the cost of the next spell. Stacking enough Add Mana makes a spell free or mana-positive. Resource cost becomes a composable, modifiable axis rather than a fixed property.

Interaction types:

  1. Drilling (destructive phasing) — Noita has three distinct terrain interactions: Bouncing (reflects), Phasing (teleports through), and Drilling (DESTROYS terrain on contact, carving a path). Drilling permanently changes the arena — it's not just passing through, it's removing the obstacle. We have Phasing (terrain) and Bounce (terrain) but not destructive interaction.

  2. Projectile absorption — Noita's "Spells to Power": absorbs nearby friendly projectiles and converts their damage into bonus damage on the absorbing projectile. One ability EATS another ability's carriers for power. A carrier-to-resource-to-damage pipeline.

  3. Velocity → Damage conversion — Some Noita spells scale damage with velocity squared. Speed modifiers become damage multipliers. Accelerating Shot + Heavy Shot = projectile that starts slow but reaches extreme velocity = extreme damage at range. This turns pathing/speed modifiers into damage modifiers through conversion.

Constraints (not modifiers themselves, but rules about how modifiers compose):

  1. One trigger per skill — PoE 2 enforces: if a skill is wired into two trigger bridges simultaneously, it's DISABLED. This prevents degenerate stacking. A design constraint on the composition system itself.

  2. Recursion depth limit — Noita limits self-referential compositions to depth 2. Greek letter spells calling other Greek letter spells stops at 2 levels. Prevents infinite loops while still allowing interesting nesting.

  3. Trigger cooldown — PoE 2 enforces a 0.20 second cooldown between triggered casts, regardless of how fast energy accumulates. This caps the maximum output of any trigger bridge chain.

OK, the main thing I'll say is that I don't like the energy system from PoE 2. Seems like they used it to prevent crazy builds from happening, but my game will be single player so it doesn't matter. Given all this information, both from these games and our previous document, I want you to try to come up with a single system (like gems in PoE, but likely something else) that captures the full extent of possibilities. You may decide to update the old document with the new findings from these games first, but I suspect that figuring out the system first, and then updating the old document to match the new system will be more fruitful, however it's your call on how to do it. I'm vague about what the system itself might be because I simply don't know.

Ask me any questions before proceeding.

Let me think through this before asking questions. The research surfaced a lot, but I think the key insights for system design boil down to a few principles:

What the system needs to solve:

  1. Individual ability definition (carrier + trigger + modifiers)
  2. Ability-to-ability composition (trigger bridges, cross-ability targeting)
  3. Modifier scoping (which modifiers affect which abilities)
  4. Meta-modification (modifiers that modify bridges/connections, not just abilities)

What existing systems get wrong (for our purposes):

The core insight I keep coming back to: the composition unit should be something that naturally bundles "what it does" (carrier + modifiers) with "how it connects to other things" (trigger bridges). And the connections between units should themselves be modifiable.

Here's the system idea forming — Orbs as composition nodes:

Since the game literally has orbs orbiting the player, each orb IS an ability. An orb contains:

Orbs connect to other orbs via links. A link defines: "when [event] happens to Orb A, fire Orb B at the event location." Links have a bridge type (Cast on Hit, Cast on Expire, Detonate, etc.) and can themselves have modifiers (multicast, formation, filter, delay).

Example build: Orb 1 (Manual, Projectile, Homing + Multi-fan) └─ Link: Cast on Hit ──→ Orb 2 (Area, Explode + Larger Area) └─ Link: Cast on Kill ──→ Orb 3 (Chain, DoT)

You fire homing fan projectiles. Each hit spawns an explosion. Each explosion kill triggers chain lightning with DoT. Three orbs, two links, clean scoping.

This naturally provides:

Before I go deeper, some questions:

AskUserQuestion 

User has answered your questions: "How many orbs should a player typically manage at once? This sets the complexity budget for the entire system."="5, 7 probably, but this highly depends on how it turns out in testing, don't rely on it too heavily." user notes: 5, 7 probably, but this highly depends on how it turns out in testing, don't rely on it too heavily., "How should orbs, modifiers, and links be acquired during gameplay?"="This doesn't matter now and will be decided later." user notes: This doesn't matter now and will be decided later., "Should links (connections between orbs) be items/objects that players find, or should any orb be freely connectable to any other?"="This doesn't matter, let's focus on just making the system work logically and implementation-wise first. We'll decide constraints based on what feels right on testing. Unless you need to assume some constraints now... but it's hard for me to know what/how they should be without actually having something concrete to play with." user notes: This doesn't matter, let's focus on just making the system work logically and implementation-wise first. We'll decide constraints based on what feels right on testing. Unless you need to assume some constraints now... but it's hard for me to know what/how they should be without actually having something concrete to play with., "The current game has 5 auto-firing attack types. Should abilities be primarily manual (player-aimed) or auto-triggered (fire when conditions met)?"="Should be like most games we analyzed, manual, can be made auto, some may be auto. These are behavior types, right? The system should be able to handle whatever we decide for any individual ability." user notes: Should be like most games we analyzed, manual, can be made auto, some may be auto. These are behavior types, right? The system should be able to handle whatever we decide for any individual ability.. You can now continue with the user's answers in mind.

Good — the user wants the system to be general and implementation-focused, with constraints decided through testing later. Let me write the system design.

This session is being continued from a previous conversation that ran out of context. The summary below covers the earlier portion of the conversation.

Analysis: Let me go through the conversation chronologically:

  1. Session start: This is a continuation from a previous conversation. The summary from the previous conversation explains that the user was working on building the ORBS (Orthogonal Rule Binding System) ability system for Orblike. They had:

    • Created ability_reference.md with ~360 ability descriptions across 5 games (PoE, LoL, Dota 2, Isaac, RoR2)
    • Created ability_design_reference.md with 6 ability tables and modifier reference
    • The document hadn't been opened for review yet

  2. Opening the document: I opened ability_design_reference.md in NeoVim with MarkdownPreview for the user to review.

  3. Testing abilities: User asked to test classifying a "projectile that chains to nearby enemies on hit, chains N times, dies on last hit." I read the full document and classified it using the tables. Key discussion about H1 Consumed + H3 Chain compound hit behavior.

  4. Compositionality discussion: User asked "how might we derive from it practices for generating abilities that increase our compositional ability?" I provided a deep analysis about:

    • The "default template" (T1 Manual, A1 Aimed direction, D1 Projectile, B1 Instant, H1 Consumed, E1 Damage) maximizes modifier surface area
    • The "one deviation sweet spot" — deviate on 1-2 axes for best composability
    • Event multiplication as the engine of builds
    • Compositional poverty signatures

  5. Area compositionality: User asked about areas vs projectiles. I analyzed that areas are inherently less versatile (~70-80% of projectile versatility) but not drastically so. Identified missing area modifiers (cascade, moving, growing, residue, segmented). Key insight: areas compose on temporal/spatial axes while projectiles compose on trajectory/hit-event axes.

  6. Naming and full carrier analysis: User asked for a name for the "fundamental objects" and full analysis of all carriers. I proposed "carrier" as the name and analyzed 17 carriers:

    • Projectile (~46 mods), Zone (~32), Trap (~30), Area (~30), Melee (~27), Orbit (~27), Beam (~27), Chain (~24), Attached (~24), Aura (~24), Targeted (~22), Trail (~20), Tether (~20), Movement (~15), Summon/Deployable (~12 direct, ~40+ inherited), Terrain (~10)

  7. Document update - remove abbreviations: User asked to update the document to:

    • Add carriers table
    • Remove ALL abbreviations (T1, A1, D1, MD1, etc.)
    • Keep carriers, main tables, modifier tables I rewrote the entire ability_design_reference.md with these changes.

  8. Modifier brainstorm: User asked me to "go wild" and create as many new modifiers as possible. I generated 120 numbered modifiers across all categories.

  9. User filtering: User went through all 120 and gave detailed feedback:

    • Approved ~90+ modifiers
    • Specific corrections: #5 should be "Burst" not "Volley", add "Parallel" as separate; #6 should be "Converging" not "Shotgun"; #8 Phasing should cover friendlies/enemies/terrain/walls
    • Key feedback: #13 - LMP/GMP/Volley should be GENERAL across carriers (beams, orbits, etc.)
    • Beams CAN use projectile pathing via Bezier curves (Isaac Brimstone)

    • 20 "on command" should be linkable with triggers → modifier→modifier concept

    • 38, #39 should be general area modifiers, not aura-specific

    • 58 → collapse into area modifiers, #59 → duration modifiers, #93+94 → 95 (resource on hit)

    • Major insight about "Cast on X" meta-modifiers: many specific modifiers decompose into [trigger bridge] → [payload]
    • User asked me to do a separate meta-modifier analysis after updating

  10. Document update with all modifiers: I updated ability_design_reference.md with:

    • Carrier Modifiers restructured into: Count, Pathing, Phasing, Size, carrier-specific sub-sections
    • New Targeting Modifiers section (9 entries)
    • New Meta-Modifiers — Trigger Bridges section (7 bridges + composition examples + decomposition table)
    • All modifier tables expanded significantly
    • Design Checklist expanded to 9 items

  11. PoE 1+2 + Noita research: User asked to look at these games for additional meta-modifiers. I launched two research agents:

    • PoE 2 agent: Found meta gems, energy accumulation system, invocations, Cast on Minion Death, Cast while Channelling, Warcry Exert, charge system, Spirit reservation, proximity-based triggers, Druid form transitions, combo counter
    • Noita agent: Found trigger spells as carriers, multicast, formations, divide, Greek letter spells (copying), timer triggers, payload isolation/scoping, drilling, Spells to Power, Always Cast, lifetime modifiers, trigger loops, wrapping

  12. Synthesized findings: I presented 27 numbered items from the research:

    • Trigger bridge refinements (#1-7): accumulation/energy model, invocation, cast while channelling, cast on entity death, timer trigger, filtered triggers, proximity-based cross-ability trigger
    • Cross-ability composition (#8-11): cross-ability targeting (Ice Nova on Frostbolt), exert/charge buffering, shared state/charges, resource reservation
    • Grouping (#12-14): multicast (different abilities), formation, divide
    • Composition mechanics (#15-19): trigger carrier independence, payload isolation, retrofit trigger, copying by reference, always-inject
    • Resource conversions (#20-21)
    • Interaction types (#22-24): drilling, projectile absorption, velocity→damage conversion
    • Constraints (#25-27)

  13. Questions and system design: I asked 4 questions about orb count, acquisition, links, and activation. User answered:

    • 5-7 orbs, flexible based on testing
    • Acquisition doesn't matter now
    • Constraints don't matter now — focus on logical system
    • Manual primarily, can be made auto

  14. System design document created: I created Orblike/orbs/system_design.md with the full ORBS system design:

    • Orbs as composition nodes (Core, Trigger, Targeting, Behavior, Hit Behavior, Effects, Modifiers)
    • Links between orbs with bridge types and link modifiers
    • Scoping rules (payload isolation, link modifier scope, global modifiers)
    • Activation flow
    • Loop prevention
    • Shared state (charges)
    • Exert (temporal modifier buffering)
    • Mapping to every analyzed game system
    • 7 example builds
    • Open questions

Files created/modified in this session: - E:\a327ex\Orblike\orbs\ability_design_reference.md — rewritten twice (carriers + no abbreviations, then expanded with all modifiers + meta-modifiers) - E:\a327ex\Orblike\orbs\system_design.md — NEW, the ORBS system design - E:\a327ex\reference\poe2-meta-modifier-mechanics.md — created by research agent - E:\a327ex\reference\noita-wand-composition-system.md — created by research agent

No code errors occurred. User corrections were all about design/naming decisions, not bugs.

Summary: 1. Primary Request and Intent: The user is building the ORBS (Orthogonal Rule Binding System) ability system for Orblike, a game using the Anchor engine with SNKRX visual style. The session continues from prior work where ability_reference.md (~360 ability descriptions across 5 games) and ability_design_reference.md (building block tables + modifier reference) were created. In THIS session, the user's goals were: - Review and test the ability design reference by classifying sample abilities - Explore compositionality — what makes abilities prone to interesting builds vs. not - Identify all "carrier" types (the fundamental objects of abilities) and analyze their compositional richness - Update the design reference: add Carriers table, remove ALL abbreviations (T1, MD1, etc.), restructure modifiers - Brainstorm extensive new modifiers, filter them, and add approved ones to the document - Research PoE 1+2 and Noita for meta-modifier patterns (trigger bridges, modifier→modifier composition) - Design a complete composition SYSTEM (like PoE gems but different) that captures the full extent of possibilities

  1. Key Technical Concepts:

    • Carrier: The fundamental game-world object an ability creates (Projectile, Beam, Area, Zone, Aura, Orbit, Trail, Melee, Targeted, Chain, Summon, Deployable, Tether, Attached, Movement, Terrain, Trap — 17 total)
    • Modifier surface area: How many modifiers can meaningfully apply to an ability. Projectile is king (~46), then spatial carriers (~27-32), then targeted/relational (~20-24), then utility (~10-15)
    • The "one deviation" sweet spot: Abilities with 1-2 non-standard axes have maximum build diversity. Standard template = Projectile, Manual, Aimed direction, Instant, Consumed, Damage
    • Event multiplication: Chain/Pierce/Split/Multi multiply hit events, which multiplicatively interact with on-hit triggers
    • Trigger Bridges (Meta-Modifiers): Cast on Hit, Cast on Expire, Cast on Death, Cast on Kill, Detonate, Cast on Movement, Cast on Transition, Timer, Cast at Carrier — composable linkers between abilities
    • Payload isolation: Each ability is its own modifier scope; modifiers don't bleed across linked abilities
    • Parametric vs. Event modifiers: Parametric mods (pathing, count, size) change continuous properties. Event mods (on-hit effects) can decompose into trigger bridges
    • The Orb System: Each orbiting orb IS an ability (Core + Trigger + Targeting + Behavior + Hit Behavior + Effects + Modifiers). Orbs connect via Links (bridge type + link modifiers). No position ordering — composition is a graph.
    • Link modifiers: Multicast, Formation, Divide, Filter, Delay, Accumulation, Invocation — modify the bridge itself
    • Shared State (Charges): Cross-orb communication without direct links
    • Exert (Temporal Modifier Buffering): Orbs that produce temporary modifiers consumed by next N activations of other orbs
    • Beam pathing via Bezier curves: Beams CAN use projectile pathing modifiers (homing, zigzag, etc.) via Bezier curves, as demonstrated by Isaac's Brimstone
    • Cross-ability targeting: One ability's carriers become another's targeting locations (Ice Nova on Frostbolt = "Cast at Carrier" bridge type)
    • PoE 2 findings: Meta gems (Cast on X with energy accumulation), Invocations (stored manual release), Cast while Channelling, Cast on Minion Death, Warcry Exert, charge system, Spirit reservation
    • Noita findings: Trigger spells as independently modifiable carriers, payload isolation via scoping, Timer triggers (carrier persists), Multicast (group different abilities), Divide (N copies at 1/N power), Formations, Greek letter copying, drilling (destructive phasing)

  2. Files and Code Sections:

    • E:\a327ex\Orblike\orbs\ability_design_reference.md

      • The ORBS equivalent of EBB's ATTACK_REFERENCE.md. Rewritten TWICE in this session.
      • First rewrite: Added Carriers table (17 carriers with composability ratings), replaced Delivery table, removed all ID abbreviations, restructured Carrier Modifiers into Projectile/Area-Zone/General sub-sections, added new area mods (cascade, moving, growing, residue), expanded classification examples
      • Second rewrite: Massive expansion. Carrier Modifiers restructured into Count (7), Pathing (14), Phasing (3), Size (4), Zone/Area-specific (10), Orbit-specific (2), Melee-specific (3), Attached-specific (3), Tether-specific (5), Summon/Deployable-specific (3), Terrain-specific (2), Trap-specific (3), Trail-specific (1), General (8). Hit Behavior Modifiers expanded from 10→22. Trigger Modifiers from 5→12. NEW Targeting Modifiers section (9 entries). Behavior Modifiers from 4→12. Effect Modifiers from 10→18. NEW Meta-Modifiers — Trigger Bridges section with 7 bridges, composition examples, decomposition table, and "what does NOT decompose" section. Design Checklist expanded to 9 items.

    • E:\a327ex\Orblike\orbs\system_design.md (NEW — created at end of session)

      • The complete ORBS composition system design
      • Defines: Orb structure (Core, Trigger, Targeting, Behavior, Hit Behavior, Effects, Modifiers), Links (bridge types + link modifiers), Scoping Rules (payload isolation, link modifier scope, global modifiers, inherited modifiers), Activation Flow, Loop Prevention, Shared State (Charges), Exert (Temporal Modifier Buffering)
      • Bridge types: Cast on Hit, Cast on Expire, Cast on Death, Cast on Kill, Detonate, Cast on Movement, Cast on Transition, Timer, Cast at Carrier
      • Link modifiers: Multicast, Formation, Divide, Filter, Delay, Accumulation, Invocation
      • Maps to every analyzed game system (PoE support gems, PoE meta gems, Arcanist Brand, Ice Nova on Frostbolt, PoE 2 Invocation/Exert/Charges, Noita trigger spells/multicast/divide/formations/timer, Isaac items, RoR2 on-hit items, RoR2 Engineer turret)
      • 7 example builds: Homing Bomber, Orbital Detonator, Brand Contagion, Channelled Beam Bomber, Turret Network, Mine Layer, Frostbolt + Ice Nova
      • 7 open questions (cooldown values, link limits, self-links, fan-in, global stacking, charge types, visual representation)

    • E:\a327ex\reference\poe2-meta-modifier-mechanics.md (created by research agent)

      • Detailed PoE 2 meta-modifier mechanics: Meta Gems, Energy accumulation, Invocations, Orchestrator gems, Support triggers, Spirit reservation, Warcry Exert, Charge system, Curse/Mark layer, Druid forms, Proximity triggers, Combo counter, Ascendancy auto-casts

    • E:\a327ex\reference\noita-wand-composition-system.md (created by research agent)

      • Detailed Noita wand composition: 23 patterns including modifier accumulation, multicast/grouping, formations, triggers as miniature wands, Add Trigger series, Divide By, Greek letter spells, Wand Refresh, Chainsaw, lifetime modifiers, terrain interactions, mana as resource, Spells to Power, passive spells, spell duplication, trigger loops, wrapping, Always Cast, extra modifiers, velocity→damage, path modifiers, recursion limits, Delayed Spellcast

    • E:\a327ex\Orblike\orbs\ability_reference.md (not modified this session)

      • ~360 ability descriptions across 5 games, created in previous session

  3. Errors and fixes:

    • No code errors occurred in this session.
    • User corrections were all design/naming decisions:

      • 5 "Volley" should be renamed "Burst (sequential)"; actual PoE "Volley" is "Parallel" (side-by-side projectiles)

      • 6 "Shotgun" is diverging (starts point, spreads); what I described (converging) should be "Converging" or "Reverse Shotgun"

      • 8 Phasing should be expanded to cover friendlies, enemies, terrain, walls separately

      • 13 LMP/GMP should be GENERAL across carrier types (beams, orbits, etc.), not just projectiles

      • Beams CAN use pathing mods via Bezier curves — I initially said they mostly can't

      • 38, #39 (Pulsing, Expanding on kill) should be general area modifiers, not aura-specific

      • 58 (trail wider) → collapse into area modifiers; #59 (trail persistent) → collapse into duration modifiers

      • 93 (lifesteal) + #94 (shield on hit) → collapse into #95 (resource on hit)

      • User rejected PoE 2's energy accumulation system for their game: "I don't like the energy system from PoE 2. Seems like they used it to prevent crazy builds from happening, but my game will be single player so it doesn't matter."

  4. Problem Solving:

    • Solved the "what is the fundamental object of an ability" naming problem → "Carrier"
    • Solved the compositionality measurement problem → modifier surface area counting, axis deviation from standard template
    • Solved the "areas are less composable than projectiles" question → inherently less but gap is smaller than tables suggested; added missing area modifiers
    • Solved the "how do modifiers compose with other modifiers" problem → Meta-Modifiers / Trigger Bridges that decompose specific modifiers into [trigger condition] → [payload]
    • Solved the "what system captures all possibilities" problem → The Orb Graph system where orbs are composition nodes with links as trigger bridges

  5. All user messages:

    • "OK, let's test a few abilities. A projectile that chains to nearby enemies on hit. It chains N times and then once that's done it does on the last enemy hit."
    • "The H1 consumed thing and how it combines with H1 -> H7 is interesting... What we want is that compositional ability. But now that we have the tables, how might we derive from it practices for generating abilities that increase our compositional ability? How can we tell that the abilities we're generating are prone to interesting changes and thus will lead to potentially interesting builds, vs. when they're not?"
    • "What about areas? I can see how projectiles are highly modifiable, but does the same apply to areas or are they inherently less verstabile than projectiles?"
    • "What about beams, summons, single target, and other 'base', uh, what should we even call these, fundamental objects of an ability? Try to come up with a decent name for it and then do this same analysis for them as well. And try to list all the ones that you think apply that I may have not noticed."
    • "OK, let's change the document to take these into account, and also to not use abbreviation for the names of things. SO MD1 or whatever shouldn't be used, because I don't have the table always available to me. Just use the actual name of the thing when talking, so remove all abreviations. So the document should now have carriers, the main tables, the modifier tables."
    • "Go wild and create as many modifiers as you can think of for as many carriers, triggers, etc you can think of. Show them to me here before adding them to the file. Just a flat list with each modifier in a line, explaining what it does, what it affects, etc. Obviously, avoid ones that already exist. After, I'll filter those based on which ones I think are good to add to the file. Prefix each one by a number (1, 2, 3, etc) so I can refer to them easily later."
    • [Long detailed filtering message approving/rejecting/modifying ~120 modifiers, with extensive feedback about meta-modifiers, Cast on X patterns, modifier→modifier composition, general vs specific modifiers, collapsing redundant entries. Key quotes: "these meta modifiers like Cast on Death, When Damage Taken, and various others, can act as bridges that allow for more specificity", "For every modifier we have, think, could this be made more modular with other 'meta/trigger' modifiers like Cast on X?", "a lot of these can be simplified by assuming we have trigger modifiers, or that we have a more general modifier that applies to multiple things"]
    • "Let's look at PoE 1 + PoE 2 + Noita for extra meta modifiers that we might have missed."
    • "OK, the main thing I'll say is that I don't like the energy system from PoE 2. Seems like they used it to prevent crazy builds from happening, but my game will be single player so it doesn't matter. Given all this information, both from these games and our previous document, I want you to try to come up with a single system (like gems in PoE, but likely something else) that captures the full extent of possibilities. You may decide to update the old document with the new findings from these games first, but I suspect that figuring out the system first, and then updating the old document to match the new system will be more fruitful, however it's your call on how to do it. I'm vague about what the system itself might be because I simply don't know. However, the game is named 'Orblike' because it's kind of an exploratory test for me for ToP story 2, which involves the mana leak consuming orbs... And so whatever system you generate, you could try to make it fit into this. However, this is not the primary goal! Focus on making a cool system first, even if it doesn't fit this idea. This is a detail that ultimately doesn't matter much. Ask me any questions before proceeding."
    • [Answers to 4 questions]: "5, 7 probably, but this highly depends on how it turns out in testing, don't rely on it too heavily." / "This doesn't matter now and will be decided later." / "This doesn't matter, let's focus on just making the system work logically and implementation-wise first." / "Should be like most games we analyzed, manual, can be made auto, some may be auto. These are behavior types, right? The system should be able to handle whatever we decide for any individual ability."

  6. Pending Tasks:

    • User has NOT yet reviewed the system_design.md document (just created, not yet opened for them to view)
    • The ability_design_reference.md should be updated with new findings from PoE 2 and Noita research (user noted this but said system design first was more fruitful — now that system is drafted, this update may be next)
    • The system design needs to be reviewed, discussed, and potentially refined before implementation
    • Eventually: implement actual abilities in Orblike using this system

  7. Current Work: I just finished creating E:\a327ex\Orblike\orbs\system_design.md — the complete ORBS composition system design document. This was written in response to the user's request: "I want you to try to come up with a single system (like gems in PoE, but likely something else) that captures the full extent of possibilities." The document defines orbs as composition nodes with cores/triggers/targeting/behavior/hit-behavior/effects/modifiers, links between orbs as trigger bridges, scoping rules, shared state, and maps to every analyzed game system. It includes 7 example builds and 7 open questions. The file was written but I did NOT yet open it in NeoVim with MarkdownPreview for the user to review.

  8. Optional Next Step: Open system_design.md in NeoVim with MarkdownPreview for the user to review, and present a summary of the system design. The user said "I want you to try to come up with a single system" — the system has been drafted and needs their review. Following the established pattern in this conversation (create document → open for review → discuss → iterate), the next step is to open it and let the user read through it.

If you need specific details from before compaction (like exact code snippets, error messages, or content you generated), read the full transcript at: C:\Users\adn.claude\projects\E--a327ex\ee3e2eaa-a459-4dc8-9749-c859da57ef1d.jsonl Please continue the conversation from where we left off without asking the user any further questions. Continue with the last task that you were asked to work on.

I had just finished creating the ORBS system design document. Let me open it for you to review.

Bash (~/bin/neovim.exe E:/a327ex/Orblike/orbs/system_design.md -- -c "MarkdownPreview")

Command running in background with ID: b1ir7crkp. Output is being written to: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\b1ir7crkp.output

The document is open for you. Here's a quick summary of the system design:

The core idea: Each orbiting orb IS an ability. Orbs are composition nodes in a graph — no position ordering, no sequence. Composition comes from how orbs connect to each other.

An orb contains: Core (carrier type), Trigger, Targeting, Behavior, Hit Behavior, Effects, and Modifiers — all drawn from the building block tables in the design reference.

Links are directed connections between orbs: "when [event] happens to Orb A, fire Orb B." Nine bridge types (Cast on Hit, Cast on Expire, Cast on Death, Cast on Kill, Detonate, Cast on Movement, Cast on Transition, Timer, Cast at Carrier). Links have their own modifiers (Multicast, Formation, Divide, Filter, Delay, Accumulation, Invocation).

Scoping rules enforce payload isolation — modifiers on Orb A never bleed into Orb B. Global modifiers (the Isaac/RoR2 item layer) exist outside individual orbs and affect everything matching a condition.

Shared State (charges) lets orbs communicate without direct links. Exert (temporal modifier buffering) lets one orb produce temporary modifiers consumed by the next N activations of any orb.

The document maps every system we analyzed (PoE support gems, PoE meta gems, Arcanist Brand, Ice Nova on Frostbolt, PoE 2 Invocation/Exert/Charges, Noita trigger spells/multicast/divide/formations/timer, Isaac items, RoR2 turrets) to show how this single system captures them all. Seven example builds demonstrate the range, and seven open questions flag things that need testing.

Take your time reading through it — I'm curious what you think, especially about the link system and whether the bridge types feel complete.

The bridge types + link modifiers parts feel the weakest to me. It seems arbitrary why we'd only have those types of bridge types/link modifiers. Couldn't the link modifiers at least be essentially anything? Why have those behaviors there instead of elsewhere? Multicast, for instance, is a modifier itself for normal abilities, like Spell Echo or Multistrike, why have it there? That part of the system feels the weakest to me. It also seems like it's very few Cast On X events, like where's On Damage Taken and various others that I know exist in PoE? What about some that can be derived from other games as well? It seems like a small list, but maybe that's just an impression. In your examples the linked orbs also usually don't have their own activation methods, I think in reality those orbs will also be able to be activated by the player some way. I like most of the rest.

Before diving into further changes to the document, let's discuss remaining issues more.

These are good critiques and I think they point at a structural issue rather than just missing entries. Let me work through each one.

Bridge types — too few, and the boundary feels wrong

You're right that the list is small. Cast when Damage Taken is a glaring omission. But I think the deeper problem is that I'm conflating two different things under "bridge types":

  1. Carrier events — things that happen to another orb's carrier (hit, kill, expire, death, crit, timer). These genuinely need a link because they reference a specific other orb. "When Orb A's carrier hits something → fire Orb B" — you need to know which orb's carrier you're watching.

  2. Player/world events — things that happen to the player or the world (damage taken, movement threshold, low HP, entering a zone). These don't need a link at all. They're just trigger types on the orb itself. "This orb fires when I take damage" doesn't reference any other orb — it's watching the player.

In PoE, Cast when Damage Taken is a support gem on the skill, not a link between two skills. It replaces the skill's normal trigger. That's because it's a player event, not a carrier event. Meanwhile, Cast on Critical Strike genuinely links two skills — skill A crits, skill B fires.

So the fix isn't just "add more bridge types." It's recognizing that player/world events belong in the Trigger table (which already has Manual, Periodic, Passive, etc. — just expand it with On Damage Taken, On Movement, On Low Health, On Stun, etc.). Bridge types should be only the carrier-event connections that inherently reference another orb. That makes the bridge type list feel less arbitrary — it's specifically "events on another orb's carrier," not a grab-bag of everything.

That said, even the carrier-event list should probably be expanded. Missing ones I can think of: On Crit (filtered version of On Hit, but common enough to be worth calling out), On Block/Parry (if those exist), On Pierce (each pierce event), On Chain (each chain hop).

Link modifiers — the arbitrary split

This is the critique I think cuts deepest. You're exactly right about Multicast. Spell Echo in PoE is a support gem on the spell. It makes the spell cast twice whenever it's cast, regardless of how it was triggered. It's not a property of any link between spells. Same with GMP (Formation), same with Volley, etc.

I put them on links because I was thinking "when this link fires, how many times does the target orb fire?" But that's the wrong framing. The right framing is: "when this orb activates (from any source), how does it behave?" Multicast, Formation, Divide — these are all carrier/count modifiers. They already exist in the modifier tables. They don't belong on links.

What's actually link-specific? I think only things that modify the connection itself:

But honestly, even those could be reframed. Filter is really a conditional modifier on the trigger. Delay is a trigger modifier. Accumulation is a trigger modifier.

I think the cleanest design might be: any modifier can be placed on either an orb or a link. The modifier itself is the same — placement determines scope. Multicast on the orb = always multicast. Multicast on a link = multicast only when activated through that specific link. No special "link modifier" category at all.

This eliminates the arbitrary split entirely. The link becomes very simple: bridge type + any modifiers you want to scope to that specific trigger chain.

Linked orbs having their own activation

The system already says "An orb can also receive activations from incoming links, regardless of its own trigger" — but you're right that the examples don't show this, which makes it seem like linked orbs are passive recipients. In reality, every orb should be a fully specified ability. Ice Nova in PoE can be self-cast (centered on you) AND triggered on Frostbolt positions. The link adds an extra activation source, not the only one. The examples should reflect this.

So the structural changes I'm thinking:

  1. Expand the Trigger table with player/world events (On Damage Taken, On Movement Threshold, On Low Health, On Dodge, etc.) — these are orb triggers, not bridge types
  2. Narrow bridge types to specifically carrier-event connections (things that reference another orb's carrier), but expand that list (add On Crit, On Pierce, On Chain, etc.)
  3. Eliminate the "link modifier" category — any modifier can be placed on an orb (always applies) or on a link (scoped to that activation source). Links become: bridge type + optional modifiers
  4. Fix examples to show linked orbs with their own triggers/targeting

Does this direction feel right, or do you see different structural issues I'm missing?

Yes, please update the documents with all these corrections, they all feel right.

Let me re-read both documents to plan the edits carefully.

Read (E:\a327ex\Orblike\orbs\system_design.md)

     1→# ORBS System Design
     2→
     3→The Orb composition system. Each orbiting orb IS an ability. Orbs connect to each other via links, creating trigger chains. Modifiers customize individual orbs. The system has no position-ordering — composition is a graph, not a sequence.
     4→
     5→---
     6→
     7→## The Orb
     8→
     9→An Orb is the fundamental composition unit. It defines one ability.
    10→
    11→An orb contains:
    12→
    13→| Property | What it defines | Values from |
    14→|----------|----------------|-------------|
    15→| Core | The carrier type — what the orb creates in the world | Carriers table (Projectile, Beam, Area, Zone, Chain, Orbit, etc.) |
    16→| Trigger | What activates this orb on its own | Trigger table (Manual, Periodic, On-damage-taken, Passive, etc.) |
    17→| Targeting | How it picks targets when self-triggered | Targeting table (Aimed direction, Auto-target, Self, etc.) |
    18→| Behavior | Temporal pattern | Behavior table (Instant, Duration, Channelled, etc.) |
    19→| Hit Behavior | What happens when the carrier contacts a target | Hit Behavior table (Consumed, Pierce, Chain, Explode, etc.) |
    20→| Effects | What it does to targets | Effect table (Damage, DoT, Slow, Displacement, etc.) |
    21→| Modifiers | Modifications to any of the above | Modifier Reference entries |
    22→
    23→Every entry from the Building Block Tables in the design reference is a possible value for its corresponding orb property. Every entry from the Modifier Reference is a possible modifier.
    24→
    25→An orb can also receive activations from incoming links (see below), regardless of its own trigger.
    26→
    27→---
    28→
    29→## Links
    30→
... [291 more lines]

Read (E:\a327ex\Orblike\orbs\ability_design_reference.md)

     1→# ORBS Ability Design Reference
     2→
     3→High-level building blocks for describing abilities. An ability is defined by choosing a carrier and one entry from each building block table. Some abilities combine multiple entries (noted with +).
     4→
     5→Detailed ability descriptions: `ability_reference.md`
     6→
     7→---
     8→
     9→## Carriers — The fundamental object of the ability
    10→
    11→The carrier is what the ability creates in the game world — the entity or phenomenon that delivers effects to targets. Different carriers have different **modifier surface area**: the number of meaningful ways they can be changed by modifiers. Higher surface means more build diversity potential.
    12→
    13→**Design principle:** The most compositionally rich abilities deviate from "standard" carrier defaults on 1–2 axes while keeping other axes standard. The standard axes are where modifiers attach; the deviation is what gives the ability its identity.
    14→
    15→| Carrier | Description | Composability | Examples |
    16→|---------|-------------|---------------|---------|
    17→| Projectile | Discrete entity traveling through space | Very High — trajectory, count, and hit behavior all independently modifiable | Fireball, Ezreal Q, Sven Storm Hammer |
    18→| Zone | Persistent region at a location, ticks over time | High — tick rate, duration, stacking, spatial mods | Caustic Arrow, Teemo mushroom, Gasoline |
    19→| Trap | Dormant zone that activates on a condition | High — zone properties plus conditional activation layer | Techies mines, PoE traps/mines, Teemo shroom |
    20→| Area | Instant region of effect at a point | High — inherent multi-hit, size/shape/cascade mods | Crystal Nova, Centaur Stomp, Reverse Polarity |
    21→| Melee | Close-range hit or swing | Medium-High — attack speed × on-hit, splash is transformative | Nasus Q, Loader punch, Mercenary Laser Sword |
    22→| Orbit | Entities circling a unit at fixed radius | Medium-High — count × orbit speed, passive offense | Blade Vortex, Sacrificial Dagger, Pretty Fly |
    23→| Beam | Instant or persistent line, no travel time | Medium-High — sweep, tick rate, width/length; pathing via Bezier curves | Brimstone, Lux R, Technology, Railgunner |
    24→| Chain | Effect jumping between nearby targets | Medium — event multiplication, compounds with on-hit | Arc, Chain Frost, Mystic Snake, Ukulele |
    25→| Attached | Effect stuck to a target, pulses autonomously | Medium — tick × chain × duration, fire-and-forget | Storm Brand, Explosivo |
    26→| Aura | Persistent field attached to a unit, moves with it | Medium — movement speed = coverage, "I am the zone" | Righteous Fire, Frost Relic, Blasphemy |
    27→| Targeted | Point-and-click effect, no spatial object | Medium-Low — reliable, composes through effect/trigger only | Doom, Hex, Orchid, Finger of Death |
    28→| Trail | Effect along the caster's movement path | Low-Medium — movement-dependent, narrow but unique | Pencil (EBB), Toxic Trail |
    29→| Tether | Persistent connection between two entities | Low-Medium — relational, conditional, niche | Io Tether, Morgana R Soul Shackles |
    30→| Summon | Autonomous mobile entity | Low direct, Very High inherited — recursively compositional | Raise Zombie, The Backup drones, Happiest Mask |
... [502 more lines]

Good, I have both documents. Let me now work through all the changes. I'll update both documents — system_design.md gets the structural rework (bridge types narrowed + expanded, link modifiers eliminated, examples fixed), and ability_design_reference.md gets the expanded trigger table (player/world events moved there).

Let me start with the system_design.md since it has the biggest structural changes.

Read (E:\a327ex\Orblike\orbs\system_design.md)

     1→# ORBS System Design
     2→
     3→The Orb composition system. Each orbiting orb IS an ability. Orbs connect to each other via links, creating trigger chains. Modifiers customize individual orbs. The system has no position-ordering — composition is a graph, not a sequence.
     4→
     5→---
     6→
     7→## The Orb
     8→
     9→An Orb is the fundamental composition unit. It defines one ability.
    10→
    11→An orb contains:
    12→
    13→| Property | What it defines | Values from |
    14→|----------|----------------|-------------|
    15→| Core | The carrier type — what the orb creates in the world | Carriers table (Projectile, Beam, Area, Zone, Chain, Orbit, etc.) |
    16→| Trigger | What activates this orb on its own | Trigger table (Manual, Periodic, On-damage-taken, Passive, etc.) |
    17→| Targeting | How it picks targets when self-triggered | Targeting table (Aimed direction, Auto-target, Self, etc.) |
    18→| Behavior | Temporal pattern | Behavior table (Instant, Duration, Channelled, etc.) |
    19→| Hit Behavior | What happens when the carrier contacts a target | Hit Behavior table (Consumed, Pierce, Chain, Explode, etc.) |
    20→| Effects | What it does to targets | Effect table (Damage, DoT, Slow, Displacement, etc.) |
    21→| Modifiers | Modifications to any of the above | Modifier Reference entries |
    22→
    23→Every entry from the Building Block Tables in the design reference is a possible value for its corresponding orb property. Every entry from the Modifier Reference is a possible modifier.
    24→
    25→An orb can also receive activations from incoming links (see below), regardless of its own trigger.
    26→
    27→---
    28→
    29→## Links
    30→
... [291 more lines]

Now let me rewrite system_design.md with all the structural changes.

Write (E:\a327ex\Orblike\orbs\system_design.md)

The file E:\a327ex\Orblike\orbs\system_design.md has been updated successfully.

Now let me update the ability_design_reference.md — the main change is expanding the Trigger table with player/world events, and updating the Meta-Modifiers section to reflect the new bridge type list and the unified modifier placement model.

Edit (E:\a327ex\Orblike\orbs\ability_design_reference.md)

The file E:\a327ex\Orblike\orbs\ability_design_reference.md has been updated successfully.

Now update the Meta-Modifiers section to reflect the expanded bridge types and the unified modifier placement model.

Edit (E:\a327ex\Orblike\orbs\ability_design_reference.md)

The file E:\a327ex\Orblike\orbs\ability_design_reference.md has been updated successfully.

Now update the Trigger Modifiers section — "Cast on Movement" was a bridge type but should now be a trigger modifier (or rather, it was already in the trigger table as On-movement). Let me also clean up the trigger modifiers to not duplicate things that are now in the trigger table directly.

Edit (E:\a327ex\Orblike\orbs\ability_design_reference.md)

The file E:\a327ex\Orblike\orbs\ability_design_reference.md has been updated successfully.

Now let me open the updated system design in NeoVim for review.

Bash (~/bin/neovim.exe E:/a327ex/Orblike/orbs/system_design.md -- -c "MarkdownPreview")

Command running in background with ID: byc00hnvt. Output is being written to: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\byc00hnvt.output

Both documents are updated. Here's a summary of all the changes:

system_design.md:

  1. Bridge types narrowed and expanded. Bridge types are now specifically carrier events — things that happen to another orb's carrier. Added Cast on Crit, Cast on Pierce, Cast on Chain, Cast on Bounce. Removed Cast on Movement (moved to trigger table as On-movement threshold). The document explicitly states that player/world events belong in the Trigger table, not as bridge types.

  2. "Link modifiers" section eliminated. Replaced with the unified scoping rule: any modifier can be placed on an orb (always applies) or on a link (scoped to that link's activations). The Scoping Rules section now has a table showing how the same modifier behaves differently depending on placement. Multicast, Formation, Divide are no longer a special link-only category.

  3. All example builds now show fully-specified orbs. Every linked orb has its own trigger, targeting, and a description of how it works both self-cast and link-triggered. E.g., Build 1's Orb 3 is now "On-damage-taken | Auto-target | Chain" — it independently fires chain lightning when you take damage, AND fires from kill locations when triggered by the link.

  4. New open question #8 about modifier conflicts when both the orb and a link have the same modifier type.

ability_design_reference.md:

  1. Trigger table expanded with player/world events: On-damage-taken (threshold), On-low-health, On-dodge/evade, On-CC, On-movement (threshold). Added explanatory text about the trigger/bridge distinction.

  2. Meta-Modifiers section updated to reflect the new bridge type list (added Cast on Crit, Cast on Pierce, Cast on Chain, Cast on Bounce), the unified modifier placement model, and fixed the decomposition table (Chain → Projectile per hop now uses Cast on Chain, not Cast on Hit).

  3. Trigger Modifiers section simplified — removed entries that are now just trigger types in the main table (On-crit, On-damage-taken, On-CC, On-dodge). Kept structural modifiers like Automatic, Periodic, trigger type swaps, delay, accumulation threshold.

This seems much better, I'm happier with this design. I'm sure there are details to iron out but we'll do so as we move forward with the actual implementation of the system. Thank you.

Glad the structure feels solid now. The unified modifier placement and the trigger/bridge distinction were the right calls — much cleaner than the arbitrary split. Good luck with the implementation, and we can iron out the open questions (cooldowns, link limits, self-links, etc.) as you hit them in practice.

<task-notification> <task-id>byc00hnvt</task-id> <tool-use-id>toolu_014uAbezwY7a1pq8ZdZJMYRi</tool-use-id> <output-file>C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\byc00hnvt.output</output-file> completed

Background command "Open updated system_design.md in NeoVim with MarkdownPreview" completed (exit code 0) </task-notification> Read the output file to retrieve the result: C:\Users\adn\AppData\Local\Temp\claude\E--a327ex\tasks\byc00hnvt.output