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

Engine choice: Redot (Godot fork) #1

New issue
Open
opened 2026-10-17 21:52:17 +00:00 by muse-lantern · 2 comments
muse-lantern commented 2026-10-17 21:52:17 +00:00
Member
Copy link

Decision: Redot

Target: PCVR (SteamVR via OpenXR)
Later: Quest standalone — dropped until much later. Not a current goal.

Constraint: Pure native engine where possible. GDScript-equivalent + built-in features first. Native modules only if something truly can t be done in-script.

Why Redot over Godot

  • Lighter engine — leaner is better for XR where every ms of frame budget counts
  • MCP for AI agents built into the engine — first-class agent interface for the ResoLink → agent → engine pipeline
  • Language improvements: structs, traits, nullable static types (top-requested Godot features Redot actually shipped)
  • Still MIT, still free, no runtime fees
  • Standard OpenXR via SteamVR — no Quest-specific concerns at all right now

Godot (not chosen)

  • Meta-funded Quest/OpenXR work is nice, but Quest-specific extensions aren t the priority
  • Heavier engine, no MCP integration
  • Would be the fallback if Redot s XR stack proves problematic

Unity ❌

  • Runtime fees kick in after certain revenue/player thresholds, even for free games

Unreal ❌

  • "Unreal Smear": lighting engine + temporal upsampling smears fine details during motion
  • Causes physical motion sickness for Zach
  • Non-negotiable

Prototyping pipeline

  • Prototype in Resonite (VR-native iteration, fast)
  • ResoLink — Resonite feature exposing full dev tools over the game via API
  • Agent uses ResoLink to pull all world/object data, including Flux graphs, then rebuilds into Redot
  • Flux → GDScript translation is the key bridge (node graphs to script logic)
  • Geometry/layout/components map to Redot scenes
  • Philosophy: Resonite prototypes don t need to be perfect. They capture the core concepts of HOW a system works — interaction design, feel, flow. Those concepts get reused and rebuilt to be actually functional in Redot. The prototype is a thinking tool, not shippable code.

Open questions

  • Verify Redot OpenXR → SteamVR pipeline (basic scene, headset tracking, controllers)
  • Performance headroom on PCVR (much more forgiving than Quest, but physics-heavy design still needs budgets)
  • Spike brief (written for Godot Quest, renderer/thermal sections less relevant now): ~/workspace/proactivity/drafts/vr-godot-quest-spike-brief.md
  • How faithful can Flux → GDScript translation be? (paradigm differences)
  • Redot MCP capabilities — what exactly is exposed?
## Decision: Redot **Target:** PCVR (SteamVR via OpenXR) **Later:** Quest standalone — dropped until much later. Not a current goal. **Constraint:** Pure native engine where possible. GDScript-equivalent + built-in features first. Native modules only if something truly can t be done in-script. ### Why Redot over Godot - **Lighter engine** — leaner is better for XR where every ms of frame budget counts - **MCP for AI agents built into the engine** — first-class agent interface for the ResoLink → agent → engine pipeline - **Language improvements:** structs, traits, nullable static types (top-requested Godot features Redot actually shipped) - Still MIT, still free, no runtime fees - Standard OpenXR via SteamVR — no Quest-specific concerns at all right now ### Godot (not chosen) - Meta-funded Quest/OpenXR work is nice, but Quest-specific extensions aren t the priority - Heavier engine, no MCP integration - Would be the fallback if Redot s XR stack proves problematic ### Unity ❌ - Runtime fees kick in after certain revenue/player thresholds, even for free games ### Unreal ❌ - "Unreal Smear": lighting engine + temporal upsampling smears fine details during motion - Causes physical motion sickness for Zach - Non-negotiable ### Prototyping pipeline - **Prototype in Resonite** (VR-native iteration, fast) - **ResoLink** — Resonite feature exposing full dev tools over the game via API - Agent uses ResoLink to pull **all world/object data, including Flux graphs**, then rebuilds into Redot - Flux → GDScript translation is the key bridge (node graphs to script logic) - Geometry/layout/components map to Redot scenes - **Philosophy:** Resonite prototypes don t need to be perfect. They capture the *core concepts* of HOW a system works — interaction design, feel, flow. Those concepts get reused and rebuilt to be actually functional in Redot. The prototype is a thinking tool, not shippable code. ### Open questions - Verify Redot OpenXR → SteamVR pipeline (basic scene, headset tracking, controllers) - Performance headroom on PCVR (much more forgiving than Quest, but physics-heavy design still needs budgets) - Spike brief (written for Godot Quest, renderer/thermal sections less relevant now): ~/workspace/proactivity/drafts/vr-godot-quest-spike-brief.md - How faithful can Flux → GDScript translation be? (paradigm differences) - Redot MCP capabilities — what exactly is exposed?
muse-lantern changed title from Engine choice: Godot vs alternatives to Engine choice: Redot (Godot fork) 2026-10-18 02:49:05 +00:00
merith-tk commented 2026-10-19 23:01:29 +00:00
Owner
Copy link

One important note is that of Redot turns out not to be the way to go, I am willing to consider other engines, however the main idea right now is to use redot for the reasons stated above,

One important note is that of Redot turns out not to be the way to go, I am willing to *consider* other engines, however the main idea right now is to use redot for the reasons stated above,
merith-tk commented 2026-10-20 00:14:26 +00:00
Owner
Copy link

One large question, is do we want to use Redot LTS 26.1 or latest release 26.3? This is an important decision of do we pin at the LTS release? or should we continue using the "latest" version?

Also should we stick to Redot native? or Redot Mono? this is important for various design implementations and performance changes.

One large question, is do we want to use Redot LTS 26.1 or latest release 26.3? This is an important decision of do we pin at the LTS release? or should we continue using the "latest" version? Also should we stick to Redot native? or Redot Mono? this is important for *various* design implementations and performance changes.
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#1
No description provided.