Types that explain themselves.
I built a lightweight RTTI layer for safe casting, type lookup, factory hooks, and attributed fields. It lets designers add runtime properties through JSON while C++ systems still receive typed data.
ENGINEERING PROJECT
C++ Game Engine
PROJECT SUMMARY
I built a data driven C++ game engine from scratch where game objects are defined in JSON, so changes need no recompiling. Each file is parsed into Scope and Datum, containers for typed data, and a factory builds the C++ objects and attaches Actions, reusable behaviors like looping increments and timers.
THE ENGINEERING GOAL
Let gameplay change without rebuilding the engine around it.
I designed game objects, components, behaviors, and sequences to be defined through JSON and assembled at runtime. I kept engine clients on stable interfaces while the services behind them remained replaceable.
WHAT I BUILT
- I built runtime reflection and attributed objects for type safe metadata.
- I created a service manager, abstract factories, JSON content parsing, and reusable Actions.
- I implemented a custom memory service with named heaps, allocators, coalescing, and usage statistics.
- I built the content foundation later used by Bloons TD5 towers, upgrades, behaviors, and paths.
ARCHITECTURE AT A GLANCE
Content moves through small, focused systems.
I separated loading, object construction, behavior, and memory so each part could evolve without forcing gameplay code to know every implementation detail.
- 01 / LOAD
I built a Content Service that reads JSON through registered parsers.
- 02 / REPRESENT
I used Scope and Datum to store typed runtime data and nested structures.
- 03 / BUILD
I created a Factory Service that builds reflected game objects and Actions.
- 04 / RUN
I used composable Actions to execute gameplay behavior from external content.
RUNTIME FOUNDATIONS
Flexible content with clear boundaries.
I built each foundation to improve iteration while keeping ownership and performance visible.
Depend on the interface.
I built a Service Manager that exposes subsystems by interface, while factories construct objects from reflected type names. That keeps client code stable when an implementation changes.
Control cost. Compose behavior.
I implemented named heaps and coalescing allocators to expose usage data and control fragmentation. I used Action lists to turn external content into ordered gameplay behavior that can be reused and extended.
ENGINE IN PRACTICE
Built to support a real game.
The engine mattered because it made a complete gameplay project easier to author, test, and optimize.
Bloons TD5 Recreation
I used this engine’s content and service architecture to support towers, upgrades, behaviors, paths, and collision data in a six person game project. The companion case study focuses on the systems I personally owned.
The spatial partitioning I built for it cut average collision time from about 1.5 ms to 0.6 ms a frame. I measured it with high resolution timers in code while the game processed more than 200 projectiles per frame.
1.5 ms to 0.6 ms collision time per frame