TheCherno Reboots Game Engine Series: AI-Assisted Development and Hazel Code Review

Well-known game engine developer TheCherno (Ashurno), after stepping away from full-time YouTube, has announced the reboot of his classic Game Engine series. This time, he plans to leverage AI tools to dramatically accelerate engine development while still personally overseeing architectural design. In his latest video, he conducted an in-depth code review of the public version of the Hazel engine he started 8 years ago, sharing numerous insights on modern game engine development.

Why Reboot the Game Engine Series

TheCherno's Game Engine series began in 2018, when he was 23 years old and working on game engine-related projects at EA. Eight years later, at 31, both his personal technical expertise and the entire software engineering landscape have undergone tremendous changes.

He candidly admitted that the core reason the series went on hiatus was the sheer workload — one person had to write every line of code on camera while simultaneously explaining the purpose of each line. The information density was simply too much. But now, AI has changed the equation: AI can handle large amounts of boilerplate code and implementation details, while the developer focuses on architectural design and quality control.

"This isn't about having AI generate an entire engine with one click," he emphasized. "It's very granular — like telling AI to generate a window using a GLFW submodule that conforms to specific architectural conventions. The value has shifted from writing code to design, architecture, and real engineering decisions."

Hazel Engine Code Review: Issues and Highlights

Environment Setup Struggles

TheCherno approached the Hazel review with the mindset of "receiving someone else's project for code review." The first issue appeared during environment setup: the Vulkan SDK downloader only downloaded a corrupted 1KB file, and the version validation logic was also broken — it used string matching to check the SDK version and couldn't recognize version 1.4 installed on the system.

Interestingly, the reason this OpenGL engine requires the Vulkan SDK is that it uses the SPIR-V shader compilation toolchain (shaderc and SPIRV-Cross), a more modern approach to shader management. SPIR-V (Standard Portable Intermediate Representation) is an intermediate shader language defined by the Khronos Group that serves as a bridge between source-level shader languages (such as GLSL and HLSL) and GPU drivers. The traditional approach is to hand GLSL source code directly to the OpenGL driver for runtime compilation, but compiler quality varies widely across drivers, leading to compatibility issues. By pre-compiling GLSL to SPIR-V bytecode via shaderc and then decompiling it back to the shader language required by the target API using SPIRV-Cross, developers can achieve a "write once, deploy everywhere" shader workflow.

Overuse of Static Variables

The most frustrating finding in the code review was the extensive use of static variables. Using the entity_classes map in the scripting engine as an example, he explained in detail why this practice is harmful:

• Chaotic lifetime management: Static variables are destroyed after the main function ends, and their destructors may depend on systems that no longer exist
• Explicit cleanup burden: You must manually clean up these containers when switching projects or shutting down the engine
• Violation of RAII principles: Despite using reference counting (shared_ptr), the static lifetime negates the benefits of automatic resource management

RAII (Resource Acquisition Is Initialization) is the core resource management paradigm in C++: objects acquire resources during construction and release them during destruction. Smart pointers like shared_ptr are quintessential RAII implementations. However, static variable destruction occurs after main returns, during the C++ runtime cleanup phase, when other subsystems (such as graphics API contexts or memory allocators) may have already been destroyed. This causes cleanup operations in destructors to trigger undefined behavior. This is the well-known "Static Initialization Order Fiasco" — one of the most classic pitfalls in C++.

His recommendation: make this data a member variable of an object with a well-defined lifetime, so that when the parent object is destroyed, all child data is naturally cleaned up along with it.

Design Flaws in the Logging System

The core_logger and client_logger inside the Log class are both static members. TheCherno argued that a better approach would be to make the Log class itself a globally accessible singleton while keeping its internal members as regular member variables. This preserves global accessibility while gaining the benefits of automatic construction and destruction.

Architectural Strengths

Layer System

The application organizes functionality through layers. Different executables (editor, runtime) can push different layers. Debug layers can be conditionally stacked on top of runtime layers and removed in distribution builds. This design is both flexible and practical.

Entry Point Abstraction

entry_point.h automatically handles main function declarations across different platforms (standard main vs WinMain), and users only need to implement the CreateApplication function. This design is still preserved in the modern version of Hazel.

2D Batch Rendering

The renderer treats all 2D geometry (including sprites, circles, and text) as quads, using different shaders to achieve different effects. Circles aren't drawn with triangle fans — instead, they're computed mathematically within a quad via shaders.

Mouse picking is implemented by rendering each entity's ID to a separate framebuffer attachment — a classic and efficient approach. Specifically, the rendering pipeline maintains an additional integer-format framebuffer attachment alongside the normal color output, where each pixel stores the unique ID of the corresponding entity. When the user clicks on the screen, the engine reads the ID value at that position to determine the selected entity, avoiding the overhead of per-object ray testing on the CPU side.

Key Improvements for Building a New Engine from Scratch

TheCherno ultimately leans toward building a new engine from scratch while drawing on Hazel's architectural strengths. He outlined several key areas for improvement:

Rendering API Abstraction: Instead of fine-grained RHI abstractions (like DrawIndexed and SetClearColor), provide high-level interfaces like DrawMesh and let each backend handle the details internally. Vulkan will be the primary target, with the possibility of future expansion to other APIs. RHI (Render Hardware Interface) is the engine's abstraction layer over low-level graphics APIs (Vulkan, DirectX, Metal). Fine-grained RHI creates a one-to-one abstraction for every API call, which is flexible but results in massive interface code that's hard to optimize. High-level abstractions like DrawMesh treat a complete mesh draw as an atomic operation, allowing each backend to freely organize command submission, state management, and resource binding according to its own API characteristics, making it easier to implement optimizations like the command buffer batching required by Vulkan.

Shader System: A complete shader compilation pipeline needs to be established — write in one language, automatically compile to the format required by each target API. The good news is that DirectX's Shader Model 7 will support SPIR-V.

Runtime Separation: Establish the separation between editor and runtime (the final shipped game executable) early on, rather than having only an editor as in the current version.

Scripting System: Drop Mono in favor of Coral, a library developed by Peter, compatible with .NET 10. Mono is the open-source implementation of the .NET Framework that Unity has long used as its C# scripting runtime, but its updates lag behind and it has limited support for modern .NET features. Coral is a lighter-weight .NET hosting library built directly on Microsoft's official CoreCLR runtime, offering compatibility with the latest .NET versions, better performance, more complete language feature support, and more active ecosystem maintenance.

Performance Profiling: Replace the homegrown JSON profiling tool with Tracy. Tracy is an open-source real-time performance profiling framework widely used in game and graphics engine development. Unlike simple JSON timeline exports, Tracy supports nanosecond-precision CPU/GPU event capture, memory allocation tracking, lock contention analysis, and provides a standalone visualization client for real-time or offline analysis. Its instrumentation-based design (marking code regions via macros) incurs minimal overhead, making it suitable for always-on use during development.

The Boundaries of AI-Assisted Game Engine Development

TheCherno has a very clear vision for AI's role in game engine development: AI handles implementation, humans handle decisions. Specifically:

• What AI does: Generate boilerplate code, implement well-defined feature modules, handle repetitive coding tasks
• What humans do: Architectural design, technology selection, quality review, performance optimization strategy

He specifically emphasized that this is not "AI slop" — the goal is still to build a high-quality product. AI's value lies in enabling one person to accomplish within a reasonable timeframe what would otherwise require an entire team.

This "AI-augmented development" approach may represent the best practice direction for solo developers and small teams — not being replaced by AI, but using AI to expand the boundaries of individual capability.

Key Takeaways

• TheCherno plans to reboot the Game Engine series, leveraging AI for implementation details while personally overseeing architectural design to dramatically accelerate development
• A code review of the 8-year-old Hazel engine revealed core issues including overuse of static variables and chaotic lifetime management
• He leans toward building a new engine from scratch, adopting modern approaches such as high-level rendering API abstraction, Vulkan-first design, and the Coral scripting system
• AI's role in engine development is to handle boilerplate code and implementation details, not to replace architectural decisions and quality control
• Architectural designs like the layer system, entry point abstraction, and SPIR-V shader pipeline are considered worth preserving and improving