Engine choice: Redot (Godot fork) #1

New issue

Open

opened 2026-10-17 21:52:17 +00:00 by muse-lantern · 7 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.

muse-lantern commented 2026-10-20 16:18:08 +00:00

Author

Member

Copy link

Two questions, both worth answering deliberately. First a correction: the current LTS isn't 26.1 -- 26.2 LTS went stable June 30, 2026, so the real choice is 26.2 LTS vs 26.3 latest.

26.2 LTS vs 26.3: 26.3 stable only dropped October 15 (five days ago) -- headliners are WorldScape3D (built-in terrain editor, actually relevant to us), plus Structs, Traits, and nullable static types, which are the biggest GDScript upgrade in a while. Tempting, but it's fresh: the VR stack we'd depend on (OpenXR vendor plugin, godot-xr-tools compatibility) is unverified on it, and Redot is volunteer-maintained, so latest carries more churn risk than on upstream Godot. LTS is Godot 4.5-based, bugfix-focused, backward-compatible. My lean: pin 26.2 LTS now, re-evaluate 26.3 deliberately once the VR pieces are proven on it -- don't ride latest on a fork while we're still prototyping.

Native vs Mono: lean native (GDScript). The VR ecosystem -- godot-xr-tools, OpenXR examples, nearly all tutorials -- is GDScript-first; iteration is faster with no compile step; and you skip the .NET SDK + separate export templates toolchain. The traditional argument for C# (raw speed, mature IDEs like Rider, strong typing) got weaker with 26.3's typed GDScript features. One Redot-specific caution: Mono builds have historically lagged standard releases (4.3.1 shipped with no Mono build at all; it only returned in the 4.4 alphas) -- verify a 26.x Mono build actually exists before treating it as an option. Escape hatch: in a .NET build you can mix both (GDScript calling C#), so starting native doesn't lock the door if one subsystem later needs C# speed.

My vote: 26.2 LTS + native GDScript, revisit 26.3 after VR verification. Your call though -- if WorldScape3D terrain turns out to be load-bearing for the Region's geography, that could flip the version question.

• Lantern

Two questions, both worth answering deliberately. First a correction: the current LTS isn't 26.1 -- **26.2 LTS went stable June 30, 2026**, so the real choice is 26.2 LTS vs 26.3 latest. **26.2 LTS vs 26.3:** 26.3 stable only dropped October 15 (five days ago) -- headliners are WorldScape3D (built-in terrain editor, actually relevant to us), plus Structs, Traits, and nullable static types, which are the biggest GDScript upgrade in a while. Tempting, but it's fresh: the VR stack we'd depend on (OpenXR vendor plugin, godot-xr-tools compatibility) is unverified on it, and Redot is volunteer-maintained, so latest carries more churn risk than on upstream Godot. LTS is Godot 4.5-based, bugfix-focused, backward-compatible. My lean: **pin 26.2 LTS now, re-evaluate 26.3 deliberately** once the VR pieces are proven on it -- don't ride latest on a fork while we're still prototyping. **Native vs Mono:** lean native (GDScript). The VR ecosystem -- godot-xr-tools, OpenXR examples, nearly all tutorials -- is GDScript-first; iteration is faster with no compile step; and you skip the .NET SDK + separate export templates toolchain. The traditional argument for C# (raw speed, mature IDEs like Rider, strong typing) got weaker with 26.3's typed GDScript features. One Redot-specific caution: **Mono builds have historically lagged standard releases** (4.3.1 shipped with no Mono build at all; it only returned in the 4.4 alphas) -- verify a 26.x Mono build actually exists before treating it as an option. Escape hatch: in a .NET build you can mix both (GDScript calling C#), so starting native doesn't lock the door if one subsystem later needs C# speed. My vote: **26.2 LTS + native GDScript**, revisit 26.3 after VR verification. Your call though -- if WorldScape3D terrain turns out to be load-bearing for the Region's geography, that could flip the version question. - Lantern

muse-lantern commented 2026-10-20 16:25:11 +00:00

Author

Member

Copy link

Decision: version pin + Mono rule

Version pin: Redot LTS 26.2. We pin to the LTS line. Newer releases (26.3+) get re-evaluated after the VR stack is verified working on the pin — not adopted on release day.

Mono vs native rule: Mono/.NET is fine to use — but if something can be remade into native script (GDScript), native is the way to go. This gives us the ability to reach for Mono/dotnet code when it's genuinely needed, with a standing reason to prefer native whenever native can reasonably do the job.

In short: native by default, Mono by justification.

## Decision: version pin + Mono rule **Version pin: Redot LTS 26.2.** We pin to the LTS line. Newer releases (26.3+) get re-evaluated after the VR stack is verified working on the pin — not adopted on release day. **Mono vs native rule:** Mono/.NET is fine to use — but if something can be remade into native script (GDScript), native is the way to go. This gives us the ability to reach for Mono/dotnet code when it's genuinely needed, with a standing reason to prefer native whenever native can reasonably do the job. In short: native by default, Mono by justification.

muse-lantern commented 2026-10-21 00:07:08 +00:00

Author

Member

Copy link

Editor build refinement (Zach, 2026-10-20): we use the Mono build of Redot LTS 26.2 as the standard editor — even when not using Mono features, so the capability is there when needed. The native-first Mono rule above is unchanged (GDScript by default, Mono by justification).

Practical note from verification on my VM: the Mono editor requires the .NET SDK 8.0+ installed — without dotnet available it fails to load hostfxr and crashes outright on project load (it does not degrade to GDScript-only mode). With .NET SDK 8.0.426 present, the Mono build imported the game skeleton cleanly (14 framework classes, zero errors) and its MCP server works headless, same as the non-Mono build.

Reflected in the skeleton PR (dead-air/da-game#1) README pins.

**Editor build refinement (Zach, 2026-10-20):** we use the **Mono build** of Redot LTS 26.2 as the standard editor — even when not using Mono features, so the capability is there when needed. The native-first Mono rule above is unchanged (GDScript by default, Mono by justification). Practical note from verification on my VM: the Mono editor **requires the .NET SDK 8.0+ installed** — without `dotnet` available it fails to load hostfxr and crashes outright on project load (it does not degrade to GDScript-only mode). With .NET SDK 8.0.426 present, the Mono build imported the game skeleton cleanly (14 framework classes, zero errors) and its MCP server works headless, same as the non-Mono build. Reflected in the skeleton PR (dead-air/da-game#1) README pins.

muse-lantern commented 2026-10-22 17:09:51 +00:00

Author

Member

Copy link

Terrain3D — compatibility report & possible uses (researched 2026-10-22)

Zach asked whether the "terrain tools in newer Godot" are real and mature, and to track the answer here on the engine tracker. Short version: Godot core has no terrain system (not in 4.6/4.7; 4.8 is in feature freeze without one). What circulates as "Godot terrain" is Terrain3D by Tokisan Games — a third-party plugin now featured in the new Asset Store. Below is the full check against our stack, then what we could use it for.

Compatibility report

Axis	Finding	Verdict
Engine version	Current stable Terrain3D 1.0.2 (1.0 shipped Mar 2025), with builds for Godot 4.3–4.6+	✅ Covers our Godot 4.6.3 standard pin
Build flavor	GDExtension (C++), loads into stock official builds; no .NET build, no custom engine build, no engine recompile	✅ Matches the standard-build decision (GDScript-only project)
Renderer	Docs: Compatibility / OpenGLES 3 fully supported since 1.0 (Godot 4.4+); Forward+ Vulkan also fully supported if the project ever returns to it	✅ Works on our gl_compatibility path — this was the make-or-break item
License	MIT	✅ Passes the da-game external-resources gate; vendor-and-pin like godot-xr-tools
Platforms	Prebuilt binaries: Windows, Linux, macOS, Android, iOS. Web export experimental. D3D12 has a texture-array mipmap caveat	✅ Our targets covered; caveats are off our path
Editing	Editor sculpting (raise/lower/flatten/smooth), holes, texture painting (up to 32 layers), color/wetness painting; heightmap import from WorldMachine / Unity / Unreal / HTerrain / raw	✅ Mouse-driven editor work (Zach-side); heightmaps can also be generated/imported programmatically
Runtime	GPU clipmap mesh, 10 LOD levels, terrains 64m → 65.5×65.5km in non-contiguous regions; foliage/instance scattering with LOD; dynamic collision generated around the player; navigation baking; full documented runtime API incl. editing	✅ Fits level-based structure + PlayerBody locomotion
Maintenance	Active project (Tokisan Games + contributors), built for their own shipped-game work first; docs site, tutorials, demo project; 1.0.2 is a maintained stable line, not an alpha	✅ The maturity question that prompted this: yes, production-grade

What DEAD AIR could use it for

1. Region exteriors (the headline use). Sculpted open terrain — badlands/steppe/wasteland — around safe zones and POIs, at a scale the current flat-sandbox approach can't fake. Heightfield + our fog design pairs naturally: terrain rolls off into The Quiet.
2. Traversal/movement testing now. A real landscape in the sandbox level for locomotion, stamina, and line-of-sight work instead of a ground plane and cubes.
3. Menu-as-place backdrop. The shared menu/New Game area could sit in a terrain bowl rather than on a slab.
4. Environmental storytelling scatter. Its instancer (with LOD) suits dead trees, debris fields, wreckage — placed once, streamed cheaply.
5. Base-building ground. Terrain height/slope queries via the API for placement rules; dynamic collision keeps physics honest around the player.
6. Procedural first drafts. Generate base heightmaps from noise in code, then hand-sculpt in the editor — Lantern can produce/import heightmaps headlessly; final sculpting is Zach's editor pass.

Risks / open questions (why this is a spike, not an adoption)

• VR frame budget unproven for us. Clipmap terrain is designed for performance, but stereo rendering at ~90Hz under gl_compatibility on the target rig is our number to measure, not the docs'. Needs a spike: ~1km sculpted terrain in the sandbox, fog on, frame times checked flat + estimated for stereo before any headset commitment.
• Our fog is load-bearing. Terrain3D uses its own shader stack; how it takes Godot fog (our transition/Quiet mechanism) must be verified in the spike, not assumed.
• First binary dependency. xr-tools is pure GDScript; Terrain3D's compiled libraries add per-platform binaries and gate future engine upgrades on its release cadence (the 4.3–4.6+ spread is reassuring).
• Heightfield limits. No overhangs or true caves. Holes exist (cave entrances work); Region interiors stay separate geometry — consistent with the fog-transition design, but worth stating.
• Persistence. Runtime terrain edits via the API would not be captured by the #28 snapshot save format as-is; if terraforming ever becomes a feature, that's design work, not a freebie.
• Repo weight. Heightmap/control textures run to real megabytes per region — plan on Git LFS for terrain data if this lands, like the assets repo.

Recommendation

Track, don't adopt yet. Proposed next step (on Zach's go): a throwaway spike branch — Terrain3D dropped into the sandbox level, ~1km of sculpted terrain, fog enabled, frame-time measurements, and a fog-behavior check — reported back here before any decision. If adopted: pin the version, vendor it under addons/ alongside xr-tools, and add it to docs/external-resources.md.

— Lantern

## Terrain3D — compatibility report & possible uses (researched 2026-10-22) Zach asked whether the "terrain tools in newer Godot" are real and mature, and to track the answer here on the engine tracker. Short version: **Godot core has no terrain system** (not in 4.6/4.7; 4.8 is in feature freeze without one). What circulates as "Godot terrain" is **Terrain3D** by Tokisan Games — a third-party plugin now featured in the new Asset Store. Below is the full check against *our* stack, then what we could use it for. ### Compatibility report | Axis | Finding | Verdict | |---|---|---| | Engine version | Current stable **Terrain3D 1.0.2** (1.0 shipped Mar 2025), with builds for **Godot 4.3–4.6+** | ✅ Covers our **Godot 4.6.3 standard** pin | | Build flavor | **GDExtension** (C++), loads into stock official builds; **no .NET build, no custom engine build, no engine recompile** | ✅ Matches the standard-build decision (GDScript-only project) | | Renderer | Docs: **Compatibility / OpenGLES 3 fully supported** since 1.0 (Godot 4.4+); Forward+ Vulkan also fully supported if the project ever returns to it | ✅ Works on our `gl_compatibility` path — this was the make-or-break item | | License | **MIT** | ✅ Passes the da-game external-resources gate; vendor-and-pin like godot-xr-tools | | Platforms | Prebuilt binaries: Windows, Linux, macOS, Android, iOS. Web export experimental. D3D12 has a texture-array mipmap caveat | ✅ Our targets covered; caveats are off our path | | Editing | Editor sculpting (raise/lower/flatten/smooth), holes, texture painting (up to **32 layers**), color/wetness painting; heightmap import from WorldMachine / Unity / Unreal / HTerrain / raw | ✅ Mouse-driven editor work (Zach-side); heightmaps can also be generated/imported programmatically | | Runtime | GPU clipmap mesh, **10 LOD levels**, terrains 64m → 65.5×65.5km in non-contiguous regions; foliage/instance scattering with LOD; **dynamic collision generated around the player**; navigation baking; full documented runtime API incl. editing | ✅ Fits level-based structure + PlayerBody locomotion | | Maintenance | Active project (Tokisan Games + contributors), built for their own shipped-game work first; docs site, tutorials, demo project; 1.0.2 is a maintained stable line, not an alpha | ✅ The maturity question that prompted this: yes, production-grade | ### What DEAD AIR could use it for 1. **Region exteriors (the headline use).** Sculpted open terrain — badlands/steppe/wasteland — around safe zones and POIs, at a scale the current flat-sandbox approach can't fake. Heightfield + our fog design pairs naturally: terrain rolls off into The Quiet. 2. **Traversal/movement testing now.** A real landscape in the sandbox level for locomotion, stamina, and line-of-sight work instead of a ground plane and cubes. 3. **Menu-as-place backdrop.** The shared menu/New Game area could sit in a terrain bowl rather than on a slab. 4. **Environmental storytelling scatter.** Its instancer (with LOD) suits dead trees, debris fields, wreckage — placed once, streamed cheaply. 5. **Base-building ground.** Terrain height/slope queries via the API for placement rules; dynamic collision keeps physics honest around the player. 6. **Procedural first drafts.** Generate base heightmaps from noise in code, then hand-sculpt in the editor — Lantern can produce/import heightmaps headlessly; final sculpting is Zach's editor pass. ### Risks / open questions (why this is a spike, not an adoption) - **VR frame budget unproven for us.** Clipmap terrain is designed for performance, but stereo rendering at ~90Hz under `gl_compatibility` on the target rig is *our* number to measure, not the docs'. Needs a spike: ~1km sculpted terrain in the sandbox, fog on, frame times checked flat + estimated for stereo before any headset commitment. - **Our fog is load-bearing.** Terrain3D uses its own shader stack; how it takes Godot fog (our transition/Quiet mechanism) must be verified in the spike, not assumed. - **First binary dependency.** xr-tools is pure GDScript; Terrain3D's compiled libraries add per-platform binaries and gate future engine upgrades on its release cadence (the 4.3–4.6+ spread is reassuring). - **Heightfield limits.** No overhangs or true caves. Holes exist (cave *entrances* work); Region interiors stay separate geometry — consistent with the fog-transition design, but worth stating. - **Persistence.** Runtime terrain edits via the API would **not** be captured by the #28 snapshot save format as-is; if terraforming ever becomes a feature, that's design work, not a freebie. - **Repo weight.** Heightmap/control textures run to real megabytes per region — plan on Git LFS for terrain data if this lands, like the assets repo. ### Recommendation Track, don't adopt yet. Proposed next step (on Zach's go): a throwaway spike branch — Terrain3D dropped into the sandbox level, ~1km of sculpted terrain, fog enabled, frame-time measurements, and a fog-behavior check — reported back here before any decision. If adopted: pin the version, vendor it under `addons/` alongside xr-tools, and add it to `docs/external-resources.md`. — Lantern

muse-lantern commented 2026-10-22 17:48:53 +00:00

Author

Member

Copy link

Update 2026-10-22 (later): integrated. Zach directed integration now, unused or not. Terrain3D 1.0.2 is vendored unmodified at addons/terrain_3d/ (official release; demo/ not vendored), the editor plugin is enabled, and tests/terrain_check.gd guards the load: da-game PR #7 (merge is Zach's call, as always).

Verified on the pinned Godot 4.6.3 standard build, headless: import clean, terrain classes register, terrain + data instantiate, empty-terrain height query returns the NaN no-data sentinel; smoke/arms/addon suites still pass.

The spike questions from the report above (VR frame budget under stereo + gl_compatibility, fog interplay with its shader stack) remain open for when a level first wants terrain — integration changes nothing about them.

— Lantern

**Update 2026-10-22 (later): integrated.** Zach directed integration now, unused or not. Terrain3D 1.0.2 is vendored unmodified at `addons/terrain_3d/` (official release; `demo/` not vendored), the editor plugin is enabled, and `tests/terrain_check.gd` guards the load: **[da-game PR #7](https://git.merith.xyz/dead-air/da-game/pulls/7)** (merge is Zach's call, as always). Verified on the pinned Godot 4.6.3 standard build, headless: import clean, terrain classes register, terrain + data instantiate, empty-terrain height query returns the NaN no-data sentinel; smoke/arms/addon suites still pass. The spike questions from the report above (VR frame budget under stereo + `gl_compatibility`, fog interplay with its shader stack) remain open for when a level first wants terrain — integration changes nothing about them. — 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

Subscribe

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.