CUSTOM 3D GAME ENGINE

Engine and Graphics Programmer

December 2025 - Present

PC

C++, OpenGL, GLSL, GLFW, GLEW, CMake, Git

View Repository

This project is a custom 3D game engine written in C++ using OpenGL. I’m building the foundational systems required for real-time rendering, including graphics infrastructure, resource management, input handling, and engine architecture.

I’ve always been curious about how video game engines work under the hood, so I decided to start exploring engine development by building a 3D game engine from scratch. The goal of this project is to develop a deeper understanding of how modern game engines are structured by implementing the core systems that drive real-time interactive applications.

Since this is my largest solo project so far, it also pushes me to think more deeply about software architecture: how systems communicate and how to structure a scalable codebase as the project grows.

Right now, the engine has reached its first milestone: the foundational engine architecture is complete. Current features include:

- Graphics API abstraction layer
- Shader program management system
- Vertex buffer and vertex layout system
- Mesh and material abstractions
- Render queue for organizing draw calls
- Input management system
- Core engine and application architecture

One of the biggest challenges has been designing engine systems while learning the graphics pipeline at the same time. In most projects where I already understand the technology, I can usually plan the architecture ahead of time. With this engine, many of the concepts are things I’m actively learning as I build them.

For me, the best way to learn is often to just dive in and start building. Instead of trying to study every detail of how game engines and graphics pipelines work before writing any code, I chose to learn through implementation. That approach means I’m often learning the underlying concepts while implementing the system itself.

Because of that, I sometimes implement something in a simpler or more direct way first just to understand how it works. Once the concept clicks and I start to see the trade-offs, I revisit the system and redesign it into a cleaner, more modular structure.

For example, some early rendering code started out tightly coupled, with OpenGL draw calls happening directly inside higher-level systems. Once I understood the pipeline better, I refactored those pieces into more modular components. I introduced a render queue so scene systems submit render commands during the update phase, which are later executed during the render phase. The renderer processes these commands and forwards them through a graphics API wrapper, allowing the engine to interact with a graphics interface rather than calling OpenGL directly. This keeps scene logic decoupled from the underlying graphics API and makes the renderer easier to extend in the future.

Building the engine this way has helped me understand not just how the graphics pipeline works, but also how the pieces of an engine need to be structured so they remain flexible as the project grows.

The next milestone is expanding the engine with scene management and full 3D rendering, including:

- GameObject transform systems
- Camera systems
- 3D meshes and model loading
- Lighting and material systems
- Asset management

In my next project, I want to move beyond OpenGL and explore modern graphics APIs like Vulkan to gain a deeper understanding of GPU-level rendering systems.

If you're interested in following the day-to-day development of the engine, I document my progress with regular development logs on my LinkedIn.