现代化游戏引擎正在成为一个工业软件，或者说，游戏开发本身便属于一种带有娱乐性质的轻工业。本文会记录构建一个现代化 + 工业级游戏引擎所需要考虑的事情。

工业软件设计

以建模软件Maya为例，我们可以参考得到一个成熟的图形相关工业软件所需要的设计。

  • Maya的软件设计
    • 编辑器
      • 让美术人员进行建模工作
    • 插件
      • 让技术美术编写自动化脚本/工具，提高美术人员工作效率
      • 项目组自定义的工作流程
        • 连通其他软件，比如集成Peforce/SVN等适合美术的版本控制软件，与其他引擎编辑器间传输场景数据
    • SDK
      • 提供插件开发需要的各种API，让技术美术有足够自由度为项目定制功能
      • 运行时与编辑器间避免耦合
      • 提供各类脚本语言的绑定，降低开发门槛
    • 运行时
      • 提供实时的几何模型处理能力
      • 提供简易的实时渲染能力
    • 工具
      • 可以看成是官方提供的插件，专业性更强
      • 方便与其他工业软件的协作，比如FBX数据导入/导出
      • 提供用户常用的功能，比如一些烘焙工具制作贴图，离线渲染器查看出图效果

游戏引擎设计

参考Maya的设计，游戏引擎也可以这样分层。

  • 自制游戏引擎
    • 编辑器
      • 各类人员都需要能在一起工作
      • 可视化编程(蓝图), AI状态机/决策树，参数配置，策划
      • 可编程的3D音频工具，或者对接FMod/Wwise之类的工作流，音效
      • 从其他DCC软件导入编辑好的模型，材质，并在编辑器内二次处理(连接游戏场景，配置参数)，美术
      • 编写必要的游戏脚本，与其他非开发人员协作来反复梳理游戏流程，程序
    • 插件
      • 非所有游戏类型通用的工具，比如程序化生成关卡，地形，建筑等
      • 项目组自定义的工作流程
        • 比如策划配置表能在编辑器内打开，方便填写
        • 集成可视化版本控制工具，方便非开发人员
    • SDK
      • 提供插件开发需要的各种API，让技术美术有足够自由度为项目定制功能
      • 运行时与编辑器间避免耦合
      • 提供各类脚本语言的绑定，降低开发门槛
    • 运行时
      • 提供不设上限的实时渲染能力
        • 结合各种离线烘焙作为trick来提升效果
        • 利用最新的硬件红利，RTX
        • AI技术带来的新轮子，DLSS/FSR
      • 提供易用的各类游戏性功能模块
        • 物理
        • AI
        • 音频
        • …
    • 工具
      • 游戏资源编译，3D模型，材质资源优化
      • 各平台发布打包
      • 对接各类游戏中间件，也可以用插件形式发布，避免license问题
        • Simplygon减面
        • SpeedTree植被生成
        • Houdini程序化生成建筑物
        • MetaHuman生成数字人

总得来说，游戏涉及到的开发人员工种类型要比传统工业软件来得多，专业性质上不会那么较真，看起来/玩起来是对的即可。

对于其他已知游戏引擎，Unity优势在编辑器的易用性和插件层的生态上，Unreal则拥有高质量的运行时及专业化工具。

其他成熟的自研游戏引擎通常是适配公司内部的工作流程，或者适配公司特色的游戏项目类型，比如R星拥有的游戏引擎对于射击，载具，开放世界有很精细的支持；2K的体育游戏系游戏引擎则对于动捕，真实感渲染，物理，球类AI这些有长年的积累。

开发流程设计

另外，可以参考一些成熟公司的软件开发流程来提高开发体验。

  • 软件开发流程
    • 自动构建
      • 日常构建版本，包括不同平台，不同需求的包体
        • 非开发人员可以自己下载，了解软件最新情况
        • 确保项目健康，没有break build
        • 新入职的开发人员可以参考服务器上的步骤脚本，入手项目构建
    • 自动测试
      • 开发人员创建Pull Request准备提交时，可以选择触发，了解到自己的代码是否破坏了其他功能
      • 每次新的commit合并到主线时自动触发，有失败的测试邮件通知开发者
        • 第一时间捕捉到新bug的出现
        • 明确造成bug的开发者以及提交记录
    • 代码审查
      • 同组开发人员之间需要互相Review对方的Pull Request，提出有意义的改进建议，得到组内同意后合并
      • 修改其他组功能时，邀请Owner进行Code Review
    • 通知机制
      • 每一个代码模块拥有Owner记录，该模块有其他人提交代码/构建失败/测试失败后，自动邮件通知Owner

技术上的选择

现在想要开发一个3D游戏引擎，难度上因为Github等开源社区的出现，已经降低了非常多。举个例子，以前想做一个跨平台的3D游戏引擎，不同的渲染API都实现一遍就需要花费很长的时间，还有各个平台的窗口创建，游戏输入，操作系统相关API封装(比如文件操作，多线程)。而现在，我们选用一套开源的RHI(Rendering Hardware Interface, 也就是各平台3D图形API的抽象层)，再加上开源的跨平台应用程序方案，就可以快速得到一个任意平台都能跑出3D画面的程序了。

所以在引擎开发的早期，我们希望多借助开源的轮子来把引擎搭建起来，在开发过程中发现轮子的缺点，然后再考虑优化，或者有必要的情况下自己造轮子。

  • 游戏引擎轮子(TBD)
    • makefile - premake
      • 候选：cmake, bazel
    • RHI - bgfx
      • 候选: TheForge, DiligentEngine
      • 自己写 DX11 / DX12 / Vulkan / Metal / OpenGL
    • Application - sdl2
    • 3D模型文件读取 - assimp
    • 3D音效 - openal-soft
    • 音频文件读取 - libsndfile
    • …