实现快速迭代的引擎设计 - Capcom RE Engine的架构与实现

[译]实现快速迭代的引擎设计 - Capcom RE Engine的架构与实现

ken hu · 6 天前

原文（日文）：ラピッドイテレーションを実現するゲームエンジンの設計

CEDEC2016上的一个Session。基本上是根据PPT的翻译（可能成为笔记更恰当一点），夹杂了一些现场听来的信息。PPT里有很多优点举例基本没什么营养就省略了。没正经的翻译过文章，有错误欢迎指正。主要是来抱囧聚大腿的。

以下正文：

引擎简介

RE Engine是Capcom内部开发的次世代游戏引擎
支持PS4,XboxOne,PC(Steam/UWP)等平台
应用于开发中的项目生化危机7
引擎特征：高性能，高开发效率 <- 本文主要内容

游戏开发循环

编程 → Build → 确认 → ...
DCC工具编辑 → 资源转换／导出 → 确认 → ...
游戏启动 → 测试／试玩 → 参数调整 → ...
QA → Bug修正 → 打包 → ...

传统开发流程中，上面各个步骤不是费时间就是需要大量手工操作，效率相对低下。

快速开发的实现

→ 最终节省下来的时间用来提升游戏质量

减少等待时间（主要是Build以及资源转换等）
减少每回试错的时间
提高在运行环境（特别是主机上）中运行的频率
降低Bug率

RE Engine界面（译注：基本与UE4或Unity相近，支持所见即所得的编辑方式）

一些细节

生化7目前大约有20万行C#
Editor里可以直接运行（整体更像UE4一点），支持所有资源的重新载入
Scene是树状结构，有一个Master Scene，里面有Chapter1Scene等，导出Master Scene就等于是打包游戏。随着游戏流程Load/Unload Scene
演讲的石田智史就是设计了MT Framework的人

Scene的结构示例

----------------------------------------------------------------------------------------------------------

引擎架构

（译注：演讲包括了新旧引擎的对比，但旧引擎的参考价值不大，故基本省略）

工具架构（Editor）
- 工具和Runtime用TCP/IP通信同步
  - Runtime就算崩溃了Editor也能继续运行
  - Runtime包含了各个平台的实现（如PS4的Runtime）
- 工具部分用WPF/C#开发，运行于Windows平台
- 问题点
  - Runtime使用C++，而工具使用C#开发（包括游戏逻辑）
  - 通信同步导致大量操作需要异步的实现，增加了复杂度
  - 通信受限于传输速度
- 解决方案
  - 统一通信协议：二进制通信，用C#的定义生成C++代码，Query/Response形式
  - 远程对象系统：跨语言，跨进程的标识对象
    - RuntimeType，RuntimeObject跟C#自己类似，成员貌似只是key-value对
    - 通过ObjectID来同步（ID的正负来标识Editor/Runtime）
    - 以手动同步为主，也可以注册进Observer来监视更新，对性能有影响
    - Gizmo之类的辅助对象也采用类似的方法实现
  - 优点
    - Runtime可以自由切换
    - 可以对应一些只能在实际环境确认的功能（VR，手机等）
    - Runtime经常会崩溃ww
资源架构
- File-Based（旧）→ Asset-Based（新）：文件更容易产生冗余，并且不利于Reload
- 所有资源支持异步更新，用Cache加速资源转换，根据依赖关系优化打包速度
- 问题点
  - Scene加载的时候需要预载入所有资源
  - 引擎需要把握资源的载入顺序
  - 需要实现异步载入的功能
- 解决方案
  - 静态资源依赖关系生成
    - 导入Asset的概念：在文件里追加了Metadata
      - 工具启动的时候载入所有的Asset，并生成依赖关系
    - 禁止代码控制的资源载入（译注：是不是完全不支持动态载入没有细说）
  - 严格的资源管理（译注：听起来自由度相当低，但毕竟是内部引擎估计可以根据实际需求调整而不用Hack）
    - 禁止同步载入（容易导致Spike），并且异步载入有利于整体吞吐量
    - 强制实现Reload
    - 从游戏代码不能直接访问资源

资源依赖关系示例

脚本架构
- 旧引擎开发游戏即使用上分布式Build多的时候也要15分钟，并且容易崩溃，内存破坏
- 新引擎开发游戏时，游戏的逻辑部分完全使用C#，Build最多10秒，内存管理更好
- 问题点
  - C#比C++更慢（Marshal，异常）（译注：猜测Marshal应该主要是与SDK的交互或者与第三方库的交互）
  - GC导致的长时间停止
  - 主机平台兼容性差（JIT禁用等）
- 解决方案
  - 自制C#虚拟机（REVM）
    - 以AOT为前提，不支持JIT
    - 提高C++亲和性，降低Marshal开销
      - 重写C#对象布局 ↓ ，包了一层C++对象在里面，Marshal的时候可以直接传指针。RC为引用计数。
      - C# → C++：利用Clang解析C++代码，生成供C#访问的接口，最终和直接调用C++函数开销相同
      - C++ → C#：利用template，最终和函数指针开销相同（译注：黑魔法没仔细看。。。）
    - 更轻量的标准库（从Core FX搬）
    - 编译
      - 开发时：MicroCode（IL不适合解释执行，自制MicroCode） → 解释执行
      - Release时：C++（il2cpp）→ 编译（Marshal部分inline展开）
        
        编译时间：分散编译15分钟左右（跟旧引擎相近）

C#的编译流程（Release时生成C++代码）
C#与C++的运行速度比较（有了GC当后盾对象生成快了很多）
开发时与实际运行时的效率比较（译注：可以看出来开发时候也不是特别惨）

自制实时垃圾回收（译注：有些概念不太懂就没详细解释了）

现有的GC不适合游戏

分代GC：Major GC导致的长时间停止
并行GC：GC执行中的速度低下，需要足够的空余内存
自动引用计数方式：循环引用的泄露，对引用计数操作的高Overhead

适合游戏的实时GC（FrameGC）

限定于游戏应用
主循环的同期点
C#作为脚本的前提

特征

预测，可控的停止时间（GC中）
即时释放性（译注：用完的内存尽早释放）
可以更有效的利用所有内存
在多核环境下发挥性能
与C++的亲和性

GC算法（译注：原ppt内有简单的流程动画说明可供参考）
- LocalObject：TLS，存在LocalTable里（当然也是TLS），C#生成的对象都作为LocalObject
- GlobalObject：所有线程都能访问，C++生成的对象都作为GlobalObject
- LocalObject → GlobalObject（译注：有点类似C#的Box只不过这里不是stack和heap的区别而是可访问线程和所属Table的区别）
- LocalFrame GC：C#的函数调用都结束的时候执行，释放所有LocalObject（译注：跟函数调用完了退栈差不多）
- Local GC：LocalTable满了的时候执行，根据引用计数释放LocalObject（实际很少发生）
- GlobalObject 释放
  - 由各个线程增减引用计数，为0了就释放
  - 当没有所有线程里都没有C#的栈（C#的调用都结束）的时候，执行Global GC（释放所有被有被用到的）
- 循环引用由Incremental Cycle GC释放
  - （译注：基本上就是扫一遍找出循环部分）
  - 每帧Check循环引用的辅助表CycleRoot，按需GC

FrameGC的Overhead
- Write Barrier：线程内的直接Check引用计数，跨线程的利用InterlockedCAS
- LocalObject→GlobalObject：类似↑

FrameGC的一帧的Profile结果（译注：整数估计是Profile的Sample数）

----------------------------------------------------------------------------------------------------------

总结

C#就是好！
- 生产效率大幅提升
- 杜绝应用层（游戏逻辑）产生的崩溃情况
执行效率没有问题！

REVM比写的挫的C++更快
FrameGC改变了GC不适合游戏的常识