This page describes the target state for Splitframe, not a claim that every part of the engine already exists in finished form.
The point of the roadmap is to define the product we are building toward, keep the architectural stances coherent, and make the final public position legible before the engine reaches full maturity.
Target State
Native-first host
The runtime owns frame lifecycle, device lifecycle, presentation, recoverability, and performance policy.
Python where iteration matters
Python remains valuable for gameplay, orchestration, and project logic without pretending to be the whole runtime.
Deterministic build and asset contracts
Cooked assets, shader bundles, schemas, packaging, and runtime lookup become part of the product surface.
First-class plugins and mods
Stable APIs, capability gates, compatibility rules, and lifecycle control define a real extension platform.
Editor on the same engine model
Tooling and editor layers should grow from engine-owned data and runtime contracts, not invent a separate hidden world.
2D strength with a credible path to 3D
3D should emerge from shared architecture, not a marketing bolt-on or a fork into a second engine.
Disciplined cross-platform shipping
Cross-platform support should come from packaging, validation, and host capability discipline rather than backend sprawl.
Architectural Stances
The native host owns the runtime
Python gameplay code is important, but it is not the authority for frame ownership, presentation, device recovery, renderer health, or runtime policy. That belongs to the native host.
This stance already fits the engine well: runtime profiles are enforced, cooked-content requirements are explicit, and the renderer contract is treated as a real boundary instead of an implementation detail.
Contracts matter more than convenience
Splitframe should continue to prefer schema'd packets, versioned content manifests, compatibility checks, and explicit failure over loose implicit behavior.
- Python/native rendering payloads
- Cooked content bundles and asset manifests
- Plugin and mod manifests
- Editor-to-runtime data exchange
- Project build outputs and target packages
If two parts of the system need to cooperate, the goal is to make the contract visible and testable rather than "magically compatible."
Code-first does not mean anti-tooling
Splitframe should not become an editor-only black box. The engine should remain usable from code, testable in code, and automatable in code.
- The engine remains code-first
- The editor becomes a powerful client of the same engine data model
- The editor does not become a second source of truth
Plugins and mods are products, not hacks
If plugins and mods are first-class, they need more than dynamic imports. They need stable public APIs, manifest-based discovery, capability-gated services, sandbox boundaries, dependency rules, and project/editor integration.
Splitframe already has meaningful foundations here. The final state is to turn those foundations into a supported extension platform.
3D should emerge from engine generalization, not a rewrite
Splitframe should not market "2D and 3D" unless the underlying architecture can carry both without forking into two unrelated engines.
- Keep host, content, plugin, and tooling architecture shared
- Generalize scene, transform, resource, and render submission models
- Add 3D as another consumer of the same runtime spine
Cross-platform should come from disciplined packaging
The goal is not to accumulate a pile of half-supported runtimes. The goal is to have one authoritative engine model with platform-aware host, packaging, content, and deployment layers.
- A stable host/runtime boundary
- Target-aware cooking and packaging
- Predictable platform services and capabilities
- Platform validation and CI coverage
What Splitframe Should Not Become
Not a generic everything-engine
Splitframe should not win by listing a pile of unrelated features.
Not a loose Python framework
The runtime should not become whatever each project happens to improvise.
Not a black-box editor product
Code, source control, and automation must stay first-class.
Not unstable modding theater
Mods and plugins cannot depend on random internal seams and still be credible.
Not a fake 3D claim
3D should not be advertised unless the architecture can actually carry it.
Not backend chaos dressed up as portability
Cross-platform delivery should come from packaging discipline, not runtime sprawl.
Roadmap
The roadmap is ordered by architectural dependency, not by marketing drama.
Finish the product boundary
The first step is to make the engine tell the truth about itself.
- Remove leftover
gwoopnaming and old workspace assumptions - Tighten the public engine docs around the actual runtime model
- Bring examples in line with the native-first engine stance
- Reduce the public "everything bucket" feel of the Python surface
If the public story, docs, and examples still describe an older engine shape, everything after that gets harder to explain and harder to trust.
Harden the native 2D runtime
Splitframe should first become excellent at its current core before claiming the rest of the roadmap.
- Stable native host lifecycle and recovery behavior
- Mature render health and telemetry surfaces
- Stronger cooked-content and shader-bundle workflows
- Repeatable profiling and performance validation
- Better runtime observability in development and CI
The 2D runtime is the base that every other ambition depends on: tooling, plugins, packaging, and future 3D all inherit from it.
Formalize the extension platform
Plugins and mods need to stop being side systems and become a real engine product line.
- Stable script ABI and public extension documentation
- Capability-gated engine service surface
- Project and plugin packaging rules
- Version compatibility and dependency policy
- Sandbox and trust model for mod and plugin execution
A moddable engine only becomes credible when extension boundaries are explicit, portable, and testable.
Build the editor and tooling layer
Once the runtime and content contracts are stable, Splitframe can grow a proper editor and project toolchain.
- Project creation and workspace tooling
- Asset import, validation, and cook inspection tools
- World and scene editing built on engine-native data
- Runtime inspection, diagnostics, and profiling panels
- Plugin-aware editor extension points
The editor should sit on top of stable runtime and content contracts. Building it earlier would encourage duplicate logic and unstable file formats.
Generalize the engine core for 3D
The 3D roadmap should begin as an architectural generalization program, not a marketing splash.
- Shared scene and resource contracts for both 2D and 3D
- Transform, camera, lighting, and material models that scale
- Generalized render submission and asset formats
- Editor and tooling support that does not split into separate products
3D is only worth advertising when it grows from the same disciplined runtime and tooling spine that makes the 2D engine valuable.
Expand platform delivery
Cross-platform support becomes real when project packaging and validation become part of the product.
- Target-specific cooking and bundle generation
- Platform service abstractions and capability declarations
- Packaging flows for supported targets
- Build validation and test coverage across target platforms
Cross-platform promises are only believable after the runtime, content, extension, and tooling layers are stable enough to ship repeatedly.
How to Read This Roadmap
This roadmap is not a promise to add random headline features. It is a statement that Splitframe is aiming for a very specific kind of engine.
- Native-runtime first
- Code-first but tooling-rich
- Deterministic in content and build outputs
- Extensible by design
- 2D-strong with a real path to 3D
- Capable of shipping across platforms without losing its center
That is the destination the website should market, and the engineering work should be judged by whether it moves the engine toward that state.