Rust AI-native game engine roadmap: editor save-boundary research and six draft content PRs

What they did

The author worked on a Rust AI-native game engine (rust-ai-native-game-engine) and treated the roadmap as a research-and-contract exercise rather than a feature sprint. First they read the public editor source and docs of three reference engines to understand how save, close, and export boundaries actually behave: Godot at a pinned 4.8 beta commit (editor_undo_redo_manager.cpp, editor_node.cpp, editor_interface.cpp) to confirm that a save request is not the same as a successful disk write; UnityCsReference at a pinned 7000.0.0a10 alpha commit (EditorWindow.cs, ContainerWindow.cs, EditorSceneManager.bindings.cs) while noting the Reference-Only License forbids copying or translating Unity code; and Unreal's public 5.8 MCP and unattended-command docs, while explicitly not reading engine source (the EpicGames/UnrealEngine metadata read returned 404 and they did not attempt logins, OAuth, or license bypass). They then mapped those findings onto their own codebase at a frozen head, identifying that root-close protection in crates/orr_editor/src/app.rs only checks dirty tilemaps while scene, sprite, and UI panels each save separately, so a Scene Save does not imply sprite or UI state is saved. They wrote a prioritized plan (P0 close protection, P1 capability/export readiness diagnostics, input settings surviving export, small progress/UI/audio loops, read-only impact previews, P2 runtime extensions) with explicit minimum scope and acceptance criteria for each. In parallel they published six dependency-ordered draft PRs (#264 tilemap, #266 animation sequencing, #267 terrain ramps, #268 tile fill, #269 planar UV, #270 tile resize), verifying each base/head and tree against the frozen local tree via GET. They also scoped issue #271 for preserving MCP error envelopes (structuredContent with origin/code/kind allowlist) without breaking existing text and isError behavior, and kept #265 as the active build lease so Cargo was not run until it was released.

How it went

Six draft PRs were published in dependency order with head/tree hashes verified against the frozen local tree, and the comparison analysis plus a prioritized roadmap were written up with per-item acceptance criteria. All six heads had zero hosted workflow runs; no ready-for-review flips, dispatches, or merges happened, and main and PR #1 were untouched. The #265 close-protection work is described as source review and RED-test preparation in progress, not a passing fix. The #271 MCP error-envelope work is isolated source implementation, explicitly unverified. The author repeatedly states this is research integration and limited start-of-work, not implementation completion, test pass, publication, or merge.

Worth knowing

Everything here is draft and unverified: no CI runs on the six PRs, no merge, and the #265 fix and #271 implementation are both incomplete. The comparison is a source-and-docs reading, not a fresh build or Windows acceptance run, and the author warns against treating Editor Play or software-GPU smoke tests as deployment success. Version pinning is messy by design: Godot is a 4.8 beta snapshot, Unity source is a 7000.0.0a10 alpha that does not match the 6.3 LTS docs cited, and Unreal's 5.8 query did not load so 5.7 links stand in. Unreal engine source was never read, and Unity's Reference-Only License blocks reuse. The post is in Korean and dense with internal issue numbers, so external readers cannot verify most claims without repo access.

Wiring

Work was anchored to a frozen local commit and tree so every published branch could be diffed exactly. Reference sources were pinned separately: Godot at commit 469659e0 (4.8 beta, MIT) with specific editor files read; UnityCsReference at 6c1fc791 (7000.0.0a10 alpha) with EditorWindow.cs, ContainerWindow.cs, and EditorSceneManager.bindings.cs read under the Reference-Only License; Unreal limited to public 5.8 MCP and command-line docs with no engine source access. On the engine side, the analysis traced crates/orr_editor/src/app.rs (root close), editor.rs (scene dirty), sprite_panel.rs and collect_ui_panel.rs (separate saves), app/mesh_workspace_save.rs (sequential, non-atomic save), diagnostics.rs (existing CPU/ERP/pending stats), orr_package manifest and project_export/admission.rs (input sidecar absent from copy scope), and windows_export.rs launcher (no extra args passed). The six PRs were chained by base/head so each builds on the previous, all left as drafts with no dispatch. Issue #271 was scoped to crates/orr_remote/src/error.rs, crates/orr_mcp/src/bridge.rs, and server.rs, preserving Fail(String), existing CLI, first text block, and isError while adding a sanitized structuredContent error object with a finite kind allowlist and no auto-retry. A build lease on #265 gated Cargo execution.

Try it yourself

Read the editor save and close paths in this repo (start with crates/orr_editor/src/app.rs root-close handling, editor.rs scene dirty tracking, sprite_panel.rs, and collect_ui_panel.rs). For each panel, determine whether a save request guarantees a successful disk write, and list every place where a Scene Save would leave sprite or UI state unsaved. Then write a short prioritized plan: P0 close protection that cancels root close on any dirty or unapplied document with a Keep editing option and no global Save All or auto-discard; P1 a read-only capability and export-readiness summary derived from actual feature flags, reusing existing diagnostics stats without relabeling CPU as GPU. For each item give minimum scope, explicit exclusions, and acceptance criteria including file/checksum invariance on repeated cancel. Do not run Cargo while a build lease is held, do not change public APIs or dependencies, and do not copy or translate code from Unity, Unreal, or Godot — cite their public docs and contracts only.