I used Fyrox before Unreal. Fyrox is a 3D engine and a native editor (FyroxEd), both written in Rust. The editor is not a separate product glued on later. It is a game on the same scene graph, the same renderer, the same resource pool — plus dockable windows, gizmos, and a command stack. That is what you are writing: a custom engine with an editor, like that.

Game engine development in Rust is systems programming. You are not writing a gameplay script on top of someone else’s runtime. You are writing the runtime: the event loop, the device, the scene memory, the command buffer, the present — and then the editor that authors that scene. Same class of work as C and C++. The compiler proves the memory story before the frame runs. There is no garbage collector. Each node, each swapchain image, each inspector widget has one owner.

The editor is a game

FyroxEd is built with Fyrox. Same Scene, same renderer, extra nodes for gizmos and an editor camera, extra windows for authors. Play mode runs the game in a separate process so a crash does not take the editor with it. Copy that split. Do not begin by forking Unreal, or by wrapping another engine and calling it yours.

Memory management is the engine

Memory is the argument of the language, and it is the argument of the engine. A C++ engine leaks when a node outlives its mesh, or crashes when a pointer outlives the object. A garbage-collected engine (C#, Java, JavaScript, Go) pauses when the heap is walked mid-frame — or you spend the rest of the project fighting the collector so it does not. Rust makes the story compile.

// Scene owns every node. Handles are indices, not pointers.
struct Handle(u32);

struct Node {
    name: String,
    local: [f32; 16],
    children: Vec<Handle>,
}

struct Scene {
    nodes: Vec<Node>,
}

struct Engine {
    scene: Scene,
    // gpu: Device + Queue + Surface — also owned here
}

impl Engine {
    fn tick(&mut self, dt: f32) {
        self.update(dt); // exclusive: scripts, physics
        self.render();   // then a shared view for draw
    }

    fn update(&mut self, dt: f32) {
        for node in &mut self.scene.nodes {
            node.local[13] += dt; // translate Y
        }
    }

    fn render(&self) {
        let _n = self.scene.nodes.len();
        // encode commands, present. Drop frees the encoder. No GC.
    }
}

fn main() {
    let mut engine = Engine {
        scene: Scene { nodes: vec![] },
    };
    engine.tick(1.0 / 60.0);
} // Engine dropped. Scene, Vec, GPU — all freed.

How to write the engine and the editor

Runtime first. Editor second. A spinning mesh with a camera you own is already an engine. The windows in the screenshot come after the scene can save. Fyrox’s public source is a map of that cut, not a product to clone: fyrox.rs · github.com/FyroxEngine/Fyrox · FyroxEd overview. Copy the architecture. Name the crate yours.

Start small. cargo new my-engine. A window that closes. A surface that clears a color. A triangle, then a cube with a camera you own. Then the pool of handles. Then a dt tick that spins the cube. Then load an OBJ. Then save the scene to a file. Then a second binary: walk the graph into a list, pick a handle, show its transform, draw a gizmo. That list is the World Viewer. That panel is the Inspector. Those two plus the viewport are already an editor. Docking, prefabs, and play-in-editor come after that loop is honest. Fyrox took years of this. Do not begin by rewriting the whole of FyroxEd.

Crate map

One crate until it hurts. Then a workspace so the editor and the runtime stay two binaries on one Scene. Each crate owns one job. The engine crate is glue — the tick — not magic.

my-engine/
  Cargo.toml                 # [workspace] members
  crates/
    core/                    # math, pool of handles, uuid
    graph/                   # scene nodes, transforms, cameras
    render/                  # wgpu device, pipelines, present
    resource/                # load meshes, textures, scenes
    engine/                  # the tick — glue, not magic
    editor/                  # FyroxEd-shaped: viewer, inspector, gizmos
  README.md
  LICENSE                    # MIT OR Apache-2.0, like Rust itself
  .gitignore                 # /target, *.pdb

Push it to GitHub

A crate that only lives on your disk is a sketch. GitHub is how it becomes a project other people can clone, compile, and fork. Install Rust from rustup.rs so cargo --version prints. Install GitHub CLI if you want gh repo create in one step.

1. Scaffold: cargo new my-engine --lib. Split into the workspace above when the first module is no longer a sketch.
2. Keep build junk out of git. Cargo already writes a .gitignore with /target. Add *.pdb on Windows.
3. Write README.md — what it is, how to cargo run -p editor, what GPU it needs. Add LICENSE. MIT OR Apache-2.0 is the Rust default.
4. Commit locally, then publish. gh creates the empty repo and pushes in one command. Without it, create the repo on github.com and add the remote yourself.

# After cargo new my-engine --lib, and a README + LICENSE
git init
git add README.md LICENSE Cargo.toml src .gitignore
git commit -m "Initial engine crate"

# GitHub CLI — public repo, this folder, push
gh repo create my-engine --public --source=. --remote=origin --push

# Without gh:
# git remote add origin git@github.com:YOU/my-engine.git
# git branch -M main
# git push -u origin main

Optional next: a GitHub Action that runs cargo test on every push. Optional later: compile a wasm demo and park it on GitHub Pages — the same way oTTeCAD sits on this site. The modeler below is that discipline applied to mesh topology instead of a scene graph.