Working Notes
Section Breakdown
Entries by section, colored by tier — computed live from the doc, not hand-maintained.
C0 Game Details
S1 Title / Naming
answeredNo title has been decided yet. "Momentum" was only ever a working codename, never a proposed title — it survives as this project's folder name; the document files themselves were renamed to
notary.* (2026-07-18) for unrelated reasons outside this doc's scope. Neither name should be read as a signal about the eventual in-game title.explainWhat is the game's actual title?
S2 Scope & Platform
Filler. Engine, platform(s), networking model, team/studio, release target, and monetization are all still undecided — see the empty fields in Info. This subsection is where those get worked out via Q&A; Info should be updated to mirror whatever gets settled here.
explainWhat engine is this being built in? Godot was floated early for an abandoned 2D prototype idea, but nothing's been confirmed for the current 3D direction.
explainWhat platform(s) is this targeting?
yes/noIs monetization even a consideration for this project (e.g. a free personal/portfolio project vs. a commercial release), or is that itself still undecided?Genuinely undecided, not just unasked — user's own framing: this combat system is deliberately being built as something that "could be implemented and built upon in many different areas of gaming," with an explicit long-shot reference point of eventually being ambitious enough to replace something like Entropia Universe (cited as an example of a virtual-economy MMO the user considers exploitative/scammy) rather than resemble it. Monetization model isn't being decided now because the shape of what this even becomes isn't decided yet — see the scale-ambition note in Game Modes → Parked / Future Modes, which this directly extends.
C1 Combat System
S1 Modes (d3)
established
Modes (mutually exclusive; exactly one active). "State" is retired as a synonym for this. Three top-level nodes — see each Mode's own subsection below for role/behavior/defense/internal structure. Mobile → Calm [forced, on hit] · → Combat [only via Calm, no direct edge] Calm → Mobile [input] · → Combat [input, no opponent required] Combat → Calm [Cancel only — cold restart, no casual drift] * → Combat [forced, from Mobile or Calm, on being hit] * → Aerial [forced, from any Mode, on becoming airborne — falling, knocked off a height, glide source] exceptions: character traits/skills/items may grant shortcuts not listed above (e.g. direct Mobile→Combat, Combat→Calm without Cancel) — see Character Traits / Kit
establishedMode changes aren't always voluntary or player-initiated: they can be forced by events (e.g. getting hit forcing Combat, above) or incited/anticipated by an opponent reading behavior — someone starting to disengage can signal "they're about to bail into Mobile," prompting a preemptive response before the shift even happens.This read-and-react layer is the same core tension flagged in UX → Telegraphing & Clarity: Mode-shifts themselves, not just windups/attacks, are something opponents will be reading.
establishedEntering any top-level Mode can complement whichever Mode a player is coming from — e.g. Calm → Mobile can grant a brief boost letting a player reach Sprint faster than the default ~1s-of-jogging transition.
establishedVoluntary Mode shifts have a cooldown to prevent rapid chaining — recently having been in Combat restricts how quickly a player can chain further voluntary shifts afterward (e.g. Combat → Calm → Mobile in quick succession takes a beat, not instant). Forced transitions (getting hit, becoming airborne) aren't subject to this.
establishedCombat reaches Mobile only via Calm, for the baseline actor — no direct edge.
designWhether a trait/skill/item exception could ever grant a direct Combat→Mobile shortcut, and what would gate it, is undefined — deferred, not designed yet.
establishedIncapacitation composes with whichever Mode a player is in rather than replacing it, the same way Debilitation does — a player can be Incapacitated-and-Combat, Debilitated-and-Combat, or Incapacitated-and-Disabled (see Status) simultaneously; these stack rather than conflict.Same litmus applies to Aerial's still-open reclassification question below.
indexThe old "full Mode hierarchy" question lived here but bundled four separate undefined pieces, none of which could actually be answered from this subsection alone. Broken up and relocated to where each piece is actually owned: Stance/Release/Recovery's formal status → now lives directly in Combat's own subsection below; jog/sprint as Mobile's internal tiers → now lives directly in Mobile's own subsection below (formal mechanics still to be defined in Movement → Mode-Speed Interaction); Verticality/Aerial's basic definition and its connection to this graph → partially resolved, then reopened: initially filed as one of Mobile's internal gears (still its documentation home, see Mobile below), but confirmed 2026-07-18 that Aerial is reachable directly from Calm and Combat too (falling, being knocked off a height), not only via Mobile → Climbing — see the reclassification question under Mobile; Status forcing Mode transitions beyond the already-answered Sneak-break case → Status.
1.1 Mobile (d2)
established
Mobile
role: top-level Mode
behavior: distance-focused
defense: none (no Parry)
→ Calm [forced, on hit]
→ Combat [only via Calm — no direct edge]
gears (internal speed/traversal tiers):
A. Jog default speed
B. Sprint reached after ~1s of jogging
C. Climbing gear of mobility — mechanics open, see below
D. Aerial general airborne state (falling, gliding); enters automatically from any Mode
on becoming airborne, not a dedicated input — see belowestablished[Aerial] Covers general airborne states, not just wall/ceiling-crawl positioning — falling after jumping off a climbed or elevated surface, or gliding via a source such as a glider (a world/map interactable object) or a personal glide ability (character/gear-gated). The roster of glide sources is open-ended, not a fixed list.
established[Aerial] Entry is automatic/contextual, not a dedicated input — becoming airborne by any means (jumping off while Climbing, falling from a height, using a glide source) puts a player into Aerial, from any top-level Mode.
established[Aerial] A player can be hit while Aerial, but it's harder than hitting a grounded target with a backdrop — an airborne silhouette against open sky is a harder target, closable by attacker skill, not an absolute defense.Aerial-target readability is its own design question worth a dedicated pass — see Hit Locations / Positional Damage and UX → Telegraphing & Clarity.
explain[Aerial, C1S1.1D] Now that Aerial is confirmed reachable directly from Calm and Combat (falling, knocked off a height) and not only via Mobile → Climbing, does it still make sense to file it as one of Mobile's gears, or does it need reclassifying — e.g. as a Status-like overlay (comparable to Incapacitation, not tied to one parent Mode) rather than a gear nested under a single Mode? Documentation currently keeps it here regardless of the answer, since this is still its most complete definition.User's reasoning, not yet conclusive: Aerial doesn't cleanly fit either Status (all-Negative now) or Boons (all-positive by definition). Sneaking is "almost always positive" — even at its worst (about to be caught) it still gives an edge toward escaping into Mobile, never a pure downside, which is exactly why it now lives in Boons. Aerial isn't like that: entered unexpectedly, it's a disadvantage; entered deliberately, it's an advantage (see the planned-vs-forced combat-capability note below). Its valence depends entirely on how it was entered — doesn't fit Boons' always-good shape, and doesn't fit Status' always-imposed-and-bad shape either. The old question about whether Sneaking/Invisibility needed a third neutral/tactical category is resolved (they got their own Section, Boons, instead) — but that resolution doesn't obviously extend to Aerial, since Aerial's problem isn't ambiguous valence at rest, it's valence that flips based on entry. Still genuinely unresolved. Proposed, not decided: applying the same coexistence litmus just used to confirm Incapacitation stays a Status (does it compose with a Mode, or replace it?) points the same direction for Aerial — the leaping-strike mechanic already establishes you can carry an active Combat Stance into the air, and Aerial is reachable from Calm/Mobile/Combat alike without replacing whichever of those you were in. That's the same shape as a Status, not a Mode. Not asserting this as final — flagging that the tool the user just introduced for Incapacitation seems to answer this one too, pending confirmation. Status 2026-07-20: user "kind of agrees" with the Status-overlay lean but isn't confident enough to lock it in, and expects not to be until the combat system as a whole is better established — leave open rather than forcing it. Related loose idea floated in the same breath, not yet a real proposal: a general internal-vs-external cause tracker (was this state entered by the player's own action, or imposed by something else) that could apply beyond just Aerial. Purely a brainstorm note for now.
established[Aerial] Combat capability while Aerial depends on planning, not on being airborne itself. A player cannot freshly enter a Stance/attack once already airborne — unexpected Aerial entry (a fall, a knockback) leaves them restricted and vulnerable. A player can attack while Aerial only if the Stance/attack was already committed to before leaving the ground — e.g. a "leaping strike," carrying an active Stance into the air with jump momentum adding to strike force. No changing Stance mid-air — hard baseline rule.Follows the same momentum-carries-into-damage principle as guns/bullet velocity, see Movement → Momentum & Velocity. Future exception, not designed: an aerial-only Stance tied to specific weapons and/or the not-yet-named magic-adjacent system — would layer on via the existing trait/skill/item exception mechanism, see Character Traits / Kit.
established[Aerial] Gliders are either world/map interactable objects (environmental) or equippable Items, depending on type — no single rule.No Items subsection exists yet in this doc — structural gap, both glider flavors will need to hook into whatever that system becomes.
established[Aerial] The baseline actor has no innate glide of any kind — a personal glide requires equipment. Other character archetypes may have innate glide or flight; out of scope until character-type variety is designed (post-MVP).
established[Aerial] Landing depends on how Aerial was entered, not a flat return to Mobile — a player lands back into whichever Mode they were in before going airborne (a Calm-initiated fall returns to Calm, etc.). Mirrors how Sneak/Invisibility resolve contextually rather than to one fixed Mode.
established[Climbing] A distinct traversal action, mechanically separate from Jog/Sprint — not a context layer applied on top of them.
explain[Climbing, C1S1.1C] Entry method is undecided among three options, not fully resolved: a dedicated button press, a hold-to-initiate input, or fully automatic/contextual on touching a climbable surface (the same shape as Aerial's contextual entry). The automatic/contextual option is explicitly the least appealing of the three so far. Likely to end up mirroring whatever mechanism gates entering Mobile generally, once that's pinned down.
answered[Climbing, C1S1.1C] Design intent: getting hit while Climbing should carry real risk — likely triggering Incapacitation (a fall), forcing Recovery, which per the existing hit→Combat rule (see the Mode graph above) forces a transition into Combat. Escaping from there typically means finding a way back to Calm and then into Sneaking, Invisibility, or Mobile to disengage. "Strong chance," not guaranteed — exact odds/mechanics still open.Ties to the fall-from-height candidate cause already flagged under Incapacitation's MVP-causes question — Climbing is the concrete source of that fall. Also connects to the new "grounded vs. Aerial" hit-difficulty note above — a Climbing player who falls transitions through this same harder-to-hit window briefly before landing/Incapacitation resolves.
1.2 Calm (d1)
established
Calm role: top-level, default behavior: world interaction — walking, opening doors, picking up items defense: none (Block/Parry are Combat-only, see Defense (Block/Parry)) → Mobile [input] → Combat [input; no opponent required]
1.3 Combat (d1)
established
Combat role: top-level, committed defense: Block, available anytime (see Defense (Block/Parry)) target-lock: none — engageable by/can engage anyone in range (relevant in FFA) → Calm [Cancel only — cold restart, no casual drift] internal loop: A → B → C → D → (A | Cancel→Calm) A. Stance windup/charge B. Release the strike C. Recovery post-Release; duration/mechanics still open, see Stance & Release D. Neutral Combat's internal ready state — distinct from Calm, see Stance & Release
S2 Boons (d1)
establishedBoons is the Section for positive-valence effects (Sneaking, Invisibility) — categorically distinct from Status (Incapacitation/Debilitation/Disabled, all imposed and negative), not just the "good" end of the same taxonomy.
naming"Boon" is a deliberate throwback — Asheron's Call used the term for what most games call a buff.
2.1 Sneaking (d1)
establishedDetection-based on field of view — whether a player is within another player's vision cone/line of sight, not raw proximity. A sneaking player is visually obscured, hard to see, and blends into the background, with increasing effect in shadow.
establishedIllumination (light sources — items, abilities, spells) diminishes sneak obscurity rather than binary-canceling it — a gradient effect, brighter light making a sneaking player easier to spot rather than instantly revealing them.
establishedSneak is broken by: illumination reducing obscurity below the threshold needed to stay hidden, being hit outright by something (e.g. a spread of fire), or being knocked into Incapacitation.
establishedBreaking out of Sneak, whether by choice or by being spotted, resolves into either Combat or Mobile — most likely Combat.
establishedField of view can itself be narrowed (making it easier to get into Sneak) or widened (making it harder) by items/abilities on either side.
designNormal (non-sneaking) targeting: a target ring appears around an opponent when directly looked at with the crosshair. There will be a crosshair; exact camera positioning mechanics are still unsettled.No dedicated Targeting subsection exists in this doc yet — flagging as a structural gap, same as Items above. Depends on User Perspective → Camera and Opponent-State Readability, where camera mechanics are also still open.
designNo player nametags are currently planned — this is what makes the Sneak visual fade (character becoming visibly obscured on successful sneak) actually meaningful instead of redundant with a UI label.This is a User Perspective → HUD & Framing decision surfacing here first; that subsection is still a placeholder and should reflect the no-nametags choice when it gets its own pass.
establishedSneak is a small, self-contained primitive, independent of whether the parked stealth-deception mode (see Game Modes → Parked / Future Modes) ever gets built.
environmentLighting isn't only item/ability-driven (see illumination above) — time-of-day and map-baked lighting (night, shade, direct sunlight) should be a baseline factor in sneak obscurity too, not just a temporary buff/debuff layered on top.
environmentCover/objects provide obscurity independent of lighting — dense geometry can make a player hard to spot in broad daylight the same way shade does at night. Two separate obscurity inputs (light, clutter) that likely stack rather than substitute for each other.
2.2 Invisibility (d1)
establishedA separate status from Sneaking, with different rules. Expected to almost always be a short-term effect.
establishedInvisibility suppresses the target ring/highlight entirely, even under direct crosshair contact — a hard rule, not an obscurity gradient like Sneak. Sneak works by avoiding detection; Invisibility works by suppressing the targeting system outright even when "detected."
establishedOnly broken by being outright hit by something — being looked at or otherwise detected does not break it, unlike Sneak.
explainLeaning is that Invisibility is a sub-Calm effect specifically, rather than usable from any Mode — is that a hard requirement (only functions while in Calm) or just the typical use case? Worth resolving explicitly, since it sits in tension with Boons generally not being tied to one parent Mode.Partial answer 2026-07-20, tension acknowledged but not resolved: becoming invisible, regardless of cause, forces the player into Calm — a deliberate rule so a player can't attack directly out of Invisibility with no reaction time for the opponent. Invisibility is also expected to be heavily motion-sensitive (moving within line of sight affects detectability), though whether that motion-sensitivity mechanic belongs to Invisibility or to Sneak isn't settled — and Sneaking is expected to be "almost crucial" while Invisible, since it's essentially the only Mobile-adjacent action available in that state. User's own words: this does conflict with the Calm-only framing as currently written, and that conflict is explicitly deferred, not resolved — needs its own follow-up pass once the Sneak/Invisibility motion-detection relationship is worked out.
S3 Status (d1)
establishedStatus is a separate layer from Modes: a Mode is exactly one at a time and defines what a player is doing (Mobile/Calm/Combat); a Status layers on top of whichever Mode is active and defines a temporary condition. Multiple statuses can be active at once, and a status generally isn't tied to one specific parent Mode.
establishedStatus is Negative-only: Incapacitation, Debilitation, Disabled. Positive effects (Sneaking, Invisibility) live in their own Section, Boons.
establishedA player cannot switch Modes while Incapacitated, by default. Exceptions (traits, items, etc.) must be named and granted explicitly.
establishedRecovery from a negative Status has two shapes by severity: short-term Incapacitation (a knockdown, a stun) clears on its own in a second or two, no intervention required. Permanent/severe cases (a broken or missing limb, and Disabled generally) require an external restoration system (magic, technology, or something else — not yet decided which) to reverse at all.
indexRapid-fire status brainstorm below (gray, deliberately unsorted) — a big batch of candidate status names/ideas, dumped fast on purpose rather than formalized one at a time, to be sorted into Incapacitation/Debilitation/Immobility/new-category in a later pass once the pile is big enough to see the shape of it. Nothing below is a claim yet.
brainstorm: unarmedConcussed. Brief knock-out distinct from generic Incapacitation (a short, game-pace-appropriate "out for a second" flavor specifically from a blow to the head, not a long real-world KO). Dislocated (arm/joint). Nerve/tendon damage that disrupts signal to a limb (exact term TBD — not a physiologist, per the user).
establishedRecovery from being knocked down includes a brief input window (x frames), during the transition out of Incapacitation into another Mode, to choose a follow-up action that carries into the Mode being entered — e.g. a kick or a roll while getting up, similar to a fighting game's wake-up options. The entered Mode complements the one just left, rather than the transition being a blank pause.
brainstorm: elementalCold/Freezing. Frostbitten (severe, per-limb). Burning/Scorched, with burn-degree tiers (1st/2nd degree floated). Ignited, as possibly distinct from generic "burned" — exact distinction TBD. Shocked — floated as causing a brief Incapacitation ("bird on a power line" reference).
designElemental effects are primarily environmental by default; weaponizing one (a thrown incendiary, alchemy, an imbued/enchanted weapon, tech-based delivery) is deliberately less common, in any scale of world — "the world is as conservative as the combat system itself."
brainstorm: respiratorySmoke inhalation, spores, and drowning all converge on "can't breathe, can choke out" — possibly the same underlying mechanic with different triggers, not three separate systems. Open question raised directly by the user: what's the actual taxonomy for elemental/environmental ailments at all — is there a real difference between a burn, being ignited, and whatever else fire does, or does this need its own categorization pass before any of it gets built.
brainstorm: poison & miscPoisoned. Paralysis — unsure if it's poison-specific or could also come from a precise physical hit; user explicitly deferred this judgment call. Tripping/stumbling — user flagged this might be too minor/granular to formalize as a real status. Bleeding/bleed-out — user unsure which existing category (if any) this belongs to.
brainstorm: sleepAsleep (narcolepsy-flavored). Drowsy (a lesser variant of Asleep). Drunk (a similar-shaped Debilitation to Drowsy).
brainstorm: immobilityCaught in a trap; leashed/rooted to a surface by a trap specifically (as opposed to the already-established Fortitude-based leg rooting) — a second possible route into the same rooted-Immobility outcome, via an external object rather than limb damage.
designBoons (see above) were deliberately not part of this brainstorm pass — user went almost entirely Negative on purpose and expects to keep it that way for now, not an oversight.
brainstorm: added by AIA few candidates not yet mentioned, offered per the user's invitation to fill gaps — none confirmed: Blinded (total vision loss, distinct from Confusion's distorted-but-present vision). Feared (a psychological effect forcing disengagement rather than a physical one). Slowed (reduced speed short of full rooting — a lighter-weight sibling to Immobility's leg case). Exhausted (stamina-depletion-driven, ties to the stamina-gating idea already floated in Health / TTK / Stamina). Exposed/Marked (an easier-to-hit debuff — the inverse of the harder-to-hit-while-Aerial mechanic already established, applied as a status rather than a Mode-specific effect).
3.1 Incapacitation (d1) negative
establishedIncapacitation: cannot act at all, for a duration. An umbrella category — many distinct, unrelated causes can put a player into it. The Mobile knockdown reaction from Modes is one specific cause, not the definition.
establishedMVP causes, beyond the Mobile knockdown reaction: (1) falling, from height, at sufficient impact velocity (not distance alone); (2) leg Fortitude collapse, a hit that depletes leg Fortitude enough to knock the player down, see Hit Locations / Positional Damage; (3) Stunned, always causes Incapacitation, unlike the other two which are conditional. Backstab-caused Incapacitation is indirect, routing through whichever region the backstab lands on.
establishedStunned is specifically head-trauma-caused (a physical blow, not sensory disruption), presents as a ragdoll, and always results in Incapacitation — not conditional, not a matter of degree. A named cause/flavor within Incapacitation's umbrella, not its own separate Status.
designFall-breaking mechanism floated as a possible mitigation for the leg-Fortitude-collapse-from-falling cause specifically — reduces or prevents the knockdown. Not defined yet; no home decided (could be a base mechanic, or gated behind a trait/skill like other exceptions in this doc).
establishedIncapacitation duration is neither a flat number nor a simple per-cause lookup — it stacks and multiplies from multiple contributing factors, compounding rather than being read off one severity value.
explainConfirmed factors so far: the cause itself, and fall velocity specifically for the falling case; equipment can lessen or worsen the multiplier. "Character stats" is not yet a defined system/term in this doc and shouldn't be assumed as a factor until it is. Left open (not fully answered) — the actual formula/weighting is deferred to a future pass once more of the surrounding systems are defined.
3.2 Debilitation (d1) negative
establishedDebilitation: can still act, but with reduced function. Also an umbrella — many distinct, unrelated causes.
establishedExample cause: Confusion — a perceptual/visual effect where the game world renders incorrectly to that player (distorted vision), triggered by sources like a dust cloud or a temporary poison.
establishedSecond example cause: a flashbang — sensory disruption puts the target under Debilitation, not Stunned/Incapacitation. A flashbanged player can still act, including attacking wildly, just with degraded function.
establishedImmobility is a named flavor of Debilitation (reduced function, still able to act), not a separate Status slot.
establishedArms: tied to the dominant/nondominant equip system — sufficient damage to an arm degrades whatever's equipped in it rather than stopping it outright (formally named Fortitude, see Hit Locations / Positional Damage). Legs: sufficient damage roots the player in place — locked, unable to move, but still able to act/fight from where they stand; severe/sudden leg-Fortitude collapse instead knocks the player down into Incapacitation — same underlying stat, split by severity.
establishedForced disarming (an opponent stripping a weapon) and voluntarily throwing/dropping a weapon both convert a player to fighting bare-handed — the floor of arm Immobility, never reduced to zero function. Arm damage degrades fist effectiveness the same way it degrades an equipped weapon's function; no hand-to-hand exemption, but fists are never reduced past that bare-handed floor.
3.3 Disabled (d1) negative
establishedDisabled is permanent (or conditionally-permanent, reversible only via a specific restoration condition), unlike every other Status. Coexists with any Mode and any other Status — a player can be Disabled-and-Incapacitated, Disabled-and-Combat, or Disabled-and-Debilitated, all simultaneously.
establishedAcquired either as an inherent character-build choice (present from the start, in exchange for a permanent benefit elsewhere) or in-world (e.g. a cursed item). A symmetric permanent-positive-trait tradeoff lives as a Character Trait rather than a Status itself — see Character Traits / Kit.
establishedAlso reachable as an escalation from a temporary Debilitation left unresolved (rapid necrosis, severe burns, nerve damage, an untreated dislocation) — its own gameplay loop, not only a character-creation option.Extends into Progression & Meta → Roster Unlocks. Reference point: Darkest Dungeon's affliction system.
establishedRestoration requires an external system, not passive time. What that system actually is (magic, technology, or something else) isn't decided; that it must exist and be external is the settled part.
S4 Stance & Release (d1)
establishedWithin Combat: enter a Stance (the windup/charge state) → choose a Release (the actual strike) → Recovery → back to Neutral — Combat's own internal ready sub-gear, distinct from the top-level Calm mode. From Neutral a player can enter a fresh Stance, get hit and re-enter Recovery, or Cancel out to Calm.
establishedGetting hit during Recovery doesn't interrupt into a separate new Recovery — it just extends the current one. If that hit also causes Stunned specifically, Recovery pauses rather than just extending, and takes longer still, which also triggers Incapacitation per Stunned's own rule. Ordinary (non-Stun) hits during Recovery stay a Recovery-duration penalty only.
establishedPost-Release Recovery is the same underlying mechanism as recovering from Incapacitation, differing by duration/severity. Modeled like the attack-speed/hits-per-second stat common to most combat systems: heavier weapons carry a much longer Recovery than light ones.
inputsLeft click = dominant execution, right click = nondominant. Same two buttons mean different things depending on current mode (Mobile/Calm/Combat) and current Stance — this contextual reuse is the core depth engine.
scale~15–30 total executions per character across all stances/weapons (rough, unconfirmed number).
establishedLanding a hit gives both a shortened Recovery and access to follow-up options, not just damage/status on the target.Follow-up sequences themselves aren't designed yet — expected to be where a large share of the system's weight and risk comes from.
explainDoes the Stance → Release → Recovery sequence deserve formal sub-Mode status of its own (i.e. is it part of the top-level Mode graph), or does it stay a purely internal Combat mechanic that the graph doesn't need to model?Relocated from Modes, where it couldn't actually be answered — it depends on this subsection's own definitions settling first. Still open, needs more discussion — but the actual default behavior is already settled regardless of how it's modeled: by default, completing Stance→Release→Recovery returns you into Combat (Neutral), not out to Calm. This question is purely about whether the Mode graph needs to represent that internally, not about what the behavior is.
S5 Cancel & Feinting (d1)
flaggedCancel can interrupt Stance or early Release and redirect into a different Stance, at a cost (not instant — vulnerable frames you must survive).Cast into doubt 2026-07-20 by a more precise answer below: Cancel was originally envisioned as applying to interrupting a Release's execution animation specifically, not a mere Stance/windup switch — this note's "can interrupt Stance" framing may be too broad. Needs re-review against the note below rather than trusting both as simultaneously true.
establishedSwitching Stances while still mid-windup (before committing to a Release) is not automatically a Cancel — that swap is free, since nothing's actually been executed yet. Cancel applies to interrupting the execution/animation of a Release (or later), at minimum. Exception: a Stance that itself behaves like an execution — has its own windup/vulnerability the way a Release does (e.g. a "chanting" Stance) — makes leaving that Stance count as a real Cancel too.
designFeinting isn't a special system — it's just "Cancel → Windup(different action)" as a first-class transition. Fists have the widest cancel window of any weapon type, which is what makes hand-to-hand the highest skill ceiling.
answeredCancel cost scales by weight, not flat — heavier/slower windups cost more to cancel out of than light ones.Leaning, not fully locked — user's own framing was tentative ("not sure what the costs... relates to, but scaling by weight is probably accurate"). Treat as the working default, revisit if it doesn't hold up once actual numbers get attached.
answeredSame underlying window as ordinary post-Release Recovery, not a distinct mechanic — but outcome-modulated the same way an ordinary hit-during-Recovery extends Recovery (see Stance & Release): a successful Cancel likely shortens the resulting Recovery window, while getting hit while canceling likely extends it (or causes some other, not-yet-defined penalty).
S6 Charge & Damage Scaling (d1)
chargeHolding left/right click while in a Stance builds charge up to a cap; releasing early = lower damage (e.g. ~1.0x), releasing near cap = higher (e.g. ~1.4x).
chargeBlocking also scales with hold time (up to ~1–1.5s) — reduces damage taken, but blocking without a follow-up plan is just delaying the loss.
establishedOvercharge isn't a hard numeric punishment — holding a charge past its peak lets momentum/velocity fall back off, degrading the eventual swing back down toward what an uncharged release would have done, rather than staying capped at the peak or getting an explicit penalty applied. The real cost of overcharging is exposure: the longer a player holds, the longer they're telegraphing what's coming, which is itself an opening an opponent can read or punish. Charging up is slower than the discharge/release itself.
S7 Hit Locations / Positional Damage (d1)
establishedHitboxes are split by body region: head, torso, left arm, right arm, left leg, right leg.
establishedAttacks from behind deal a damage bonus. This is universal — the same bonus in Calm as in Combat, not mode-dependent — with a small number of exceptions.
establishedThe exceptions are gear- and anatomy-driven, not a fixed rule list. Gear can cover a region well enough from one side (e.g. back armor) to blunt the bonus that would otherwise apply. The "behind = bonus" framing assumes an anthropological base actor — humans are physiologically better protected from the front, so torso sides, the side of the head, and almost the entire backside are all comparably vulnerable, not just the literal rear. Non-human creatures aren't guaranteed to follow that pattern: a warthog, for example, is optimally hit from the sides/belly, not "behind" in the human sense.Non-human/creature hitbox vulnerability zones will need their own per-species definition — flag for whenever non-human actors are designed.
establishedEach of the 6 hit regions (head, torso, left/right arm, left/right leg) has its own Fortitude — a per-region durability stat. What depleted Fortitude does is region-specific: arms degrade equipped-weapon function (see Immobility); legs risk a knockdown into Incapacitation; head and torso behave differently again — see below.
establishedLegs specifically: sufficiently low leg Fortitude from a hit (explosions and other heavy impacts named as examples) can knock a player onto the ground, triggering Incapacitation. Conditional, not automatic — depends on how much Fortitude the hit actually takes, and possibly mediated by a fall-breaking mechanic (not yet defined).
flaggedHead hits are comparatively simple by design — "cut and dry," matching how a surprise/unseen head hit already reads in most games with a head hitbox. Not further complicated the way torso/legs/arms are.Cast into doubt by the weapon/velocity-dependent lethality answer below: in many cases a head hit kills outright the same way a heart hit does, which depends on weapon and force behind the hit — not obviously "cut and dry" anymore. Needs re-review, not necessarily a reversal — head may still be simpler in practice than torso even if it isn't a flatly separate case.
answeredTorso/heart lethality is weapon-type and force/velocity dependent, not a flat Fortitude-depletion curve the way arms/legs are — this is what makes torso mechanically more complex. A precise heart hit can kill the baseline (human) actor outright through sheer damage — not a literal HP-bypass — and a head hit often can too, under the same logic; both depend on the weapon and the velocity/force actually behind the hit. Stabbing reaches the heart far more easily than slashing, which needs substantially more velocity/force to cut deep enough to matter. A fist strike to the same spot doesn't matter regardless of location — insufficient force, full stop. Bodies have depth (a torso hit's lethality depends on how deep it penetrates, not just where it lands), which is part of why torso is the complex region — but how to actually model/implement penetration depth isn't defined yet.Ties directly to the still-undefined nature of Health itself — see the new foundational question in Health / TTK / Stamina, which this was the trigger for.
explainBody depth was floated above as necessary for torso/head lethality to make sense (how far a hit penetrates matters, not just which region it lands in) — but how to actually model or implement penetration depth isn't defined yet.
establishedBackstabs can cause Incapacitation, but indirectly — through whichever region the backstab lands on, not as an automatic universal rule.
Deferred: exact Fortitude numbers/thresholds per region — an earlier pass sketched specific per-location percentages, but that was premature detail and got pulled back out. Revisit with real numbers once the region-specific effects above (torso especially) are fully defined, including how location interacts with Mobile's jog/sprint tiers and whether location matters outside Mobile at all.
S8 Defense (Block/Parry) (d1)
establishedBlock and Parry are both Combat-only — Calm has no defensive action of its own (see Modes). Block is available anytime within Combat (damage reduction); Parry redirects the attack and pulls the player into Combat's internal Neutral sub-gear (see Stance & Release).
S9 Weapons & Character Styles
scopeFirst weapon set: fists, dagger, gladius, katana (or similar reach-tier blade), automatic gun, bolt-action/revolver-style single-shot.
flaggedTwo layers to a character: (1) Character/style — determines how stances resolve into different executions even with the same weapon, (2) Weapon — determines available Stances/Releases and timing profile.Cast into doubt 2026-07-20 by the Trait/Skill/Weapon layering answer in Character Traits / Kit: "how stances resolve into different executions" sounds like it's describing the Skill system (learned/practiced proficiency), not a Trait-based identity layer. Still unresolved after a real attempt — see the follow-up note below rather than treating this line as current.
brainstorm: styleWhat "Style" actually is was worked through at length 2026-07-20, not resolved — user's own close: "I just don't know." Three placements were tried: (1) Style as a fixed, backstory-baked discipline a specific character was trained in (Trait-adjacent, tied to the character-selection/lineage lore in Setting & World → Tone / Fiction) — broke down against three real cases: what does an untrained character have, can a character pursue different training later, and can styles overlap/blend? A purely fixed Trait-like Style can't easily answer any of those. (2) Style folded fully into Skill — plausible, but didn't sit right on its own. (3) Style as a subcategory of Weapon, prompted by the user's own instinct that a style needs an object to apply to (a "sword style" is meaningless without a sword) — closest to correct, but Weapon doesn't obviously own Style the way it owns available Stances/Releases.
Leading (not locked) synthesis: Style is a school/grouping within the Skill tree (see Character Traits / Kit for the tree/motion-transfer model), where the tree's branches happen to be scoped by weapon category — an overhead-swing branch only exists in the context of bladed/blunt weapons, never guns, which is exactly why style always needs "a thing" to apply to without Weapon needing to own it as a property. This framing resolves all three break-cases at once: no training = no investment in that branch yet (a valid starting state, not a null case); pursuing other training = investing in a different branch later, same slow-acquisition/decay mechanic Skill already has; overlap = ordinary partial investment across branches, which trees support natively. Not confirmed — flagged as the current best guess to revisit once Skill's actual tree gets designed.
Leading (not locked) synthesis: Style is a school/grouping within the Skill tree (see Character Traits / Kit for the tree/motion-transfer model), where the tree's branches happen to be scoped by weapon category — an overhead-swing branch only exists in the context of bladed/blunt weapons, never guns, which is exactly why style always needs "a thing" to apply to without Weapon needing to own it as a property. This framing resolves all three break-cases at once: no training = no investment in that branch yet (a valid starting state, not a null case); pursuing other training = investing in a different branch later, same slow-acquisition/decay mechanic Skill already has; overlap = ordinary partial investment across branches, which trees support natively. Not confirmed — flagged as the current best guess to revisit once Skill's actual tree gets designed.
designGuns are fundamentally different: the entire mechanism IS the windup. Bullet velocity may scale with character movement speed at time of fire instead of a stance-charge.
S10 Character Traits / Kit (d1)
establishedPer-character traits, executable skills, or items can grant exceptions to the default mode-transition rules from Modes — e.g. a trait allowing direct Mobile→Combat, or a skill that drops you straight from Combat back to Calm instead of Cancel-and-restart. These are opt-in exceptions layered on top of the default Mode graph, not a replacement for it.
establishedTrait, Skill, and Weapon are three distinct layers: what a character is (Trait, intrinsic identity), what a character has learned (Skill, practiced technique/proficiency), and what a character is using (Weapon). A character's apparent "preference" for a given weapon is a Skill phenomenon — more practice with it — not a Trait or identity thing.See Weapons & Character Styles for the still-unresolved fallout of this on that Section's own layer naming.
establishedTrait is fixed, not loadout-based — intrinsic to the character type, part of what that character fundamentally is, not something picked or swapped before a match.Only one character type exists so far; the payoff of "intrinsic to type" shows up once multiple character types exist, a post-MVP discussion — see Modes → Mobile → Aerial.
yes/noCan a trait-granted transition exception be read/anticipated by an opponent the same way default transitions can, or does it introduce genuinely hidden information?Flag: the whole system's core tension (see UX → Telegraphing & Clarity) depends on opponent state being readable. An unreadable trait-based mode-skip could undercut that at a systemic level, not just a balance level. No longer blocked on the vocabulary question below — Trait itself is now defined — just still genuinely unanswered.
explainFoundational, surfaced 2026-07-20: what actually distinguishes a Trait from a Skill, an Attribute, an Ability, and a Spell? Partial progress made 2026-07-20, still genuinely open overall:
Trait — settled: intrinsic to the character type, part of what a character fundamentally is, not learned or chosen. Not a clean opposite of Disabled either, despite both being "fixed" in some sense — a Disability can be acquired randomly/in-world, a Trait just is what you are from the start. The exact edge between them isn't fully drawn, just no longer assumed to be a simple positive/negative mirror pair.
Attribute — deliberately not being defined right now. User explicitly doesn't want to discuss raw stats at all at this stage (ties to the development-priority philosophy in Game Modes → Parked / Future Modes — numbers layer on later, not now). Do not assume Attribute = stat; that candidate was floated and explicitly declined, not confirmed.
Skill — settled: a learned/practiced technique, matching the original candidate. Acquisition/decay model floated 2026-07-20, adapted from an unrelated passive project of the user's (a civilizational model where power is distributed via a weight system checked against a digital system — mechanics of that source system not relevant here, just the borrowed principle): skills are acquired relatively slowly, and decay with disuse — a kind of reverse cooldown, losing aptitude for something you haven't done recently. Decay itself isn't flat: the higher a skill was ever raised, the faster it degrades once neglected (a "further to fall" curve, not a constant rate). Crucially, disuse impedes current performance but not the underlying memory of having learned it — relearning something previously mastered is faster than learning it fresh, the same way real skill/muscle memory works. Not yet worked out how this actually plugs into the rest of the system, just the base principle.
Ability — genuinely undecided, user hasn't formed a position yet and wants to think through the word's etymology before deciding whether it even belongs in this taxonomy at all. Do not assume the earlier "granted active action" candidate.
Spell — undefined, user deliberately not going further into it yet. Strong adjacent opinion on record though: dislikes how magic systems typically work about as much as typical combat systems, and specifically rejects the "automatically-charging arbitrary resource" (mana-style) model — magic-like effects should cost something closer to a real fuel/resource, possibly in addition to an arbitrary pool rather than instead of one. See the companion philosophy note in Game Modes → Parked / Future Modes.
Trait — settled: intrinsic to the character type, part of what a character fundamentally is, not learned or chosen. Not a clean opposite of Disabled either, despite both being "fixed" in some sense — a Disability can be acquired randomly/in-world, a Trait just is what you are from the start. The exact edge between them isn't fully drawn, just no longer assumed to be a simple positive/negative mirror pair.
Attribute — deliberately not being defined right now. User explicitly doesn't want to discuss raw stats at all at this stage (ties to the development-priority philosophy in Game Modes → Parked / Future Modes — numbers layer on later, not now). Do not assume Attribute = stat; that candidate was floated and explicitly declined, not confirmed.
Skill — settled: a learned/practiced technique, matching the original candidate. Acquisition/decay model floated 2026-07-20, adapted from an unrelated passive project of the user's (a civilizational model where power is distributed via a weight system checked against a digital system — mechanics of that source system not relevant here, just the borrowed principle): skills are acquired relatively slowly, and decay with disuse — a kind of reverse cooldown, losing aptitude for something you haven't done recently. Decay itself isn't flat: the higher a skill was ever raised, the faster it degrades once neglected (a "further to fall" curve, not a constant rate). Crucially, disuse impedes current performance but not the underlying memory of having learned it — relearning something previously mastered is faster than learning it fresh, the same way real skill/muscle memory works. Not yet worked out how this actually plugs into the rest of the system, just the base principle.
Ability — genuinely undecided, user hasn't formed a position yet and wants to think through the word's etymology before deciding whether it even belongs in this taxonomy at all. Do not assume the earlier "granted active action" candidate.
Spell — undefined, user deliberately not going further into it yet. Strong adjacent opinion on record though: dislikes how magic systems typically work about as much as typical combat systems, and specifically rejects the "automatically-charging arbitrary resource" (mana-style) model — magic-like effects should cost something closer to a real fuel/resource, possibly in addition to an arbitrary pool rather than instead of one. See the companion philosophy note in Game Modes → Parked / Future Modes.
designFloated 2026-07-20: other systems (magic and Abilities named directly, plus confirmed Calm-only activities — gathering, acquiring world resources, world-object interaction) would scale off the Skill system at minimum, and likely other things too — equipment was named as a candidate second input. Confirms Skill isn't combat-exclusive; non-combat, Calm-gated activities are expected to have their own trainable skills too.
designSkill transfer principle, floated 2026-07-20: skill is tied to the underlying motion/technique, not the specific tool or weapon used to practice it — repeatedly using a pickaxe trains its overhead-swing motion, which would also improve unrelated weapons that share that same motion (a broadsword, a large axe), but wouldn't meaningfully improve an unrelated motion like a stab. Separately, and regardless of technique-specificity, general physical activity always raises baseline physical capability on its own — a distinct, non-technique-specific layer underneath the motion-specific skill transfer above.
establishedSkill is represented as a branching tree, not flat lists — general/base motions (e.g. an overhead swing) branch out into progressively more specialized ones, mirroring the motion-transfer principle above. Unlike a typical game "skill tree" (which gates what you're allowed to do), this tree is about how well you can do something you can already attempt — proficiency/mastery, not access.Exact tree shape/content is still undesigned; the paradigm itself is the settled part.
explainFloated 2026-07-20: equipment itself might carry its own Traits and/or Abilities, not just the character — implementation completely undecided, just the idea that gear-level Traits/Abilities could exist alongside character-level ones.
S11 Neutral Game & Spacing
Filler. How range/distance interacts with mode choice, and how melee-vs-gun spacing tension resolves moment to moment.
S12 Health / TTK / Stamina
Filler. Needs: health pool size relative to charged-hit damage (theme is "one mistake can end it" → likely low HP / high burst), whether stamina gates repeated stance entry or charging, regen between exchanges.
answeredFoundational, surfaced 2026-07-20 while resolving the torso/heart instakill question in Hit Locations, answered (as a strong lean, not fully locked) later the same day: user would avoid a traditional numeric Health pool entirely if at all possible. In its place, the real threshold is succumbing — reaching a point where you simply can't act or fight anymore — read emergently off the stacking of per-region Fortitude, Disability, and Status effects already defined elsewhere, rather than tracked as its own separate number. User's own hedge: "if I can avoid using a health system, I'm probably going to" — direction is clear, exact mechanism (how "can't act anymore" actually gets computed from the underlying pieces) isn't designed yet.
philosophyDeath, surfaced 2026-07-20: user is most inclined toward death being either permanent or transformative, not a respawn-and-continue mechanic — this is a leaning, not a locked decision, and doesn't rule out persistent-character modes existing elsewhere. Even where an entity dies outright, the intent is to keep tracking that entity in some system even after it no longer exists in the world, rather than the data simply ending. Exact shape of that tracking (what it's for, what persists, whether the player sees it) is undefined.The likely mechanism surfaced later the same day: see the character-selection/lineage system in Setting & World → Tone / Fiction — dying doesn't necessarily end the underlying lineage, even if it ends that specific playthrough.
S13 Hit Feedback & Hitstop
Filler. How charge level, blocks, and parries are communicated in the moment (hitstop/freeze-frames, screen shake) so fast, calculated play stays readable.
S14 Practice / Training Space
Filler. Given the system's complexity, a dedicated space to learn timings against a dummy or in isolation.
C2 Movement
S1 Base Movement
Filler. Base walk/run speed, acceleration/friction feel, jump arc, crouch.
S2 Mode-Speed Interaction (d1)
designNon-combat mode runs faster; Combat mode still fairly fast but with more drag and different movement mechanics while in a Stance (progressive speed penalty the longer you're wound up).
establishedJog-to-sprint is a continuous ramp, not two discrete steps — a player accelerates from jog up to sprint speed over the default transition time noted under Modes, rather than snapping between two flat values.
explainFloated alongside the ramp answer: sprint may conditionally unlock other actions once reached — e.g. taking flight — rather than just being a higher flat speed. Not defined which actions, or what "conditionally" means here (a resource cost, a specific input, terrain/context-gated). Likely ties to Modes → Mobile → Aerial.
S3 Momentum & Velocity
Filler. How velocity carries between modes — e.g. bullet velocity scaling off movement speed at time of fire (noted under Combat) belongs here too as a general momentum rule.
answeredConfirmed to apply beyond guns: a deliberate leaping strike (jump momentum carried into a melee Stance already active before leaving the ground — see Modes → Mobile → Aerial) should add jump momentum to strike force under the same general rule. Exact formula/scaling still undefined — this subsection remains the right home for that math once it's worked out.
S4 Traversal & Verticality
designWall-crawling and ceiling-crawling as core traversal, not just a gimmick — feeds directly into Mobile's Aerial gear (see Modes → Mobile).
environmentElevation asymmetry as a terrain factor: having the high ground should be a real mechanical advantage/disadvantage (sightlines, escape options, maybe fall-damage-into-melee risk) independent of who built for it — a byproduct of map geometry, not a character stat.
S5 Dashes / Special Movement
Filler. Dashes, flips, wall-runs — floated once as gun-user mobility options to offset lack of melee feint depth.
C3 Game Modes
S1 1v1
modeThe primary proving ground. Comparable feel-references: "Your Only Move Is Hustle" (visual/pacing) and "Rounds" (closer to actual play feel).
S2 Free-For-All (~25)
modeNot a battle royale exactly. Closer to Angel Arena (Warcraft 3 mod): pick a hero, roam a map, fight, acquire things on the map. Jungling-adjacent feel.
S3 Parked / Future Modes
philosophyDeliberately not oversaturating with modes now. Combat system should be able to slot into a broader sandbox/stealth-deception mode later — the "Among Us for adults" idea, positioning/line-of-sight/weapon-scarcity driven. Not being built now.
philosophyBroader scale ambition, not a current commitment: currently designing around a sandbox/Playbox PvP core (create a mode, create rules, execute the systems) — but built with the awareness that this combat system could eventually grow toward something at the scale of an alternative ARPG/MMO (TERA named as a reference point), with a much wider roster of status effects, good and bad, and nonsensical systems (e.g. a floated magic system) layered on top. Process: build the core system at something like Minecraft's baseline simplicity, then let it grow toward Minecraft's actual in-practice complexity — sense first, nonsense layered on later, not designed in from the start.
philosophyNamed reference point, framed as something to do better than, not resemble: Entropia Universe, cited directly by the user as an example of an exploitative real-money virtual economy. Ties to the still-open monetization question in Game Details — the reluctance to commit to a monetization model now is downstream of this: what this becomes at scale isn't decided, so how it would ever be monetized isn't either.
philosophyDevelopment priority order, stated directly 2026-07-20: movement, combat, and environment-interaction come first, built toward the "realistic core" principle already established elsewhere in this doc — deliberately not stat-driven the way typical action-RPG combat is ("the majority of the force and power behind your actions" shouldn't be arbitrary spreadsheet numbers). RPG-style progression numbers aren't rejected — explicitly wanted too — but the game isn't built around them; they layer onto the movement/combat foundation later, not the reverse. Reference points named directly: Monster Hunter's combat as something admired specifically for feeling skill/weight-driven rather than stat-driven; World of Warcraft's face-tank-and-heal-through-it combat as the pattern being avoided — "serious... in the way you choose to do things," not necessarily in tone or appearance. World, art style, audio style, and similar are all expected to naturally emerge once the movement/combat foundation is solid, not designed in parallel with it now. Explicit stakes, user's own words: "without something novel, none of that matters" — the project's viability rests on the combat/movement system itself being genuinely differentiated; everything else is downstream and contingent on that succeeding first.
philosophyMagic system, surfaced 2026-07-20 while working the Trait/Skill/Attribute/Ability/Spell vocabulary: user is strongly opinionated here — dislikes how magic systems typically work about as much as they dislike default/typical combat systems, which is exactly the same energy behind this project's whole combat-first approach. Core rejected pattern: magic-like effects (a fireball, etc.) shouldn't be paid for purely with an automatically-charging arbitrary resource (the generic "mana" model). Preferred direction, not yet designed: cost something closer to a real fuel/resource — possibly stacked on top of an arbitrary pool rather than replacing it entirely, not just swapping one abstraction for another. Nothing else about the magic system (what it does, how "Spell" specifically works) is defined yet — this is a cost-model opinion, not a system design.
C4 Multiplayer & Netcode
S1 Timing / Latency Sensitivity
Filler. Given how much of this system lives in precise hold-timing and cancel windows, online play will be very sensitive to latency/rollback handling.
S2 Server Model
Filler. Dedicated / P2P / rollback — architecture choice, kept here since it's still player-facing (feel), separate from deep implementation in Engine & Technical.
S3 Matchmaking
Filler.
C5 Control Scheme
S1 Mouse & Keyboard Map
inputsMouse + keyboard. Left click / right click = dominant / nondominant execution buttons. WASD for movement.
inputsKey space under consideration: Q E R T F, 1 2 3 4 5, maybe F1–F3, Tab, tilde, X Z C V — many as modifiers rather than direct actions.
Reminder: all specific key bindings are placeholders until the mode system is locked.
S2 Mode-Shift Keys (d1)
establishedSwitching out of a Stance before committing to a Release is free by default (see Cancel & Feinting) — nothing's been executed yet, so it isn't a Cancel. Only interrupting an actual Release execution (or an execution-like Stance) costs via Cancel.Q/E's role as mode-shift keys still needs its own pass once more of the input map is defined — this only resolves the free-vs-costed question, not the binding itself.
S3 Rebinding / Accessibility
Filler. Full rebinding, hold-vs-toggle for charge/block, colorblind-safe telegraph cues.
S4 Controller Support
Filler. Whether a gamepad layout is planned, and how dominant/nondominant maps to triggers/bumpers.
C6 User Perspective
S1 Camera
cameraLeaning toward a Dragon's Dogma / Aetheron-style locked follow-behind camera. Feels quasi-isometric at times.
environmentCrosshair-based targeting means the camera itself creates blind spots — a player standing just outside the crosshair's hover radius may go unseen even in the open, separate from any Sneak/obscurity mechanic. Worth treating as its own readability factor, tied to Opponent-State Readability below.
S2 Opponent-State Readability
Filler. Can you visually tell what stance/charge level an opponent is in from the fixed camera angle?
S3 HUD & Framing
Filler. What's on screen (health, charge meters, stamina) given the locked camera.
C7 UX
S1 Telegraphing & Clarity
Filler. How windups/feints are telegraphed clearly enough to read at speed without giving away too much — the core tension of the whole game.
S2 Onboarding / Tutorial
Filler. How a new player is taught stance/cancel/charge without a wall of text.
S3 Settings & Options
Filler.
C8 Engine & Technical
stub — implementation only, kept separate from design intent above.
S1 Engine Choice
Filler. Godot was mentioned early on for the original 2D prototype idea.
S2 Physics / Networking Architecture
Filler.
S3 Tooling / Pipeline
Filler. Mocap retargeting pipeline (DeepMotion/Cascadeur → rig) belongs here as the technical counterpart to Art Style's Animation/Mocap note.
C9 Art Style
S1 Visual Direction
direction3D, not 2D. Reference feel: Dragon's Dogma / Aetheron beta — locked-behind-camera that reads almost isometric at times.
fidelityAbove Pokémon-level simplicity, well below Yu-Gi-Oh-style density. No redundant decoration.
S2 Silhouette Readability
Filler. Given how much this game depends on reading an opponent's stance/charge at speed, silhouette clarity per weapon/stance may matter more here than in most games.
S3 Animation / Mocap
animationAI/webcam-based motion capture (DeepMotion, Cascadeur, Rokoko Video, Move.ai) is the planned path.
S4 VFX Language
Filler. Visual language for charge level, parry windows, cancel windows — ties into Hit Feedback under Combat.
S5 Color & Mood
Filler.
C10 Audio
S1 Combat Feedback Audio
Filler. Sound as a second information channel alongside visuals — cues for charge level, parry timing, feints. Likely as important here as VFX given the read/react nature of the system.
S2 Music / Ambience
Filler.
S3 Voice / Barks
Filler.
C11 Progression & Meta
S1 Session Loop
Filler. Why a player comes back tomorrow — not yet discussed.
S2 Ranking / Skill Tracking
Filler. Not yet discussed.
S3 Roster Unlocks
Filler. Not yet discussed.
designThe permanent-disability/permanent-positive-trait tradeoff system floated in Status was flagged by the user as extending here too — a possible build-defining unlock/progression axis, not just a Status mechanic. Not developed yet; just the pointer.
designLikely the real home for the "roster" side of the character-selection/lineage system revealed in Setting & World → Tone / Fiction — players choosing from organically-born, already-identified characters rather than creating one is fundamentally a Roster Unlocks question, not just a Tone/Fiction one. Not developed here yet; the fiction-level reveal came first.
S4 Cosmetics
Filler. Not yet discussed.
C12 Setting & World
stub — may stay minimal; some PvP-first games (e.g. Rounds) carry almost no setting at all.
S1 Tone / Fiction
philosophyFoundational reveal, 2026-07-20, surfaced while trying to answer Health / TTK / Stamina: players don't create characters from scratch. They select an existing character — one "organically born" inside the world through a process the user hasn't determined yet and doesn't intend to for a long time. The character already has an established identity before the player takes it on; playing is described directly as "all acting," inhabiting something that already exists rather than authoring it. User frames this as a deliberate break from genre convention going back to the earliest character-creation games ("defying things that were established with games on Atari").
philosophyLineage, 2026-07-20: when players coordinate (mechanism undefined), it's possible to establish lineages — meaning a player can potentially be reborn back into the same genetic/narrative line their previous character died in, rather than simply picking an unrelated new character afterward. This is the likely mechanism behind the still-open death-tracking intent noted in Health / TTK / Stamina — dying may end a specific character without ending what that player is connected to in the world.
Everything else about Tone/Fiction is still filler — this is a foundational pillar, not a finished picture. World-generation mechanics for how characters are "born," what determines lineage eligibility, and how this connects to Roster Unlocks (see Progression & Meta → Roster Unlocks) are all undesigned.
S2 Map / Location Concepts
Filler.
design principleAnchor principle: the environment should grant real, asymmetric mechanical advantage/disadvantage on its own — lighting (see Sneaking), cover (see Sneaking), elevation (see Traversal & Verticality), and camera blind spots (see Camera) — independent of character build. Map/location design should lean into that rather than building purely neutral arenas.