前言

比起SIGGRAPH來說，GDC Vault裡雖然也有大量遊戲開發相關的知識分享，但由於主要是視頻為主，因此能被我拿來作為二手知識粗讀一遍的文稿類內容相對沒那麼多；另外，GDC提供的PPT原稿裡面是不附帶解說稿的，所以其實詳細程度是不如看原視頻的。在這之中，偶爾還是能翻出一些詳略合適的內容（比如之前也讀過的《HiFi-Rush》和《電馭叛客2077》）。

ECS是Entity Component System的縮寫，雖然從名稱看不出其對於內存連續性和並行執行的意義，但它已經是行業公認的代表面向數據編程的設計模式框架。文末會附一篇Games104介紹ECS部分的鏈接。

本人雖然沒有實際參與過ECS模式的內容開發，只是粗略體驗過Unity（DOTS）和Unreal（Mass）的示例，但這次難得看到一篇ECS系統在3A遊戲中實際應用，出於個人好奇還是帶大家一起讀一下。

這篇粗讀以翻譯原文稿的PPT頁內容為主，打星號的部分則是我個人的補充說明。

演講人個人履歷

1 系統框架概述

NorthLight引擎

NorthLight是一個聚焦的、藝術家導向的遊戲引擎和工具套件——由Remedy Entertaiment開發，賦權給我們現在和未來開發的遊戲。

在創造工業化導向的遊戲視覺方面不斷進行技術演進：

《量子破碎》中頂尖的面部動畫
《控制》中（Remedy產品）首次使用的硬件光線追蹤

對於《心靈殺手2》，NorthLight有著多項提升：

GPU驅動的管線
基於SDF的風系統
植被控制
更多可以參見remedy官方提供的鏈接

NL引擎中的新ECS框架

在2021年，新的ECS（Entity Component System）物體模組在NL中被啟用了。
它替代了之前使用的重度面向對象（OOP）實體組件框架，通過預定義的函數和事件圖來連接不同的實體之上的組件。
ECS是一個軟件設計方案，它通過分離數據和行為來改進代碼的重用度。其中數據被以一個緩存友好的方式存儲，以提升性能。
一個緩存友好的數據分佈，和NL ECS的易於並行化都能提升性能。
更重要的是，它能使遊戲玩法的程序員更易於理解遊戲邏輯的執行流程。

NL引擎中的ECS

NL引擎的ECS有如下特點：

它有實體（entities）概念，它們是有唯一性的標識符。
有組件（components）概念，是純數據類型（的結構），不執行行為。
組件可以被動態增加或移除。
它有系統（system）概念，是由包含特定組件的實體匹配而成的函數功能。
系統訪問數據的讀寫操作定義可以在編譯時就進行驗證，而這是一個強項。

*之所以可以在編譯時驗證是一定程度放棄了“動態類型”的，後面看例子就能看出。

ECS框架概覽——組件

組件是純數據結構，用來表達一個狀態。
它們不應包含任何行為，而只有狀態數據。
如果你需要提供一個公用接口以處理組件數據（以某種方式），可以採用一個自由函數傳入這個組件（作為參數）的方式，而不是作為組件的函數方法（method）。

*PPT頁中可以看到血量計算函數的具體寫法。

ECS框架概覽——環境

環境保存遊戲中能被全局訪問的數據。
它們直接存在於內存中，而不與任何實體關聯。
任何環境類型只以單例的形式存在於遊戲中。

*PPT頁中可以看到以遊戲光標為例的一套寫法，包含基本結構、更新位置、繪製。

ECS框架概覽——實體

實體是一個概念上的物體，由被稱為組件的數據結構組成——每個組件代表了該物體的一類特定功能。
一個實體由其關聯的組件集合來定義。對於實體來說並不存在具體的“物體”概念。
一個實體能被一個32位的整型數標識（相當於ID）。
代碼中仍有能表達單一或多個實體，並訪問其組件的方式。

ECS框架概覽——訪問定義

訪問定義是一個模板化的數據結構，它允許定義一次數據訪問（的內容）。
它是用於使ECS系統理解你的依賴項的。

*可以看到PPT頁中的類似面向過程的語法，以及一些基礎的模板樣式。

ECS框架概覽——訪問的類型

定義鏈通常以一個特定的訪問範圍定義作為結尾（如果需要的話），以指明從一個實體或一個集合中讀取數據。

*PPT頁中的Group和Query都是對應集合類型。

ECS框架概覽——系統

一個ECS中的系統是一個自由函數，它能接收一些輸入、進行處理併產生一些輸出給組件。
系統也能添加或移除組件。
系統使用訪問和環境作為參數。

ECS框架概覽——系統（示例）

*PPT頁中引用了兩個實體：可受傷角色實體、傷害來源實體。而系統函數主要內容是基於一組傷害來源（查詢）進行定時傷害結算。

ECS框架概覽——系統註冊

為使一個系統生效，我們需要將其註冊到遊戲循環中。

我們可以將其註冊到不同的遊戲循環階段中——對應系統組的概念：

可變更新
固定更新
固定更新前的可變更新

當註冊系統時，添加依賴項來影響系統的執行順序是可行的。如果沒有指定順序，則系統會按訪問需求的順序執行。

ECS框架概覽——系統註冊（示例）

*這裡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容器中。