日前，Perforce攜手合作伙伴龍智一同亮相Unreal Fest 2024上海站，分享Helix Core版本控制系統及其協作套件的強大功能與最新動態，助力游戲創意產業加速前行。

Perforce解決方案工程師Kory Luo在活動主會場，帶來《Perforce Helix Core+UnrealEngine工作流程與使用實踐》的主題演講，分享Helix Core在ProjectTitan項目中的關鍵角色、與UnrealEngine的配置技巧、常見的使用誤區及解決辦法、以及Helix Core的最新功能與應用等重磅干貨。

此次演講的精華回顧，我們將分為上下兩期為您呈現（內容有精簡優化）；本期為（上）期，敬請持續關注。

大家好！我叫Kory，來自Perforce Software，很榮幸能參加這次Unreal Fest上海站的活動。相信大家在活動期間過得非常充實，也希望大家能在此找到自己所需要的新技術和新功能。

接下來，我將為大家介紹Helix?Core版本控制系統及其與UnrealEngine相輔相成的工作流程和最佳使用實踐。

Helix Core和ProjectTitan：關于這場4000+人參與的全球藝術盛會的細節

話不多說，首先來做個小調查：大家是否了解ProjectTitan？或者是否曾參與到這個藝術創作中來？

ProjectTitan是由Epic Games發起一個UE藝術盛會，對全球的UE藝術家開放。該項目提供一個基本開放的世界觀框架，鼓勵所有參與者共同協作，去創造一個嶄新的世界。在這個64平方公里的虛擬土地上，有各種地貌，比如濕地、沙漠、森林等，參與者可以在其中創建各類角色、材料、道具和效果等等。

Helix Core作為這次項目的版本控制軟件，負責存儲ProjectTitan當中的所有數據信息，助力協同完成了這場創作。該項目歷時10周，從3月份一直持續到6月份。項目結束時，ProjectTitan一共有4122名用戶參與，協同創建了17000個變更列表。項目結束后，下載到本地電腦會占據75GB的磁盤空間，服務器端儲存的版本控制文件一共有350GB。

ProjectTitan 服務器規格

首先，我們來了解下ProjectTitan中的服務器規格。

為了方便Epic Games和Perforce去管理構建這樣一個項目，初始的服務器規格其實非常小，性能相對較弱，部署在AWS上，使用的是AWS C5.large，只有兩個VirtualCPU和4GB的RAM。

但是當項目開始運行后，參與者變得非常多。第一周大概有800多個用戶，第二周就激增到1600個用戶。如此一來，小規格的服務器就不再適用了。于是，我們相應擴充了服務器規格，采用m5.2xlarge，內存為32GB，這個規格支撐了項目運行的大部分時間。

在項目后期，我們觀察到RAM的峰值達到了32GB。為了確保項目的持續順利運行，保障客戶體驗，我們將配置升級到m5.4xlarge。另外，關于我們的儲存空間，root volume有50GB；用于存儲日志的hxlogs，也是50GB；用于存儲元數據的hxmetadata，有80GB；hxdepot是用于存儲版本控制軟件的實體文件，大概為1T。

ProjectTitan 服務器拓撲結構

下面來看一下ProjectTitan服務器的拓撲結構，了解我們是如何支撐4000多名用戶在AWS上面完美地完成這場藝術創作的。

我們有一個主服務器在英國倫敦，有三個代理服務器，其中兩個在美國的維吉尼亞和加利福尼亞，還有一個在韓國首爾，以便亞太地區的用戶能夠更好地與Helix Core進行交互、下載文件。我們代理服務器的安裝非常簡單，對配置的要求也相對較低。其配置是主服務器初始時的最低配版本，完全能夠支持大量用戶的訪問和下載。

整個ProjectTitan服務器的部署，都是通過我們的SDP（Server Deployment Package）服務器部署包進行安裝的。使用該部署包不需要支付任何費用，也無需注冊任何信息。

如果您對Helix Core的部署有任何問題，歡迎咨詢Perforce中國授權合作伙伴——龍智，我們的專業服務團隊可為您提供相應指導。

ProjectTitan 服務器監控功能

接下來，我們來了解ProjectTitan服務器的監控功能。我們使用P4Prometheus來實時監察，了解服務器的運行狀況。

從上圖的第一張圖表中，可以看出CPU的使用率不足25%，處理指令非常絲滑，沒有任何問題。

第二張圖表中，可以看到內存峰值在32GB上下浮動，我們也是觀察到這個變動之后，才繼續升級了服務器的規格。

第三張圖表可以看到服務器的負載情況，每天有多少個用戶訪問服務器，每個時段有多少個指令在服務器進行交互，這些都是可以直觀呈現的。

最后一張圖表，用于監察磁盤空間。我們每天都會清理磁盤空間，清理舊的日志，以確保項目的順利進行。黃線代表服務器元數據儲存空間。在項目后期我們擴充了該磁盤，所以圖表可見其向下波動。所有人執行的每一項操作，我們都可以在服務器監控到。

另外，我們為什么會在項目結束前五天或前一周的時候，去擴充metadata的磁盤空間呢？因為我們考慮到，大部分的UE藝術家，往往在項目結束前會進行大量提交，有可能導致系統卡頓和運行不暢。最終，我們選擇擴充磁盤空間，也是避免了這一情況，成功為項目保駕護航，確保了項目的順利完成。

P4Prometheus 概述

P4Prometheus是一個與Helix Core相集成的監控框架。管理員可以通過圖中的一些圖表，直觀了解到服務器的運行狀況，而不用去盯著那些死板的數字了。

通過實時監控服務器的運行狀況，我們可以處理日志，并在Grafana面板上清楚地展示，以便于管理員實時了解。在監測一些實時指標時，我們也可以將其視作為一個系統預警，以有效地減緩意外的發生，并在問題產生之前就將其解決。

Helix Core與UnrealEngine的配置：適用于任何規模的安裝基本知識和技巧

接下來，我們一起來了解大家比較關心的內容——UnrealEngine如何與Helix Core集成使用，也有一些基本知識要為大家介紹。

Typemaps

我們先來認識Typemaps。Typemaps是一個自定義文件，用于規定文件存入到Helix Server當中所對應的文件儲存類型。

上圖右側的圖表，包含了binary文件，也就是二進制文件。從事美術開發的人員都知道，二進制文件是不能合并的，這就會導致多人同時處理同一文件時，可能會產生工作沖突。

為了避免這一問題，有效地提升開發效率，我們引入了filetype modifier，也就是“+l”，我們叫exclusive lock，即文件的專屬鎖。如何理解呢？有了文件專屬鎖，一旦文件被某個用戶檢出（checkout），服務器將顯示專屬鎖，防止其他的用戶修改同一文件，避免工作浪費，從而提升工作效率。

當管理員在服務器端設置好Typemap后，用戶在上傳文件時，它就會自動根據該表分配文件的存儲類型。上圖中，我們還看到“+S2”的文件類型，什么意思呢？我們只保留最新的兩個版本文件到服務器端，以節省磁盤空間。如果大家有需要的話，也可以參考設置。

我們提供的Typemap是一個標準模板，適用于UnrealEngine和Unity，下載后即可投入使用。進一步了解Typemap，歡迎咨詢Perforce中國授權合作伙伴龍智。

如果需要更改Typemap，該怎么辦?

Typemap設置后，如需更改，也可以進行實時更改，但不會影響已存到服務器現有版本的文件類型。如需更改現有的文件類型，可以使用P4 retype進行更改。

上圖下方是一個示例，可知之前的 .uasset管理員設置的文件類型是binary，我們發現同時更改二進制文件可引發沖突后，對文件類型進行“+l”操作，那此后服務器當中的所有.uasset文件類型都是“binary+l”。

.p4ignore文件

下面來看一下 .p4ignore。顧名思義，ignore就是“忽略”，它是在客戶端上傳文件時用于忽略特定文件的一項規則。

如何忽略？就是通過上圖所示的這張表。對于文件路徑或是相符的文件名稱、擴展名，都可以通過該表進行忽略。

舉例來說，如果將系統生成的文件上傳到服務器，會非常占空間且無用，那么，我們就可以在上傳之前將其忽略掉。管理員在設置好這個功能后，可以提交到我們的版本倉，這樣用戶在下載文件的時候，該ignore文件就會自動下載到本地的磁盤空間。然后，ignore規則就開始適用了。

當然，也有一個小bug。因為用戶對版本倉都是有更改權限的，很可能存在文件誤刪或誤改的情況。這個時候也沒有關系，因為我們在服務器端還有控制管理。管理員可以在流規范（stream spec）中直接設置，進一步設置ignore規則。不過呢，相對于.p4ignore，流規范中的ignore在通配符使用上相對比較局限。所以我們通過用戶端的.p4ignore和服務器端的ignore設置，來進行雙重管控，避免將不必要的文件上傳到服務器。

權限及文件保護設置

接下來，我們談談權限管理。

我們的IP至關重要，為了防止團隊文件被未授權的人員或者第三方訪問，管理員可以為整個服務器的用戶或小組設置獨立的專屬權限。

Helix Core的權限控制非常細粒度，可以精確到每一個版本倉、每一個文件夾、每一個子文件夾、每一個特定文件或者特定的一個擴展名，這些全部都可以在protection table中進行設置。

對于新加入項目組的用戶，操作不太熟練，可能會出現誤改或誤刪的情況，影響到項目進度。我們可以通過限制其訪問范圍來避免這一情況，也可以根據職位給予合適的權限和合適的文件路徑。

另外，在與第三方合作時，往往需要限制第三方的合作視野，我們也可以通過Helix Core進行很好地權限控制。

具體來認識一下protection table。它包含多個縱列，比如權限級別，它能夠控制用戶是否可以提交、下載、創建分支，以及能否查看特定路徑的特定文件，包括文件名、文件內容等等。

下圖是ProjectTitan項目中權限表的部分截圖示例。

可以看到，這個開放項目在初始時，所有用戶的權限都比較開放，但對于一些關鍵文件（比如11-16行），我們設置了“no open”，也就是說，對于這些文件，所有用戶都是無法更改和刪除的。此外，我們還可以限制訪問的IP地址，確保只有在受信任的IP地址中，用戶才能獲得相應的訪問權限。

備份及服務器還原點設置

再來了解一下還原點設置，我們稱之為checkpoint。它記錄了Helix Core服務器當中所有元數據的全部信息，包括誰、在什么時間、修改了什么版本、執行了什么操作。所含的信息比如：常見的變更列表、用戶信息、標簽、分支、工作請求等等，checkpoint都將其全部包含在內。

不過，我們在創建還原點時需要注意其對數據庫性能的影響。因數據庫大小的不同，鎖住數據庫的時長也不同。在服務區繁忙時會導致命令堆積，從而影響到服務器性能。因此，我們建議在服務器負載較低的時間段，比如夜間或凌晨，進行checkpoint的創建。另外呢，Helix Core的服務器部署包（SDP）也提供了自動化腳本，可以設置在夜間的某個時段，自動化創建checkpoint。

未完待續......