a327ex.com

Orblike Design Consolidation

Summary

Pure-design session (no code). Reviewed Orblike's accumulated design docs, ran two rounds of design-clarification Q&A, dropped procgen map terrain in favor of small hand-laid maps, then consolidated the design into two clean working docs (design.md, plan.md) at the project root and archived superseded reference material.

Doc audit / starting state:

User's redesign vision (stated upfront for common ground):

Q&A round 1 (11 numbered + 6 missing-item questions):

Q&A round 2 (4 follow-ups):

Consolidation — wrote two new docs:

Notable explicit choices flagged for user review:

Doc cleanup — archived to reference/archive/:

Reference docs preserved (still load-bearing): tags.md, interactions.md, ability_*.md, SNKRX_*, snkrx_style_effects.md, poe_*.md, mockup HTMLs/PNGs.

Let's take a look at Orblike. Read through the documents to figure out what the current design decisions are. We're going to review them and change the game in this session. There will be no coding, just redesigning the game.

Bash (ls E:/a327ex/Orblike/)

anchor/
anchor.exe*
assets/
design.md
door.lua
main.lua
map.lua
map_generation.lua
maps/
plan.md
plan_beach.md
player.lua
reference/
run.bat
tools/
v1/
wall.lua
wall_flow.lua
wall_palettes.lua
wall_patterns.lua
wall_symbols.lua

Bash (ls E:/a327ex/Orblike/v1/ E:/a327ex/Orblike/reference/ 2>&1 | head -60)

E:/a327ex/Orblike/reference/:
001-No-title/
004/
008 - Antitower [success]/
0567f50c-db16-406f-8f2a-af58755ba13b.png
1111a417-0189-4565-8b76-6edc7a464ba7.png
112020/
1511855f-2003-4392-bfb4-04c1e301f277.png
22c3ec27-cb02-4db1-876e-5bbff8a967fb (1).png
22c3ec27-cb02-4db1-876e-5bbff8a967fb.png
239A5-P60B91D/
422f57a7-dc79-49a3-9b49-0277f3747a73.png
4b1746c7-ac48-4dfa-b47e-dcd38fc7a728.png
4d926f55-d4ce-4524-97c9-c36dee6bf659 (1).png
4d926f55-d4ce-4524-97c9-c36dee6bf659 (2).png
4d926f55-d4ce-4524-97c9-c36dee6bf659.png
54d154aa-6064-4b20-9858-faf532f702f5.png
6358a60c-212b-43a0-8d74-5d8426d938c3.png
BUILDRX2/
Balatro/
Rekoyam Tsohg/
SNKRX/
SNKRX_visual_effects_catalog.md
ability_design_reference.md
ability_editions.md
ability_modifier_map.md
ability_reference.md
ai_coding_paradigms.md
anchor_usage_analysis.md
archive/
... [30 more lines]

Bash (wc -l E:/a327ex/Orblike/design.md E:/a327ex/Orblike/plan.md E:/a327ex/Orblike/pl...)

  177 E:/a327ex/Orblike/design.md
  308 E:/a327ex/Orblike/plan.md
  671 E:/a327ex/Orblike/plan_beach.md
  145 E:/a327ex/Orblike/main.lua
 1301 total

Read (E:/a327ex/Orblike/design.md)

1    # Orblike — Design
2   
3   High-level design for the Anchor 2 rewrite. Captures locked-in decisions. Not exhaustive — downstream details (specific items, NPCs, balance numbers) live elsewhere or will emerge during implementation.
4   
5   ---
6   
7   ## Concept
8   
9   A roguelike action RPG built on a PoE-style meta-loop. You play a sigil mage sponsored by the **Psyonian state** to cleanse regions of **null mana** corruption. Between cleansings, you return to a sponsored hideout to re-equip, craft, and plan the next expedition. Die, and everything resets — the state assigns a new mage to the post.
10  
11  The game is designed as a **platform for leagues**: modular map-level mechanics that vary gameplay style (bullet-hell, tower defense, survivors, etc.) while sharing the same hideout/inventory/map shell.
12  
13  ---
14  
15  ## Lore (brief)
16  
17  The Psyonian state sponsors null-mana cleansing. Mages with sigil/orb training are funneled into state-issued hideouts as independent contractors. The hideout is a Psyonian-run waystation: starter gear on loan, staffed NPCs, access to the teleporter network. Other NPCs at the hideout are state-employed support: a logistics/gear officer, a teleporter engineer, etc.
18  
19  Maps are places in the world saturated with null mana. "Map items" are teleporter beacons attuned to a specific place. The goal of a run is to track null mana back to its source and destroy it (the final boss).
20  
21  **Equipment visual identity** (from `reference/lore.md`): floating, robed, masked figure. Sigil glowing overhead. Orbs circling. Hands and feet ringed with magical bands.
22  
23  ---
24  
25  ## Core Loop
26  
27  1. **Spawn on the tutorial beach.** (New game or after death.) PoE-Twilight-Strand-style guided opening that teaches the orb + gem socketing loop. See `plan_beach.md` for the full tutorial spec.
28  2. **Walk through the beach**, picking up a starter orb, a starter ability gem (Fireball), and a support gem (Spread), socketing them, learning combat, and defeating a mini-boss.
29  3. **Step through the exit** → arrive at the hideout.
30  4. **Approach map NPC** → select a map (starter map free from this NPC; others from your inventory).
... [148 more lines]

Read (E:/a327ex/Orblike/plan.md)

1    # Orblike — Implementation Plan
2   
3   Phase-by-phase plan for the Anchor 2 rewrite. See `design.md` for locked-in design decisions this plan implements.
4   
5   **Strategy recap:** Build the high-level shell (hideout, beach tutorial, menus, inventory, orbs UI, map UI, run lifecycle) in Anchor 2 first. Port the combat (arena) from v1 last. The v1 code stays functional at `v1/` for reference and comparison throughout.
6   
7   After Phase 1 (hideout shell, done), the next big chunk of work is **the tutorial beach map** — a PoE-Twilight-Strand-style opening that runs *before* the hideout and teaches the orb + gem socketing loop. The full implementation spec for that work lives in `plan_beach.md` (it replaces what was Phase 2 — UI primitives — in this doc, expanding it to include all the data + UI + combat + tutorial scaffolding needed to ship the beach). Phase 3+ resumes here after `plan_beach.md` ships.
8   
9   **Pacing:** Incremental. Each phase should be testable on its own. User tests and gives feedback between phases. No chaining phases without check-ins.
10  
11  ---
12  
13  ## Phase 0 — Setup (done)
14  
15  - `v1/` holds old game + old framework, runnable via `run-v1.bat`
16  - Root holds v2 starter `main.lua` + v2 framework (`anchor/`), runnable via `run.bat`
17  - Assets duplicated into `v1/assets/` for isolation
18  - Design locked in `design.md`
19  
20  ---
21  
22  ## Phase 1 — Hideout shell (DONE)
23  
24  Player walks around the hideout with camera-follow. Went beyond the
25  original "empty rectangular room" scope — the hideout is now its own
26  thing with a proper visual identity.
27  
28  **What shipped:**
29  - Player movement ported from v1 (collider, WASD input, rotate-to-mouse)
30  - Map polygon pipeline: jagged boundary polygons with distance-field wall
... [279 more lines]

Read (E:/a327ex/Orblike/plan_beach.md)

1    # Orblike — Beach Tutorial Plan
2   
3   Implementation plan for the **opening beach map** that runs before the
4   hideout. PoE Twilight-Strand-style guided tutorial that teaches the
5   orb + gem socketing loop before dropping the player at the hideout.
6   
7   This doc supersedes the "you spawn directly at the hideout" assumption
8   in `design.md` (§ Core Loop). After this map ships, the run start order
9   becomes: **fresh game → beach tutorial → hideout → maps → final boss**.
10  
11  The plan is structured to be implemented straight through, in phase
12  order. Decisions deliberately deferred to implementation time are flagged
13  in **§ Deferred Decisions** at the end so the implementer doesn't burn
14  time looking for specs that aren't there.
15  
16  ---
17  
18  ## Goal
19  
20  Teach the orb + gem composition loop diegetically through play. Player
21  learns, in order:
22  
23  1. **Movement** (WASD — already in).
24  2. **Picking things up** (click ground item → inventory).
25  3. **Equipping an orb** (drag orb from inventory to character's orb slot).
26  4. **Body-contact damage exists as a fallback** (kill first enemy by ramming).
27  5. **Socketing an ability gem** (drag Fireball into orb's active slot).
28  6. **Casting** (LMB at mouse cursor).
29  7. **Socketing a support gem** (drag Spread into orb's other slot).
30  8. **Linked supports modify the active ability** (Fireball now fires 3-spread).
... [642 more lines]

I've read the main design docs. Let me also pull in the orb ability system reference (the core build-depth mechanic) and the lore — those are central to any redesign discussion.

Read (E:/a327ex/Orblike/reference/orblike_ability_system.md)

1    # Orblike Ability System
2   
3   The ability system is a **PoE-clone slot model**. Each orb is an item
4   with a fixed number of socket slots; gems are the resources that go
5   into those slots. An orb's behavior is the composition of the gems
6   socketed in it. Orbs orbit the player; each equipped orb is bound to
7   one input key.
8   
9   This doc supersedes the older "board topology with within-board
10  trigger connections" design. That model — branching, fan-in, loops,
11  within-board connections with their own modifier scopes — has been
12  dropped in favor of the simpler model below. (The previous version
13  lives at `archive/orblike_ability_system_old.md` if needed.)
14  
15  ---
16  
17  ## The Orb
18  
19  An orb is a piece of equipment. It defines:
20  
21  - **A fixed number of socket slots** (typically 2–6, set when the orb is generated).
22  - **Slot types** — each slot has a type. Most slots are `untyped` (accept any gem). Some orbs feature typed slots (e.g., active-only, trigger-only) as a defining characteristic.
23  - **An activation mode** for the orb's active gem (manual / auto / passive).
24  - **An input binding** assigned at equip time (LMB, RMB, MMB, 1-5 in equip order).
25  
26  ```
27  ORB (3 slots)
28  ┌───────────┬───────────┬───────────┐
29  │ untyped   │ untyped   │ untyped   │
30  └───────────┴───────────┴───────────┘
... [380 more lines]

Read (E:/a327ex/Orblike/reference/lore.md)

1    # Orblike Lore
2   
3   This document captures the world's lore as it currently exists, with emphasis on how each piece connects to game systems. Lore is treated as the *source of truth* for mechanics — game rules emerge from how the world works rather than being arbitrary numbers.
4   
5   ---
6   
7   ## The World
8   
9   The world is suffused with **ambient mana** — a base substance that exists everywhere, like air or sunlight. Mages convert ambient mana through their bodies into **personal mana**, which they can then use to cast spells.
10  
11  Some places in the world have been corrupted. Their ambient mana has become **null mana** — broken, unusable by mage bodies. Mages cannot directly process null mana into personal mana. Null mana is dangerous: it can't power normal life or normal magic, and it slowly accumulates in corrupted regions.
12  
13  The protagonist of the game is an **alchemist shopkeeper** who runs an orb shop. He has the rare ability to **copy the properties of any material** he has seen, touched, or analyzed — even once is enough to recreate that material from his own mana. Quantity is never his bottleneck. **Novelty is.** He needs to encounter materials he has never seen before. He commissions adventurers (the player) to venture into dangerous regions and bring back rare or unknown materials, especially from the corrupted null-mana zones.
14  
15  The game's adventuring portion is framed as these commissions. Each map run is a contract from the alchemist to clear out a region and retrieve materials. The endgame fantasy: clean up all the corrupted regions of the world by harvesting null mana through orbs.
16  
17  > **Game system mapping:** The shopkeeper half is future scope (Recettear-style sim). The action combat half is the maps and enemies. The "adventurers harvesting null mana" framing justifies why the player is in dangerous places fighting things, and why orbs exist in the first place.
18  
19  ---
20  
21  ## Mana
22  
23  Three states of mana exist:
24  
25  1. **Ambient mana** — neutral, suffused through the world, the raw substance
26  2. **Personal mana** — refined by a mage's body from ambient mana, unique to each mage like a fingerprint
27  3. **Null mana** — corrupted ambient mana that mage bodies cannot process
28  
29  ### Personal mana is unique
30  
... [211 more lines]

I've read design.md, plan.md, plan_beach.md, the orb ability system reference, and the lore doc. Here's what's locked, where it's at, and the tensions that jump out as natural redesign targets.

Where the project is right now

Shipped: Hideout shell (player movement, jagged-polygon room with side rooms, distance-field wall gradient, 32 wall symbols, distribution patterns, F-key live cycling), memory-tracking overlay (F3/F4/F5).

In progress and stuck: The tutorial beach map. Phase 2G geometry is in code, but the rocks/sea region rendering went through 7 visual iterations without landing. The postmortem at the bottom of plan_beach.md explicitly says: stop iterating on this state, start visual-first next time, or scrap the rocks-tail decoration.

Not started: Everything UI-side (Phase 2A primitives → 2L tutorial), all combat work (Phase 8 — port the 23 v1 abilities), NPCs (Phase 3), map system (Phase 7), leagues (Phase 9).

Locked-in design (current state)

Concept. Roguelike action RPG, PoE meta-loop. Sigil mage sponsored by the Psyonian state, cleansing null mana corruption. Die → everything wipes → new mage. "Platform for leagues" — modular map mechanics (tower defense, survivors, breach, delve…) sharing one shell.

Run length target. ~1 hour initially, scaling to 5–10 hours.

Core loop. Tutorial beach → hideout → pick map at NPC → portal → combat map → return via portal → repeat → final boss. Map items drop from monsters (self-sustaining economy). World map UI, no atlas tree.

Hideout. Walkable space, NPC-gated activities, portals appear after maps. Two NPCs for v1: Gear Officer (vendor) and Teleporter Engineer (map UI).

Equipment. Five slot types — mask, sigil, robe, rings (×4), orbs (×N). Only orbs have a defined mechanic; the other four are TBD.

Orb system (the build-depth engine). Each orb: 2–6 socket slots, mostly untyped. Gems socket in. Three gem kinds — ability (one per orb), support (stacking modifiers), trigger (changes activation mode). 16 carrier types (projectile, beam, area, zone, trap, melee, orbit, aura, chain, tether, attached, summon, deployable, trail, movement). 12 carrier-event triggers + 6 player-event triggers. Cross-orb synergy via shared charges, exert (PoE warcries), and global modifiers from rings/robes.

UI principle. Right side = inventory, left side = action UI, drag-drop everywhere. Inventory is infinite. Full-screen UIs do not pause combat.

Damage model (from lore.md). Three components — physical, magic, null. Flat-subtraction defenses, no percentages. Damage 1–20, defense 0–5. Null bypasses both defenses. Lore-justified by ambient/personal/null mana frequencies.

Run/death. Hard reset, no meta-progression. (Flagged as revisitable.)

Leagues. Not a top-level system — they're map modifiers that override spawn logic / objectives.

Tensions and open questions worth opening up

These are the natural redesign targets — the places where the doc itself flags doubt or where two pieces of the design are pulling against each other.

1. The lore framing has two protagonists and they're not the same. design.md says you play a Psyonian-state-sponsored sigil mage. lore.md says the protagonist is an alchemist shopkeeper who copies materials and commissions adventurers (you) to fetch them. The Recettear-style shop is "future scope" but it's the lore's centerpiece. Either the design.md framing is wrong, or the lore is aspirational and Orblike is just the action half. Worth picking one explicitly.

2. Scope vs. "keep practice projects practice." Your memory notes say not to load Orblike with Psyonia-universe ambition — big-project design goes to Psyonia/. But the current design.md is enormous: PoE meta-loop, 23 abilities, 5 equipment slot types, tag-based support compatibility, charges/exert/global modifiers, atlas-lite map system, leagues as map modifiers (tower defense / survivors / breach / delve), 5–10 hour runs. This is "rebuild PoE." The biggest redesign lever in this whole session is probably how aggressively to cut.

3. PoE complexity vs. roguelike wipe. PoE earns its complexity because your character is permanent — you spend hundreds of hours on one build. Orblike wipes everything on death and targets ~1hr runs. Players will only see a fraction of the orb/gem/trigger/charge/exert space per run. Either runs need to be longer, deaths need to be softer (some meta-progression), or the system needs to be smaller per-run.

4. The beach replays every run. The doc explicitly notes the open question: "replay the beach on every fresh run, or skip after first completion?" Given no meta-progression, currently it replays. That's a 45-second-to-several-minute scripted tutorial every death. PoE's Twilight Strand isn't a roguelike, so the analogy breaks. At minimum, second-and-onward runs probably want a skip.

5. Beach is currently visually blocked. Postmortem suggests two clean paths: (a) scrap the rocks-tail south extensions entirely and let the bay arcs carry the rocks feel, or (b) commit to the tail geometry and make the sea polygon follow it exactly with no inset trickery. Picking one is a session-level redesign decision.

6. Equipment depth is lopsided. Orbs have a deep, fully-specified system. Mask, sigil, robe, rings — four of five slot types — have no defined mechanic. The doc says sigil is "the biggest axis for build diversity," but doesn't say how. Worth either specifying these or admitting they're stat-stick gear and the orb is the only build axis.

7. Right-side HUD orb is undefined. "mana / cooldown / something else" — locked-as-undecided. This is small but real; the action layer needs a resource for orb activations or an explicit "no resource, just cooldowns" decision.

8. Map identity without an atlas. PoE's atlas tree is itself meta-progression — choosing maps matters because completing them unlocks adjacencies. Orblike has "maps appear at random positions on a world map UI" with no connectivity. So why pick map A vs. map B? Tier? Modifiers? Region type? The doc says all three but doesn't show what choosing actually does. Without atlas-style stakes, this can collapse into "click the highest-tier one."

9. Crafting is undesigned but referenced everywhere. Map mods, item mods, orb crafting (add slot / remove slot / convert type / reroll intrinsics) — all TBD as a "unified item-modifier system." That's the third big system after orbs and maps; nothing is specified.

10. The orb composition lost its connection-graph richness. The old design had within-board connections, fan-in, branches, loops. That's archived. Current orb is "PoE-clone slot + gems." Cross-orb synergy now flows entirely through implicit shared systems (charges, exert, global modifiers). That's much simpler — but also means orb-to-orb interaction is invisible to the player until they discover that orb A's charges happen to feed orb B. Worth thinking about whether the simplification went too far for what's an action game (vs. PoE's deep planning meta).

Where do you want to start? My instinct is the scope question (#2/#3) is upstream of most of the others — if Orblike stays "practice project simple" the orb system gets pruned, the beach gets simpler, the lore picks one framing, and several other questions resolve. But you may have a different priority — happy to start anywhere.

I mainly want to drop the idea of maps having their own unique generation and focus on making the game more a single, or 2 screen game where there's not that much variance between maps in terms of layout but the variance comes from gameplay differences instead. Failing to generate the beach map properly showed me that doing proper generation for maps probably would take as much work as it would have taken me to do it manually and it's not worth it. So we'll go with simpler maps. Let's have the goal of this session to also be consolidating the game's design into 1-2 files that are clear, short and to the point, so that future instances aren't confused by all the files they have to read. I'll state everything I know about the game clearly now so we can start from common ground. After, you may ask me questions to see if the design decisions we had already decided on are affirmed, changed, and which things you think are missing that are important to address.

LORE: Orbs are a construct created by Psyonian State to eventually clear the world of null mana pockets. They achieve this by being fueled by null mana itself, allowing the wielder to cast spells they otherwise wouldn't be able to due to not having the required mana themselves. Null mana is converted into the caster's personal mana and then molded for a specific ability by the orb, then the caster casts the spell as though he cast it, but using converted null mana as fuel. This is not going to explicit or matter in gameplay (at least I don't see why it would, but maybe eventually a system might need something like it), it's just for lore purposes. Abilities that are null abilities are cast by the orb itself, instead of the caster, because the caster can't process null mana (null mana hurts living beings in general). The goal of the game is going through various places, killing nearby monsters and then (conceptually, lore-wise), cleaning its pockets of null mana by charging up orbs.

GAMEPLAY: PoE-like map system, each map looks similar layout-wise, with small variations in layout but maybe big ones in environmental gameplay. Mostly just 1-2 screens where enemies constantly spawn in waves. Plays like an ARPG endgame where you have your abilities, kill enemies, get loot, go back to your hideout, repeat.

ORBS: a player can carry orbs, which act like gear in PoE, they have slots where you can slot abilities and create arbitrary combinations of active and passive abilities for high build variety. Orbs each come with their own visual setup in terms of number of sockets, which sockets are linked to which sockets, which sockets only take specific types of abilities, etc. Orbs are drops the player can get from killing monsters.

EQUIPMENT: On top of orbs we have mask, robe, rings, sigil. The first three are for further build variety, the last one relates to orbs directly. It's the equipment that, lore-wise, serves as the coordinator between caster and his orbs, aiding communication and mana transfer between both. This item is the one that can have effects that apply to all orbs simultaneously. So, for instance, if you have a sigil that ends up with a "spread 3" passive, it means all your orbs will have this passive applied to them.

UI: SRNKX-like, generated concepts in the reference/ folder, should not be hard to implement most of it visually once we know exactly what we want in each UI window.

DAMAGE: as mentioned, flat damage model, no percentages, I don't even remember if we decided on keeping or removing the physical/magic/null split, it's possible we even removed that, need to check. My intuition is to have it removed, only keeping normal damage that gets reduced by armor, and null damage that doesn't. Simple at first, we can complicate it later as needed.

TUTORIAL: first map needs to introduce the player with the concept of orbs + ability linking, this needs to proceed as planned for the beach, but now changed for a smaller map instead of a big one. After this, proceed to hideout as normal and then the run starts. This tutorial should only happen the first time the player plays the game (first run), other runs he just starts directly from the hideout, with the possibility of redoing the tutorial when needed.

CRAFTING: currently undesigned, depends on too many details about the economy and how the game will turn out after we have the loop working, so deferral is best.

Got it. Locked in. Here's what I'm reading as changed vs the existing docs, before I get into questions:

Changes from prior docs:

Questions — grouped, numbered, ordered roughly by how much they unblock consolidation:

1. Orb socket links — which model? - (a) PoE-style: sockets within an orb have a link graph; a support only applies to actives in its link group. An orb with 4 sockets might have two 2-link groups, or one 4-link, etc. Big build-design lever. - (b) All-gems-apply: all gems in an orb modify that orb's single active. "Links" are visual flavor only, no semantic effect. - (c) Something else (typed slots only, no graph — what the current doc says).

2. Map structure / end condition. - How does a map end? Wave count → boss? Time survival? Endless-til-you-leave? Single boss after a fixed wave schedule? - Are maps "one continuous wave fight in one arena" (closer to SNKRX), or "explore an arena, find rooms, fight a boss" (closer to PoE)? - When you say 1–2 screens — is that a fixed arena the camera shows whole, or a small zone the player walks around inside (camera follows)?

3. "Environmental gameplay differences" — what kinds? - Examples please. Are these: terrain hazards (lava floor, ice slip)? Spawn-pattern modifiers (more elites, faster waves)? Rule changes (tower defense mode, breach swarms)? Something else? - And: is "leagues as map modifiers" (tower defense, survivors, breach, delve) still the design, or is it now simpler — just a handful of map archetypes that vary spawn/objectives?

4. Damage model — confirm cut? - Drop physical/magic split, keep only damage (reduced by armor) and null (bypasses armor). That's it? - Or keep three: physical, magic, null?

5. Mask / robe / rings — what are they? - Sigil now has a clear identity (global modifiers on orbs). - Mask, robe, rings — are these stat-stick gear (just numbers), or do you want each to have a mechanical identity like sigil does? E.g., mask = passive auras, robe = defensive specialty, rings = trigger-event slot.

6. Cast resource. - When player presses LMB to fire an orb's active ability, what gates the rate? Cooldown only? Mana? Charges? The right-side HUD orb has been undefined since day one.

7. Cross-orb mechanics. - Current docs have charges (PoE) + exert (PoE warcries) + global modifiers as the three cross-orb synergy systems. - With sigil now owning global modifiers, do charges and exert still exist? Or do we collapse cross-orb interaction down to just sigil-level globals + whatever organic interactions emerge from triggers/timers?

8. Run end — final boss or open-ended? - Current design.md says "defeat the final boss = run win." Still true? Or run is just "play maps until you die"?

9. Death wipe. - Still hard reset, no meta-progression? The "skip tutorial after first completion" is technically a meta-progression flag, so the line isn't pure anymore — confirming you're fine with that small carve-out.

10. Inventory. - Still infinite, single-player, no stash?

11. Ability port from v1. - 23 abilities exist in v1. Do we plan to port them all, or start with a small set (Fireball + 4–5 others) and grow from there?

Things I think are missing or under-specified that we should resolve before consolidating:

I'll wait for your answers before drafting the consolidated doc. Take them in any order; you can also tell me a question is wrong-shaped and I'll re-ask.

Global modifiers can also come from rings, robes and masks, but they apply to the player. Sigil has ones that apply to abilities as though they were mods in each orb, that's the difference.

  1. Let's go with a), I think this is the simplest solution for now.
  2. We'll probably do a mix of everything depending on the map.
  3. Terrain, spawn modifiers, challenges, various things that change how a map plays in some clear way. And yes, leagues as map modifiers is also what applies here.
  4. Yea, let's keep just normal and null damage for now.
  5. Already explained, but yes, sigil stands above the character's head, mask, robe, rings are stat-stick gear that applies to the player's stats itself. We don't need to decide on an identity for each yet.
  6. I'm still undecided on this. We could try to eventually add the notion of a null mana pool, and that's what your orbs use, and that's what appears in the HUD... But I'm not sure about this because it involves tying the environment into it, and that just seems unnecessarily complicated.
  7. Charges, exert and others are player level ideas, so they exist but should not be thought of as cross orb interaction, even though in some way they may be.
  8. Yes, final boss should exist.
  9. Hard reset, no meta-progression for now.
  10. Yes.
  11. Start with a small set and grow from there.

A wave likely depends on the map, but generally will mean that a few packs spawn and then wait until they're killed to spawn more packs, or new packs spawn on a timer, or some other condition, depending on map.

I think end-of-map loot drop probably feels better and doesn't have you having to handle inventory management while gameplay is happening.

Maps come from monsters in maps but there's also an NPC in the hideout to ensure the player can't get locked out of new maps.

Tier, modifiers, environment type, reward, everything yea. Depending on your build you might favor some types of maps over others based on any or all of the aforementioned variables.

Hideout still should be a place I think, so stays as is.

Run should be saved automatically, yes, this isn't hard to implement.

Locked in. Sigil clarification noted: sigil mods apply to abilities (like in-orb mods, but globally); rings/robe/mask global mods apply to the player. Two distinct global-modifier surfaces.

Before I draft the consolidated docs, four follow-ups and one structural check:

1. Cast resource — provisional decision OK? You're undecided on null-mana-pool-tied-to-environment. Proposal for the consolidated doc: cooldowns only for v1, no mana resource. The right-side HUD orb stays empty (or shows global cooldown / charges if we use them later). Mana/null-pool flagged as a future-scope option in an "open questions" section. Good?

2. Final boss — how do you reach it? Final boss exists, but it's not specified how a run progresses to it. Options: - (a) Top-tier map. Player progresses through map tiers (T1 → T16 PoE-style) and the final boss is in a special T16+ map item that drops only from high-tier bosses. - (b) Linear story arc. After clearing N maps / a specific quest line, a final-boss map item is granted. - (c) Atlas-lite. World map UI has fixed regions; final region is gated behind clearing earlier ones. - (d) Defer. Build the loop, decide later.

3. Tutorial replay — where does the player redo it? - Hideout NPC ("Tutorial Officer" or similar)? - Options menu entry? - World object in the hideout (training dummy, signpost)?

4. Sigil mod stacking with orb-internal mods. If an orb has Spread internally, and the sigil has a global Spread, does the active ability get Spread applied twice (additive), or does the sigil's Spread only apply to orbs that don't have it socketed (no double-up), or some other rule?

Structural proposal for consolidation:

Two files at the project root, replacing the current design/plan/plan_beach trio + the most-relevant reference docs:

Reference docs that stay (still useful, not part of consolidation):

Sound right? Or do you want a different split (e.g., one combined file, or design split into "concept" vs "systems")?

  1. Yes.
  2. d)
  3. There's a door on the hideout that leads back to the tutorial map, if you go there it happens again.
  4. That's a good question. My intuition is to allow repeating of same modifiers and they stack, but I didn't think about it yet. Let's have that possible, but later we need to verify in implementation if it's feasible. I don't think v1 had this implemented.

Your plan seems good. Make sure that working documents, design and plan, are not in reference/ but alongside other files like main.lua.

Locked. Drafting now. I'll write both files, then ask before moving any files into reference/archive/.

Write (E:\a327ex\Orblike\design.md)

The file E:\a327ex\Orblike\design.md has been updated successfully. (file state is current in your context — no need to Read it back)

Write (E:\a327ex\Orblike\plan.md)

The file E:\a327ex\Orblike\plan.md has been updated successfully. (file state is current in your context — no need to Read it back)

Both files written. Quick summary of what's in each so you know where to look:

design.md (~210 lines) — concept, lore, core loop, hideout, tutorial map, maps & waves, orbs (sockets/links/gems/triggers/carriers), equipment (sigil + stat-stick gear), damage (normal + null), player-level systems (charges/exert), inventory & UI, run lifecycle, design principles, open questions, references.

plan.md (~165 lines) — current state, Phase 1 (tutorial map, 12 sub-phases), Phase 2 (NPCs), Phase 3 (map system + run lifecycle + auto-save), Phase 4 (combat port subset of 5 abilities), Phase 5 (league architecture), Phase 6+ ongoing, deferred hideout polish, doc cleanup checklist.

Notable choices I made — flag if any are wrong:

Cleanup proposal — needs your OK before I run any moves:

Move to reference/archive/:

Already-noted-superseded docs to also archive (per plan_beach.md's own consolidation list):

I won't touch any of these until you confirm. Also: read through design.md and plan.md and tell me what's wrong, missing, or worded clumsily — easier to fix now than after they accumulate references.

Yea that's fine

Bash (ls E:/a327ex/Orblike/reference/archive/ 2>&1; echo "---"; ls E:/a327ex/Orblike/r...)

implementation_plan.md
orblike_ability_system_old.md
system_design.md
---
feature_by_feature_analysis.md
lore.md
orblike_ability_system.md
three_phase_system.md

system_design.md and implementation_plan.md are already in archive. Moving the rest.

Bash (mv E:/a327ex/Orblike/plan_beach.md E:/a327ex/Orblike/reference/archive/plan_beac...)

OK

Bash (ls E:/a327ex/Orblike/reference/archive/)

feature_by_feature_analysis.md
implementation_plan.md
lore.md
orblike_ability_system.md
orblike_ability_system_old.md
plan_beach.md
system_design.md
three_phase_system.md

Done. Project root now has just design.md and plan.md as the working design docs, alongside main.lua and the other game files. Five superseded docs archived (plus the two already there). The reference/ folder still contains the load-bearing material (tags, interactions, ability tables, SNKRX/PoE references, mockups).

OK, let's end this session, name it Orblike Design Consolidation

Skill 

Launching skill: end-session

Base directory for this skill: E:\a327ex.claude\skills\end-session

End Session Workflow

This skill is invoked from the same conversation where the work was done. You already have the full session context in memory — you do NOT need to read the transcript.

Step 1: Get Session Info

Ask the user for the session title (max 30 characters). Examples: "Anchor Phase 10 Part 5", "Physics Arena Setup", "Timer System Fix", "Thalien Lune Design".

Determine the project yourself from your session context — you know which repo(s) were worked on, which files were created/modified, and where they live. No need to ask. See Step 6 for the list of known project roots; if the session touched something outside the list, infer the root from the paths you actually edited.

Step 2: Write Summary

Write the summary from your conversation memory. You have the full session context — no need to read any files.

The summary should be thorough and detailed. Each major topic deserves its own section with multiple specific bullet points. Don't compress — expand.

Purpose: These summaries serve as searchable records. Future Claude instances will grep through past logs to find how specific topics were handled. The more detail you include, the more useful the summary becomes for finding relevant context later.

Format (this is just an example structure — adapt sections to match what actually happened):

# [Title]

## Summary

[1-2 sentence overview of the session's main focus]

**[Topic 1 - e.g., "Spring Module Implementation"]:**
- First specific detail about what was done
- Second detail - include file names, function names
- User correction or feedback (quote if notable)
- Technical decisions and why

**[Topic 2 - e.g., "Camera Research"]:**
- What was researched
- Key findings
- How it influenced implementation

**[Topic 3 - e.g., "Errors and Fixes"]:**
- Specific error message encountered
- Root cause identified
- How it was fixed

[Continue for each major topic...]

---

[Rest of transcript follows]

Rules: - Be thorough — If in doubt, include more detail, not less. Each topic should be as detailed as possible while still being a summary. - Think searchability — Future instances will search these logs. Include keywords, function names, error messages that someone might grep for. - One section per major topic — Don't combine unrelated work into one section - Chronological order — Sections should match conversation flow - Specific details — Error messages, file names, function names, parameter values - Include user quotes — When user gave notable feedback, quote it (e.g., "k/d variables are not intuitive at all") - Weight planning equally — Research, proposals, alternatives considered, user feedback on approach are as important as implementation - Weight problems solved — Errors, root causes, fixes, user corrections all matter - Technical specifics — Include formulas, API signatures, parameter changes when relevant

Step 3: Get User Approval

Show the title and summary to the user. Wait for approval before proceeding. If they have corrections, fix them.

Step 4: Convert Transcript and Write Log File

# Find recent sessions (Claude + Cursor; see script). Same script lives in Anchor2:
python E:/a327ex/Anchor2/scripts/find-recent-session.py --limit 5
# or: python E:/a327ex/Anchor/scripts/find-recent-session.py --limit 5

The script shows sessions sorted by when they ended. The first result is the current conversation (since end-session was invoked here). Use it.

Convert the transcript to markdown and write the log file with the approved summary as header:

python E:/a327ex/Anchor2/scripts/jsonl-to-markdown.py [SESSION_PATH] E:/a327ex/anchor.blot.im/logs/[slug].md
# or: python E:/a327ex/Anchor/scripts/jsonl-to-markdown.py ...

The same script auto-detects Claude Code JSONL vs Cursor/Composer agent JSONL (~/.cursor/projects/.../agent-transcripts/...). For Composer sessions, use find-recent-session.py (it merges both sources) and pick the [cursor] line for the current chat.

Use lowercase hyphenated slug derived from the title (e.g., "anchor-primitives-hitstop-animation").

Then replace the default header (# Session YYYY-MM-DD...) with the approved title and summary.

Step 5: Sync Context Files to Blot

cp E:/a327ex/.claude/CLAUDE.md E:/a327ex/anchor.blot.im/context/CLAUDE.md
cp E:/a327ex/Anchor/docs/* E:/a327ex/anchor.blot.im/context/

When the session was Anchor2 (optional):

cp E:/a327ex/Anchor2/.claude/CLAUDE.md E:/a327ex/anchor.blot.im/context/CLAUDE_ANCHOR2.md

Step 6: Commit Project Repo

Identify the project repo(s) worked on this session from your own context — you already know which repos were touched and which files changed. For the common projects, here are the canonical staging commands:

Project Root Stage command
Anchor E:/a327ex/Anchor git add docs/ framework/ engine/ scripts/ reference/
Anchor2 E:/a327ex/Anchor2 git add framework/ engine/ arena/ reference/ scripts/ docs/ .claude/
emoji-ball-battles E:/a327ex/emoji-ball-battles git add -A
orblike E:/a327ex/orblike git add -A
thalien-lune E:/a327ex/thalien-lune git add -A

For a project not listed, infer the root from the files you actually created or modified this session and stage those. If multiple candidate roots look valid, ask the user which files to stage.

cd into the project root, stage, run git status to verify before committing.

IMPORTANT — FULL SUMMARY IN COMMIT: The commit message MUST include the FULL summary from the log file. Read the summary back from the log file to ensure nothing is missing.

IMPORTANT — COMMIT METHOD: The summary contains backticks, special characters, and markdown that WILL break heredocs and git commit -m. ALWAYS use the file-based method below. NEVER try a heredoc first — it will fail and produce a malformed commit that needs amending.

Commit using a temporary file (extracts only the summary text, not the markdown heading or ## Summary line):

# Extract summary: skip line 1 (# Title) and line 3 (## Summary), take lines 4 onward until the --- separator
awk 'NR>=4 && /^---$/{exit} NR>=4{print}' E:/a327ex/anchor.blot.im/logs/[slug].md > /tmp/commit_msg.txt

# Prepend the title (plain text, no #) and append attribution
sed -i "1i [Title]\n" /tmp/commit_msg.txt
printf "\nGenerated with [Claude Code](https://claude.com/claude-code)\n\nCo-Authored-By: Claude <noreply@anthropic.com>\n" >> /tmp/commit_msg.txt

git commit -F /tmp/commit_msg.txt

Step 7: Push Both Repos

# Push project repo to GitHub
git push origin main

# Push Blot repo (logs and context are already there)
cd E:/a327ex/anchor.blot.im && git add -A && git commit -m "[Title]" && git push origin master

Step 8: Confirm

Tell the user: - Commit hash - That GitHub push succeeded - That Blot push succeeded

ARGUMENTS: Orblike Design Consolidation

Drafting summary now.

# Orblike Design Consolidation

## Summary

Pure-design session (no code). Reviewed Orblike's accumulated design docs, ran two rounds of design-clarification Q&A, dropped procgen map terrain in favor of small hand-laid maps, then consolidated the design into two clean working docs (design.md, plan.md) at the project root and archived superseded reference material.

**Doc audit / starting state:**
- Read `Orblike/design.md` (177 lines), `Orblike/plan.md` (308 lines), `Orblike/plan_beach.md` (671 lines including a long postmortem on the failed beach map procgen), `reference/orblike_ability_system.md` (~410 lines, PoE-clone slot model), `reference/lore.md` (~240 lines, mana-frequency / physical-magic-null damage theory).
- Surfaced project status: hideout shell shipped (player movement, jagged polygon rooms, distance-field wall gradient, 32 wall symbols, F-key pattern/symbol/rotation cycling, F3/F4/F5 memory tracking, region/palette pipeline). Beach map procgen stuck at the rocks/sea region rendering after seven visual iterations — postmortem in `plan_beach.md` recommended scrapping procgen approach.
- Surfaced 10 tensions / open questions worth redesigning around: dual lore framings (Psyonian-state mage in design.md vs alchemist-shopkeeper in lore.md), scope vs. "keep practice projects practice" memory note, PoE-complexity vs. roguelike-wipe mismatch, beach replays every run, beach visually blocked, equipment depth lopsided (only orbs defined), undefined cast resource, no atlas-tree map identity, undesigned crafting referenced everywhere, simplified orb composition lost connection-graph richness.

**User's redesign vision (stated upfront for common ground):**
- **Maps:** drop procgen, go to small (1–2 screen) hand-laid layouts with small variation; gameplay variance comes from environmental gameplay differences (terrain, spawn modifiers, leagues as map modifiers).
- **Lore:** simplified — Psyonian State created orbs to clean null mana pockets; orbs convert null mana into caster's personal mana (or fire null abilities directly when caster can't process null mana). Lore is flavor only, not driving mechanics.
- **Orbs:** PoE-like sockets with links; gems socket in; arbitrary build combinations.
- **Equipment:** sigil = global modifiers that apply to abilities (like in-orb mods, but global across all orbs); mask/robe/rings = stat-stick gear with player-level modifiers (apply to player, not abilities).
- **Damage:** lean toward dropping physical/magic split; just normal (reduced by armor) + null (bypasses armor).
- **Tutorial:** smaller hand-laid map; first run only, replayable via hideout door.
- **Crafting:** deferred — too dependent on economy details.

**Q&A round 1 (11 numbered + 6 missing-item questions):**
- Confirmed: PoE-style socket links (option a), mix of map end conditions, terrain/spawn/league modifier variance, just normal+null damage, sigil clarification (sigil applies to abilities, mask/robe/rings apply to player), final boss exists, hard reset, infinite inventory, start with small ability set then grow, end-of-map loot drops, map items drop from monsters + softlock NPC, tier+modifier+environment+reward all matter for map choice, hideout stays as is, auto-save run state.
- Cast resource: undecided — possibly null-mana pool tied to environment but user unsure due to environment coupling complexity.
- Charges/exert: framed as player-level mechanics, not as deliberate cross-orb interaction.
- Wave structure: per-map (pack-clear gates, timer gates, etc.).

**Q&A round 2 (4 follow-ups):**
- Cast resource: cooldowns only for v1, defer null-mana-pool decision.
- Final boss reach: deferred (option d — decide once loop is solid).
- Tutorial replay: door in the hideout that re-enters the tutorial map.
- Sigil mod stacking: allow same-mod stacking with orb-internal mods (additive); verify implementation feasibility when built. v1 didn't have this.
- Structural proposal: two files (design.md ~250 lines, plan.md ~150 lines) at project root alongside main.lua, NOT in reference/. User approved.

**Consolidation — wrote two new docs:**
- `Orblike/design.md` (~210 lines) — concept, lore (flavor), core loop, hideout, tutorial map, maps & waves, orbs (sockets/links/gems/triggers/carriers), equipment, damage, player-level systems, inventory & UI, run lifecycle, design principles, open questions, references.
- `Orblike/plan.md` (~165 lines) — current state, Phase 1 (tutorial map with 12 sub-phases), Phase 2 (NPCs), Phase 3 (map system + auto-save run lifecycle), Phase 4 (combat port subset of 5 abilities to validate carrier-type variety), Phase 5 (league architecture), Phase 6+ ongoing, deferred hideout polish (symbol-to-wall distance, palette port, hideout defaults), doc cleanup checklist.

**Notable explicit choices flagged for user review:**
- Phase 4 starts with 5 abilities (Fireball + a beam + an area + an orbit + a chain) to validate carrier-type breadth, not just Fireball.
- Tutorial uses per-item ground pickup (not end-of-map drops) so the hint system can pace gem drops one at a time. Regular maps still use end-of-map drops.
- Kept hideout-polish work items (symbol-to-wall distance consistency, v1 wall palette port, hideout defaults) in plan.md as deferred — not blocking but real outstanding work.

**Doc cleanup — archived to `reference/archive/`:**
- `plan_beach.md` (project root → archive)
- `reference/lore.md`
- `reference/orblike_ability_system.md`
- `reference/three_phase_system.md`
- `reference/feature_by_feature_analysis.md`
- (`system_design.md` and `implementation_plan.md` already in archive from prior consolidation.)

Reference docs preserved (still load-bearing): `tags.md`, `interactions.md`, `ability_*.md`, `SNKRX_*`, `snkrx_style_effects.md`, `poe_*.md`, mockup HTMLs/PNGs.

Look right? Approve and I'll run the rest of the close-out (transcript export, commit, push).

Yes.

Bash (python E:/a327ex/Anchor2/scripts/find-recent-session.py --limit 5)

2026-04-27T02:42:39.368Z 4a3b53e3-651f-479d-b1f5-6f48975b71e7 [claude] <-- MOST RECENT
   C:\Users\adn\.claude\projects\E--a327ex\4a3b53e3-651f-479d-b1f5-6f48975b71e7.jsonl

2026-04-27T00:42:30.750Z 49c3ebaf-1516-4f8d-97a6-e4db761c1d10 [claude]
   C:\Users\adn\.claude\projects\E--a327ex\49c3ebaf-1516-4f8d-97a6-e4db761c1d10.jsonl

2026-04-27T00:17:53.981Z 8f867da8-6295-4e85-8aa6-d0f5774e6771 [claude]
   C:\Users\adn\.claude\projects\E--a327ex\8f867da8-6295-4e85-8aa6-d0f5774e6771.jsonl

2026-04-26T22:42:57.364Z 27b23945-15c3-4fe6-8e55-a650c008d974 [claude]
   C:\Users\adn\.claude\projects\E--a327ex\27b23945-15c3-4fe6-8e55-a650c008d974.jsonl

2026-04-26T16:44:25.853Z 4095a51e-7820-4d02-8d63-cc7b2ec545d3 [claude]
   C:\Users\adn\.claude\projects\E--a327ex\4095a51e-7820-4d02-8d63-cc7b2ec545d3.jsonl