TheCherno重启游戏引擎系列：AI辅助开发与Hazel代码审查

知名游戏引擎开发者TheCherno（Ashurno）在离开全职YouTuber身份后，宣布将重启其经典的Game Engine系列。这一次，他计划借助AI工具来大幅加速引擎开发，同时仍然亲自把控架构设计。在最新视频中，他对8年前开始的Hazel引擎公开版本进行了一次深度代码审查，并分享了对现代游戏引擎开发的诸多思考。

为什么要重启游戏引擎系列

TheCherno的Game Engine系列始于2018年，当时他23岁，在EA从事游戏引擎相关工作。8年过去，他已经31岁，无论是个人技术积累还是整个软件工程领域都发生了巨大变化。

他坦言，当年系列停更的核心原因是工作量过于庞大——一个人要在镜头前写下每一行代码，同时还要解释清楚每行代码的意义，信息量实在太大。而如今AI的出现改变了这个等式：AI可以处理大量样板代码和实现细节，而开发者专注于架构设计和质量把控。

"这不是让AI一键生成整个引擎，"他强调，"而是非常细粒度地进行——比如告诉AI用GLFW子模块生成一个符合特定架构规范的窗口。价值从代码编写转向了设计、架构和真正的工程决策。"

Hazel引擎代码审查：问题与亮点

环境搭建的坎坷

TheCherno以"收到别人项目做代码审查"的心态来重新审视Hazel。第一个问题就出现在环境搭建阶段：Vulkan SDK下载器只下载了1KB的损坏文件，版本验证逻辑也有问题——它通过字符串匹配来检查SDK版本，当系统安装了1.4版本时无法识别。

有趣的是，这个OpenGL引擎之所以需要Vulkan SDK，是因为使用了SPIR-V着色器编译工具链（shaderc和SPIRV-Cross），这是一种更现代的着色器管理方式。SPIR-V（Standard Portable Intermediate Representation）是Khronos Group定义的一种中间着色器语言，它在源码级着色器语言（如GLSL、HLSL）和GPU驱动之间充当桥梁。传统做法是将GLSL源码直接交给OpenGL驱动在运行时编译，但不同驱动的编译器质量参差不齐，容易出现兼容性问题。通过shaderc将GLSL预编译为SPIR-V字节码，再用SPIRV-Cross将其反编译为目标API所需的着色器语言，开发者可以实现"编写一次，多平台部署"的着色器工作流。

静态变量的滥用

代码审查中最让TheCherno不满的是大量使用静态变量（static）的做法。他以脚本引擎中的entity_classes映射为例，详细解释了为什么这种做法有害：

• 生命周期管理混乱：静态变量在main函数结束后才销毁，其析构函数可能依赖已经不存在的系统
• 显式清理负担：你必须手动在切换项目或关闭引擎时清理这些容器
• 违背RAII原则：明明用了引用计数（shared_ptr），却因为静态生命周期而失去了自动管理的优势

RAII（Resource Acquisition Is Initialization）是C++的核心资源管理范式：对象在构造时获取资源，在析构时释放资源。shared_ptr等智能指针正是RAII的典型实现。然而静态变量的析构发生在main函数返回之后、C++运行时清理阶段，此时其他子系统（如图形API上下文、内存分配器）可能已被销毁，导致析构函数中的清理操作触发未定义行为。这就是所谓的"静态初始化/销毁顺序问题"（Static Initialization Order Fiasco），是C++中最经典的陷阱之一。

他的建议是：将这些数据作为某个有明确生命周期的对象的成员变量，这样父对象销毁时，所有子数据自然随之清理。

日志系统的设计缺陷

日志类（Log）内部的core_logger和client_logger都是静态成员，TheCherno认为更好的做法是：让Log类本身作为全局可访问的单例，但其内部成员保持为普通成员变量。这样既保证了全局访问性，又获得了自动构造/析构的好处。

架构中的可取之处

层系统（Layer System）

应用程序通过层（Layer）来组织功能，不同的可执行文件（编辑器、运行时）可以推入不同的层。调试层可以条件性地叠加在运行时层之上，分发版本则移除。这种设计灵活且实用。

入口点抽象

entry_point.h自动处理不同平台的main函数声明（标准main vs WinMain），用户只需实现CreateApplication函数。这种设计在现代Hazel中依然保留。

2D批量渲染

渲染器将所有2D几何体（包括精灵、圆形、文本）都作为四边形处理，通过不同的着色器实现不同效果。圆形不是用三角形扇绘制的，而是在四边形内通过着色器数学计算得出。

鼠标拾取通过将每个实体的ID渲染到单独的帧缓冲附件来实现——这是一种经典且高效的方案。具体来说，渲染管线在正常的颜色输出之外，额外维护一个整数格式的帧缓冲附件，每个像素存储对应实体的唯一ID。当用户点击屏幕时，引擎读取该位置的ID值即可确定选中的实体，避免了CPU端逐对象射线检测的开销。

从零构建新引擎的关键改进方向

TheCherno最终倾向于从零开始构建新引擎，但会借鉴Hazel的架构优点。他列出了几个关键改进方向：

渲染API抽象：不再做细粒度的RHI抽象（如DrawIndexed、SetClearColor），而是提供高层级接口如DrawMesh，让各后端自行处理细节。首选Vulkan，但保留未来扩展到其他API的可能性。RHI（Render Hardware Interface）是引擎中对底层图形API（Vulkan、DirectX、Metal）的抽象层。细粒度RHI将每个API调用都做一对一抽象，虽然灵活但导致大量接口代码且难以优化。高层级抽象如DrawMesh则将一次完整的网格绘制作为原子操作，允许各后端根据自身API特点自由组织命令提交、状态管理和资源绑定，更容易实现如Vulkan所需的命令缓冲批处理等优化。

着色器系统：需要建立完整的着色器编译管线——用一种语言编写，自动编译为各目标API所需的格式。好消息是DirectX的Shader Model 7将支持SPIR-V。

运行时分离：尽早建立编辑器和运行时（最终发布的游戏可执行文件）的分离，而不是像当前版本那样只有编辑器。

脚本系统：弃用Mono，改用Peter开发的Coral库，兼容.NET 10。Mono是.NET Framework的开源实现，Unity引擎长期使用它作为C#脚本运行时，但其版本更新滞后，对现代.NET特性支持有限。Coral是一个更轻量的.NET宿主库，直接基于微软官方的CoreCLR运行时，能够兼容最新的.NET版本，获得更好的性能、更完整的语言特性支持以及更活跃的生态维护。

性能分析：用Tracy替代自制的JSON性能分析工具。Tracy是一款开源的实时性能分析框架，广泛应用于游戏和图形引擎领域。与简单的JSON时间线导出不同，Tracy支持纳秒级精度的CPU/GPU事件采集、内存分配追踪、锁竞争分析，并提供一个独立的可视化客户端进行实时或离线分析。其侵入式设计（通过宏标记代码区域）带来的开销极低，适合在开发阶段常驻开启。

AI辅助游戏引擎开发的边界

TheCherno对AI在游戏引擎开发中的角色定位非常清晰：AI负责实现，人负责决策。具体来说：

• AI做什么：生成样板代码、实现已明确定义的功能模块、处理重复性编码工作
• 人做什么：架构设计、技术选型、质量审查、性能优化策略

他特别强调这不是"AI slop"（AI垃圾），目标仍然是构建高质量产品。AI的价值在于让一个人能够在合理时间内完成原本需要团队才能完成的工作量。

这种"AI增强型开发"的思路，或许代表了个人开发者和小团队的最佳实践方向——不是被AI取代，而是用AI放大个人能力的边界。

核心要点

• TheCherno计划重启Game Engine系列，利用AI处理实现细节，自己把控架构设计，大幅加速开发效率
• 对8年前的Hazel引擎进行代码审查，指出静态变量滥用、生命周期管理混乱等核心问题
• 倾向从零开始构建新引擎，采用高层级渲染API抽象、Vulkan优先、Coral脚本系统等现代方案
• AI在引擎开发中的定位是处理样板代码和实现细节，而非替代架构决策和质量把控
• 层系统、入口点抽象、SPIR-V着色器管线等架构设计被认为值得保留和改进