Perforce演讲回顾（上）：从UE项目Project Titan，看Helix Core在大型游戏开发中的版本控制与集成使用策略

日前，Perforce携手合作伙伴龙智一同亮相Unreal Fest 2024上海站，分享Helix Core版本控制系统及其协作套件的强大功能与最新动态，助力游戏创意产业加速前行。

 

Perforce解决方案工程师Kory Luo在活动主会场，带来《Perforce Helix Core+Unreal Engine工作流程与使用实践》的主题演讲，分享Helix Core在Project Titan项目中的关键角色、与UnrealEngine的配置技巧、常见的使用误区及解决办法、以及Helix Core的最新功能与应用等重磅干货。

 

此次演讲的精华回顾，我们将分为上下两期为您呈现（内容有精简优化）；本期为（上）期，敬请持续关注。

 

大家好！我叫Kory，来自Perforce Software，很荣幸能参加这次Unreal Fest上海站的活动。相信大家在活动期间过得非常充实，也希望大家能在此找到自己所需要的新技术和新功能。

 

接下来，我将为大家介绍Helix Core版本控制系统及其与Unreal Engine相辅相成的工作流程和最佳使用实践。

Helix Core和Project Titan：关于这场4000+人参与的全球艺术盛会的细节

话不多说，首先来做个小调查：大家是否了解Project Titan？或者是否曾参与到这个艺术创作中来？

 

Project Titan是由Epic Games发起一个UE艺术盛会，对全球的UE艺术家开放。该项目提供一个基本开放的世界观框架，鼓励所有参与者共同协作，去创造一个崭新的世界。在这个64平方公里的虚拟土地上，有各种地貌，比如湿地、沙漠、森林等，参与者可以在其中创建各类角色、材料、道具和效果等等。

 

Helix Core作为这次项目的版本控制软件，负责存储Project Titan当中的所有数据信息，助力协同完成了这场创作。该项目历时10周，从3月份一直持续到6月份。项目结束时，Project Titan一共有4122名用户参与，协同创建了17000个变更列表。项目结束后，下载到本地电脑会占据75GB的磁盘空间，服务器端储存的版本控制文件一共有350GB。

 

Project Titan 服务器规格

 

首先，我们来了解下Project Titan中的服务器规格。

 

为了方便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。

 

Project Titan 服务器拓扑结构

 

下面来看一下Project Titan服务器的拓扑结构，了解我们是如何支撑4000多名用户在AWS上面完美地完成这场艺术创作的。

 

 

我们有一个主服务器在英国伦敦，有三个代理服务器，其中两个在美国的维吉尼亚和加利福尼亚，还有一个在韩国首尔，以便亚太地区的用户能够更好地与Helix Core进行交互、下载文件。我们代理服务器的安装非常简单，对配置的要求也相对较低。其配置是主服务器初始时的最低配版本，完全能够支持大量用户的访问和下载。

 

整个Project Titan服务器的部署，都是通过我们的SDP（Server Deployment Package）服务器部署包进行安装的。使用该部署包不需要支付任何费用，也无需注册任何信息。

 

如果您对Helix Core的部署有任何问题，欢迎咨询Perforce中国授权合作伙伴——龙智，我们的专业服务团队可为您提供相应指导。

 

Project Titan 服务器监控功能

 

接下来，我们来了解Project Titan服务器的监控功能。我们使用P4Prometheus来实时监察，了解服务器的运行状况。

 

 

从上图的第一张图表中，可以看出CPU的使用率不足25%，处理指令非常丝滑，没有任何问题。

第二张图表中，可以看到内存峰值在32GB上下浮动，我们也是观察到这个变动之后，才继续升级了服务器的规格。

第三张图表可以看到服务器的负载情况，每天有多少个用户访问服务器，每个时段有多少个指令在服务器进行交互，这些都是可以直观呈现的。

最后一张图表，用于监察磁盘空间。我们每天都会清理磁盘空间，清理旧的日志，以确保项目的顺利进行。黄线代表服务器元数据储存空间。在项目后期我们扩充了该磁盘，所以图表可见其向下波动。所有人执行的每一项操作，我们都可以在服务器监控到。

另外，我们为什么会在项目结束前五天或前一周的时候，去扩充metadata的磁盘空间呢？因为我们考虑到，大部分的UE艺术家，往往在项目结束前会进行大量提交，有可能导致系统卡顿和运行不畅。最终，我们选择扩充磁盘空间，也是避免了这一情况，成功为项目保驾护航，确保了项目的顺利完成。

 

P4Prometheus 概述

 

P4Prometheus是一个与Helix Core相集成的监控框架。管理员可以通过图中的一些图表，直观了解到服务器的运行状况，而不用去盯着那些死板的数字了。

通过实时监控服务器的运行状况，我们可以处理日志，并在Grafana面板上清楚地展示，以便于管理员实时了解。在监测一些实时指标时，我们也可以将其视作为一个系统预警，以有效地减缓意外的发生，并在问题产生之前就将其解决。

 

Helix Core与UnrealEngine的配置：适用于任何规模的安装基本知识和技巧

接下来，我们一起来了解大家比较关心的内容——Unreal Engine如何与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。它包含多个纵列，比如权限级别，它能够控制用户是否可以提交、下载、创建分支，以及能否查看特定路径的特定文件，包括文件名、文件内容等等。

 

下图是Project Titan项目中权限表的部分截图示例。

 

 

可以看到，这个开放项目在初始时，所有用户的权限都比较开放，但对于一些关键文件（比如11-16行），我们设置了“no open”，也就是说，对于这些文件，所有用户都是无法更改和删除的。此外，我们还可以限制访问的IP地址，确保只有在受信任的IP地址中，用户才能获得相应的访问权限。

 

备份及服务器还原点设置

 

再来了解一下还原点设置，我们称之为checkpoint。它记录了Helix Core服务器当中所有元数据的全部信息，包括谁、在什么时间、修改了什么版本、执行了什么操作。所含的信息比如：常见的变更列表、用户信息、标签、分支、工作请求等等，checkpoint都将其全部包含在内。

 

 

不过，我们在创建还原点时需要注意其对数据库性能的影响。因数据库大小的不同，锁住数据库的时长也不同。在服务区繁忙时会导致命令堆积，从而影响到服务器性能。因此，我们建议在服务器负载较低的时间段，比如夜间或凌晨，进行checkpoint的创建。另外呢，Helix Core的服务器部署包（SDP）也提供了自动化脚本，可以设置在夜间的某个时段，自动化创建checkpoint。

 

未完待续......