Overview
This is a sample project structure based on best practices from game development portfolios. Your project should tell a compelling story about what you built, the challenges you faced, and the solutions you implemented.
The Challenge: Architecting for Performance and Scale
The challenge was to deliberately break from traditional, monolithic game object architectures and create a data-oriented design focused on maximum performance and minimal memory footprint.
Having built game engines twice before, the objective was not just to implement features, but to strategically sequence development to ensure long-term stability and iteration speed. This meant establishing a robust 2D foundation using SDL2 first, proving the core systems and architecture before tackling the massive complexity of a modern 3D Physically Based Rendering (PBR) pipeline using Vulkan.
The core technical pillars were:
- Memory Efficiency: Implement a custom Entity Component System (ECS) to achieve contiguous memory allocation for components.
- Scalability: Design a tiered Asset Registry that could seamlessly transition from simple 2D assets (sprites, tilemaps) to complex 3D assets (GLTF 2.0, OBJ).
- Visual Fidelity: Incorporate a modern graphics API (Vulkan) to support advanced rendering features like Image Based Lighting (IBL).
Implementation & Architectural Strategy
Phase 1: The 2D Foundation (C++ & SDL2)
The initial phase focused on building the core engine framework and performance-critical systems, validating the architecture without the complexity of 3D rendering overhead.
Custom Entity Component System (ECS)
To achieve memory efficiency and simplify the API compared to third-party solutions (e.g., EnTT), I designed and implemented a custom ECS from scratch.
- Design Principle: Data-Oriented Design prioritizes the layout of data in memory for optimal CPU cache utilization.
- Structure: Components are stored in arrays contiguous in memory. When an Entity is created, its components are allocated tightly together, which drastically reduces cache misses when Systems iterate over large sets of Entities.
- Validation: Utilized Tracy Profiler early in development See Figure 3. Profiling confirmed successful compact memory maps and efficient allocation packing, proving the system achieved its performance target for component iteration.
Core Utility Systems
- Asset Registry: Developed a generic resource loader supporting common 2D assets: fonts, tilemaps, and sprite sheets via SDL. This generic interface was designed for later inheritance/extension to handle Vulkan-specific resources.
Phase 2: The Transition to 3D (Vulkan & PBR)
Upon successful validation of the ECS and framework, the engine was refactored to incorporate the Vulkan graphics API, a significant undertaking handled smoothly due to prior planning and experience.
Physically Based Rendering (PBR) Pipeline
- Rendering API: Implemented a full Vulkan rendering pipeline, managing swap chains, command buffers, descriptor sets, and synchronization primitives.
- Shading Model: Developed a PBR shader pipeline using HLSL for the rendering logic, which supports metallic-roughness workflows.
- Image Based Lighting (IBL): Incorporated advanced lighting by loading IBL data (irradiance and pre-filtered environment maps) using KTX textures. This adds high-quality, realistic environmental reflections and lighting to the scene.
Asset Registry (Tier 2: 3D Integration)
- Mesh System: Refactored the Asset Registry to incorporate a new custom mesh format, asset textures and materials.
- Third-Party Integration: Integrated tinygltf and tinyobjloader to load industry-standard GLTF 2.0 and OBJ models, successfully mapping their data structures (vertices, indices, materials) into the engine's internal memory format.
Results
Successfully rendered complex scenes (e.g., Sponza) and models (e.g., glTF Helmet), validating the entire PBR pipeline and asset workflow.
Conclusion & Key Takeaways
This project validated the effectiveness of strategic, phased architectural design in complex software development.
The ability to make flexible assumptions about future requirements, like designing a generic Asset Registry interface in Phase 1, allowed for efficient migration, a critical skill learned over years of professional software development. This project successfully moved from conceptual design to a functional, high-performance 3D engine core.
Gallery
Figure 1. Saint Game Engine Entity Component System API Sample
Figure 2. Saint Game Engine Entity Component System Registry Logs
Figure 3 Saint Game Engine Profiling
