A Game Engine From Scratch

Most game programmers use an engine. I built one — Azul, a single C++ codebase that grew from a memory manager into a GPU-driven animation system, developed in three stages with graded, demoed milestones under Perforce (DePaul’s realtime engine track).

Stage 1 — Core systems

The foundation everything else stands on:

• PCS Tree — a parent-child-sibling hierarchy for scene composition, the spine of the object model.
• Math library — vectors and matrices designed for the engine’s alignment and performance needs, not wrapped from a library.
• Memory manager — custom heap and allocator layer; every later system allocates through it.
• File I/O system — binary asset loading against engine-defined formats.
• Iterator integration — uniform traversal across engine containers.

Stage 2 — Animation

The same codebase extended into a content pipeline and a full animation system:

• Reworked math library and quaternion rotation support.
• Protocol Buffers serialisation for engine assets.
• 3D model loading and rendering.
• A standalone converter pipeline — Converter_3dModel and Converter_Anim tools that compile source art into the engine’s binary formats, the same DCC-to-runtime split production engines use.
• A complete skinned animation system with playback and blending.

Stage 3 — Onto the GPU

Moving the hot path off the CPU:

• Hybrid architecture — restructuring the CPU/GPU boundary so the renderer feeds the GPU coherently.
• GPU skinning — character mesh skinning moved into HLSL vertex-stage work against GPU vertex/index buffers.
• GPU animation — the full animation system driven on the GPU, with the converter pipeline extended to match.

Why it matters

Engine work is usually invisible on a resume because the code belongs to a studio. This is the same class of work — memory, math, file formats, animation, GPU architecture — done end-to-end and demoed at every milestone. The source lives in private repositories under course policy; I’m glad to walk through any subsystem in detail.