GI7B Godot projects and prototypes
- Python 52%
- GDScript 47.6%
- JavaScript 0.4%
Justin: "lets have time and motion in this project. process time - when agent starts and submits in the logs." tools/tam.py (stdlib only): start / submit / measure / show. Every timestamp is machine-read. Processing time is measured from the agent's own session store -- opencode.db for OpenCode/DS, ~/.claude/projects/*.jsonl for Claude Code -- by summing intervals between session events with each interval capped at 5 minutes; a longer gap is a human not replying, not work. submit scopes the measurement to the stamped [start, submit] window and prints a block to paste at the top of the log entry. AGENTS.md gains a mandatory "Time & motion" section: start first, submit last, paste the block verbatim, and -- the rule that matters -- report an absent measurement as absent. The tool never estimates; if there is no session store it says "unmeasured" and the log says "unmeasured". Verified against both live stores, and the failure modes were tested rather than assumed. Mid-session start caught a real bug: the first version reported duty 276% and negative idle because a 60s grace admitted pre-start events. A metric that can exceed 100% is not measuring what it claims, and it was only visible because the tool was run instead of reviewed. Cross-checks: live Claude session 50m53s processing / 10h13m elapsed / 8.3% duty; DS Stage 1 session 28m29s / 3h35m49s / 13.2% / $0.0805, which reproduces the 08-02 report exactly. B-43 closed. B-44 raised: archive the session stores nightly -- they are the only source of real processing time and four of this project's six sessions are already missing from them, including the entire MVP-0 create. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| addons/godot_mcp_server | ||
| data | ||
| docs | ||
| legacy | ||
| logs | ||
| scenes | ||
| scripts | ||
| tests | ||
| tools | ||
| .gitignore | ||
| 260723-hard-questions-agents-controlling-godot.md | ||
| AGENTS.md | ||
| DIALOGUE.md | ||
| kimi_research_brief_godot_agent_loop 260724.md | ||
| Mneme-Technical-Knowledge-Base.docx | ||
| PROGRESS.md | ||
| project.godot | ||
| README.md | ||
godot-ship-and-station
Evaluator: Kimi Code CLI (kimi-k2.5) Evaluation Date: 2026-07-23 Methodology: Repo scaffold per approved consolidation plan (rev 2)
A soft-sci-fi 3D space simulation in Godot 4.6, set in the Mneme universe (Cepheus Engine). A procedural star system is generated from Mneme-CE-World-Generator JSON; the player travels it in ships that obey real orbital mechanics, with time acceleration, trip planning, docking, spin-gravity stations, and — eventually — procedural ships, habitats, and cities across a frontier sector ~100 parsecs from Sol.
Pillars
- Soft sci-fi first — physics you can plan around: Kepler orbits, patched conics, Δv budgets, launch windows, spin gravity, destructive collisions.
- Realistic ships — interplanetary ships cannot land; surface access is via orbiters and infrastructure.
- One continuous world — time accelerates; trips are scheduled, not teleported.
- Procedural everything — systems from Mneme JSON, ships/habitats from blender-mcp-ships, cities from the MWG economics/population engines.
Layout
| Path | Purpose |
|---|---|
scenes/, scripts/ |
The Godot game |
data/samples/ |
Dev fixture: a Mneme system JSON |
data/catalog/ |
HYG real-star catalog (interstellar layer, M8) |
addons/godot_mcp_server/ |
godot-mcp editor plugin (agent toolchain) |
tools/blender/ |
blender-mcp addon + test scripts |
editor/ |
Bundled Godot 4.6.2 Linux binary (gitignored) |
docs/ |
architecture, roadmap, asset-map, setup guides |
tests/ |
Headless smoke tests |
Docs
docs/architecture.md— engine architecture and scale strategydocs/roadmap.md— milestones M1–M9docs/asset-map.md— where every external asset lives and how it enters this repodocs/setup/— godot-mcp / blender-mcp setup guides
Status
🟡 M1 skeleton ✅ (2026-07-23); next: M1.5 Pilot — 0g spin-habitat ship
hangar (see docs/roadmap.md + docs/consolidation-strategy.md).