Design philosophy: the native host owns frame lifecycle, presentation, recovery, and policy. Python remains central for gameplay, orchestration, and iteration speed. Content, shader, plugin, and build boundaries are meant to be explicit contracts rather than soft conventions.

Splitframe started inside the Gwoop workspace. Extracting it into its own repository is not just a Git cleanup exercise, it is a product decision: engine architecture, docs, examples, and release direction can now be presented directly instead of being inferred from one game codebase.

That separation matters because Splitframe is aiming at more than the engine's current rough edges. The public product direction includes a deterministic content and packaging path, a real plugin and modding platform, editor and tooling layers built on the same data model, and a disciplined path from 2D strength toward eventual 3D support.

The clearest reasons for Splitframe to exist are still architectural: native-first frame ownership, deterministic content and shader surfaces, enforceable runtime profiles, stable extension seams, and a cleaner boundary between reusable engine code and project-specific logic. The roadmap exists to make those stances concrete rather than rhetorical.

If you want the short version of where the engine is headed, start with the roadmap. It defines the target state and the order the engine has to earn it in.