Game Engine Programming | NSEngine

01 // PROJECT_ABSTRACT

The goal of this project was to develop a 3D game engine and prototype game in C++ using a custom hybrid architectural design combining inheritance and an Entity Component System (ECS). Built from the ground up using a professional toolchain, including CMake for build management and Git via Fork, the engine focuses on highly integrated subsystems designed for scalability and reusability.

Architecturally, the system utilizes a clear hierarchy: a centralized Core manager handles initialization, baseline systems execution, and management of independent game environments. These environments encapsulate scene-specific logic, owning a collection of entities which in turn host custom component modules. A basic structural overview of this data ownership flow can be seen below.

02 // ARCHITECTURE_DETAILED

The engine is architected using a modern, lightweight C++ stack, selecting specialized third-party libraries to handle low-level subsystems while keeping the core framework modular and performant.

Rend (Graphics API Wrapper)

Acts as the dedicated 3D rendering abstraction layer, wrapping OpenGL to cleanly manage shader compilation, texture binding, and vertex buffer generation. A big reason I used this library is that you do not need to clean up memory because it utilizes RAII and releases its resources properly, basically meaning that any resources are automatically cleaned up when they go out of scope.

SDL (Platform Abstraction)

Handles low-level platform management, responsible for opening the application window, maintaining the OpenGL hardware context, and processing cross-platform input event polling.

ReactPhysics3D (Physics Subsystem)

An open-source 3D physics library integrated directly into the engine to handle rigid body dynamics, momentum, and precise spatial collision resolution.

Environments

This game engine has the framework to be able to effectively create "scenes", or environments in this case, that act just like the scenes in Unity or Unreal. Essentially the scene is the overall parent of every object, and subsequently every component on each object within each given environment. You can take a look back at the engine overview further up the page to see that hierarchy Engine > Environment > Entities > Components. Structuring it this way means that while there isn't a hardcoded environment manager, you could easily spin up your own manager to handle creating or destroying custom environments on the fly.

Entity Component System

As I mentioned previously this game engine leverages an Entity component system, which as the name suggests (and as I have previously lightly touched on) breaks objects down into 3 parts. The entity itself, this is simply a unique id that acts as a container, think the chassis of a car holding the rest of the components together. Then you have the components and systems, which in pure ECS frameworks are separate. However, this engine utilizes more of an object-oriented ECS framework that combines the two, in the car analogy they would be the computers (components) and engine (systems). These components handle their own update cycles when relevant as seen in the image below.

The components currently included within the engine are as follows:

Audio Source

A component for handling where audio gets played

Box Collider

Simple AABB Collision detection

Camera

The component responsible for what the player sees in game

Capsule Collider

Collider in the shape of a capsule similar to box collider

GUI

Basic component to handle on screen user interfaces

Renderer

This is the component responsible for rendering 3D models in the game

Rigidbody

The component that handles entity physics, movement, collision etc

Sprite Renderer

A component for specifically rendering 2d Sprites

Transform

Component that stores the positional data for the entity it is attached to

Triangle Renderer

A simple test component that renders a triangle

Resources and Inheritance

Resources are how the classes that use assets get the necessary data within this engine, there is a base resource class that holds common data between the resources, and inheriting from that are the Audio, Model and Texture classes that override the common functions to implement the functionality they need.

Simple Game Demo

To validate the engine’s core pipeline, I developed a lightweight demonstration project within the framework. While minimal in scope, the demo successfully exercises the interaction between the entity hierarchy, rendering loops, and component systems. It proves that the engine provides a practical, working abstraction layer, allowing gameplay features to be implemented rapidly without needing to write low-level boilerplate code.

03 // HURDLES_RESOLVED

The single biggest challenge i faced while creating this project was the shear volume of things to consider while creating a game engine, which can be easily become overwhelming. Because I tackled this through upfront planning rather than coding on the fly, enforcing a strict structural hierarchy before opening the IDE at all. As detailed in the class architecture diagram at the very top of this page, I mapped the entire engine into four isolated areas of responsibility: configuration control (Core), scene management (Environment), game object creation (Entity), and modular behavior (Component). This planning ensured that no matter how many features were added later, each had a predetermined, isolated slot to live in without breaking the rest of the ecosystem.

04 // RESEARCH_PAPER

If you would like to look at the full paper i wrote for this project, please click the link below.

> FETCH_FULL_RESEARCH_PAPER.PDF