生成式AI时代，我为什么坚持用C++手搓游戏引擎？

2024年下半年开始我几乎每隔几天就要回答一次同样的问题你都用了这么久生成式AI辅助写代码了怎么还在拿C折腾自己的游戏引擎不自量力去重复造轮子问的人里有同事、有网友、也有刚入行想做独立游戏的朋友。说实话这个问题我自己也翻来覆去想过很久。但当我深夜两点还在为一个缓存未命中导致掉帧的问题通宵调优当我把一段AI生成的数据管理代码合入项目后反而多花了两天排查生命周期问题我越来越确认一件事在生成式AI越来越强的时代选择用C手搓游戏引擎这件事看起来反潮流但真正做下来它带给我的东西比想象中多得多。这篇内容不是什么完整教程更像是一个阶段性的个人项目复盘。我会把从零开始架构一个C小引擎时踩过的坑、做过的设计取舍、AI工具在里面的真实定位都摊开来讲。适合正在纠结“要不要自己写引擎”的技术人也适合那些已经在用AI写代码、但总感觉哪里不对的开发者。1. 为什么在生成式AI时代我还是坚持用C手搓引擎1.1 生成式AI擅长的领域恰好不是引擎开发的核心我承认生成式AI在写代码这件事上确实强得离谱。写个冒泡排序、做个二分查找、配一下vscode的C/C环境、把一段C风格代码改写成现代C风格这些任务AI处理得又快又稳。工作中我需要写一些一次性数据转换脚本时AI能帮我省下大把时间。但游戏引擎的核心问题压根不在“这一段代码怎么写”而在“整个系统的状态怎么管理、资源生命周期怎么控制、帧时间预算怎么分配”。AI特别擅长回答“how to write”但很难替代人去回答“where to put”和“when to call”。引擎里大量问题不是语法层面的而是模块之间依赖关系、对象存活时机、内存布局这类需要整体视角才能判断的东西。举个例子AI可以帮你生成一个加载纹理并创建GPU资源的函数写得非常规范。但它不会替你想清楚这个函数在游戏循环的哪个阶段调用加载是同步还是异步如果玩家在加载过程中切关卡怎么办谁来释放这个GPU资源释放时机不对导致的崩溃AI可不会替你背锅。1.2 C在游戏引擎里的不可替代性聊引擎绕不开C。现在生成式AI这么火有人问是不是以后用自然语言描述就能把游戏做出来引擎语言选什么都没区别。我的答案是短期内这个想法还太乐观。游戏引擎的终局诉求有两个硬指标一个叫确定性一个叫性能。C给你的不是“容易写”而是“控制”。你可以精确控制堆上哪个对象在什么时刻被构造和析构你可以决定一块内存是在栈上还是某个自定义分配器里你可以手动管理缓存局部性让数据按帧访问顺序紧密排列。这些能力在其他语言里要么被隐藏、要么被限制但引擎开发恰恰需要它们。Unity和Unreal底层为什么还是C因为它们需要极致性能。GamePlay层可以用C#、Blueprint但引擎核心层——渲染、物理、动画状态机——跑的都是C代码。手搓引擎的意义就是把这层控制权握在自己手里。生成式AI当然可以帮助写C但“用AI写代码”和“用C做引擎”之间并不矛盾反而C的硬核特性逼着你把控制权搞清楚这时候AI写辅助代码才有真正的用武之地。1.3 手搓引擎最大的收获不是引擎本身而是底层感知坦白讲以一个人的业余时间手搓一个引擎别指望它能跟Unreal 5正面刚。把手搓引擎当成“做一个能跑DEMO的完整游戏”这是最大的误区。手搓引擎真正的价值在于把黑盒变成白盒。用Unity时Vector3、Transform、Renderer对你来说是一堆封装好的轮子你调用它们但并不知道它们内部发生了什么。一旦遇到性能问题你只能打开Profiler看但很难定位到引擎内部。手搓引擎倒逼你把每一个环节都亲手写一遍向量运算、矩阵乘法、空间变换、纹理采样、深度测试、GPU管线状态切换……写完这些之后你再回去用商业引擎理解深度完全不同。另外C游戏引擎开发会逼你面对很多日常业务开发根本碰不到的问题内存碎片、悬垂指针、死锁、着色器编译错误、跨平台窗口系统差异。这些问题每一个单独拿出来都够写一篇长文。亲手踩过一遍你对计算机运行方式的理解会上升一个层次。这个收益很难量化但做过后你会发现再调任何系统级代码时直觉会准很多。2. 手搓引擎的框架设计先界定边界再划分模块2.1 自己写与直接用的边界别盲目从零“手搓”听起来很硬核但不代表所有东西都要从零写。手搓引擎的关键是掌握核心架构和渲染循环至于IO、数学库、图片解码这类基础工具完全没必要自己造轮子否则项目推进速度会慢到让你怀疑人生。我当时定的边界原则是这样的核心引擎架构、渲染循环、场景管理、ECS、组件系统自己写这是学习目标。数学库用glm成熟可靠自己手写向量矩阵纯属浪费时间。纹理加载用stb_image几百行代码解决PNG/JPG解码问题。窗口和上下文创建用GLFW跨平台窗口、OpenGL上下文、输入事件都处理得好。音频先放一边Miniaudio这类小库可以后期接进来。这个选择保证了“引擎的灵魂是自己的但手脚可以借用现成的轮子”。手搓不是目的理解和掌控架构才是目的。如果你连GLFW都不肯用非要从创建Windows窗口句柄开始写那一大半时间会消耗在跟操作系统打交道上而不是游戏引擎本身。2.2 分层模块设计核心、平台、资源、渲染、逻辑我的引擎代码组织主要按两层大框架走核心运行时层和游戏层。核心运行时层不依赖任何游戏内容只提供通用能力。大致分这几个模块平台抽象层封装窗口、输入、时间屏蔽GLFW的细节。核心基础层日志、断言、内存分配器、容器、数学类型包装。资源管理模块纹理、Shader、模型、音频等资源的加载、缓存与释放。渲染模块网格数据上传、材质参数设置、绘制批次的收集和提交。场景与组件模块ECS或Component模型负责实体创建与销毁、组件增删改查与遍历。游戏层具体玩法逻辑包括角色控制、相机、简单物理、场景装配。这样划分的好处是单向依赖游戏层依赖场景与渲染场景与渲染依赖核心基础层核心基础层不反向依赖任何上层模块。改渲染方案时游戏层代码不会被波及。这个依赖方向是我从Unreal和Unity的架构书里抄来的思路但用在个人项目里同样有效。补一个我以为所有人都知道、但后来发现很多人不知道的点模块之间不要互相include私有头文件公共接口尽量通过纯虚类或前置声明隔离。你的引擎规模小还可以硬扛一旦超过一万行代码循环依赖会让你每次重构都头大。2.3 自研引擎与商业引擎收益、代价与适用场景对照手搓引擎和直接用Unity/Unreal不是非此即彼的关系核心看你的目标是什么。下表是我自己的判断逻辑分享出来供参考。维度商业引擎Unity/Unreal自研C引擎上手速度快几天内能出原型慢几个月才能搭出可用的骨架性能控制受引擎架构限制需要摸黑调优完全可控按需定制可精细到缓存行可学习性学会了用法但内部机制偏黑盒全程握在自己手里白盒学习社区与生态海量教程、插件、商店资源全靠自己遇到问题要啃文档和源码适合场景快速做玩法验证、独立游戏上线、团队协作引擎学习、特定技术挑战、极致的性能需求交付风险引擎升级可能带来兼容性风险风险集中在自身引擎质量但完全可控如果你只是想快速做一款游戏、验证玩法那千万别手搓引擎直接上Unity或Unreal性价比高得多。但如果你想知道“游戏循环到底是什么”“一个GameObject的生命周期到底谁在管理”“绘制一帧的流程从哪开始到哪结束”手搓引擎就是最快的路径。这两种目标没有高下之分只是路径差异。3. C引擎核心环节的实现细节3.1 内存分配与对象生命周期管理新手写C引擎最常见的灾难就是把“对象到处都是生命周期不确定”这件事当默认状态。用智能指针确实能省事但引擎里每个对象都走shared_ptr会导致性能崩盘引用计数增减本身有开销更难控制的是内存碎片。我的保守推荐是组合拳引擎启动阶段直接分配一大块内存池核心对象全部用unique_ptr或裸指针管理并规定所有权归属。谁创建、谁释放这个规则要写入引擎的文档第一页不然后面调试会让你怀疑人生。举一个我在对象池上踩过的例子粒子系统最需要频繁创建和销毁对象。最初我用裸指针配合vector存储粒子每帧有新粒子就push_back粒子消亡要遍历vector找到再erase导致频繁发生内存分配和搬移。后来改成固定容量对象池预分配4096个粒子槽位用一个空闲链表记录可复用槽位粒子销毁只做二件事调用析构、把槽位压回空闲链表。实测下来一帧的粒子更新耗时从12毫秒降到不到1毫秒。这里贴一个简单的固定容量对象池核心片段template typename T, size_t Capacity class FixedPool { public: FixedPool() { for (size_t i 0; i Capacity; i) { freeSlots_.push_back(i); } } template typename... Args T* acquire(Args... args) { if (freeSlots_.empty()) return nullptr; size_t index freeSlots_.back(); freeSlots_.pop_back(); T* ptr reinterpret_castT*(storage_ index * sizeof(T)); new (ptr) T(std::forwardArgs(args)...); slotOwner_[index] true; return ptr; } void release(T* ptr) { if (!ptr) return; size_t index (reinterpret_castchar*(ptr) - storage_) / sizeof(T); ptr-~T(); slotOwner_[index] false; freeSlots_.push_back(index); } private: alignas(T) char storage_[Capacity * sizeof(T)]; std::vectorsize_t freeSlots_; bool slotOwner_[Capacity]; };模板参数指定容量和类型placement new负责在预分配内存上构造析构函数手动调用。核心思路是内存空间在引擎启动时固定分配运行期不做堆内存分配只通过空闲链表做逻辑上的“分配”和“释放”。这个模式在高频对象粒子、子弹、UI节点上都能直接复用。3.2 渲染管线起步从窗口创建到Shader封装渲染模块是引擎里最复杂也最核心的一环。我选择从OpenGL起步不直接上Vulkan理由是Vulkan的学习曲线太陡一个人在没有图形学基础的情况下直接冲Vulkan大概率会在验证层报错里迷失方向。OpenGL足够让你弄懂现代GPU管线的核心概念。窗口创建这一步用GLFW非常直接。初始化GLFW、创建窗口、设置OpenGL上下文版本、注册输入回调流程其实很有规律。// 初始化框架 if (!glfwInit()) { log(GLFW init failed); return -1; } glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 3); glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 3); glfwWindowHint(GLFW_OPENGL_PROFILE, GLFW_OPENGL_CORE_PROFILE); GLFWwindow* window glfwCreateWindow(1280, 720, MyEngine, nullptr, nullptr); glfwMakeContextCurrent(window); // 加载OpenGL函数指针 if (!gladLoadGLLoader((GLADloadproc)glfwGetProcAddress)) { log(GLAD init failed); return -1; }这里容易被忽略的一个点是GLAD。OpenGL驱动只保证提供GL 1.1的函数指针高版本API函数需要通过glfwGetProcAddress手动获取。GLAD做的就是这件事。很多新手在这里卡住画面黑屏也没报错其实就是没加载扩展函数。Shader封装是另一个难点。我在实际工作中习惯把shader写成独立的.glsl文件运行时先读文件、编译、再链接。这样改shader不需要重新编译C代码配合文件监听可以做到热重载。下面是一段简化的Shader类class Shader { public: Shader(const std::string vsPath, const std::string fsPath) { std::string vsSource readFile(vsPath); std::string fsSource readFile(fsPath); GLuint vs compile(GL_VERTEX_SHADER, vsSource); GLuint fs compile(GL_FRAGMENT_SHADER, fsSource); program_ glCreateProgram(); glAttachShader(program_, vs); glAttachShader(program_, fs); glLinkProgram(program_); checkErrors(program_); glDeleteShader(vs); glDeleteShader(fs); } void use() { glUseProgram(program_); } GLuint id() const { return program_; } private: GLuint program_; };编译shader失败时最好把错误日志完整打印到控制台同时标注shader文件名和行号。没有这步你调一个语法错误的shader可能要对着黑屏瞎猜半天。补一个经验shader编译器报错的行号经常不准尤其是预处理指令较多的shader排查时先检查语法高亮提示再逐段注释定位。3.3 ECS实体组件系统架构与实现要点手搓引擎如果只做一个核心架构我强烈推荐做ECSEntity Component System。传统OOP把实体当成一个包含所有行为的大类代码会随功能增加而膨胀。ECS的思路反过来实体只是一个ID结构体只存数据系统System负责处理数据。数据连续排列遍历时CPU缓存命中率更高性能优势巨大。一个最小可用ECS大致包含三部分实体ID生成器、组件存储、系统调度。实体ID可以简单理解为一个无符号整数ID生成器保证新创建的实体不重复销毁后ID可以复用。我在实现上用了一个很常见的思路叫稀疏集合。简单说就是维护两组数组一组按连续内存顺序存储实体ID另一组记录实体ID到组件数据的映射。这样既能保证实体遍历时内存连续又能做到O(1)的组件访问。ECS的实现细节很多我不铺开写全套但给一个重要建议对于个人引擎项目不要把组件存储直接做成哈希表不然遍历所有实体时要遍历哈希槽位缓存命中率很低。用vector做连续存储实体销毁时用swap-with-last技巧把最后一个元素搬移到被删位置代价小并且保持存储紧凑。3.4 热重载与资源管理开发效率的生死线所有引擎最后都会踩到同一个坑改完代码要等重新编译改完资源要重启程序。开发迭代的速度直接决定你还能在这条路上坚持多久。热重载分两块。一个是资源热重载主要是纹理、shader、模型文件被外部修改后引擎内部能够自动检测并重新加载。做法可以是在主循环每帧检查文件的修改时间戳或者在后台起一个文件监视线程。另一个是代码热重载C做起来麻烦一些常见思路是把游戏逻辑编成动态库引擎运行时用dlopen加载重编游戏逻辑后重新加载动态库。代码热重载我早期没做主要是时间和精力有限但它对开发体验的提升是质变级别的。如果条件允许建议至少把shader热重载做了这个性价比极高调渲染效果时不用反复重启程序体感立刻不一样。资源管理的另一个重点是引用计数和重复资源去重。比如同一张纹理被多个模型引用如果没做统一管理显卡显存会存两份一模一样的纹理浪费显存不说加载时间也在翻倍。我的解决办法是一个简单资源管理器资源文件路径作为key资源对象作为value先查缓存再加载加载完引用计数加一释放时计数减到零才真正销毁。4. 生成式AI在手搓引擎开发中能做什么、不能做什么4.1 AI替我解决的那些脏活累活说了这么多坚守C的原因也要客观讲AI在手搓引擎项目里确实帮上忙的地方。我的体验是这类工具最适合处理的是“信息的搬运和格式转换”类工作这些工作在引擎开发里还真的不少。举几个我实际用AI的场景帮我写一批C单元测试。引擎里的数学库矩阵、四元数、向量运算每个函数要验证边界条件和结果精度手工写测试用例非常枯燥。AI可以按我给的功能描述生成测试骨架我只要补充几个特定边界值节省的时间很可观。帮我分析编译错误。编译器报了一长串模板实例化错误时让AI解释错误线索并给出修复建议偶尔能给我提供一些方向不过可靠性一般最终还是要自己去查标准库文档。帮我整理跨语言调用代码。比如要在C和Lua脚本之间做绑定AI可以快速生成一批轻量接口封装代码。帮我做代码风格统一。把老旧的C风格代码改写成现代CAI能做得又快又好改完我只需要review逻辑是否有偏移。这类工作的共性在于目标明确、边界清楚、输出形态固定AI的错误模式相对容易识别。我敢把这类任务交给AI因为即使AI写错检查成本很低风险也可控。4.2 AI生成代码的盲区为什么反复审查还是容易出问题问题出在AI输出那些“看起来对但内在逻辑完全错”的代码。举个我遇到过的真事我需要一个异步资源加载类于是用AI生成了一段使用线程池和future的代码。它编译通过、表面逻辑也完整但在高并发加载纹理时偶发纹理内容错乱。排查了一天才发现AI生成的那段代码里有几个静态变量在跨线程读写时没有加锁也没有用原子操作。这在静态分析时很隐蔽因为它不会编译报错只有运行到特定并发场景才出问题。更常见的盲区是生命周期问题。AI生成一个对象用了shared_ptr但不知道它被存到了哪个容器里、谁还持有引用。我甚至见过AI生成的代码在函数返回后返回了局部变量的引用编译器可能都不给警告运行起来就是随机崩溃。所以我在项目里立了一条硬规矩AI生成代码必须先过三关。第一关是编译关第二关是代码审查关重点查所有权、生命周期和线程安全第三关是运行关必须在测试场景里压测至少几百帧才能合入主分支。这条规矩帮我拦住了至少七八个潜在崩溃点。4.3 我和AI协作的分工边界经过一段时间磨合我和AI的分工逐渐固定下来。整体原则是架构决策、模块接口设计、性能热点代码必须自己手写工具脚本、胶水代码、格式化代码、文档注释可以放心交给AI。引擎的主循环、ECS核心、渲染管线、资源管理机制这些属于引擎的“骨架”我全部自己写。因为这些地方的错误成本太高一次设计失误可能导致后面几千行代码都要跟着返工。相比之下AI生成的辅助代码就算有问题也只需要局部修复不会波及整个项目。这个过程也纠正了我一个初始的错误认知AI不是来替代程序员思考的它更像是把你的思考效率放大了一倍。前提是你自己得有足够清晰的判断力知道哪些代码重要到必须人工掌握。这种判断力从哪里来恰恰来自手搓引擎这样的基本功训练。所以看似反潮流的背后其实是一条互补的路。5. 手搓引擎常见问题与排查技巧5.1 编译链接最基础也最容易被AI代码搞崩的一层手搓引擎的项目规模到几千行代码后编译错误和链接错误的比重会显著上升。最让我头疼的是模板实例化和符号重定义这类问题。模板错误信息动辄几十行不熟悉模板机制的开发者很容易被绕晕。实测最有效的办法不是盯着报错看而是把编译器报告的第一个文件:行号提取出来直接跳转到出错代码处先看具体上下文。链接错误常见于多个.cpp文件重复定义全局变量。C的全局变量默认外部链接如果在头文件里定义了变量并到处include链接器就会报警重定义。正确做法是在头文件里用extern声明在.cpp里定义。如果AI生成的头文件里出现了变量定义审查时务必多看一眼这是我被坑过的重灾区。5.2 运行期崩溃内存问题排查的正确姿势手搓引擎里最凶猛的敌人是内存问题越界写、释放后使用、内存泄漏。这类问题最扯淡的地方在于崩溃点往往跟错误发生点离得很远你看到的是莫名其妙的白屏或随机闪退真正出错的地方在几百帧之前。我的心得是不要舍不得花时间构建Debug工具链。一套AddressSanitizer加一个gdb或lldb就能解决80%的问题。ASan能精确告诉你哪块内存被越界访问了、是哪个线程在哪个位置写入的。如果没有这套工具排查内存问题纯粹靠猜效率极低。另外一个被很多人忽略的习惯是每个类都写一个debug打印函数在关键生命周期节点构造、析构、复制、移动输出日志。虽然日志量大但在排查“对象释放后还被访问”这类问题时这套日志能帮你快速还原对象的时间线很快定位到是谁偷偷保存了一份悬垂引用。5.3 性能与帧率定位瓶颈的实战手法当你开始往引擎里添加越来越多的功能帧率一定会下降。这时候不要凭感觉猜瓶颈要依靠profiler。我最推荐Tracy它采样开销很低、界面直观能显示每个系统每帧的执行时间。用它跑一遍真实场景立马能看到到底是渲染模块耗时高还是物理模拟模块拖后腿还是某个系统的单帧分配开销大。从我的经验看个人引擎最常见的性能问题排前三一是对象拷贝过多导致内存分配频繁二是CPU端每帧重复创建和销毁临时对象三是遍历数据没有遵循缓存友好原则。前两条可以用对象池和移动语义解决第三条要把结构体数组SoA布局替换掉数组结构体AoS布局。这里补一个小实验数据我在项目里把一个组件存储从AoS改成SoA后遍历所有实体更新位置和速度的耗时下降了近40%。原因很好理解SoA布局下CPU读连续内存块时cache命中率大幅提升一次性从内存搬到L2缓存的数据量更多加载等待的时间更少。对于引擎这种追求极致帧率的程序数据布局的优化比局部逻辑优化管用得多。5.4 手搓引擎的心态管理与节奏建议做手搓引擎这件事技术难点反倒是其次最难的是长时间坚持下来。我个人经验是一定要控制范围。一开始别想做全功能引擎物理、骨骼动画、网络同步全上做两个月还没出一个能玩的场景人基本就崩了。我给自己的节奏是先跑通一个旋转的多边形再放一个贴图纹理的方块第三个月才加上相机控制和简单的ECS。每完成一个阶段足以给自己一个持续做下去的理由。还有一个实战建议每个模块完成后立刻写个小的测试场景跑起来验证效果。不要等所有模块都开发完再统一测试那时候bug多到一起爆炸你根本舍不得删掉任何代码局面会非常难看。小步快跑每个阶段都有可运行的东西这个习惯会救你很多次。最后补充一个很实在的建议把引擎的依赖项控制到最少。手搓引擎的乐趣在于掌控感如果为了省事一下拉了十几个第三方库最后你会花大量时间处理库的兼容性问题反而啥都没学到。我的原则是尽量少依赖GLFW负责窗口glm负责数学stb_image负责纹理glad负责加载函数指针其他全自己写。这个精简的依赖集让整个项目非常好编译换台电脑就能跑不用处理一堆环境问题。写在最后的一点真实感受踩的坑多了我发现手搓引擎送给我的不是那个跑起来的DEMO而是一整套排查问题的底层直觉。当我在网上看到别人求助“为什么我的游戏一运行就闪退”时我脑子里会瞬间闪过好几个候选原因这正是一行行C代码、一场场调试、一次次把系统拆开重装练出来的反应。生成式AI时代有很多问题可以靠它快速得到答案但只有你亲手写过一遍系统、亲手排过底层故障才知道问题该往哪个方向找、哪些答案不能直接信。如果你也想试试手搓引擎这条路我的建议很简单挑一个平台选一个图形API打开编译器从画出一个三角形开始剩下的路会在代码里一点点展开。