ADITYA SINHAGAMEPLAY DESIGN + ENGINEERING
← All projects
ENGINEERING PROJECT

C++ Game Engine

ROLEEngine Programmer

TEAMSolo project

DATEJan – Apr 2025

TYPEData Driven Game Engine

PROJECT SUMMARY

I built a modular C++ game engine around external data, clean separation of concerns, and fast content iteration. It later became the foundation for a team built Bloons TD5 recreation.

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.
View architecture and documentation ↗
Bloons TD5 recreation built on the custom C++ game engine
The engine was validated by building a playable Bloons TD5 recreation on top of it.
JSON defining a tower behavior in the custom C++ game engine
JSON describing a tower behavior that fires at the nearest Bloon.
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.

  1. 01 / LOADI built a Content Service that reads JSON through registered parsers.
  2. 02 / REPRESENTI used Scope and Datum to store typed runtime data and nested structures.
  3. 03 / BUILDI created a Factory Service that builds reflected game objects and Actions.
  4. 04 / RUNI used composable Actions to execute gameplay behavior from external content.
Class diagrams for clock services, content services, JSON parsing, and content handlers
Content and service architecture. Parsers, handlers, factories, registries, and clock services remain behind focused interfaces.
Class diagram for the custom memory service and allocator provider
Memory architecture. Clients request an interface while the service provides the allocator implementation.
Class diagram for RTTI, attributed objects, factories, and composable Actions
Runtime behavior architecture. RTTI, attributed objects, factories, and Actions connect content to executable behavior.
RUNTIME FOUNDATIONS

Flexible content with clear boundaries.

I built each foundation to improve iteration while keeping ownership and performance visible.

REFLECTION

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.

SERVICES & FACTORIES

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.

MEMORY & ACTIONS

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.

Explore the gameplay systems ↗Read the engine documentation ↗