01
The host owns the frame, not your gameplay scripts
Splitframe treats frame lifecycle, renderer health, presentation, and recoverability as native runtime concerns instead of leaving them implicit in a loose scripting loop.
Splitframe Engine
Build games on a native runtime without giving up Python gameplay.
Splitframe is being built as a native-first engine with deterministic content contracts, first-class plugins and mods, a code-first path to tooling, and a credible runway from strong 2D foundations toward eventual 3D. The point is not to be another feature-bucket engine. The point is to make the runtime, content pipeline, and shipping path behave like real production systems.
- Native Vulkan runtime
- Python gameplay layer
- Deterministic cooked content
- Runtime policy enforcement
Host model Native-first
Gameplay layer Python
Content path Cooked + validated
Architecture Engine and game are separate products with separate responsibilities
Runtime Native-first frame ownership with explicit health and recovery contracts
Position Not another broad 2D framework: a stricter host for scriptable games
Why Splitframe
The point is to build an engine with a stronger production spine than a scripting-first framework usually has.
Splitframe is aiming at a specific final state: native host ownership, deterministic content and packaging, first-class extensions, editor and tooling growth, and a believable path from 2D runtime strength into a more general engine.
02
Content, shaders, and runtime policy are explicit surfaces
Cooked content bundles, shader/runtime compatibility, and runtime profiles are enforced as contracts so production behavior is shaped deliberately instead of emergently.
03
Keep Python where iteration speed actually matters
Scenes, systems, and game behavior stay scriptable, but the scripting layer rides on top of a stricter host and render pipeline rather than pretending to be the runtime.
04
The engine is a product, not a pile of game code
Splitframe exists as a reusable engine with its own docs, release surface, and contracts. Gwoop is a consumer, not the definition of the engine.
Design Philosophy
Treat the runtime as a real product surface, then let gameplay, tools, and extensions grow on top of it.
Splitframe puts hard edges around runtime profiles, cooked content, renderer compatibility, extension boundaries, and project packaging. Python remains central, but not as an excuse to keep the engine loose or the shipping path improvised.
Host model Native-first
Gameplay layer Python
Engine stance Tooling-ready
from splitframe import GameEngine, EngineConfig, Scene
class BootScene(Scene):
def handle_event(self, event):
return True
def update(self, dt):
pass
def render(self, game):
pass
engine = GameEngine(
EngineConfig(
game_title="Splitframe Project",
screen_width=1440,
screen_height=900,
tile_size=32,
)
)
engine.scene_manager.push(BootScene(engine))
engine.run()Docs Preview
Start with the target state, then drill into the current engine seams.
The docs are organized to make the engine direction legible first: what Splitframe is trying to become, which architectural stances are non-negotiable, and which runtime/content contracts already exist in code.
Getting Started
01 Install Splitframe, run the engine locally, and understand the first runtime concepts.
Runtime Architecture
02 Understand the native runtime, engine modules, and Python gameplay layering.
Roadmap
03 The target state for Splitframe and the milestones required to reach it.
Engine Overview
100 High-level engine layout, current core surfaces, and repository ownership.
Building Splitframe
110 Python package setup and native runtime build commands for the engine.
Testing Splitframe
120 Boundary checks, import smoke coverage, and standalone engine verification.
Migration Notes
130 Extraction status, deferred cleanup work, and compatibility notes for the repo split.
Release Signal
The release story should show the engine converging on its target state.
Changelog entries should prove that Splitframe is getting stronger at runtime discipline, extension boundaries, tooling foundations, and packaging, not just accumulating miscellaneous subsystems.
Next Move