前言

1 系统框架概述

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

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

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

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

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

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

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

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

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

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

2 案例解析——THE CASE BOARD

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 在得到所有条目的叠放信息后，我们可以对Z坐标进行排序。
• 为实现这一点，我们创造了“层”的概念——基于某一条目其下条目的数量。
• 为创造这些“层”，我们需要读写所有条目数据以处理全部依赖关系。（*读写的是不同的组件类型）

• 最终，在我们计算完XY和Z值后，我们为条目设置实际的空间变换。
• 将这一逻辑放在一个独立的系统中，使我们能仅在实际需要时“锁定”变化组件，而不会阻止其它系统在一帧中的早些阶段来与其交互。

• 实体的动画（弹簧运动）是被一个不同的（可以用于其它游玩特性的）系统来处理的。
• 为一个条目增加动画，只用为其增加一个运动组件。
• 当动画结束时，我们移除这一组件。
• 我们使用一个特定的辅助物体——指令缓冲来注册这些组件的布局，并在每一帧的最后被flush。

3 脚本调用

• 某些案件板功能需要开放给设计师，在脚本系统中使用。
• 我们使用Lua作为脚本语言。
• 我们并不在Lua端反射数据。设计师不需要考虑例如组件、访问定义等这类概念。作为替代，他们操作函数，传入实体ID作为参数。
• 我们提供了两种从Lua端进行交互的方式：C++的Lua绑定；Lua事件。
• 我们的Lua脚本执行于一个单线程序列。当它们被执行时，所有组件的状态都是同步过的，并且也没有其它系统在执行。这样，设计师们有不用考虑多线程相关的问题了。

1. 一个绑定函数——在C++和Lua虚拟机之间传输数据，并校验输入的参数的有效性。
2. 文档注释——用于生成VS Code中汇集式的函数说明。
3. 类型定义——被Lua的类型校验器用于检测脚本错误。类型定义信息是基于文档注释自动生成的。

• 从Lua参数堆栈获取参数。
• 检验参数有效性，对于无效的类型（例如函数希望输入一个string，但传入了number）或值（例如超出范围的值），在必要时进行报错。
• 调用C++函数或类方法以执行实际的逻辑。
• 将返回值和返回值的数量推入Lua堆栈。

• Lua事件是C++向Lua脚本通信的方式。
• 我们使用环境（*这里还是ECS概念）LuaEvents来收集一帧中的事件。
• 收集的事件会在下一帧开始被派遣调度。
• 每个发送了Lua事件的系统都需要是单线程的，因为需要对LuaEvents环境进行数据写入。

• 通过ECS框架，gameplay程序员的思维模式被改变了。与处理对象不同，这个框架里我们和数据打交道。
• 总的来说程序执行看起来很像和数据库交互，因为我们（更关注于）查询和修改数据。
• 动态增加和移除组件的能力使我们能在运行时轻松地为不同实体开关系统。
• 系统注册允许我们显式的指定访问同一份数据的不同系统的执行顺序。
• 为获得更好的性能，更佳的方式就是把数据拆分成不同的组件，而不是放在一起。
• 我们可以构造一个便利和坚固（robust，直接翻成“鲁棒”也行）脚本交互系统，它不需要设计师关心数据的分布（结构）及并行化逻辑。

结语