Seed Engine

Problem

A self-directed project to understand game engines by building one — the systems most web work never touches: real-time rendering, physics, procedural generation, streaming, and crash-safe persistence.

What I did

seed_engine is the reusable C++20 library; seed_demo is a game built on it (an explorable island with a destructible timber platform, digging, and building). It does chunk streaming, destructible building physics, generated materials, normal-map lighting, and background checkpoints that leave the previous save loadable if a commit is interrupted.

Separately, seed_editor is a full dockable visual editor (Dear ImGui) with terrain tools, a multi-selection inspector, prefabs, Lua scripting with live syntax checking, undo/redo, and one-click macOS app export — all kept strictly out of the shipped games so they never link the editor.

Outcome

A working engine, demo, and editor with defined, documented memory budgets (resident chunks, ECS entities, physics bodies), repeatable benchmarks, and a validation record that’s honest about what’s been exercised (macOS/OpenGL) versus what’s still pending (Windows/Linux sign-off).

It’s the project that best shows I can reason about low-level systems and performance, not just application code.