Splitframe is organized around a native-first runtime surface, reusable engine systems, and a Python gameplay layer that stays modular rather than sprawling across the whole renderer stack.
The important architectural point is that these layers are not equal peers. They have different responsibilities.
The Runtime Stack
At a high level, Splitframe is aiming at this shape:
- Native host/runtime owns frame lifecycle, presentation, device recovery, and renderer health
- Engine systems own scenes, content lookup, input, runtime policy, save/state, and reusable gameplay-adjacent services
- Python gameplay/project layer owns scenes, entities, game rules, progression, and project bootstrap
- Project content owns cooked assets, data, configuration, and game-specific resources
That structure is the difference between “an engine with a Python gameplay layer” and “a Python codebase that also renders.”
Native Host Responsibilities
The host/runtime layer is where Splitframe tries to stay opinionated.
It is responsible for:
- frame begin/update/render/present flow
- native backend selection and compatibility validation
- device, surface, and swapchain lifecycle
- renderer health and recoverability signaling
- runtime profile policy
- Python/native render submission contracts
This matters because gameplay code should not quietly become the authority for host behavior. If a game needs deterministic presentation, cooked-content requirements, and a stable renderer contract, then the host has to own those concerns directly.
Engine System Layer
Above the host is the reusable engine layer.
This is where Splitframe keeps systems such as:
- scene management
- input handling
- content loading and cooked bundle lookup
- reusable runtime services
- plugin and modding boundaries
- debug and observability surfaces
The system layer exists so game projects do not have to reinvent runtime-facing services from scratch. It is also where engine/game separation becomes easier to enforce.
Python Gameplay Layer
Splitframe is not trying to eliminate Python from game development. The gameplay layer remains one of the engine’s strongest values.
Python is a good fit for:
- game bootstrap
- scene composition
- project-level rules
- progression, interaction, and orchestration logic
- tool-driven iteration during development
The boundary is that Python gameplay should sit on top of the runtime and engine system layers instead of implicitly replacing them.
Content And Runtime Contracts
One of the strongest architectural choices in Splitframe is that content and runtime assumptions are meant to be explicit.
That includes:
- cooked asset manifests
- runtime bundle lookup
- shader bundle activation
- schema and compatibility checks
- build outputs that can be reasoned about
The goal is to make the shipping path predictable. A project that depends on the engine should know what content shape the runtime expects and what artifacts the build produces.
Plugins, Mods, And Tooling
The extension/tooling story only makes sense if it respects the runtime layers.
That means:
- plugins and mods should target stable APIs rather than arbitrary internals
- capability gates and manifests should define what extensions are allowed to do
- editor and tooling surfaces should build on the same engine-owned data model
- project automation should not have to bypass the runtime contracts to work
This is why the extension platform and tooling ambitions belong in the core architecture story, not as optional afterthoughts.
Why This Matters For 3D
Splitframe is strongest today as a 2D engine, but the eventual 3D ambition only makes sense if the shared architecture is already sound.
The runtime model should generalize:
- host lifecycle should stay authoritative
- content contracts should remain deterministic
- plugin/tooling boundaries should stay shared
- project packaging should not fork into unrelated pipelines
That is the only credible way for 3D to emerge later without becoming a second, incompatible engine.
What This Architecture Is Trying To Avoid
Splitframe should not drift into:
- a generic everything-engine with no center
- a script-first framework where runtime policy is ad hoc
- an editor-only world where code becomes second-class
- a modding story built on unstable internal seams
- a cross-platform story that depends on many competing runtime models
The architecture exists to prevent that drift.
Where To Go Next
If you want the product direction after the architecture shape, go to Roadmap.
If you want the engine-source truth behind these ideas, go to the generated docs, starting with Engine Overview.