- GDScript 95%
- Python 4.7%
- GDShader 0.3%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
|
||
| .forgejo/workflows | ||
| addons | ||
| assets/player | ||
| data | ||
| docs | ||
| levels/sandbox | ||
| scenes | ||
| src | ||
| tests | ||
| tools | ||
| .gitignore | ||
| LICENSE | ||
| openxr_action_map.tres | ||
| project.godot | ||
| README.md | ||
DEAD AIR — game
A Godot project for DEAD AIR, Zach's open-source VR survival game.
(Engine history: built on Redot LTS 26.2 through 2026-10-21; migrated
to Godot — see docs/engine-migration.md for the decision record and
the one-time cache-wipe step every existing checkout needs.)
Started as a framework skeleton (directory layout, class names, signals,
stubs); real systems land via design issues in
dead-air/game-planning.
Status
Basic menu flow is in. The game boots into the Sandbox level's menu area: a persistent Game root owns the player rig and loads levels underneath it, and the same physical area serves as main menu, new-game starting area, and sandbox — modes redress it (MenuContent / StoryContent / SandboxContent groups). Menu is a world-space laser-pointer panel (mouse works too, in flat/desktop mode). Continue is present but disabled until save/load lands; locomotion is provisional (left-stick smooth + snap turn) pending the #19 locomotion decisions.
Headless check: tests/smoke_menu.gd (run with
godot --headless --path . --script res://tests/smoke_menu.gd).
Pins
- Engine: Godot 4.6.3, standard build (NOT the .NET build) —
pinned; upgrade only deliberately, after the test suites + a
headset pass on the new version. No .NET SDK is required to open,
run, or test this project. (Was Redot LTS 26.2 until the
2026-10-21 migration —
docs/engine-migration.md.) - Blender LTS 5.2.2 — for asset work.
Scripting rule
GDScript only. The project contains no C# and uses the standard Godot build. Adopting .NET is a project-wide switch (editor build, SDK, MSBuild, export templates — paid by every contributor for a subsystem-local benefit), so it requires a specific justification: a profiled compute-bound subsystem that lives in .NET data and crosses to the engine in bulk, or a named load-bearing NuGet library with no adequate GDScript/GDExtension alternative. Native hot kernels go to GDExtension, which works in the standard build.
Design source
The design record lives in dead-air/game-planning issues:
- #19 — base-layer primitives (Item → Health & Damage → Interaction → Inventory → Player Avatar → Health Display)
- #24 — development milestones / systems roadmap (render → movement → interactions → inventory → advanced movement → advanced interactions)
- #28 — save data format: versioned registry, uniform item tree, full snapshots, containers-as-items
Addons
DEAD AIR's content packages are called addons (not mods): the
system is built for adding new content first; alteration is allowed
but extension is the intent. Addons are .pck/.zip packs mounted
at startup that can shadow any base file at the same res:// path —
the official release's licensed asset pack ships this way. The
player model works the same: base arms are CC0
(assets/player/arms/player_arms.glb), overridable by any pack.
Full details: docs/addons.md.
Layout
src/core/— item registry, save gamesrc/items/— item definitions and runtime instancessrc/health/— health component, damage infosrc/interaction/— grab points, grabbable, ranged grabsrc/inventory/— container volumes, snapperssrc/player/— XR rig, arms view model, staminasrc/ui/— displaysaddons/— Godot editor plugins land here later (godot-xr-tools decision still open). Not to be confused with game addons (content packs) — seedocs/addons.md.data/levels/— level descriptors (data-driven; addons can add)data/registry/— item definition data (data-driven from day one)