Introducing Gamepenter: A Humble Game Engine Project That Kept Growing

Gamepenter is a personal game engine project that has gradually grown into a larger runtime and tooling effort.

It is not being presented as a finished product, and it is not trying to pretend it can instantly stand beside the biggest engines in the industry. What it does have, based on the current state of the project, is a real architecture, a working runtime, a growing set of samples, a packaging pipeline, and a clearer direction than it had when it first began.

Today, Gamepenter is a C++ game engine built around SDL3, an Entity Component System based world model, Python scripting, 2D physics, scene-driven content, and a virtual file system that supports both development-time projects and packaged builds. It also includes supporting tools such as build and packaging scripts, an asset editor, and a structure that is slowly moving toward a broader Gamepenter Studio vision.

This article is meant to introduce Gamepenter in a simple and honest way: where it came from, what it looks like today, and how the current architecture is shaping up.

A game engine is one of the most demanding kinds of software to build because it has to bring together many different technical concerns into one working whole. It is not just a renderer, not just a scripting layer, not just an editor, and not just a runtime loop. A real engine has to deal with assets, input, audio, simulation, tooling, packaging, performance, debugging, platform behavior, and the everyday needs of actually making games.

From my own experience, I would honestly say a game engine can be one of the most complex pieces of software a developer can work on. In some ways, I find it even more complex than software systems I got involved with, because a game engine has to combine real-time responsiveness, creative flexibility, developer workflow, content handling, and cross-system coordination all at once. It sits in a difficult space between software engineering, tooling, runtime systems, and creative production.

That complexity also exists inside a very large industry. The global video game market is a massive entertainment behemoth, generating nearly $190 to $197 billion in annual consumer spending and services. By contrast, the specialized game engine market is a smaller but rapidly expanding niche, valued at approximately $3.5 to $11.4 billion annually. Within that space, Unreal Engine, Unity, and Godot are the names most people think of first, while GameMaker and other specialized tools also continue to serve important parts of the market. Around those engines there is an entire tool ecosystem as well, including art tools, audio pipelines, asset workflows, build systems, packaging utilities, and studio-specific production software.

That matters because it gives the right context for Gamepenter. This project is not appearing in an empty field. It exists in a space that is already mature, competitive, and full of powerful tools built by large teams over many years. That is exactly why I think it is important to be honest about what Gamepenter is and is not.

Gamepenter started in 2017 as a degree project.

It began as a Final Year Project for a Bachelor of Science (Honours) in Computer Science and Software Engineering at Oxford Brookes University. The original idea was not just to make a game, but to build a cross-platform 2D game engine and game development tool that could help make game creation easier.

The first version was built in Java. At the time, that made sense for two reasons. First, Java was a practical way to take advantage of cross-platform capability. Second, it matched the academic environment around the project and made it easier to focus on engine ideas, tool building, and reusable systems rather than low-level platform details.

After that university version was completed, the idea behind Gamepenter never really disappeared.

In early 2025, I rewrote Gamepenter in Python. That decision came from heavy exposure to Python over the years and from how simple and productive it can be, especially when experimenting with systems, tools, and gameplay ideas. Python made iteration easy and helped reconnect the project to the original goal of building something flexible and approachable.

But as the project continued, performance limitations became harder to ignore, especially when trying to run even 2D games on Android. Because of that, I made the decision to rewrite Gamepenter again in C++ in Q4 2025.

That rewrite became the foundation of the current version of Gamepenter.

Since then, the project has moved forward step by step. Features have been added gradually, the runtime has become more structured, the tooling has improved, and the architecture has become more deliberate. So the current Gamepenter is not a sudden new idea. It is the latest stage of a project that started in 2017, went through Java, then Python, and finally arrived at its current C++ form.

This diagram shows the major transitions in Gamepenter’s history, starting from the original 2017 university project and moving through the later rewrites. It is meant to make the project’s evolution easy to follow at a glance before the article moves into the current architecture.

Right now, Gamepenter is best described as a Windows-first game runtime and tooling project with cross-platform goals.

The live codebase currently includes:

• a C++ engine runtime
• SDL3-based platform and rendering foundations
• an Entity Component System based world model
• Python scripting for gameplay behavior
• 2D physics integration
• scene loading and scene-driven entity creation
• asset loading, caching, and packaging support
• desktop packaging workflows
• sample projects that exercise different parts of the engine
• early tooling such as the Gamepenter Asset Editor

That may not sound flashy, but it is the part that matters most to me: the project is becoming real through actual implementation, not just plans.

This diagram gives a folder-accurate overview of the project today, showing the main top-level surfaces that define how Gamepenter is organized. It helps separate the core engine code, the runtime launcher layer, and the asset editing tool.

The current Gamepenter codebase is organized around separate subsystems instead of one large runtime blob.

At a high level, the architecture is built from:

• core runtime systems
• asset systems
• scene systems
• scripting systems
• rendering systems
• audio systems
• physics systems
• input and platform systems
• UI and debug systems
• the runner layer that boots and composes them

That split is important because Gamepenter is trying to grow in a maintainable way. The goal is not just to add features, but to make sure responsibilities are reasonably clear as the project gets bigger.

This diagram groups the checked code folders more directly so the reader can see how the codebase is divided into major responsibilities. It shows that the runner is the launch and composition layer, the engine contains the reusable runtime systems, and the asset editor exists as a separate tooling surface rather than as part of the runtime executable itself.

When Gamepenter starts, the runner resolves configuration, finds the active project, loads mounted roots or packaged bundle paths, initializes runtime services, loads assets, loads project and scene data, sets up scripting and audio, spawns scene entities into the world, registers systems, and then enters the main loop.

That boot flow is one of the areas where the current codebase already feels much more grounded than earlier versions.

The runtime works with layered configuration files such as:

• gamepenter.ini
• assets/runtime.ini
• assets/project.ini

This lets the project separate window and runner settings, runtime behavior, and project metadata instead of forcing everything into one place.

This diagram shows the checked runner startup flow from the first application entry point through configuration resolution and runtime initialization. It is meant to summarize the sequence that turns a project on disk into a live running scene inside the main loop.

This diagram shows how the different configuration layers combine before the runtime begins normal execution. It highlights that Gamepenter does not depend on one single file, but instead merges root settings, project-local settings, and command-line overrides into one effective runtime configuration.

Gamepenter uses a fixed-step main loop with separate input, simulation, and rendering phases.

In practice, that means:

• input is pumped once per frame
• simulation runs on a fixed timestep
• rendering runs separately with interpolation
• large frame hitches are clamped
• runaway catch-up updates are limited

This is a practical choice for the kind of runtime Gamepenter is trying to become. It helps keep gameplay updates more predictable, gives physics a steadier environment, and avoids tying all behavior directly to rendering speed.

The engine also uses a scheduler that registers systems by phase and priority. That makes the runtime flow easier to understand and easier to extend.

This diagram shows the high-level order of one frame, from input handling through simulation and finally presentation. It exists to explain the broad pacing model of the runtime before the article discusses scheduler phases and system responsibilities in more detail.

This diagram highlights the three main scheduler buckets used by the runtime and shows how work is grouped instead of being processed as one undifferentiated update pass. It reinforces the idea that Gamepenter’s frame loop is structured around phases with clear intent.

Gamepenter uses an ECS-style world as the main way to store and update gameplay state.

Entities and components are created in the world, then different systems operate on them during the frame loop. That world model is already being used for scene-created entities, renderable objects, scripted entities, and physics-driven entities.

The important thing here is not just that an ECS exists. It is that the project is consistently using one shared world model across the runtime. That makes the engine easier to reason about and helps different features work together through the same underlying structure.

This diagram shows how several different runtime concerns converge into one shared Entity Component System world. The goal is to make clear that scene data, scripts, rendering state, and physics state are not isolated subsystems with separate object models, but parts of one common gameplay world.

One of the stronger parts of the current architecture is the scene layer.

Gamepenter loads project and scene definitions, then uses a scene manager to spawn live entities into the world. Scenes can currently describe things such as:

• 2D transforms
• 3D transforms
• cameras
• sprites
• primitive 3D meshes
• 3D model references
• rigid bodies
• colliders
• attached script modules

That means Gamepenter is already more than a code-only runtime. The scene file is becoming one of the main authoring contracts for the engine.

The scene manager also supports scene reset, reload, named-entity lookup, and spawn/destroy services that can be exposed back into the scripting layer.

This diagram shows how project data and scene definitions pass through the scene manager before becoming live runtime entities. It is useful for understanding where authored content stops being static data and starts becoming active game state.

This diagram shows the typical kinds of data a scene entity can describe in the current engine. It gives a compact view of how transforms, visuals, physics, and scripts can be attached to one entity definition and then instantiated at runtime.

Python scripting is one of the most useful parts of Gamepenter for iteration.

The current runtime includes a script VM and a script system that allow gameplay logic to live in scripts while the engine core stays in C++. The engine handles script module loading, reload behavior, lifecycle calls, context around the active entity, and the connection between scripts and engine services.

For script-driven entities, the runtime already supports a familiar lifecycle such as:

• ready
• start
• fixed update
• update
• destroy

Scripts can also interact with runtime state such as:

• the active world
• the current entity
• input state
• 2D physics
• scene services
• layout metrics for responsive positioning helpers

This is one of the most practical parts of the engine because it allows gameplay behavior to change quickly without rebuilding the whole runtime every time.

This diagram shows how Python scripts connect to the virtual machine, the script system, and the runtime services exposed around them. It is meant to clarify that scripting is not an isolated add-on, but part of the runtime loop with access to world, input, physics, and scene-level helpers.

This diagram shows the main lifecycle stages for script-driven entities in the order they are expected to occur during normal runtime behavior. It gives readers a simple mental model for how scripted gameplay code is entered, updated, and eventually torn down.

Gamepenter also includes a dedicated 2D physics layer.

The physics world is responsible for synchronizing physics bodies with ECS entities, stepping simulation on the fixed timestep, updating transforms back into the world, rebuilding bodies when needed, and collecting collision and trigger events.

Those events are then routed into the scripting layer through callbacks, which makes physics part of gameplay rather than a completely separate system.

This is still an area that will continue to improve, but the current structure is already useful and gives the engine a good base for gameplay-heavy 2D samples.

This diagram shows how the physics layer interacts with the world, the simulation step, transform updates, and script callbacks. It makes the current 2D physics flow easier to understand by reducing it to the core data and event path.

Gamepenter’s rendering path is still evolving, but the current architecture already has a useful shape.

The engine has a renderer abstraction and currently works with SDL3-based rendering backends. The runtime also supports multiple rendering slices instead of treating rendering as one giant block. Right now those slices include things such as:

• frame begin
• sprite rendering
• primitive 3D rendering
• 3D model rendering
• HUD and overlay rendering

This matters because it allows the renderer to grow one piece at a time.

Gamepenter is clearly still stronger today in 2D and lighter hybrid 2D/3D workflows than in advanced 3D, but the architecture already shows how more rendering features can be added without rewriting the whole runtime model.

This diagram shows how the renderer fans out into the main rendering passes currently described in the runtime architecture. Its purpose is to show that rendering is already broken into slices, which makes the system easier to expand incrementally.

This diagram shows the relationship between the SDL3 platform layer, the renderer abstraction, and the current rendering directions supported by the project. It gives a compact picture of how platform-facing rendering support connects to higher-level output paths in the engine.

One of the areas where the project feels most solid is the asset side.

Gamepenter already has:

• an asset registry
• file loading helpers
• caches for textures, audio clips, and script source
• a virtual file system abstraction
• support for both filesystem-backed and archive-backed content access

This gives the engine a cleaner development-to-packaging story.

During development, projects can be read directly from normal folders. In packaged mode, the same higher-level systems can read from bundled content through a virtual file system and mounted roots model. That means assets, scripts, and scenes do not need a completely different logic path just because the project has been packaged.

That is a very useful direction for the project because it keeps the content model more consistent.

This diagram shows how both development folders and packaged archives feed the same content access layer through the virtual file system. The important idea here is consistency: the engine is trying to read the same kinds of content through one higher-level path whether the project is unpacked or packaged.

This diagram shows the current asset path from registry and loader into the main caches used by the runtime. It is intended as a quick explanation of how asset discovery and loading are organized before assets are consumed by rendering, audio, or scripting.

Audio is also integrated into the same broader runtime model.

The engine includes an audio system that initializes audio playback, loads clips from asset metadata, supports reload and unload behavior, and plays audio through the runtime rather than through isolated sample-specific code.

Alongside that, Gamepenter already includes supporting systems for:

• logging
• trace output
• overlays and HUD text
• input handling
• project-local fonts
• headless and automated runs

These are not glamorous features, but they are the kinds of things that make an engine more usable in practice.

This diagram groups the support features that are visible in the checked engine and runner code, including debug, logging, hot reload, and shutdown behavior. It helps show that a usable engine is made not only from gameplay systems, but also from the surrounding support features that make development, testing, and observation practical.

Gamepenter is already being exercised across a range of sample projects, and those samples can be downloaded for testing.

That includes examples such as:

• fireworks
• bouncing boxes
• Snake
• Boxman
• Space Invader
• 2D physics demos
• primitive 3D samples
• 3D model samples

There is also an asset editor for working with packaged asset archives. It is still modest in scope, but it is a good example of the project moving beyond the runtime executable itself and toward a broader workflow.

The biggest difference between the current Gamepenter and the older versions is not just the language choice.

It is the level of architectural care.

The original 2017 version started from a valid and useful academic idea. The Python rewrite in early 2025 helped re-open the project in a simpler and more experimentation-friendly way. But the current C++ version is where the architecture has started becoming more deliberate.

The codebase now pays more attention to:

• subsystem ownership
• runtime separation
• scene and asset boundaries
• packaging flow
• scripting integration
• observability
• long-term maintainability

That does not mean everything is finished. It just means the project now has a clearer backbone.

This diagram summarizes how the project moved from the original idea into the current gradual improvement phase. It works as a closing visual reminder that the current architecture is the result of several iterations rather than a single uninterrupted build.

It is also important to say what Gamepenter is not.

Gamepenter is not trying to present itself as a finished AAA engine. It is not pretending to replace the biggest established engines. It is not claiming every system is mature.

What it is trying to become is simpler and more honest than that:

• a usable engine for experimentation and game development
• a project where runtime and tooling can evolve together
• a place to explore architecture, workflows, and maintainable engine design
• an engine I can use to build my own commercial games
• something I can also share with other developers who may find it useful
• a long-term effort that improves step by step

Gamepenter is an active and evolving project. As development continues, I will be publishing updates, technical articles, architecture discussions, development logs, and downloadable samples.

To follow the latest progress of the project, visit: Gamepenter Page

The project page serves as the central hub for Gamepenter-related content and will continue to grow as new features, tools, and documentation become available.

Gamepenter started as a university project in 2017.

It was first built in Java because of its cross-platform capabilities. In early 2025, it was rewritten in Python to take advantage of the language’s simplicity and the ease of rapid experimentation. Later, in Q4 2025, it was rewritten again in C++ when performance limitations, particularly around running 2D games on Android devices, made a native approach the more practical long term direction.

Since then, the project has continued to grow slowly, steadily, and honestly.

Today, Gamepenter already includes a functional runtime, clearly defined architectural boundaries, scene loading, Python scripting, 2D physics, asset management, packaging support, sample projects, and early development tools. There is still a significant amount of work ahead, but there is now enough in place to clearly see the shape of the engine and where it is heading.

That is probably the best way to introduce Gamepenter today.

Gamepenter is not trying to compete directly with the established leaders in the game engine market. My goal is much more practical than that. I want to build Gamepenter into an engine that I can confidently use to develop my own commercial games.

If it becomes useful to other developers as well, I am happy to share it. However, the first responsibility of the project is to be real, usable, reliable, and capable of supporting the games I personally want to create.

Gamepenter is not a finished destination.

It is a real project that has been rebuilt more than once, has learned from every iteration, and is gradually becoming the engine I originally hoped it could grow into.