最近着手把一个攒了挺久的C游戏引擎项目重新整理了一遍从渲染、场景管理到资源加载终于跑通了一个端到端的Demo。中途换了三次架构方案、修了十几个隐蔽的崩溃问题也把VS Code的C/C环境、CMake组织、动态库调用这些边角料折腾了个遍。这篇博文就是把这些经验原原本本写出来给想碰引擎开发的朋友做个参考。内容既适合刚学完C语法、想做个正经项目练手的人也适合已经在写简单游戏、想进一步理解引擎内部逻辑的开发者如果你是刚接触C最好像看地图一样先对照目录抓大框架不用一上来就啃代码。这个项目解决的痛点是很多人“会写C但不知道怎么组织一个能长期维护的引擎工程”单文件Demo跑得飞起一旦想拆模块、做渲染封装、接第三方库就无从下手。下面我会按设计、搭环境、实现核心模块、算法落地、排坑这样一条线来讲全是实际操作中验证过的方案。1. 引擎项目从哪开始整体定位与模块拆解1.1 我为什么坚持用C做引擎做游戏引擎的语言选择其实没有太多悬念。C能在提供接近底层的控制力同时保留足够的抽象能力这决定了它在渲染、物理、实时交互这些场景里几乎没有替代品。你可能听说过有人用Rust做引擎或者用C#做开源引擎但商业级和绝大多数工业级引擎的核心层依然是C。原因说白了就两条一是内存布局可控二是性能可预期。内存布局可控意味着我可以精确知道一个对象占多大空间、在什么生命周期被创建和销毁这在游戏每帧要管理成千上万个对象时是命脉。C#、Java这类带GC垃圾回收的语言会出现“不定时卡顿”而引擎最忌讳的就是帧率突然掉一下。C里我用智能指针、对象池、内存池等手段可以让分配和释放变成可控行为不会让GC在关键时刻出来捣乱。性能可预期则体现在底层数据结构的自由度上。比如我想用一个紧凑的连续内存数组存粒子系统的数据而不是用散落的堆对象存储这会让缓存命中率高出一个量级。C允许我随手把一个struct数组放到一块内存里同时还能用模板和虚函数做高层的逻辑抽象。所以选C不是情怀问题是工程问题的必然答案。1.2 引擎骨架模块划分与依赖关系引擎开发最大的坑就是一开始把模块划分得太随意后面互相耦合成一锅粥。我最终确定的模块结构是这套Core模块日志、断言、数学基础库向量、矩阵、四元数、内存分配器。Platform模块窗口创建、输入处理、时间管理。这一层是直接和操作系统打交道的。Render模块渲染设备抽象、顶点缓存、着色器管理、纹理管理、渲染命令队列。Scene模块场景节点树、组件容器、游戏对象生命周期。Asset模块资源加载、资源缓存、导入导出格式支持。这套结构有个核心原则依赖关系必须是单向的。Core层是最底层Platform不依赖RenderRender不依赖SceneAsset可以依赖Render和Scene但反过来不行。这种单向依赖让项目能分模块测试也能在出问题时快速定位是哪个层崩了。我试过一开始把渲染和场景耦合在一起写后来加个材质系统就差点重构拆开之后清爽很多。模块之间靠接口通信。比如Scene想知道一帧里要渲染哪些对象它不会直接去enumeration Render的API而是生成一份“渲染请求列表”Render层消费这个列表。这个设计模式在引擎圈叫“数据驱动渲染”好处是方便做多线程优化、批量合并、再排序也给后面做GPU Driven Renderer留了口子。1.3 引擎层与应用层的边界很多初学者写引擎会把游戏逻辑直接写进引擎里。这是个非常危险的习惯。我的做法是把引擎当成一个库游戏逻辑作为“应用层”跑在引擎之上。引擎暴露给应用层的是一套高层接口创建场景、创建对象、挂组件、加载资源、注册更新回调。引擎层做的事永远是通用逻辑渲染、物理、输入映射、资源管理。应用层做的事永远是具体游戏逻辑主角控制、敌人AI、关卡触发、技能系统。边界清晰之后你会发现写新玩法的时候基本不用动引擎代码最多加组件类型。这个边界的价值在于游戏项目可以快速迭代引擎项目可以保持稳定两个团队的配合成本才降得下来。2. 环境搭建与工程组织别让工具拖后腿2.1 VS Code里的C/C环境配置用VS Code开发C引擎配置的环境步骤不复杂但有很多细节需要掌握。我用的方案是msvc编译器 CMake Ninja这套组合在Windows下很顺畅。你可能看到很多教程说用MinGW我建议你用MSVC因为MSVC对Windows API、调试器PDB符号、以及第三方库的兼容性更好特别是做引擎要调GPU驱动接口时MSVC踩的坑更少。VS Code的C/C扩展需要配置几个文件c_cpp_properties.json告诉IntelliSense编译器路径、标准版本我用的C17、预定义宏。tasks.json定义构建任务我一般配置CMake生成Ninja构建文件然后执行ninja。launch.json配置调试器使用cppvsdbg类型调用MSVC调试器。有个Windows下非常容易踩的坑MSVC环境下IntelliSense配置了Windows SDK路径后还是提示找不到windows.h。原因是编译器路径配置的是cl.exe但预定义的宏_WIN32没有被IntelliSense正确识别。解决办法是在c_cpp_properties.json里手动添加defines: [_WIN32, _DEBUG]。这个问题看起来小但会一直给你报错实际构建却没问题很容易让人误判代码有错。VS Code里所有函数、变量都没办法跳转出现这个问题时先查是不是存在多个compile_commands.json文件。C/C扩展依赖这个文件做精准索引如果存在生成在build目录里的副本和根目录的副本两者不一致会导致索引错乱。把根目录的compile_commands.json删掉只保留build目录里的然后重新执行“C/C: Reset IntelliSense Database”基本就能恢复跳转。2.2 用CMake组织多模块工程引擎项目规模上去之后手动写Makefile或者Visual Studio工程都不合适。我用CMake统一管理CMake的好处是跨平台、生成器多、模块化能力强。我的CMake结构大概是这样cmake_minimum_required(VERSION 3.20) project(MyEngine) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_library(engine_core STATIC src/core/log.cpp src/core/assert.cpp src/core/math.cpp ) add_library(engine_platform STATIC src/platform/window_win32.cpp src/platform/input.cpp ) add_library(engine_render STATIC src/render/device.cpp src/render/vertex_buffer.cpp src/render/shader.cpp ) add_executable(game_demo src/app/main.cpp ) target_link_libraries(engine_platform PUBLIC engine_core) target_link_libraries(engine_render PUBLIC engine_core engine_platform) target_link_libraries(game_demo PRIVATE engine_render engine_scene engine_asset)这一步的关键是把每个模块拆成独立库链接关系只在需要时才建立。项目规模变大后你会发现这种组织方式让增量编译速度快很多改渲染层代码不会导致整个Scene模块重编。关于编译器选项我特别重视警告设置。开发期必须开启/W4MSVC或者-Wall -Wextra -WpedanticGCC/Clang并有选择地开启/WX把警告提升为错误。你可能觉得这样太严格但引擎代码一旦编译成动态库一个未初始化成员变量在运行时造成的崩溃能让你排查一整晚警告全开能在早期把很多问题截住。2.3 导出动态库时extern C与API设计如果你做的引擎需要被C#、Python或其他语言调用动态库导出这一步就很重要。通常做法是给导出API加上extern C和__declspec(dllexport)Windows/__attribute__((visibility(default)))Linux。举个例子#ifdef __cplusplus extern C { #endif ENGINE_API void* Engine_CreateContext(); ENGINE_API void Engine_DestroyContext(void* ctx); ENGINE_API void Engine_Tick(void* ctx, float dt); #ifdef __cplusplus } #endif这里的ENGINE_API是一个宏在构建动态库时定义为__declspec(dllexport)在使用方编译时定义为__declspec(dllimport)。C#调用时用的是P/Invoke后面排坑部分我会详细说Access Violation的问题本质就是运行时签名不匹配。API设计上有个重要原则不要把C类直接暴露给C接口尤其是含STL成员、虚函数、模板的类。C#的P/Invoke能正确对应C结构体、普通指针和原始类型但没见过谁能正确对应一个含std::vector大小写敏感的C类。所以我的做法是只暴露void*句柄做资源引用再用普通函数逐一操作对象。这样能避开ABI兼容性这个大坑。3. 核心实现从游戏循环到内存管理3.1 游戏循环与固定时间步长游戏引擎的心脏是游戏循环。最简单的实现是while循环里不断获取输入、更新逻辑、渲染。但这个朴素版本有个容易忽视的问题不同机器的帧率不一样如果逻辑更新直接乘上每帧间隔物理模拟和动画会因为帧率波动而产生“时快时慢”的效果。我采用的方案是固定时间步长加状态插值。核心代码是这种形式const float fixed_dt 1.0f / 60.0f; float accumulator 0.0f; while (running) { float frame_time clock.getElapsedTime(); accumulator frame_time; input.poll(); while (accumulator fixed_dt) { scene.update(fixed_dt); // 以固定步长更新逻辑 accumulator - fixed_dt; } renderer.render(scene, interpolationFactor(accumulator, fixed_dt)); }这个方案的关键是accumulator它把不稳定的帧间隔累积起来凑够一个固定步长就更新一次逻辑。假如一帧耗时30ms而固定步长是16.67ms那么这一帧会执行一次逻辑更新剩下的13.3ms让渲染层做插值。渲染层根据accumulator / fixed_dt的比例把上一帧和当前帧的物体位置做插值输出平滑的画面。这套逻辑配合垂直同步效果会明显好于无脑每帧更新。我在写这个模块时踩过一个坑忘了处理螺旋死循环。比如一帧耗时1秒累加器会累积大量待处理的固定步长导致一次循环里执行几十次逻辑更新游戏瞬间卡死或者物理穿透。现在的做法是在累加器加上限比如最多处理5个固定步长多出的时间直接丢弃防止“死亡螺旋”。3.2 渲染层的封装与资源生命周期渲染层是引擎里最复杂、最难做好的模块。我的做法是向上层提供一个“设备模型”把底层APIOpenGL/Direct3D/Vulkan隐藏在一组接口之后。这样上层不需要关心当前是哪个API只要创建顶点缓冲、编译着色器、提交渲染命令即可。核心类大致是RenderDevice封装上下文创建、句柄管理、同步操作。VertexBuffer/IndexBuffer管理显存里的几何数据。Shader编译并管理GPU着色器程序。Texture管理图片资源、采样状态、格式转换。RenderCommand单帧内要执行的某个绘制操作。资源生命周期这里非常容易出错。初学者经常犯的错误是在渲染命令被GPU执行之前就释放了顶点缓冲结果表现为随机帧的物体闪烁或直接崩溃。正确的做法是使用引用计数CPU侧创建顶点缓冲时引用计数为1每提交一个用到它的RenderCommand就加1GPU执行完该命令回调后减1减到0才真正释放。我在实际项目中用的是一个资源句柄表内部维护std::atomic引用计数保证线程安全。另一个高频卡点是着色器编译。调试期我会打开着色器编译日志把所有警告和错误输出到一个log文件里。着色器代码报错不像C那样有清晰的IDE提示找不到问题时会像无头苍蝇一样。一个小技巧是把着色器用一个非常简单的常数输出开头确定编译通过后逐步加功能这样能快速定位出错的代码段。这个习惯帮我省了大量时间。3.3 场景树与组件系统的设计思路场景树Scene Graph是引擎管理游戏对象的基础结构。每个游戏对象有一个父节点、若干子节点渲染时世界坐标会从根节点向叶子节点层层传递。常见的实现方式有两种一种是传统对象树每个对象持有指针指向父节点和子节点列表另一种是柏油带式ECS实体组件系统。我采用的是折中方案对象树 每个对象上挂组件列表。对象树解决层次变换问题组件列表解决功能扩展问题。组件接口设计为class Component { public: virtual ~Component(); virtual void update(float dt) {} virtual void onTransformChanged() {} // ... 其他生命周期回调 };为了让你更好理解可以把场景树想象成文件夹系统根目录下面是文件夹嵌套文件夹你看到这个目录结构就知道每个文件在哪个层级。游戏里一个主角对象它的子节点可能是武器、盾牌、相机节点相机节点只负责定义视角位置武器节点只负责挂模型这样组织起来代码逻辑和数据处理都清晰得多。场景树的更新时机需要注意先更新所有物体的变换从父向子推再更新行为组件最后做碰撞检测和渲染提交。如果把行为更新放在变换推之前组件拿到的Transform可能是上一帧的旧值表现出来就是“操作卡一帧”的滞涩感。排序顺序也是细节变换更新必须自上而下行为更新通常自下而上或者按优先级碰撞检测和渲染准备放在最后。3.4 内存池与智能指针的正确姿势C里最容易被诟病的就是内存管理。用智能指针能解决大部分问题但频繁创建和销毁游戏对象时shared_ptr的原子引用计数开销和堆分配开销会拖慢性能。我的策略是分两级第一级生命周期跨帧的大型资源纹理、网格、着色器用unique_ptr或者句柄表管理引用计数只在提交渲染命令时增加。这类资源不会被每帧创建销毁用智能指针完全够。第二级每帧可能创建和销毁的小对象每帧发射的弹道、粒子、临时特效用内存池。内存池在启动时分配一块大内存创建对象时从这里分配一个槽位销毁时回收槽位不涉及系统级malloc/free。实测这种模式能让一帧内数百个临时对象的创建销毁时间减少一个数量级。智能指针的踩坑点shared_ptr有循环引用问题。比如场景节点A持有子节点B的shared_ptrB又持有A的shared_ptrA和B永远无法被释放。解决方案是父节点持有子节点的unique_ptr子节点只持有一个裸指针指向父节点因为父节点的生命周期一定覆盖子节点不需要增加引用计数。写代码时记住一条经验指针传播方向有向时向下用unique_ptr向上用裸指针就能避免大部分循环引用。内存池实现里还需要注意“对象是否正在被使用”的判断。我会在每个槽位加一个魔法数分配时填入一个随机值销毁并回收时改为0。这样即使某处不小心持有了已经回收的对象指针也能通过魔法数校验快速发现而不是读到一个被复用的未知对象。这个机制在调试期几乎可以立即定位use-after-free问题。4. 算法与数学在引擎中的落地4.1 快速幂、前缀和这些算法真能派上用场看标题可能觉得算法和引擎没什么关系但实际开发里高频用到的这几个算法能明显提升系统效率也常出现在引擎的中间层快速幂场景里频繁出现指数级衰减函数比如光照的衰减计算、缓动动画的贝塞尔插值、物理里的阻尼系数。如果每帧都直接调用pow(0.95f, dt * 60)其实性能一般但换成整数次幂场景就适合快速幂。比如计算某个倍率随时间增长的指数序列用二进制拆分的快速幂免去大量重复乘法。通用写法double fast_pow(double base, int exp) { double result 1.0; while (exp) { if (exp 1) result * base; base * base; exp 1; } return result; }前缀和主要用于引擎编辑器里的性能分析。比如脚本性能分析器记录每帧各系统耗时需要快速查询某一时段内总耗时用前缀和数组就能实现O(1)查询。游戏里做区域伤害计算、养成数值表查询也经常用到。判断质数优化这个听起来是纯算法题但引擎的资源哈希表扩展时需要判断扩容大小是否质数减少哈希冲突编辑器工具做随机数种子检查也用得到。朴素判断方法是从2试除到sqrt(n)优化写法是先用6的倍数法跳过3的倍数情况再在5、7、11、13的步长上试除实际能减少约三分之二的循环次数。单调栈和分治做UI自动布局、地形LOD选择时单调栈可以在线性时间内找到最近受遮挡的层级分治排序是很多空间加速结构的底层思想比如后来提到的K-D树、四叉树都源于分治。这些算法在写引擎工具链时几乎是日常储备。4.2 数值运算的精度与效率平衡游戏引擎里的数值运算有一类典型问题浮点数误差累积。摄像机长时间旋转后矩阵会出现微小漂移物理模拟长时间运行后对象会缓慢穿过地面。这类问题啃着不明显但要重视。一个常用策略是定期正交化矩阵每隔N帧对旋转矩阵做正交化消除累积的缩放误差和倾斜误差。另一个策略是用双精度存储世界坐标的根节点用单精度存储局部坐标这样既能减少单精度误差在大坐标下的放大效应又能保持渲染性能。这个技巧在开放世界引擎里很常见。关于效率我常用的优化顺序是先做Profiling定位热点函数再调整算法复杂度最后才做指令级优化。实测下来不要过早优化比其他任何优化建议都重要。比如你花三个晚上用SIMD优化一个排序函数结果Profiling显示它的耗时只占0.5%那就纯粹是浪费时间。正确的做法是先把功能跑通用性能分析工具看火焰图找到真正的热点再动手。4.3 字符串、数组与结构体的处理细节C里字符串处理是个容易出现隐蔽bug的点。引擎编辑器的资源路径处理、游戏内的硬盘存档、日志输出都充满字符串操作。我先说一个容易踩坑的点std::string的拼接性能。如果你在一帧内大量做str str xx式拼接会产生很多临时对象。更好是预先调用reserve分配足量空间然后用append或追加。基于字符串和数组的处理有个很常见的场景C字符串转数组。比如把一个带分隔符的资源路径maps/level1/tiles/grass按/分隔为字符串数组用于树形节点查找。常见实现std::vectorstd::string split(const std::string s, char delim) { std::vectorstd::string tokens; std::stringstream ss(s); std::string item; while (std::getline(ss, item, delim)) { tokens.push_back(item); } return tokens; }结构体链表是另一类基础但重要的语法。场景树其实就是一个结构体链表的复杂变体每个节点有数据Transform、Mesh引用和指针子节点链表、下一兄弟节点指针。实现结构体链表的核心是别忘记初始化每个节点的指针字段否则释放时顺手遍历到野指针就崩了。用nullptr给next、prev、parent、child初始化是防止崩溃的最基础做法。字符串数组初始化也是新人高频踩坑点。C风格数组和std::array、std::vector的初始化方式不一样// C风格 const char* names1[] { player, enemy, npc }; // std::array std::arraystd::string_view, 3 names2 { player, enemy, npc }; // std::vector std::vectorstd::string names3 { player, enemy, npc };推荐优先用std::array和std::string_view因为它们在编译期就能检查大小而且没有动态内存分配。引擎里大量配置表数据用这类结构存储能显著减少运行时开销。5. 排错手记那些年我踩过的坑5.1 C#调用C动态库的Access Violation做游戏引擎编辑器时我经常用C#写工具界面工具调用C引擎的动态库结果频繁遇到运行时错误AccessViolationException c0000005。这个错误的本意是访问了非法内存地址C#和C之间最常见的原因有两个P/Invoke签名不匹配和调用约定不匹配。比如C导出函数__declspec(dllexport) void Engine_Tick(void* ctx, float dt);C#那边正确的声明是[DllImport(engine_core.dll, CallingConvention CallingConvention.Cdecl)] public static extern void Engine_Tick(IntPtr ctx, float dt);我踩过的坑是CallingConvention没有显式指定默认是Winapi在Windows上实质是StdCall但C里默认调用约定是Cdecl。调用约定不匹配会导致参数从哪里清理、栈如何平衡这个问题乱掉于是出现访问违例。解决办法是C导出函数显式加__cdecl或者C#这边CallingConvention.Cdecl显式匹配。另一个隐蔽坑结构体布局。C#端的结构体如果包含bool而对应的C是bool它们的字节大小在不同编译选项下可能不一样。通常我更建议C导出接口用int代替bool用固定大小的整数类型代替原生类型用IntPtr代替对象指针最大程度减少ABI差异。排查这类问题的标准套路先写一个最简单的C函数如int Add(int a, int b)在C#里调用验证基础P/Invoke流程再逐步加参数哪个函数一接真实参数就崩溃基本能锁定签名问题最后用WinDbg或者Visual Studio附加到托管进程看崩溃时的调用栈能直接看到是哪个模块访问了非法地址。这个方法能把排错时间从几小时压缩到十几分钟。5.2 中文乱码、编码与跨平台陷阱引擎里出现中文乱码常见路径有资源文件读取、日志输出、控制台显示。Windows下默认编码是GBK而代码文件保存成UTF-8时字符串字面量的字节序列就会不同。处理办法是统一编码源文件全部用UTF-8 with BOM确保MSVC能正确识别外部资源JSON、配置文件全部用UTF-8读取时用库函数或者自己写的转换函数转成std::wstring或自定的UTF-8字符串。控制台输出中文乱码的坑Windows控制台代码页默认是936GBK而程序里输出UTF-8字节序列就会显示成乱码。我常用的解决办法是调用SetConsoleOutputCP(CP_UTF8)或者干脆不依赖控制台输出把日志写进文件用VS Code打开看这样就不会出现控制台代码页的麻烦。跨平台的文件路径分隔符也有坑Windows用\Linux用/。如果引擎里到处写死分隔符项目换到Linux直接崩。我从一开始就封装一个Path类所有文件路径必须通过它来拼接和处理内部统一转成/格式在Windows API调用前再转回\。这个习惯帮我省了后面很多跨平台适配工作。5.3 调试技巧与日志系统日志系统是引擎里最容易被忽略但最有价值的模块。我用的是spdlog作为基础库再封装一层方便引擎内部调用。日志级别分为Trace、Debug、Info、Warn、Error、Critical六档。发布版会把日志级别设为Info或Warn以上调试版全部输出。这里有一个实用的经验Warn以上级别一定要附带上下文信息比如是哪个对象、哪个资源、哪个函数触发的警告。否则日志显示warn: render_command failed根本没有排错价值你需要的是warn: [RenderDevice::ApplyState] DrawIndexed failed for mesh grass_01, slot3。调试崩溃问题时的经典工具是生成Dump文件。Windows下设置SetUnhandledExceptionFilter(ExceptionFilter); LONG WINAPI ExceptionFilter(_EXCEPTION_POINTERS* info) { // 生成minidump文件 // 记录异常码、模块、栈回溯 return EXCEPTION_EXECUTE_HANDLER; }这个函数一定要挂在核心模块里出现崩溃时截获异常、写Dump、记录调用栈然后优雅退出。否则每次崩溃都靠用户口述“屏幕闪过一下没了”来定位效率太低。这个Filter配合PDB符号文件能让崩溃以比较快的速度定位到具体函数和行号。调试变量无法跳转的问题也就是前面提到的IntelliSense索引失效多数是compile_commands和扩展缓存的问题。修复方法跟2.1节一样重置索引、清理多份compile_commands即可不用为了这个去重装扩展。5.4 工具链扩展与配套生态引擎开发不只是运行时刻的代码还涉及编译器、链接器、调试器的全链路配合。我整理了自己的工具链清单用途推荐方案备注代码编辑VS Code C/C扩展配置好IntelliSense后体验良好构建系统CMake Ninja多模块组织清晰增量编译快编译器MSVC / Clang引擎开发建议以MSVC为主调试器Visual Studio / VS Code(cppvsdbg)查看内存布局、查看寄存器用VS更顺手性能分析Windows Performance Analyzer / Intel VTune火焰图定位热点函数内存检测Application VerifierWindows配合调试器捕获越界和越权访问日志spdlog轻量、可扩展、适合内嵌如果你做的是偏计算密集的引擎模块比如粒子模拟、地形生成、或者在引擎里做物理跑酷游戏可以考虑接入CUDA。cuda c programming guide里有完整的编程模型和优化建议核心是把数据拷贝到显存、写kernel、同步拷贝回来。它比较适合大批量并行计算不适合小规模分支逻辑使用前提是把数据布局设计成AoS还是SoA要想清楚一旦想清楚收益是实打实的。链接MySQL这种需求一般出现在服务器端工具或者玩家数据处理上。C连接MySQL通常走官方Connector/C库注意版本与MySQL Server版本兼容性链接时配置好额外的include和lib目录即可。如果只是做本地编辑器工具也可以用SQLite比MySQL轻量得多。收尾一点做引擎的心得我做这个小引擎最大的体会是引擎开发最花时间的不是某个炫酷的渲染效果而是把工程边界理清楚、把资源生命周期管好、把调试手段配齐。算法运用和语言特性引用、指针、值传递、友元、回调、模板看似孤立在工程中会融为一体。比如回调函数让组件的状态改动精准传递引用和指针决定了对象是否被拷贝、是否被搬运值传递提供了隐式拷贝的方便引用则避免了不必要的拷贝开销朋友域在序列化、编辑器系统里让工具代码访问到引擎私有状态省去一堆public接口。开发时先把场景树、渲染层、资源管理层这些基础模块打磨干净再逐步加功能。遇到网上所谓“崩溃卡死”的问题先看日志、再抓Dump、最后猜逻辑不要一开始就怀疑编译器坏了。如果你也被C引擎开发吸引建议从小demo开始先做一个窗口、画个三角形然后加一个会动的立方体再加一个T键切换线框模式的调试快捷键。一步一步把每个模块的接口稳定下来再往里面塞具体功能这条路比直接抄一个大引擎源码可靠得多。后续扩展方向可以是加入物理引擎集成、网络同步、动画状态机或者做成一个游戏编辑器工具链。每次重构你都会对“为什么引擎要这么设计”有更深的理解也希望对正在走这条路的朋友有一点实在的帮助。