7.9 KiB
date, type, tags, permalink
| date | type | tags | permalink | ||||||
|---|---|---|---|---|---|---|---|---|---|
| 2026-06-08 | session |
|
gamevault/07-sessions/2026/2026-06-08-combat-depth-direction |
Session 2026-06-08 — Direction: combat-first + the combat-depth track
A design/strategy session (no code). Operator: "This does not feel like a game... expand the design + a clear roadmap to a core playable fun loop. Pushback where it'd substantially help. Ground it in real game design + real published games + the solo-dev constraint."
Goal
Diagnose why an engineering-complete project doesn't feel like a game, set a direction, and lay out a combat-depth milestone track.
Process
- Scan: read Identity, Pillars, Milestones, Backlog, Systems_Index, DR-004, content inventory (3 abilities = same projectile; 6 enemy prefabs = 1 brain; 8 items; structures). Confirmed the gap: vast infrastructure, hollow content; "Live interactive fire test" never done.
- Intake gate (4 questions): operator wants all three pillars (the fusion is the identity / unsure), passion/craft, co-op NON-NEGOTIABLE, solo + Claude.
- Diagnosis + pushback (delivered in chat): development was breadth-first + correctness-first → a "tech demo of a game"; the four pillars are three deep genres a solo dev can't make co-equal; the fix is braid-don't-co-equal with combat as the primary verb. Grounded in The Riftbreaker / Core Keeper / Deep Rock Galactic / Risk of Rain 2 / Left 4 Dead / Vlambeer.
- Combat-depth design pass (ultracode workflow, 9 agents): 5 design lenses (movement/defense · ability kit · enemy AI · co-op · game feel), each grounded in real games and the actual DOTS code → 1 synthesis (thesis + MC-1…MC-5) → 3 adversarial critics (netcode-feasibility · solo-scope · fun), all go-with-changes.
Done (decisions + docs)
- DR-028_Combat_Primary_Verb_Depth_First — combat is the primary braided verb; base+automation braid around it (not co-equal); depth-before-breadth + per-milestone fun-gates; inventory Phases 2–4 + automation breadth paused.
- Path_to_Fun — new north-star roadmap: the braided loop + the combat-depth track MC-1…MC-6 (re-cut per the critics) with build notes.
- Revised Pillars (combat primary + depth-before-breadth), Identity (+the braid section), Milestones + Backlog (pivot/pause), 00_Home/Home (pointers).
Key findings from the design pass (carry into MC-1)
- The keystone is enemy COMMITMENT + a punishable whiff paired with the dodge. The dash is the answer, a committed lunge is the question; both are inert alone (aim is already decoupled from move → kite-strafe-and-click already beats the one brain). So MC-1 ships the dash and the Charger lunge as one playtest unit, validated by play, not against the current commitment-free melee.
- Two MC-1 netcode blockers (pre-caught): (1) i-frames must negate damage per-
DamageEventagainst the tick it was authored — stamp a non-replicateduint SourceTickonDamageEvent(HealthApplyDamageSystemdrains the prior-tick melee event in the predicted group), not "is DashState active now." (2)CharacterControlhas no sharpness field — also driveCharacterComponent.GroundedMovementSharpnessnear-instant for the dash window, else the dash ramps ("walk faster"). Budget the Burst-processor edit (focused editor; expect a restart). - Telegraph readability is a PRECONDITION, not polish: drive the cue off the replicated
AttackWinduptick countdown (enemies are interpolated ~100ms late); lengthen windups to ~27+ ticks; make enemy-projectile dodgeability a Play-gate. - Co-op validated early + cheap: pull a server-only
EnemyStatussynergy byte into MC-3 (slow+burst duo > two soloists). Downed/revive (MC-5) replicates a[GhostField] uint DownedUntilTickdiscriminator to keep the derive rollback-correct; no server-onlyKnockbackStateon predicted players. - MC-6 (multi-slot kit) is last + review-gated — the only HIGH-risk item; ship hitscan/cone (no predicted spawn) before generalizing
ProjectileClassificationSystemto a ghost-type set; 2–3 slots before 4.
Addendum — roadmap refinement (same day, ultracode)
Operator: "Lets refine the roadmap fully." A second multi-agent pass refined Path_to_Fun end-to-end — 4 deepen lenses (combat track · the economy braid · endgame/win-lose · production discipline, each grounded in the actual code) → synthesis → 3 code-grounded adversarial critics (netcode-feasibility · solo-scope · fun-coherence), all go-with-changes. Outcome:
- Path A / Path B hard split + a mandatory Decision Gate. Committed Path A = MC-0 (instrument the box) · MC-1 (dash + committed Charger) · MC-4 (melee cone) · EB-1 (machines can die) · EB-2 (felt spend / turret ammo from the factory) · END-1 (a losable Core) · END-2 (final siege, win/lose) — a complete, shippable small game with a point. Everything else (MC-2/3/5/6 · EB-3/4/5 · END-5) is provisional Path B, re-estimated only after Path A's fun-gates pass; END-3 narrative + END-4 content-treadmill CUT to the revisit table (an empty event bus is negative value for a content-light solo project). No Path B work begins until an explicit ship-vs-continue decision is logged.
- Code-grounded corrections (critics read the systems): a THIRD
DamageEventstamp site (TurretFireSystem.cs:95);DashStateneeds an explicitStartTick; the i-frame negation is a cross-group tick-alignment problem (HealthApplyDamageSystemin the predicted group drains the strikeEnemyAISystemappended a tick earlier in the plain group) — MC-1 mandatory-review agenda item #1. The MC-2 "wave director" is already built (Threat/Cycle/Wave) — only the weighted enemy-MIX table is new. - New cross-cutting discipline: a falsifiable fun-gate protocol + MC-0 instrumentation (so feel claims are counted — e.g. timed-vs-spam dash hit-counts), a ~35-row tuning-knob surface (baked vs live server-singleton + defaults), the solo+Claude two-lane cadence (friend = an EXTERNAL Path-A dependency at EB-2's Demo B), a risk register (R1–R11), and demo checkpoints (Duel / Loop / Crisis). 10 operator forks catalogued (locked the next day — see Addendum 2).
Direction unchanged (DR-028_Combat_Primary_Verb_Depth_First); the refinement sharpened scope realism, falsifiability, and netcode precision.
Addendum 2 — Path A forks locked (2026-06-09)
Operator process correction: gameplay-design forks are the operator's call — present each with a recommendation, never auto-decide or mark a default "official" without an okay (a workflow attempting to auto-lock every fork was halted mid-run). Worked the forks interactively; Path A is now fully locked (DR-029_Path_A_Fork_Locks · Path_to_Fun#Locked decisions (Path A)): free-aim + whole-window dash · Charger = a new prefab · cleave = its own button + cooldown · Husks push-for-base · soft-loss + wounded-base-persists (SaveData v3) · turret-only ammo with soft run-dry · win-meter = both sieges + Aether deposits (the one non-default pick — the stronger braid) · winning = keep-playing · final = one big escalating wave. Live-singleton picks stay tunable at playtest. Standing rule: re-run the same present-the-forks ritual before each Path B milestone; Path B forks stay open. Saw also present-forks-dont-auto-decide.
Next
Path A is locked and concretely specified. Operator's call: start MC-0 + MC-1 (instrument the box, then dash + Charger committed-lunge + readable telegraph — honoring the three-site SourceTick i-frame fix, the DashState.StartTick window, and the Burst-affecting CharacterProcessor edit) via a normal plan→approve→build slice — or commit the refined vault docs. Per Path_to_Fun, MC-1 is the project kill-switch: if its fun-gate fails after a real tuning pass, STOP and re-cut combat before building on it.