dead-air/game-planning
Watch
3
0
Fork
You've already forked game-planning
 1
Code Issues 22 Pull requests 1 Projects Releases Packages Wiki Activity Actions

[Planning] Redot primitive layer: base mechanics architecture #19

New issue
Open
opened 2026-10-18 14:12:34 +00:00 by muse-lantern · 10 comments
muse-lantern commented 2026-10-18 14:12:34 +00:00
Member
Copy link

Purpose

Design the base-layer primitives that all game mechanics build on. These are the foundation — damage, inventory, player avatar, health display, items, interaction.

Status: Planning phase. No implementation yet.

Proposed primitive set

1. Health & Damage

  • Health component — current/max, damage()/heal() methods, signals on change/death
  • Damage event — type, amount, source, hit location (structured, not just a number)
  • Damage types — ballistic, anomaly, fall, environmental (extensible enum)
  • Damage resistance/armor hooks (for later)

2. Item (base class)

  • Item — name, weight, volume (for volumetric inventory), Affected %, Affliction
  • Item types — weapon, consumable, artefact, material, container
  • Item instances vs item definitions (definitions are data, instances carry state)
  • All items flow through the Affected %/Affliction lifecycle

3. Inventory

  • Volumetric container — 3D volume, non-clipping placement (the backpack)
  • Weight tracking — ties to movement penalties
  • Item registry — what items exist in the game
  • Container interface — backpacks, pouches, bracers all implement it differently

4. Player Avatar

  • VR rig — head, hands, tracked body
  • Player view: HL:Alyx-style (visible hands + arms in first person, body implied)
  • Future multiplayer: proper full player model needed eventually (not now)
  • Asset library: Zach has Larian Studios assets to evaluate for usable models
  • Locomotion — movement method (TBD: teleport, smooth, etc.)
  • Interaction — grab, use, combine (the verbs)
  • Bracer slots — quick-access, wrist-mounted
  • Grip poses are skeleton-dependent — avatar rig defines the hand bones

5. Health Display (VR-appropriate)

  • Diegetic over HUD — wrist display? in-world? physical feedback?
  • Damage feedback — vignette, haptics, audio cues
  • No flat-screen HUD elements floating in space

6. Interaction System

  • Interactable interface — anything the player can grab/use
  • Grab system — physics-based grabbing
  • Use system — context-sensitive "use" action
  • Ability interactables hook in here (telekinetic grabs, artefact gates)

Ranged grab (two-tier):

  • Short range: ITR-style telekinetic grab — reach out, pull nearby objects to hand
  • Long range: HL:Alyx-style gravity glove yank — flick wrist, object arcs to you
  • Resonite ProtoFlux exists for the arc math (community-made, custom simulated
    physics since Resonite has no native physics engine — was janky)
  • In Redot this should be much cleaner with a real physics engine: proper
    projectile arc calculation instead of hand-rolled simulation
  • The arc should feel physical — the object has weight, it travels through space,
    you catch it. Not a teleport.

Architecture notes

  • Autoloads for global systems (InventoryManager, DamageSystem?)
  • Base classes for Item, Container, Damageable
  • Components for Health, Grabbable, Usable
  • Data-driven where possible (item definitions as Resources, not hardcoded)
  • Modding-friendly from day one (see #17)

Resonite prototyping

  • Fresh clean base for prototyping primitives in Resonite
  • Refinement in Resonite is NOT expected to be proper — it is concept validation
  • Resonite "collections" (data tables) are helpful for structuring item data
  • Core concepts transfer to Redot; implementation is Redot-native

Open questions

  • Which primitives first? (suggested: Item → Health → Interaction → Inventory → Avatar → Display)
  • How much should be Resonite-prototyped vs designed on paper?
  • Signal-based or direct-call for damage events?
  • Should Affliction be part of the base Item or a separate component?
## Purpose Design the base-layer primitives that all game mechanics build on. These are the foundation — damage, inventory, player avatar, health display, items, interaction. **Status:** Planning phase. No implementation yet. --- ## Proposed primitive set ### 1. Health & Damage - **Health component** — current/max, damage()/heal() methods, signals on change/death - **Damage event** — type, amount, source, hit location (structured, not just a number) - **Damage types** — ballistic, anomaly, fall, environmental (extensible enum) - Damage resistance/armor hooks (for later) ### 2. Item (base class) - **Item** — name, weight, volume (for volumetric inventory), Affected %, Affliction - **Item types** — weapon, consumable, artefact, material, container - Item instances vs item definitions (definitions are data, instances carry state) - All items flow through the Affected %/Affliction lifecycle ### 3. Inventory - **Volumetric container** — 3D volume, non-clipping placement (the backpack) - **Weight tracking** — ties to movement penalties - **Item registry** — what items exist in the game - Container interface — backpacks, pouches, bracers all implement it differently ### 4. Player Avatar - **VR rig** — head, hands, tracked body - **Player view:** HL:Alyx-style (visible hands + arms in first person, body implied) - **Future multiplayer:** proper full player model needed eventually (not now) - **Asset library:** Zach has Larian Studios assets to evaluate for usable models - **Locomotion** — movement method (TBD: teleport, smooth, etc.) - **Interaction** — grab, use, combine (the verbs) - **Bracer slots** — quick-access, wrist-mounted - Grip poses are skeleton-dependent — avatar rig defines the hand bones ### 5. Health Display (VR-appropriate) - Diegetic over HUD — wrist display? in-world? physical feedback? - Damage feedback — vignette, haptics, audio cues - No flat-screen HUD elements floating in space ### 6. Interaction System - **Interactable interface** — anything the player can grab/use - **Grab system** — physics-based grabbing - **Use system** — context-sensitive "use" action - Ability interactables hook in here (telekinetic grabs, artefact gates) **Ranged grab (two-tier):** - **Short range:** ITR-style telekinetic grab — reach out, pull nearby objects to hand - **Long range:** HL:Alyx-style gravity glove yank — flick wrist, object arcs to you - Resonite ProtoFlux exists for the arc math (community-made, custom simulated physics since Resonite has no native physics engine — was janky) - In Redot this should be *much* cleaner with a real physics engine: proper projectile arc calculation instead of hand-rolled simulation - The arc should feel physical — the object has weight, it travels through space, you catch it. Not a teleport. --- ## Architecture notes - **Autoloads** for global systems (InventoryManager, DamageSystem?) - **Base classes** for Item, Container, Damageable - **Components** for Health, Grabbable, Usable - Data-driven where possible (item definitions as Resources, not hardcoded) - Modding-friendly from day one (see #17) --- ## Resonite prototyping - Fresh clean base for prototyping primitives in Resonite - Refinement in Resonite is NOT expected to be proper — it is concept validation - Resonite "collections" (data tables) are helpful for structuring item data - Core concepts transfer to Redot; implementation is Redot-native ## Open questions - Which primitives first? (suggested: Item → Health → Interaction → Inventory → Avatar → Display) - How much should be Resonite-prototyped vs designed on paper? - Signal-based or direct-call for damage events? - Should Affliction be part of the base Item or a separate component?
merith-tk commented 2026-10-19 23:06:23 +00:00
Owner
Copy link

Movement I want both Teleport and Smooth transportation,

Teleport Movement should have taken into consideration people abusing it to cheese areas that are meant to take a while to get through or specific movement things, consuming stammina to use in general rapidly

Smooth Movement should have two things, walking and sprint speeds.

For all controls we are mapping the meta quest controls of grip, trigger, joystick, stick click, two face buttons, and capacitive presence for interactables such as range or gravity grabs, a seperate physical movement and gesture for either

Movement I want both Teleport and Smooth transportation, Teleport Movement should have taken into consideration people abusing it to cheese areas that are meant to take a while to get through or specific movement things, consuming stammina to use in general rapidly Smooth Movement should have two things, walking and sprint speeds. For all controls we are mapping the meta quest controls of grip, trigger, joystick, stick click, two face buttons, and capacitive presence for interactables such as range or gravity grabs, a seperate physical movement and gesture for either
muse-lantern commented 2026-10-19 23:12:17 +00:00
Author
Member
Copy link

Both modes is the right call for PCVR — comfort for the motion-sensitive, speed for everyone else. A few thoughts on the details:

Teleport anti-cheese: stamina-as-cost is the right lever, but the shape matters. A shared pool with sprint would make the tradeoff real (blink across the gap or sprint out of the anomaly — not both), whereas a per-blink cooldown just paces the cheese instead of preventing it. Two other vectors worth nailing down early:

  • Vertical cheese — does the teleport target have to be grounded / within a height delta of the player? Otherwise every cliff traversal puzzle is one blink.
  • Line-of-sight — blink-to-unseen-point lets players skip entire encounter rooms. Grounded navmesh target + LoS check is the standard answer.

How are you picturing stamina regen — passive, or gated behind something (rest, consumables, the affected % system)?

Walk/sprint: the Quest stick is analog, so the natural mapping is partial deflection = walk, full tilt = sprint (stamina-draining). That frees stick click entirely — were you thinking crouch for it, or something else? Or do you want discrete speeds on a toggle instead of analog?

Capacitive presence for grabs: I like it — touch-to-preview, grip-to-commit is a nice two-stage feel. Two things I'd poke at: capacitive only senses touch, so the "separate physical movement and gesture" for range vs. gravity grabs has to be distinguishable before the grip press, and that's a discoverability risk. What's the physical difference you're picturing between the two gestures?

Also: two face buttons is scarce real estate. What's spoken for on A/B (X/Y), and does anything gameplay-critical risk getting bumped to a chord?

— Lantern

Both modes is the right call for PCVR — comfort for the motion-sensitive, speed for everyone else. A few thoughts on the details: **Teleport anti-cheese:** stamina-as-cost is the right lever, but the shape matters. A shared pool with sprint would make the tradeoff real (blink across the gap *or* sprint out of the anomaly — not both), whereas a per-blink cooldown just paces the cheese instead of preventing it. Two other vectors worth nailing down early: - **Vertical cheese** — does the teleport target have to be grounded / within a height delta of the player? Otherwise every cliff traversal puzzle is one blink. - **Line-of-sight** — blink-to-unseen-point lets players skip entire encounter rooms. Grounded navmesh target + LoS check is the standard answer. How are you picturing stamina regen — passive, or gated behind something (rest, consumables, the affected % system)? **Walk/sprint:** the Quest stick is analog, so the natural mapping is partial deflection = walk, full tilt = sprint (stamina-draining). That frees stick click entirely — were you thinking crouch for it, or something else? Or do you want discrete speeds on a toggle instead of analog? **Capacitive presence for grabs:** I like it — touch-to-preview, grip-to-commit is a nice two-stage feel. Two things I'd poke at: capacitive only senses *touch*, so the "separate physical movement and gesture" for range vs. gravity grabs has to be distinguishable *before* the grip press, and that's a discoverability risk. What's the physical difference you're picturing between the two gestures? Also: two face buttons is scarce real estate. What's spoken for on A/B (X/Y), and does anything gameplay-critical risk getting bumped to a chord? — Lantern
muse-lantern commented 2026-10-20 17:13:33 +00:00
Author
Member
Copy link

Grip poses: authored hand reference as override, procedural grab as default

Refines the grip-pose design above.

The hand reference (authored grips)

  • Artists get a reference hand — the player hand model — to place against the item in Blender, positioning the grip how they like. The reference is authored against the player avatar's hand/skeleton (grip poses are skeleton-dependent).
  • The reference lives in the shared library (blender-assets/_lib/) so every artist works against the same hand.
  • Parenting: a grip reference can be parented to a part of the item — the pump on a shotgun, the slide on a pistol, other moving/sliding parts. The engine follows the reference, so the hand tracks the part as it moves.

No reference = procedural grab (the default)

  • Items without an authored reference get the natural "close hand on object" pose: fingers wrap around the object procedurally, curling until collision stops them.
  • Remote pull: a pulled item arrives at the center of the hand at a default rotation, then the fingers curl. So a remotely grabbed item needs no authored anything.
  • This massively lowers per-item work: generics need zero grip authoring. Authored references are reserved for equipment where the grip actually matters.

Why this ordering

Authored = override, procedural = default. The 90% case (loot, props, junk) costs nothing; the 10% case (weapons, tools) gets artist precision, including grips that ride moving parts.

## Grip poses: authored hand reference as override, procedural grab as default Refines the grip-pose design above. ### The hand reference (authored grips) - Artists get a **reference hand** — the player hand model — to place against the item in Blender, positioning the grip how they like. The reference is authored against the player avatar's hand/skeleton (grip poses are skeleton-dependent). - The reference lives in the shared library (`blender-assets/_lib/`) so every artist works against the same hand. - **Parenting:** a grip reference can be parented to a *part* of the item — the pump on a shotgun, the slide on a pistol, other moving/sliding parts. The engine follows the reference, so the hand tracks the part as it moves. ### No reference = procedural grab (the default) - Items without an authored reference get the natural **"close hand on object"** pose: fingers wrap around the object procedurally, curling until collision stops them. - **Remote pull:** a pulled item arrives at the **center of the hand at a default rotation**, then the fingers curl. So a remotely grabbed item needs no authored anything. - This massively lowers per-item work: generics need *zero* grip authoring. Authored references are reserved for equipment where the grip actually matters. ### Why this ordering Authored = override, procedural = default. The 90% case (loot, props, junk) costs nothing; the 10% case (weapons, tools) gets artist precision, including grips that ride moving parts.
muse-lantern commented 2026-10-20 17:22:56 +00:00
Author
Member
Copy link

Drivable bones: da_rig.bone.<name>

Moving parts on items are armature bones, named with a strict prefix:

da_rig.bone.BONENAME
  • The prefix marks a bone as engine-drivable: on import, the engine scans the skeleton for da_rig.bone.* and exposes those bones as named controls.
  • They can be driven for animation and procedural motion — pump actions, slides, bolts — not just played back.
  • Grip references (see the hand-reference design below) parent to these bones, which is how a hand rides a moving part: the grip targets the bone, the bone moves, the hand follows.

Because the name is a strict convention, references to these bones (from grips, animations, scripts) are checkable at asset-build time — a typo'd or missing bone fails the build, not the play session.

(Prefix corrected 2026-10-20: this thread originally said ds_rid, then ds_rig — both typos. The final prefix is da_rig.)

## Drivable bones: `da_rig.bone.<name>` Moving parts on items are armature bones, named with a strict prefix: ``` da_rig.bone.BONENAME ``` - The prefix marks a bone as **engine-drivable**: on import, the engine scans the skeleton for `da_rig.bone.*` and exposes those bones as named controls. - They can be **driven for animation and procedural motion** — pump actions, slides, bolts — not just played back. - Grip references (see the hand-reference design below) parent to these bones, which is how a hand rides a moving part: the grip targets the bone, the bone moves, the hand follows. Because the name is a strict convention, references to these bones (from grips, animations, scripts) are **checkable at asset-build time** — a typo'd or missing bone fails the build, not the play session. _(Prefix corrected 2026-10-20: this thread originally said `ds_rid`, then `ds_rig` — both typos. The final prefix is `da_rig`.)_
muse-lantern commented 2026-10-20 17:27:20 +00:00
Author
Member
Copy link

The hand rig and authored poses

Naming

The rig prefix is da_rig. The hand rig's bones are named:

da_rig.hand.bone.<name>

The reference hand is scaffolding, not content

  • The hand mesh in an item's .blend is purely visual, for the artist. The system never renders it. What the build extracts is bone-transform snapshots — poses.
  • A pose is a bone-name → transform map. Because the player's own hand rig shares the da_rig.hand.bone.* names, a snapshot authored on the reference hand applies directly to the player's hand (their mesh, the authored pose).

Authored pose set (per item, as needed)

  • Primary grip — right hand and primary grip — left hand (grips are hand-specific; both are authored).
  • Secondary / stabilize pose — off-hand supporting the item.
  • Manipulation poses — a hand operating a moving part: racking a slide, working a pump, pulling a bolt. A manipulation pose can be performed by either hand, and pairs with the part's drivable bone: the hand takes the pose and follows the part as it travels.

Consequences

  • Manual weapon handling (see #15) is built from these: a reload is a sequence of hand poses + part-bone motions, not a canned full-body animation.
  • Items without authored poses still fall back to the procedural wrap-to-collision grab (see the grip comment above). Authored poses are the override, authored where hands-on time justifies it.

(Prefix corrected 2026-10-20: final prefix is da_rig.)

## The hand rig and authored poses ### Naming The rig prefix is **`da_rig`**. The hand rig's bones are named: ``` da_rig.hand.bone.<name> ``` ### The reference hand is scaffolding, not content - The hand mesh in an item's .blend is **purely visual, for the artist**. The system never renders it. What the build extracts is **bone-transform snapshots** — poses. - A pose is a bone-name → transform map. Because the player's own hand rig shares the `da_rig.hand.bone.*` names, a snapshot authored on the reference hand applies directly to the player's hand (their mesh, the authored pose). ### Authored pose set (per item, as needed) - **Primary grip — right hand** and **primary grip — left hand** (grips are hand-specific; both are authored). - **Secondary / stabilize pose** — off-hand supporting the item. - **Manipulation poses** — a hand operating a moving part: racking a slide, working a pump, pulling a bolt. A manipulation pose can be performed by **either hand**, and pairs with the part's drivable bone: the hand takes the pose and follows the part as it travels. ### Consequences - Manual weapon handling (see #15) is built from these: a reload is a sequence of hand poses + part-bone motions, not a canned full-body animation. - Items without authored poses still fall back to the procedural wrap-to-collision grab (see the grip comment above). Authored poses are the override, authored where hands-on time justifies it. _(Prefix corrected 2026-10-20: final prefix is `da_rig`.)_
muse-lantern commented 2026-10-20 19:49:05 +00:00
Author
Member
Copy link

Grip indicator + dynamic grips on parts

Status: working design. The grip system as a whole needs more thought and a prototype before any of this is 100% settled — treat everything in this thread as direction, not final spec.

The indicator

  • A visual indicator sits at the grip pose center — it shows what you are actually about to grab. On normal items, that's the item's center of mass.
  • You can only grab one thing at a time, so the indicator is the targeting disambiguator: picking one item out of a pile, or one part of a gun when other parts are near it.

Dynamic grips on parts

  • The indicator is also what makes dynamic grips usable: you can grab a part directly — e.g. grab the slide of a Makarov — using the procedural/dynamic grip, without the artist authoring a pose for that. Authored poses exist for the primary and secondary grips; everything else can still be grabbed dynamically, and the indicator shows you exactly what you'll get.
  • So the coverage model is: authored poses where they matter (primary, secondary, manipulation), dynamic grips anywhere else, and the indicator unifies both — the player always sees the grab target before committing.
## Grip indicator + dynamic grips on parts **Status: working design.** The grip system as a whole needs more thought and a prototype before any of this is 100% settled — treat everything in this thread as direction, not final spec. ### The indicator - A **visual indicator sits at the grip pose center** — it shows what you are actually about to grab. On normal items, that's the item's center of mass. - You can only grab one thing at a time, so the indicator is the targeting disambiguator: picking one item out of a pile, or one *part* of a gun when other parts are near it. ### Dynamic grips on parts - The indicator is also what makes **dynamic grips** usable: you can grab a part directly — e.g. grab the **slide of a Makarov** — using the procedural/dynamic grip, **without the artist authoring a pose for that**. Authored poses exist for the primary and secondary grips; everything else can still be grabbed dynamically, and the indicator shows you exactly what you'll get. - So the coverage model is: authored poses where they matter (primary, secondary, manipulation), dynamic grips anywhere else, and the indicator unifies both — the player always sees the grab target before committing.
muse-lantern commented 2026-10-23 02:14:19 +00:00
Author
Member
Copy link

Control scheme + rig skeleton (Zach's dictation, 2026-10-22)

The control scheme was previously written down nowhere — it existed only as wiring in the rig scene. Recording it here, with the current-state findings from a code audit:

Movement

  • Move stick: forward/back and strafing — no tank controls. (Audit finding: the rig's MovementDirect never set its strafe flag; library default off = stick X discarded = forward/back only today. Being fixed.)
  • Which stick moves is a config option (left or right); turn rides the other stick.
  • Turn settings are user-configurable: snap ↔ smooth, with player-chosen snap angle and smooth speed. (Provider parameters exist; the settings surface + persistence are the work.)
  • Settings persist in their own file, separate from the run save (they survive across runs, like the global-tracker tier).

Face buttons

  • Pause: HOLD the upper face button (by_button — B/Y) for 2 seconds. Hold, not press, deliberately — the press action stays unallocated for future use. The lower pair (ax_button) also unallocated. (This settles the face-button half of the open questions on this issue; stick-click role still open.)
  • The pause menu pauses the world and offers Options / Save / Load / Return to menu; buttons may be stubbed where the underlying system isn't built yet, if marked as stubs.

Later feature (on the map, not now)

  • Jump = turn stick up; crouch = turn stick down. (The turn provider reads only stick X, so Y is free.)

Player rig skeleton

  • The rig must carry the full avatar-contract skeleton (Resonite ExampleAvatarRig bone names, Chest capitalized) even with no mesh skinned to it, with mock collisions for IK — so a proper player model (found or made) maps straight onto it when one exists. The shipped arms are the 39-bone subset of this contract; this is one skeleton, not two.

— Lantern (from the 2026-10-22 design session)

## Control scheme + rig skeleton (Zach's dictation, 2026-10-22) The control scheme was previously written down *nowhere* — it existed only as wiring in the rig scene. Recording it here, with the current-state findings from a code audit: **Movement** - Move stick: forward/back **and strafing** — no tank controls. (Audit finding: the rig's MovementDirect never set its `strafe` flag; library default off = stick X discarded = forward/back only today. Being fixed.) - **Which stick moves is a config option** (left or right); turn rides the other stick. - **Turn settings are user-configurable:** snap ↔ smooth, with player-chosen snap angle and smooth speed. (Provider parameters exist; the settings surface + persistence are the work.) - Settings persist in their **own file**, separate from the run save (they survive across runs, like the global-tracker tier). **Face buttons** - **Pause: HOLD the upper face button (`by_button` — B/Y) for 2 seconds.** Hold, not press, deliberately — the press action stays unallocated for future use. The lower pair (`ax_button`) also unallocated. (This settles the face-button half of the open questions on this issue; stick-click role still open.) - The pause menu **pauses the world** and offers **Options / Save / Load / Return to menu**; buttons may be stubbed where the underlying system isn't built yet, if marked as stubs. **Later feature (on the map, not now)** - **Jump = turn stick up; crouch = turn stick down.** (The turn provider reads only stick X, so Y is free.) **Player rig skeleton** - The rig must carry the **full avatar-contract skeleton** (Resonite ExampleAvatarRig bone names, `Chest` capitalized) **even with no mesh skinned to it**, with **mock collisions for IK** — so a proper player model (found or made) maps straight onto it when one exists. The shipped arms are the 39-bone subset of this contract; this is one skeleton, not two. — Lantern (from the 2026-10-22 design session)
muse-lantern commented 2026-10-23 03:20:18 +00:00
Author
Member
Copy link

Correction — the pause gesture (Zach, 2026-10-22, supersedes the gesture in comment 596)

Comment 596 above records pause as holding the upper face button for 2 seconds. That was wrong — correction from Zach tonight:

Pause is the legacy gesture: press BOTH face buttons at once (ax + by together on one controller, either hand). The pause menu replaces what that gesture used to call up. It is a press chord, not a hold — the upper button's hold is not allocated to pause, and neither single button press is consumed by it (each face button's own press remains free, as before).

Fixed in da-game PR #9 (commit effbf51): the chord is edge-triggered (fires when the chord completes; holding both doesn't re-fire; one button per hand is not the gesture) and toggles pause like the controller menu button. Everything else in 596 stands (stick side option, turn settings, settings file, jump/crouch later feature, full-skeleton rig requirement).

— Lantern

## Correction — the pause gesture (Zach, 2026-10-22, supersedes the gesture in comment 596) Comment 596 above records pause as *holding* the upper face button for 2 seconds. That was wrong — correction from Zach tonight: **Pause is the legacy gesture: press BOTH face buttons at once** (ax + by together on one controller, either hand). The pause menu *replaces* what that gesture used to call up. It is a **press chord, not a hold** — the upper button's hold is not allocated to pause, and neither single button press is consumed by it (each face button's own press remains free, as before). Fixed in da-game PR #9 (commit `effbf51`): the chord is edge-triggered (fires when the chord completes; holding both doesn't re-fire; one button per hand is not the gesture) and toggles pause like the controller menu button. Everything else in 596 stands (stick side option, turn settings, settings file, jump/crouch later feature, full-skeleton rig requirement). — Lantern
muse-lantern commented 2026-10-23 03:55:09 +00:00
Author
Member
Copy link

Correction retracted — the hold stands, now strict (Zach, 2026-10-22)

Comment 628 (my "correction" from earlier tonight) is itself retracted. Zach's report was a bug report: in the tested build, pressing both face buttons opened the pause menu. I misread it as a design change and briefly implemented the chord he was flagging. Apologies for the churn — the record, final:

Pause = hold the upper face button (B/Y) alone for 2 seconds — comment 596's dictation was right all along. Now implemented strictly in da-game PR #9 (c22d369): each hand's hold timer accumulates only while that hand's B/Y is held and its A/X is not; an A/X press on the same hand at any point resets the timer, so the both-buttons press — any order, any overlap — can never open the menu. Among face-button inputs, the hold is the only way in.

Platform note (Zach, same evening): the current target is Quest controllers via SteamVR — there, the controller menu/system button is reserved by the runtime and not usable by the app, so the hold is the operative in-headset opener. On a native Quest build the menu button would be the conventional opener, so that path (and desktop Esc) stays in code for it.

— Lantern

## Correction retracted — the hold stands, now strict (Zach, 2026-10-22) Comment 628 (my "correction" from earlier tonight) is itself **retracted**. Zach's report was a *bug report*: in the tested build, pressing both face buttons opened the pause menu. I misread it as a design change and briefly implemented the chord he was flagging. Apologies for the churn — the record, final: **Pause = hold the upper face button (B/Y) alone for 2 seconds** — comment 596's dictation was right all along. Now implemented **strictly** in da-game PR #9 (`c22d369`): each hand's hold timer accumulates only while that hand's B/Y is held and its A/X is *not*; an A/X press on the same hand at any point resets the timer, so the both-buttons press — any order, any overlap — can never open the menu. Among face-button inputs, the hold is the only way in. **Platform note (Zach, same evening):** the current target is **Quest controllers via SteamVR** — there, the controller menu/system button is reserved by the runtime and not usable by the app, so the hold is the operative in-headset opener. On a native Quest build the menu button *would* be the conventional opener, so that path (and desktop Esc) stays in code for it. — Lantern
muse-lantern commented 2026-10-23 18:58:49 +00:00
Author
Member
Copy link

Amendment (2026-10-23) to the pause-gesture record in 596/633 — the gesture moves to the binding layer.

The design discussion continued and landed somewhere better than either in-game version: the game implements no pause gesture at all. Press-vs-hold disambiguation is a native feature of the runtime binding systems (SteamVR bindings carry press and hold as separate actions on one button — the Vivecraft pattern), so the gesture becomes binding data, per runtime:

  • steamvr: pause ← HOLD of the upper face button (B/Y), 2.0s — same duration and intent as 596/633, expressed in the SteamVR binding preset instead of a game-side timer. The strictness questions that occupied the in-game versions (chord poisoning, state flicker) do not exist at this layer.
  • oculus / openxr: pause ← the menu key, bound directly (the menu/system button is only reserved under SteamVR).

The in-game hold timer shipped on the pause-menu branch has been removed; the branch was folded (UI chunk, CI chunk, input code removed) and now carries the full design as da-game docs/input-system.md: a src/input/ layout (generic semantic contract + per-controller folders with per-runtime binding presets), Quest capacitive touch fully exposed as backend events (incl. the thumbrest, for later features), and addon-supplied controllers feeding the same contract. The loading-circle cosmetic from the Resonite-mod pattern is deferred — SteamVR provides its own hold feedback; the plan is preserved in that doc.

**Amendment (2026-10-23) to the pause-gesture record in 596/633 — the gesture moves to the binding layer.** The design discussion continued and landed somewhere better than either in-game version: **the game implements no pause gesture at all.** Press-vs-hold disambiguation is a native feature of the runtime binding systems (SteamVR bindings carry press and hold as separate actions on one button — the Vivecraft pattern), so the gesture becomes *binding data*, per runtime: - **steamvr:** `pause` ← HOLD of the upper face button (B/Y), 2.0s — same duration and intent as 596/633, expressed in the SteamVR binding preset instead of a game-side timer. The strictness questions that occupied the in-game versions (chord poisoning, state flicker) do not exist at this layer. - **oculus / openxr:** `pause` ← the menu key, bound directly (the menu/system button is only reserved under SteamVR). The in-game hold timer shipped on the pause-menu branch has been **removed**; the branch was folded (UI chunk, CI chunk, input code removed) and now carries the full design as **da-game `docs/input-system.md`**: a `src/input/` layout (generic semantic contract + per-controller folders with per-runtime binding presets), Quest capacitive touch fully exposed as backend events (incl. the thumbrest, for later features), and addon-supplied controllers feeding the same contract. The loading-circle cosmetic from the Resonite-mod pattern is deferred — SteamVR provides its own hold feedback; the plan is preserved in that doc.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
dead-air/game-planning#19
No description provided.