GDC 粗读丨看看《心灵杀手2》中的面向数据编程——ECS

前言

比起SIGGRAPH来说，GDC Vault里虽然也有大量游戏开发相关的知识分享，但由于主要是视频为主，因此能被我拿来作为二手知识粗读一遍的文稿类内容相对没那么多；另外，GDC提供的PPT原稿里面是不附带解说稿的，所以其实详细程度是不如看原视频的。在这之中，偶尔还是能翻出一些详略合适的内容（比如之前也读过的《HiFi-Rush》和《赛博朋克2077》）。

ECS是Entity Component System的缩写，虽然从名称看不出其对于内存连续性和并行执行的意义，但它已经是行业公认的代表面向数据编程的设计模式框架。文末会附一篇Games104介绍ECS部分的链接。

本人虽然没有实际参与过ECS模式的内容开发，只是粗略体验过Unity（DOTS）和Unreal（Mass）的示例，但这次难得看到一篇ECS系统在3A游戏中实际应用，出于个人好奇还是带大家一起读一下。

这篇粗读以翻译原文稿的PPT页内容为主，打星号的部分则是我个人的补充说明。

1 系统框架概述

NorthLight是一个聚焦的、艺术家导向的游戏引擎和工具套件——由Remedy Entertaiment开发，赋权给我们现在和未来开发的游戏。

在创造工业化导向的游戏视觉方面不断进行技术演进：

《量子破碎》中顶尖的面部动画
《控制》中（Remedy产品）首次使用的硬件光线追踪

对于《心灵杀手2》，NorthLight有着多项提升：

GPU驱动的管线
基于SDF的风系统
植被控制
更多可以参见remedy官方提供的链接

在2021年，新的ECS（Entity Component System）物体模组在NL中被启用了。
它替代了之前使用的重度面向对象（OOP）实体组件框架，通过预定义的函数和事件图来连接不同的实体之上的组件。
ECS是一个软件设计方案，它通过分离数据和行为来改进代码的重用度。其中数据被以一个缓存友好的方式存储，以提升性能。
一个缓存友好的数据分布，和NL ECS的易于并行化都能提升性能。
更重要的是，它能使游戏玩法的程序员更易于理解游戏逻辑的执行流程。

NL引擎的ECS有如下特点：

它有实体（entities）概念，它们是有唯一性的标识符。
有组件（components）概念，是纯数据类型（的结构），不执行行为。
组件可以被动态增加或移除。
它有系统（system）概念，是由包含特定组件的实体匹配而成的函数功能。
系统访问数据的读写操作定义可以在编译时就进行验证，而这是一个强项。

*之所以可以在编译时验证是一定程度放弃了“动态类型”的，后面看例子就能看出。

组件是纯数据结构，用来表达一个状态。
它们不应包含任何行为，而只有状态数据。
如果你需要提供一个公用接口以处理组件数据（以某种方式），可以采用一个自由函数传入这个组件（作为参数）的方式，而不是作为组件的函数方法（method）。

*PPT页中可以看到血量计算函数的具体写法。

环境保存游戏中能被全局访问的数据。
它们直接存在于内存中，而不与任何实体关联。
任何环境类型只以单例的形式存在于游戏中。

*PPT页中可以看到以游戏光标为例的一套写法，包含基本结构、更新位置、绘制。

实体是一个概念上的物体，由被称为组件的数据结构组成——每个组件代表了该物体的一类特定功能。
一个实体由其关联的组件集合来定义。对于实体来说并不存在具体的“物体”概念。
一个实体能被一个32位的整型数标识（相当于ID）。
代码中仍有能表达单一或多个实体，并访问其组件的方式。

访问定义是一个模板化的数据结构，它允许定义一次数据访问（的内容）。
它是用于使ECS系统理解你的依赖项的。

*可以看到PPT页中的类似面向过程的语法，以及一些基础的模板样式。

定义链通常以一个特定的访问范围定义作为结尾（如果需要的话），以指明从一个实体或一个集合中读取数据。

*PPT页中的Group和Query都是对应集合类型。

一个ECS中的系统是一个自由函数，它能接收一些输入、进行处理并产生一些输出给组件。
系统也能添加或移除组件。
系统使用访问和环境作为参数。

*PPT页中引用了两个实体：可受伤角色实体、伤害来源实体。而系统函数主要内容是基于一组伤害来源（查询）进行定时伤害结算。

为使一个系统生效，我们需要将其注册到游戏循环中。

我们可以将其注册到不同的游戏循环阶段中——对应系统组的概念：

可变更新
固定更新
固定更新前的可变更新

当注册系统时，添加依赖项来影响系统的执行顺序是可行的。如果没有指定顺序，则系统会按访问需求的顺序执行。

*这里update模块的细节作者没有给出。

*由于游戏中所有类型的执行逻辑都要放在各种系统函数中集中执行，可想而知这套框架不适合处理逻辑过于复杂并且耦合较重的游戏逻辑。

2 案例解析——THE CASE BOARD

（女主角）Saga搜集证据的串联图板。
她能通过放置线索，并将其与游戏中获得的其它信息组合来推进调查进度。
它主要的功能是帮助玩家梳理故事线，并更加投入其中。
某些游戏中的事件只能被案件板中线索的组合来触发。

玩家在游戏中能搜集不同类型的线索（通过交互、拾取、调查实景模型，以及脚本事件）。

玩家通过拖动操作来将线索放置在板上，并与其它线索组合。
部分线索会依赖案件板自身的事件触发来被放置或解锁。

游戏中会有多项进行中的调查，玩家可以在它们之间切换。

案件信息的布局是通过一个编辑工具定义的——它是由Remedy的主UI/UX设计师Riho Kroll开发的。它能允许叙事设计师以所见即所得的方式编辑案件。（*What you see is what you get）

案件布局数据会被导出成一个配置文件（lua格式），并用于游戏中。

代码以一组模块作为组织结构。
模块至少由一个头文件和一个.cpp文件。（*C++语言）
每个模块有一个或多个系统。
对于案件板的模块，其中有一组模块，各自以应对特定的功能特性。
也有一组与其它游玩系统共享的模块。

*简单看看案件板模块，其中有例如：案件板模块、手模块、案件绘制模块、案件道具生成等。而共享模块有：游戏光标模块、摄像机追拍模块、动作模块等。

板上的每个案件是一颗线索条目的“树”。
线索条目是玩家在案件板上操作的主要物体。
当一个线索条目执行了某些动作后（例如：放下、解锁、组合），一个或更多的规则可能被触发。
每个规则可能调用一些其他的动作（放置条目、解锁至手上、移除条目等），以应对特定条件被满足的场合（某些道具被放置、解锁等）。
线索条目可以通过以下方式被放置到板上：被玩家从“手”上放下；通过触发规则；显式通过脚本调用。

线索条目可能有如下类型：

案件——一个调查文件夹条目。是所有条目的父节点，被自动放置。
照片——开启一个新调查分支。通过手部操作放置。
线索——拍立得照片、引用、手稿页。由玩家在游戏过程中收集，通过手来放置。当与问题成功组合后能被放置在板上。
推理——当所有线索被与问题组合后，会被自动放置在问题下方。

我们将所有案件（名称、条目集合）、条目描述、状态（放置、解锁、挂载父节点）存储在一个环境中。

从以下角度来看这（种设计）很有用：

很便于从配置文件中加载数据。
这是一个同步点。当我们想修改当前案件板的逻辑状态时，特别是从脚本调用时，我们都需要通过案件板环境。
非常便于加载案件板的状态。

这种方案中，为一个线索条目执行任何动作会如下实现（图中）。

这是一个自由C++函数，传入itemId和一个案件板环境的可变的引用作为参数。

在这个函数中我们将执行如下步骤：

找到环境中某条目的一个可变指针。
修改（需要的）状态。
执行动作特有的逻辑。
处理动作特有的规则。

*引用reference和指针pointer是一组C++概念。

这一模块与“真实世界”条目实体一起生效，主要负责：

更新条目状态。
更新板上的条目的空间变换。

逻辑被拆分成不同的系统。这是非常必要的，因为计算和应用最终的空间变换不如它看上去那么容易。

这也使我们能：

避免锁定非必须的数据，以至于阻碍其它游戏系统的执行（例如空间变换）。
在可行时并行执行系统。
确保特定的逻辑应用到所有需要的实体上——在执行下一步骤前。

在（开发中）的很长时间里，线索条目是能通过光标在板上随意放置的。
当移动一个条目时，所有子条目需要保持其基于父条目的偏移值（一起移动）。
条目可以叠放并堆叠起来。
并且，它们的位置不能超过板的边界。

整套位置机制被拆分为多个系统，逐个执行：

更新状态和偏移值，尤其是通过案件板环境设置的“真实世界”实体。
设置条目的XY位置和边界——基于偏移值和案件板边界。
检验条目的叠放，以确认其上下关系：基于层级、条目类型、条目索引、（是否）最后被操作等。
基于叠放信息对深度排序，以计算相关的Z值。
设置条目的最终空间变换值（或直接通过动画的方式）。

*系统执行顺序是通过excuteAfter语法来确保的。

我们定义了一个组件结构以存储所有的itemId和状态。
我们通过环境中存储的条目状态来比较组件的状态，在必要时对组件做修改。
关键的访问是对于条目的实体的，因此系统可以潜在的在一个实体层级上并行执行：对于每个实体，一个系统在其所述的线程中执行。

*案件板item的具体数据结构及状态函数。

在更新了条目状态，并读取它的偏移值数据后，我们需要更新它（和板位置相关）的XY位置和边界——把板的限制列入考虑。
为存储这些值，我们特定了一个新的组件用于条目的XY边界。（*提到的ItemBoundaries组件）
这一系统将从条目组件中读取条目的状态，或许网格组件的外延值，并写入ItemBoundaries组件。

*边界处理——基于三个二维向量，中心、最小值、最大值。

在我们更新了条目的中心和边界后，我们可以检测叠放在一起的条目。
这（计算的信息）被用于后续更新条目的深度。
系统的关键访问是（特定的叠放物）实体，但我们也需要分别查询所有其它条目。（*这句的意思可以参照后面的函数体）
如果我们想保持一个实体层级的并行执行，我们需要确保在一次查询访问时不读写同一实体。（*否则就要改串行或者考虑加锁了）
然而，将叠放结果写入一个单独（分开）的组件中也是必要的。

*前面提到的特定单个实体是OverlappedItemsEntity类型的实体，后续需要写入叠放计算结果；查询的是通过ItemBoundariesQuery以访问其它Item实体，并通过itemsHaveOverlap和isItemBelow函数来确定上下层级；计算的结果写入itemsBelow容器中。