dead-air/game-planning
Watch
2
0
Fork
You've already forked game-planning
 1
Code Issues 19 Pull requests 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 · 2 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
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.