Unreal Engine 4 —— 工作流相关之代码管理

这篇博客讨论了一个团队使用UE4时，进行代码管理的方方面面所需要注意的点。

---

背景

现在的游戏行业不再是单枪匹马打天下的时代了……要做一个作品，团队的合作才是王道。

使用UE4也大概有3年了，愈发感觉到团队合作的重要性。因此打算写这么一系列博客，主要是想做个总结，顺便以飨后来人（反正也没人看）。

---

Perforce与UE4

与UE4结合最紧密的代码管理工具肯定是Perforce无疑。

更适合游戏的代码管理工具

首先，作为代码管理工具，Perforce天生就比起Git或SVN更加适合管理游戏的源码，尤其是针对于例如贴图之类的非文本文件更加友好。

与UE4的深度集成

其次，UE4针对Perforce进行了深度的集成，除了常用的check in/out等命令之外，甚至还能够针对于Blueprint进行Diff操作：

如图，可以很方便的在图形化的界面进行Blueprint进行Diff操作：

官方钦点的代码管理

其次，Perforce是Epic Games官方使用的代码管理工具。如果团队获得了Epic官方的udn授权，那么可以直接访问Epic Games对应的Depot，这样一来可以将Epic-团队与团队内部的代码管理统一到一个Perforce平台来。

因为保密相关所以就不放图了。。。

与绑定插件的集成

还有，UE4的蒙皮-绑定-动画模块在官方的Animation&Rigging Tools插件下有一个官方工作流，这个插件也与Perforce进行了深度集成：

价格？

Perforce的价格比较昂贵，但是也有针对小团队的免费版本。针对比较老的版本，可以享受20个免费的Workspace，对于小团队来说应该是足够了。最新的版本，据说减少到了5个？所以如果大家能找比较老的版本，那就偷着乐去吧……

推荐的Perforce架构

按说这不属于UE4的内容，但是我认为还是有必要提一提。针对于一个团队该如何使用Perforce，其实也是有门道的。

针对深度定制化或保密性较强的团队

针对于深度定制化（例如喜欢对引擎魔改的团队），或者保密性较强的团队（例如各外包团队）。我个人比较推荐的Perforce架构为：

• 在depot下维护一个专门的UDN目录，用于管理UE4的引擎。针对于普通团队成员，只拥有读权限。针对引擎团队、主程或技术总监，则拥有可写权限。如果对于保密性有更高的要求，则可以只将UE4下的二进制文件设为可读，Source文件夹可以设定为不可见。
• 团队成员通过这种方式来获得团队定制化的引擎，从而进行项目的开发。

这样的好处在于保密性较强，能够确保整个团队所使用的引擎都是同样的定制化的引擎。引擎的迭代由统一的引擎团队、主程或者技术总监进行负责，而负责项目开发的团队则使用统一的引擎来进行开发，而不用去操心引擎的包袱。

而这样的缺点就是不够灵活，例如说开发团队想要引入一个插件或者自己写一个插件，又或者需要使用自己写的.usf文件，那么往往需要走一趟引擎团队的流程。不过这也难免，保密性或可定制性和灵活性往往是不能兼得的。

针对使用官方引擎版本的团队

使用官方引擎版本的团队规模往往偏小，也没有足够的技术储备来进行引擎的定制化。因此往往直接就使用官方推出的引擎版本，此时推荐的Perforce架构为：

• Depot下就直接放各个项目文件夹了。
• 需要将文本代码和.exe/.pdb设定为多人可写，因为文本可以比较方便的进行Merge。
• 如果需要将引入或者自己写的插件进行代码管理，此时将其放在引擎的安装目录下是不太现实的，此时可以将对应的插件放在项目下的Plugins文件夹内，当项目启动时，也会将这个文件夹下的插件加载。
• 如果需要引入自己写的Shader(.usf文件)，并没有一个很直接的方案。这是由于引擎启动时只会加载引擎安装目录下的Shaders文件夹下的Shader。但是有个取巧的方案可以实现Shader的代码管理，具体方案请参见我以前的博客：传送门。

项目的代码管理

通常的UE4项目文件夹下会有不少文件夹，需要同步的文件夹为：

• Binaries
• Build
• Config
• Content
• Plugins
• Shaders
• Sources
• Project.png
• Project.uproject

此外，注意Saved和Intermediate文件夹记得不要同步。

另外，我个人的推荐，针对于项目的美术文件，策划文档等，最好是放到项目下的Resource_Raw文件夹下进行同步。

Perforce&UE4的注意事项

在这几年的Perforce&UE4使用过程中，我总结了一些个人认为比较好的使用习惯：

• 在开启项目前，务必记得先进行更新，如果是程序员进行了代码更新，记得重新编译一份。
• 在开始任务之前，最好在Perforce下建立对应的Pending List。这样能够比较好得进行任务分类，省的到时候提交的时候出现多提交了或这少提交了的情况。此外，主程或技术总监也能比较方便的了解到当前正在执行哪些任务。
  
• 进行文件的迁出时，最好是在p4v里面进行手动迁出到对应的Pending List，如果是在UE4内迁出，那么会迁出到Default的Pending List里面，容易搞混。
  

• 绝对不要手动设为可写，谁这么干了可以直接打死……
  

• 若更新中新增了代码文件，记得重新生成项目文件……
  

• 如果使用了Epic提供的ART来进行绑定，那么会生成对应的一个_Export.mb文件，这个文件极其重要，务必进行提交，并且日后可以用这个文件和外包进行交接。
  

• 如果在引擎内进行了asset的移动，那么务必在提交前修复重定向器：

---

总体来说，Perforce是极为适合UE4的代码管理工具。除了文中提到的那些东西外，其实还有一些值得注意的。以后有机会的话再写吧……

<全文完>