从零到一构建一个现代“C++游戏自研引擎”开发蓝图

当然不可能是真从零到一了，做为一个标题党，标题不牛对不起自己，因为游戏引擎涉及太多领域了，比如图形渲染、物理模拟、音频处理、网络通信等等。每个领域都有专业的解决方案，自己从头实现不仅效率低，而且质量难以保证。比如图形API抽象层可能需要支持不同的后端（OpenGL、Vulkan、Metal,dx等），物理引擎用Bullet或PhysX，音频用FMOD或OpenAL。这些库都是经过多年打磨的，稳定性和性能都很好。所以首先要引入这些库

为什么自研引擎要集成这么多库？
- 复杂度分工： 现代游戏引擎是极其复杂的系统。图形渲染、物理模拟、音频处理、网络通信、文件系统抽象、脚本支持、UI系统、动画系统、资源管理等，每一个都是深水区。使用成熟、经过验证的第三方库是避免重复造轮子、加速开发、保证稳定性和性能的关键。
- 专业性： 像 Bullet/PhysX（物理）、FMOD/Wwise（音频）、Assimp（模型导入）、FreeType（字体）、Lua/Squirrel（脚本）等库，是各自领域的专家级解决方案，其性能和功能深度远超自研。
- 跨平台性： 这些库通常已经处理了大量底层平台差异（Windows, macOS, Linux, iOS, Android, Consoles），使用它们能极大减轻引擎的跨平台负担。
- 标准与生态： 使用通用库（如 STB Image, GLM）有助于代码可读性、可维护性，也方便开发者社区交流和贡献。
- 聚焦核心创新： 引擎开发者应该把宝贵的时间和精力投入到引擎最核心、最能体现其独特价值的创新点上（比如独特的渲染管线、特定的游戏玩法支持框架），而不是去重新实现一个可能不如开源库的物理引擎。
为什么 OpenGL 2.0 和 3.0 都是 OpenGL？它们如何区分运行？
- 兼容性与过渡：
  - OpenGL 2.x (兼容模式/固定管线)： 这是非常古老的 API (2004年)，使用固定功能的渲染管线。它的最大优势是兼容性极广，几乎能在任何有显卡的现代设备（包括非常老的集成显卡、嵌入式设备、旧版 macOS/Linux）上运行。对于要求不高或者需要覆盖最广泛硬件的场景（如简单的2D游戏、工具软件）很有用。
  - OpenGL 3.x+ (核心模式/可编程管线)： 引入了现代可编程图形管线（顶点着色器、片段着色器），废弃了大部分固定管线功能（如 glBegin/glEnd）。它提供了更高的灵活性、性能和现代图形效果（如更复杂的材质、光照、后期处理）。这是现代游戏引擎在支持 OpenGL 的平台上的首选目标。
- 运行时区分：
  - 动态检测： 引擎在初始化时会检测目标平台/设备支持的 OpenGL 版本和扩展。
  - 创建上下文： 引擎会尝试请求创建最高可用的 OpenGL 核心上下文（例如 3.3, 4.6）。如果创建失败（设备太老），则尝试创建兼容模式上下文（2.x）。
  - 代码路径选择： 引擎内部会有不同的渲染后端实现或大量的 #ifdef 条件编译。
    - 如果检测到支持 GL 3.x+，引擎就会使用基于 Shader 的现代渲染路径，调用 glGenBuffers, glVertexAttribPointer, glDrawElements 等核心模式函数，并加载、编译、使用 GLSL 着色器。
    - 如果只支持 GL 2.x，引擎就会回退到使用固定管线函数（如 glBegin, glVertex3f, glColor3f, glLightfv）和立即模式渲染（性能差），或者利用 GL 2.x 支持的部分扩展（如 ARB_vertex_buffer_object）来模拟一些现代特性（但效果和性能有限）。
  - 抽象层隔离： 优秀的引擎设计会将与特定API版本强相关的代码封装在底层渲染接口（如 IRenderDevice）的实现类中（例如 OpenGL3Renderer, OpenGL2Renderer）。上层渲染逻辑（材质、网格、摄像机）通过这个抽象接口调用，由引擎根据初始化结果选择实例化哪个具体的渲染器实现。
- 目标： 引擎通过这种方式，在支持现代图形特性的同时，最大限度地保持向后兼容性，让游戏能在从高性能PC到老旧移动设备/低端笔记本的广泛硬件上运行（牺牲画质或性能）。

第二部分：从零构建可扩展的C++游戏引擎 - “Chosen one Engine”蓝图

引擎名称：Chosen one Engine
(释义：Chosen one 意指“天选之人”，象征构建虚拟世界的广阔空间和基础元素，暗示引擎的轻量、高效、跨平台和连接现实与虚拟世界的能力。听起来现代、技术感强，且易于发音和记忆。)

核心设计哲学：

模块化与松耦合： 引擎由独立、可插拔的子系统（模块）构成，通过清晰的接口通信。避免“上帝对象”。
数据驱动： 游戏逻辑、资源配置、关卡设计尽量通过数据文件（JSON, XML, 二进制）定义，减少硬编码。
面向数据设计 (DOD) / 实体组件系统 (ECS) 倾向： 优先考虑内存布局、缓存友好性，ECS 是管理大量游戏对象的高效范式。
抽象与分层： 严格分离平台相关代码、渲染API、核心引擎逻辑、游戏逻辑。
性能优先： 内存管理、算法选择、多线程利用始终考虑性能影响。
可测试性： 设计时考虑单元测试、集成测试的可能性。

开发阶段与核心模块构建：

阶段 0：基础架构 (地基)

平台抽象层 (PAL - Platform Abstraction Layer):
- 目标： 隐藏操作系统差异。
- 内容：
  - 文件系统 (读写、路径处理、挂载点)
  - 窗口管理 (创建、销毁、事件循环 - 可选用 GLFW 或 SDL)
  - 输入处理 (键盘、鼠标、手柄、触摸 - 封装 GLFW/SDL 输入)
  - 线程与同步 (互斥锁、条件变量、信号量、线程池)
  - 时间 (高精度计时器、帧率控制)
  - 日志系统 (分级输出到控制台/文件/调试器，跨平台)
  - 基础类型定义 (确保跨编译器大小一致)
- 关键： 定义统一的接口，在 Windows/macOS/Linux/iOS/Android 下提供不同的实现。
核心系统 (Core Systems):
- 内存管理：
  - 自定义分配器 (堆分配器、池分配器、栈分配器、帧分配器) 替代频繁的 new/delete，减少碎片，提高性能。
  - 智能指针策略 (谨慎使用 std::shared_ptr/std::unique_ptr，避免循环引用，在性能关键处考虑裸指针或自定义引用计数)。
  - 内存跟踪与泄漏检测 (调试版本)。
- 数学库：
  - 实现或集成 (如 GLM) 高性能向量 (Vec2/3/4)、矩阵 (Mat3/4)、四元数 (Quat)、几何体 (射线、平面、AABB、球体)、变换操作、插值函数。SIMD 优化 (SSE, AVX, NEON)。
- 实用工具：
  - 字符串处理、哈希算法 (CRC32, FNV1a)、UUID 生成、配置文件解析 (INI, JSON)、反射系统 (可选，复杂但强大)、RTTI (有限使用)。

阶段 1：核心引擎框架 (骨架)

资源管理系统 (Resource Manager):
- 目标： 统一加载、管理、引用计数、卸载各种资源 (纹理、网格、材质、着色器、音频、动画、字体)。
- 机制：
  - 资源句柄 (TextureHandle, MeshHandle) 代替裸指针。
  - 异步加载 (后台线程加载，避免主线程卡顿)。
  - 资源热重载 (开发时修改文件自动更新引擎内资源)。
  - 资源打包与虚拟文件系统 (优化加载速度，保护资源)。
- 依赖： PAL (文件系统), 核心系统。
实体组件系统 (ECS - Entity Component System):
- 目标： 管理游戏对象 (Entity) 及其数据和功能 (Component)，通过 System 处理逻辑。
- 核心概念：
  - Entity：只是一个唯一ID。
  - Component：纯数据 (位置 TransformComponent，渲染 MeshRendererComponent，物理 RigidbodyComponent 等)。
  - System：逻辑处理器，遍历拥有特定组件组合的实体 (如 RenderSystem 遍历所有有 Transform 和 MeshRenderer 的实体)。
- 优势： 内存连续访问 (缓存友好)、高扩展性 (动态添加/移除组件)、逻辑清晰分离。这是现代引擎的主流范式。
- 实现/集成： 可以选择自己实现一个轻量级ECS，或集成成熟库 (如 EnTT)。
场景图/世界管理 (Scene/World Manager):
- 目标： 组织管理游戏场景/关卡中的实体集合。
- 功能：
  - 实体的创建、销毁、父子层级关系 (空间变换继承)。
  - 场景的加载、卸载、序列化/反序列化 (保存/加载关卡状态)。
  - 空间加速结构 (见下方优化部分)。
- 与ECS关系： 场景管理器管理实体的生命周期和关系，ECS 管理实体的数据和逻辑。两者紧密协作。

阶段 2：表现模块 (血肉)

渲染引擎 (Render Engine) - 核心:
- 目标： 将游戏世界可视化的核心模块。
- 关键设计：
  - 渲染抽象层 (RAL - Render Abstraction Layer): 定义 IRenderDevice, IBuffer, ITexture, IShader, IRenderPass 等接口。这是引擎最关键的抽象之一。
  - 后端实现：
    - OpenGLRenderer (支持 3.x+ 核心模式，可选兼容 2.x 实现)
    - VulkanRenderer (高性能现代API)
    - MetalRenderer (macOS/iOS)
    - DirectX11Renderer / DirectX12Renderer (Windows)
  - 渲染管线：
    - 前向渲染 (简单直接)
    - 延迟渲染 (G-Buffer, 支持大量动态光源 - 更复杂但性能更好)
    - 前向+ (Forward Plus) (结合两者优点)
    - 实现基本流程：清屏 -> 深度预渲染(可选) -> 几何渲染 (到 G-Buffer 或直接) -> 光照计算 -> 天空盒 -> 透明物体 (按深度排序) -> 后处理 -> UI -> 交换缓冲区。
- 依赖： PAL (窗口), 核心系统 (数学), 资源管理器 (纹理、着色器、网格)。
材质系统 (Material System):
- 目标： 定义物体表面如何与光线交互。
- 内容：
  - 材质数据 (漫反射颜色/贴图、法线贴图、高光贴图、金属度、粗糙度、自发光等 - PBR 参数)。
  - 材质实例 (继承和覆盖基础材质参数)。
  - 与着色器的绑定 (一个材质对应一个或多个特定的着色器程序，设置着色器 uniform 参数)。
- 依赖： 渲染引擎, 资源管理器。
网格与骨骼动画系统 (Mesh & Skeletal Animation System):
- 目标： 加载、处理和渲染静态/动态网格模型。
- 静态网格：
  - 顶点数据 (位置、法线、UV、切线等)。
  - 索引数据。
  - 加载 (集成 Assimp 或自写解析器)。
- 骨骼动画：
  - 骨骼层级结构 (Bone Hierarchy)。
  - 骨骼变换 (局部空间、模型空间)。
  - 动画剪辑 (Animation Clip)：包含关键帧序列 (时间戳 + 每个骨骼的变换信息)。
  - 动画状态机 (Animation State Machine)：管理动画剪辑的播放、混合、过渡。
  - 蒙皮 (Skinning)： 在顶点着色器 (GPU Skinning) 或 CPU 上，根据骨骼当前变换计算顶点最终位置。核心公式：
    FinalVertexPos = sum(Weight_i * BoneTransform_i * BindPoseInverse_i * OriginalVertexPos)
  - 插值： 关键帧之间使用线性插值 (Lerp) 或球面线性插值 (Slerp for rotations)。
- 依赖： 渲染引擎 (Buffer, 着色器), 资源管理器, 数学库, ECS (动画组件)。
摄像机系统 (Camera System):
- 目标： 定义观察游戏世界的视点。
- 核心：
  - 摄像机组件 (CameraComponent)：附加到实体上。
  - 参数：位置、方向 (旋转)、投影类型 (透视 Perspective / 正交 Orthographic)、视场角 (FOV)、近/远裁剪平面 (Near/Far Clip Plane)、视口 (Viewport)。
  - 计算视图矩阵 (View Matrix) 和投影矩阵 (Projection Matrix) -> 组合成视图投影矩阵 (ViewProjection Matrix)。
  - 支持多视口、分屏、画中画。
  - 摄像机控制器 (自由飞行、轨道、跟随等逻辑)。
- 依赖： ECS, 数学库, 渲染引擎 (设置当前摄像机)。
光照系统 (Lighting System):
- 目标： 模拟光源及其对场景的影响。
- 光源类型：
  - 方向光 (Directional Light - 模拟太阳/月亮)：全局方向、颜色、强度。
  - 点光源 (Point Light - 灯泡/火把)：位置、颜色、强度、衰减半径。
  - 聚光灯 (Spotlight - 手电筒/车灯)：位置、方向、颜色、强度、内/外锥角、衰减。
  - 环境光 (Ambient Light)：基础亮度。
- 实现：
  - 光源组件 (LightComponent)。
  - 在渲染管线中 (前向/延迟) 集成光照计算。
  - 阴影映射 (Shadow Mapping)：为光源生成深度图，在渲染时比较深度实现阴影 (方向光CSM, 点光Cube Shadow Map)。
- 依赖： ECS, 渲染引擎 (尤其Shadow Map), 数学库。
粒子系统 (Particle System):
- 目标： 模拟火焰、烟雾、爆炸、魔法效果、雨雪等动态效果。
- 核心：
  - 粒子发射器 (ParticleEmitterComponent)：控制粒子的生成速率、初始属性 (位置、速度、大小、颜色、生命周期)。
  - 粒子模拟器 (ParticleSystem)：在 CPU 或 GPU (Transform Feedback, Compute Shader) 上更新粒子状态 (位置、速度、颜色、大小、生命周期)，应用物理 (重力、风力、碰撞 - 简单AABB或球体)。
  - 粒子渲染器：通常使用 Point Sprites 或 Billboard Quad (始终面向摄像机)，在顶点/几何着色器中实现，纹理动画 (序列帧动画)。
  - 数据驱动：定义粒子效果的各种参数曲线。
- 依赖： ECS, 渲染引擎 (绘制粒子), 资源管理器 (粒子纹理), 数学库。

阶段 3：优化与高级特性 (神经系统与盔甲)

空间分割与视锥体裁剪 (Spatial Partitioning & Frustum Culling):
- 目标： 解决“大屏地图怎么只显示需要的内容” - 关键优化！
- 技术：
  - 空间加速结构：
    - 四叉树 (Quadtree - 2D): 递归分割2D空间。
    - 八叉树 (Octree - 3D): 递归分割3D空间。
    - BVH (Bounding Volume Hierarchy): 层次化的包围体 (AABB, OBB, 球体) 树。
    - 空间网格 (Spatial Grid): 将空间划分为均匀网格。
  - 视锥体裁剪 (Frustum Culling): 利用摄像机视锥体的6个平面，快速剔除完全在视锥体外的物体 (使用包围体如 AABB/球体进行快速相交测试)。这是减少绘制调用的首要手段。
  - 遮挡剔除 (Occlusion Culling - 更高级): 判断被前方物体完全挡住的物体 (如使用 Hierarchical Z-Buffer, Software Rasterizer 等)，进一步减少绘制。
- 实现： 在场景图/世界管理器中维护空间结构。在渲染前 (RenderSystem 或专门的 CullingSystem) 执行视锥体裁剪，生成可见物体列表传递给渲染器。
细节层次 (Level of Detail - LOD):
- 目标： 根据物体距离摄像机的远近，使用不同精度的模型/纹理，减少远处物体的渲染负担。
- 实现：
  - 为网格资产准备多个LOD级别 (高模、中模、低模)。
  - 在运行时根据距离 (或其他度量) 选择当前应渲染的LOD级别。
  - 平滑过渡 (Morphing, Alpha Blending) 避免“突然切换”。
- 依赖： 资源管理器 (存储LOD网格), 渲染引擎 (切换网格), 场景管理/裁剪系统 (获取距离)。
批处理与合批 (Batching & Instancing):
- 目标： 减少 Draw Call (CPU->GPU 的绘制命令)，这是CPU端的瓶颈。
- 技术：
  - 静态批处理 (Static Batching)： 将场景中位置固定、材质相同的多个静态网格在离线或加载时合并成一个大网格 (一次Draw Call)。适用于大量静态环境物体 (建筑、岩石)。
  - 动态批处理 (Dynamic Batching - 有限)： 运行时由CPU将少量顶点数少、材质相同、变换不同的动态物体顶点数据合并 (通常有较多限制，顶点数上限、顶点格式要求等)。
  - GPU实例化 (GPU Instancing)： 强烈推荐！ 将相同网格、相同材质 (或少量不同参数) 的大量物体，通过一次Draw Call绘制。向GPU传递一个包含所有实例变换 (或其他参数) 的缓冲区，在顶点着色器中使用 gl_InstanceID (OpenGL) 或等价物来访问每个实例的数据。用于绘制大量草、树、小兵等。
- 依赖： 渲染引擎 (实现 Instancing API), 材质系统 (支持 Instanced 参数)。
帧同步 (Frame Synchronization) - 多人游戏核心:
- 目标： 在确定性锁步模拟中，确保所有客户端在相同输入下，每一帧都产生完全相同的游戏状态。解决网络延迟和抖动带来的不一致问题。适用于RTS、MOBA等需要高度一致性的游戏。
- 核心原理：
  - 锁步模拟 (Lockstep)： 所有客户端严格按帧推进。第N帧的模拟必须等所有客户端的第N帧输入都到达后才开始。
  - 确定性 (Determinism)： 游戏逻辑模拟必须完全确定。相同的输入序列必须产生绝对相同的结果。这是最大难点。
- 关键挑战与解决方案：
  - 输入同步： 客户端收集本地玩家操作，广播给所有其他客户端（或通过权威服务器转发）。使用输入帧号对齐。
  - 确定性保障：
    - 避免浮点数非确定性： 不同平台/编译器对浮点运算（特别是超越函数如 sin, cos, sqrt）的实现可能有细微差异。解决方案：
      - 使用定点数 (Fixed Point)： 将浮点数转换为整数运算（例如用 int 表示 0.001 单位）。牺牲精度和范围，保证确定性。
      - 使用确定性数学库： 所有客户端使用完全相同编译版本、相同编译选项、相同CPU指令集（禁用自动向量化）的数学库。严格控制代码路径。
      - 同步随机种子： 所有客户端使用相同的随机数种子，在相同帧请求相同数量的随机数。
    - 消除逻辑分支歧义： 避免依赖未定义行为、指针地址、枚举值顺序等可能因平台或编译而异的因素。遍历顺序（如 ECS 实体、容器）必须严格定义（例如按 Entity ID 排序后遍历）。
    - 物理引擎确定性： 集成支持确定性模拟的物理引擎（如 Box2D 在特定配置下相对确定，或定制 Bullet/PhysX）并严格控制其配置和步长。避免复杂约束和连续碰撞检测（CCD）的非确定性。
  - 断线重连/快进 (Rollback)： 当客户端掉线后重连，需要快速同步到当前状态。常用“快进”机制：服务器发送缺失帧的输入和当前完整状态快照，客户端在后台线程快速模拟这些帧。GGPO 是此领域的著名中间件。
  - 网络延迟与等待： 引入一定的输入延迟缓冲（N 帧），等待其他客户端的输入到达。高延迟玩家会感觉操作延迟大。
- 实现 (简化)：
  1. 客户端本地缓存输入队列。
  2. 每帧将本地产生的输入（按键、鼠标指令等）发送给其他所有客户端（带帧号）。
  3. 等待直到收到所有其他客户端对本帧的输入（或超时后使用预测/默认输入）。
  4. 关键： 使用完全确定性的逻辑处理本帧收到的所有输入（包括本地和远程），更新游戏状态。
  5. 渲染当前状态。
  6. 帧号递增，回到步骤1。
- 依赖： 网络模块 (见下), 核心引擎逻辑 (必须重构为确定性), 物理模块 (需确定性配置)。
网络模块 (Networking Module - 基础):
- 目标： 实现客户端-服务器或P2P通信。
- 选择：
  - 传输层协议： UDP (低延迟，需处理丢包乱序) 或 TCP (可靠有序，可能延迟高)。
  - 库选择： 集成成熟库如 ENet (UDP 基础上提供可靠/不可靠通道), RakNet (功能丰富), asio (C++ 异步网络库)。
- 基础功能：
  - 连接管理。
  - 消息序列化/反序列化 (Protocol Buffers, FlatBuffers, 或自定二进制格式)。
  - 可靠/不可靠消息传输。
  - 流量控制、心跳包。
- 依赖： PAL (Sockets)。

阶段 4：完善与工具链 (感官与工具)

音频系统 (Audio System):
- 目标： 播放背景音乐、音效、环境声。
- 集成： 集成 FMOD 或 Wwise。它们提供强大的功能（3D音效、混音、DSP效果）和跨平台支持。自己实现高质量音频引擎极其复杂。
- 依赖： PAL, 资源管理器。
用户界面系统 (UI System):
- 目标： 创建游戏内HUD、菜单、按钮等。
- 选择：
  - 集成成熟库：Dear ImGui (即时模式，适合开发工具和调试UI), CEF (嵌入网页技术，功能强大但重), NoesisGUI (商业，强大)。
  - 自研：基于引擎的2D渲染系统实现基本控件（按钮、文本、面板），实现布局管理、事件处理。复杂度高。
- 依赖： 渲染引擎 (2D), 输入系统。
脚本系统 (Scripting System):
- 目标： 让游戏设计师和关卡设计师能用更高级的语言（非C++）编写游戏逻辑和配置行为，提高开发迭代速度。
- 集成： 嵌入脚本语言虚拟机：
  - Lua: 轻量、快速、易嵌入、C API友好。非常流行 (sol2, LuaBridge 等绑定库)。
  - Python: 功能强大，生态好，但通常比Lua重 (pybind11)。
  - Squirrel / AngelScript: 语法类似C++，设计目标就是游戏脚本。
- 实现：
  - 将引擎核心功能（创建实体、修改组件、播放动画/音效、输入检测等）暴露给脚本。
  - 脚本组件 (ScriptComponent)：附加到实体，关联脚本文件/函数，在 UpdateSystem 中调用脚本逻辑。
- 依赖： 核心系统, ECS。
编辑器与工具链 (Editor & Toolchain):
- 目标： 关卡编辑、资源配置、动画编辑、调试可视化是生产级引擎不可或缺的部分。
- 关键工具：
  - 场景编辑器： 放置、旋转、缩放实体；编辑组件属性；管理层级。
  - 资源浏览器/导入器： 查看、导入、配置纹理、模型、声音等资源。
  - 材质编辑器： 可视化编辑材质参数和着色器效果 (节点式或参数式)。
  - 动画编辑器/状态机编辑器： 编辑骨骼动画剪辑和状态机过渡。
  - 性能分析器： 实时显示帧时间、Draw Call 数、内存占用、各系统耗时。
  - 调试视图： 显示碰撞体、视锥体、空间分割结构、光照范围等。
  - 日志查看器： 过滤、搜索引擎日志。
- 实现： 通常用引擎自身渲染能力构建一个独立的编辑器应用程序。大量使用 ImGui。需要强大的序列化/反序列化支持。

阶段 5：构建、测试、迭代 (成长)

构建系统： 使用 CMake 或 Premake 管理跨平台编译。
版本控制： Git。
持续集成 (CI)： 自动化编译、单元测试。
单元测试/集成测试： 为关键模块（数学、内存管理、ECS、核心算法）编写测试。
性能剖析 (Profiling)： 使用 Tracy, Remotery, Superluminal 或平台专用工具 (Xcode Instruments, Visual Studio Profiler, RenderDoc) 持续优化热点。
编写文档： API 文档、架构设计文档、教程。至关重要！
从小项目开始： 用引擎开发几个小型 Demo (弹球、简单平台跳跃、粒子效果展示) 来验证和迭代引擎功能。

总结与建议：

这是一个漫长的旅程： 构建一个功能完善、性能优异、稳定可靠的游戏引擎需要数年甚至更长时间的持续投入和迭代。不要期望一蹴而就。
优先核心： 集中精力先完成一个能在屏幕上绘制一个三角形->立方体->带纹理的模型->带简单光照的场景的渲染管线。然后加入 ECS、资源管理。有了基础骨架再添加血肉（动画、粒子、物理、声音、UI）。
利用现有库： 不要羞于使用优秀的第三方库。它们是你成功的关键加速器。把精力花在引擎的核心架构和独特的创新点上。
抽象是关键： 清晰的抽象层（平台、渲染API、音频、输入）是引擎可扩展、可维护、可移植的基石。
性能是生命线： 从设计之初就考虑性能（内存、缓存、算法复杂度、并行）。持续剖析和优化。
ECS是强大范式： 拥抱 ECS 模式，它能带来更好的性能、模块化和代码清晰度。
工具链决定生产力： 一个功能强大的编辑器会让你的引擎真正可用。尽早开始考虑工具开发。
社区与学习： 阅读开源引擎代码 (Oryol, BGFX 底层, Godot), 学习 GDC 演讲, 参与游戏开发社区讨论。