游戏美术生产工业化：项目管理&数据管理

以下文章来源于腾讯游戏学堂 ，作者Gandalf Mu

笔者曾在影视后期Pipeline领域工作多年，后来转至游戏行业并继续从事Pipeline方向的工作。影视Pipeline百花齐放，而且不断在进步，而随着游戏工业化的不断发展，游戏研发当中的Pipeline也越来越受到重视。游戏工业化包含诸多模块，其中美术流程工业化这一点，绝对绕不开，并且也是其中的重要部分。本篇文章主要和大家讨论一下影视Pipeline、游戏Pipeline，以及他们之间的异同点，涉及项目管理和数据管理两方面。文中的内容均是我个人的经历以及朋友们的经历，并不代表整个国内游戏行业。如果你那里的情况不同，非常欢迎你在评论区留言，让大家的信息更加同步，相互学习，共同进步。

我们在工作中会碰到如下问题：


我们把上述的问题，按照相关的工作岗位，聚类一下：


Pipeline 就是来解决上述问题的。

更概括一点说，Pipeline 是管理项目的信息和数据的流动。

• 信息被高效、正确、及时地传达到位
• 数据的来龙去脉、前世今生、脉络关系管理的清清楚楚明明白白
  

它是谁，它从来哪里，它要到哪里去

非常重要的前言：没有放之四海而皆准的 Pipeline 系统，一定要根据项目的实际情况，只有适合你的 Pipeline才是好的 Pipeline。如果是一个几人的小团队，喊一嗓子就能沟通到位的事情，没必要花时间精力去折腾 Pipeline系统，得不偿失；或者项目的美术资产很少，也确实没必要。

开发和维护 Pipeline 系统的人，在影视行业，叫做 Pipeline TD（Technical Director）。

下面一张图片，展示了一个动画电影的完整制作流程，你能找到 TD 在哪里吗？（友情提示，图超长）


可以看到，（Pipeline）TD 们都是在小房间之外（不参与内容制作）走动，负责监控和维护，保障整个管道正常运行的人。

继续我们的话题，本文我们从刚开始提到的三个岗位的工作内容角度，将 Pipeline 要管理的范畴，分为三大类：

• 项目管理
• Review
• 资产管理（文件和 Metadata 的管理）
  

这三者并不是隔离的，而是紧密结合在一起的，之间的数据和信息流动是要丝滑的、无缝的。

其实 Review 是包含在了项目管理中的 ，但在游戏过程中，由于大家经常忽视 Review 这一块的重要性，所以我就把它单独拎出来。

按照影视的说法，就是分 Production Management 和 Asset Management。

项目管理

我们这里不涉及项目管理模式，如Agile、Waterflow。

这里的内容主要包含：

• 任务分配、排期
• 任务的上下游关联
• 任务的资产关联
• 跟踪资产完成度、发行版本、项目进度等
  

这里涉及到的数据类型：

• Project（最顶层的，游戏项目、电影项目，或者因为某些原因拆分出来“子”项目）
• Phase（或者叫Sprint，指一段时间，加很多个 milestone，用来做阶段性排期，比如游戏要上线的6.0 版本等）
• Asset（包括影视的 Sequence/Shot、游戏的美术资产、关卡等）
• Task（将 Asset的制作拆分出来的最小级别的、可以分配到具体人的任务，并且有期望起止时间和预计时长）
• People（可以是个具体的美术人员，也可以是外包公司）
• TimeLog（记录每个 Task 的制作实际制作时长，用来衡量工作效率或者是任务预算是否合适）
  

大概的关系是：


上述涉及到的内容，最好有甘特图来协助查看和便捷编辑。

另外要有多样的 filter，协助项目每个人查看他感兴趣的部分，比如：

• 列出所有动画任务
• 列出所有两周内要过期的任务
• 列出包含在xxx版本要上线的任务
  

该系统必须可以应对变化，大到比如外部环境变化导致的延期、比如老板突然要调整游戏上线日期，小到人员离职，多增加美术、多外包、系统可以快速调整和更新排期，确保每个人都知道自己该做什么、该什么时候做、先做哪个后做哪个。

具有项目管理功能的软件/系统有很多，影视或游戏行业在这方面的基础需求也没有太多的特性，强烈建议直接使用一个用户量多的、适合你项目体量的商业系统就行，前提是这个系统必须支持二次开发，因为只满足基本需要可远远不够，按照之前的经验，我们 Pipeline 在这个部分的主要精力放在了

• 将生产数据进行各种角度的可视化，帮助PM 精细化管理项目周期和人力安排，把控项目风险，避免空转/过载
• 开发各种自动化监听脚本，比如当A任务完成80%就把 B任务状态改为“可以开始”，减少 PM 手动、重复工作量，减少人为出错
• 开发各种RTX通知机器人，比如提醒美术临期任务。及时提醒，避免遗漏
• 开发各种小工具，包括并不限于浏览器插件、基于管理系统的菜单拓展等，减少PM 操作步骤
• 生成产能报告，展示进度、落后的部分、资源闲置等等状况
  

另外，提到它必须提供二次开发接口，还因为这里的信息，是要出现在美术的工作环境中的，比如DCC、引擎里的（第三部分）

再次，还需要强调的是，该系统的数据库支持一定程度的自定义：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 Column。

随着项目越来越复杂，需求量增多，Pipeline 岗位再次被细分，甚至前几年国内都有公司招聘制片TD（在游戏可以理解为配给APM 的TA）。在我查找小黄人那张图片的时候，看到做小黄人的 Illumination 公司竟然也有招 Production Technical Director。

Review

主要包含两方面：

• Review 工具（如何更好地Review）
• 管理和跟踪反馈
  

美术上传工作内容，总监对其进行反馈；美术拿到反馈继续修改，不断迭代，直到效果通过。

这里涉及的有：

• Task（上个部分中的Task）
• Version（内容一般是图片或视频，美术的一次迭代）
• Playlist（将多个 Version 放在一起的播放列表，方便开 Review 会议时查看）
• Note（反馈，一般有文字描述、示意图片、或者其他文件作为附件）
• People（这里指上传 Version的美术/外包公司，和负责 Review 的组长或总监）
  

大概的关系是：


影视的几种 Review 形式：

• 直接日常线上Review，美术/外包随时提交，组长或总监随时反馈，Review 流程超快
• rounds，直白翻译叫巡视，走一圈：总监带着PM，走到 Artist的工位上，直接查看其 DCC 内容
• 正式的 Review 会议，有专业投影仪，标准的色彩显示，有组长、总监、PM，兴许有客户，预先准备好的 Playlist 进行挨个 Review
  

游戏还会有直接打开游戏，边体验边 Review，我们的反馈方式就要加上录音、录屏、截图。

另外，不得不提一下 Client Review，就是客户，或者是导演、老板、IP方等，在内部已经迭代了不少版，总监觉得已经离定稿不远了，可以拿出来给客户看看。

client Review 的note 需要做隔离，不能直接让相应的美术看到。

一方面，确实有语言翻译的原因，另外，还是需要“翻译”一下客户的反馈，再一方面，需要“过滤”一下客户的反馈。

Review 工具需要具备的功能：

• 可以写文字描述
• 有各种画笔功能，可以直接在画面上涂鸦
• 可以录音、录屏、截图
• Ghost and Hold Annotations（可以把视频其他帧画面的涂鸦半透明显示，适合动画环节 Review）
• Live Review （多人在线协作 Review ）
• 多版本对比看：并排着对比、叠在一起对比
• 可以查看历史 Note 反馈
• 可以切换历史Version 版本
• 可以切换其他环节的Version 版本
• 影视：可以看到前后shot，串起来看
• ......
  

没有全部功能都有的产品，各个产品有差异、有自己的护城河，我们可以把某一个功能做的特别好的小软件纳入进来，一起使用，然后将它们结果信息同步到我们的 Review系统中。

同样的，该部门的软件或者系统必须支持二次开发，我们 Pipeline 在这个部分的主要精力放在了：

• 让美术及时看到反馈，可以是发邮件、发即时消息
• 甚至让美术直接在自己的 DCC 里面看到，把反馈图片贴在场景里
• 根据新的Note 反馈，自动创建 Task，方便追踪后续是否解决了该反馈
• 美术可以更方便的上传 Version
• 批量上传 Version
• 视频标准化：画面水印、文件分辨率、文件编码、色彩空间、规范命名......
• 统计：task 有多少个 version、多少个 note，跟task 的bid 比，滞后了还是超前了，反向修正排期，让排期更合理。
• 增加更多格式支持，比如支持 3d文件预览
  

同时具备了项目管理和 Review 功能的软件有ShotGrid 、Ftrack。游戏跟影视不同，需要有软件开发的管理部分，这部分如果让诸如 ShotGrid 来管，也不是很合适（虽然它的确有软件开发管理的模块）。所以，可以两个都用，对关键的数据进行实时双向同步。

这时候，肯定有人说，用两个商业系统，那成本多高啊。

这里肯定是忽略了隐形成本，因为觉得贵：

就使用 excel 来管理，带来了协作难题，多版本信息不同步，历史修改丢失，直接影响了生产，这个成本呢？

如果选用了不合适的或者成熟度低的系统，再雇一个TA/TD 来全职开发补齐功能，请问他年包几何，开发能不能按时完成、bug有多少，这个成本呢？

非要 Google Docs/腾讯文档，支持协作，也能高级查询过滤，但公式复杂的逆天，PM 能不能学会、啥时候能学会、要不要直接招个已经会的，这个成本呢？

再次强调那句话，美术资产量不大，确实没必要。

数据管理

有一个我常被问到的问题是：那我的工程文件，是上传到 ShotGrid 里吗？这个问题，简单地回答是或不是，远远不够。所以索性就说个明白。

Data vs Metadata

Data ，在我们讨论的上下文中，指的是我们能在硬盘上看到的具体文件，比如.max、.mb、.hip文件.

这些文件有的是二进制文件，可以理解为用记事本打开，里面都是乱码，人根本就看不懂；

有些是非二进制文件，常常是类似xml 、json 、yaml 等，可以理解为用记事本打开，里面都是人类可读的单词符号，偶尔你还能“哟这不是我的节点名字嘛”

Metadata ，元数据，是描述数据的数据。

比如说 Data  是你这个活生生的人， Metadata  就是你的简历内容，什么身高、体重、身份证号等等，在没看到你这个人站在我面前之前，我通过你的 Metadata （从你简历上看到的），就可以掌握个大概，有时候就能判断出你是不是我要招的人，等我具体想深入了解你的时候，再把你喊过来当年交流（就是用相应软件打开文件）。

玩摄影的朋友可能更熟悉，Data 就是你拍的图像文件，Metadata是这张照片的 ISO、焦距、光圈、拍摄时的地点、曝光......

在我们讨论的上下文中，一般是这几类：

• 文件本身的信息：创建时间、修改时间、大小、创建者、存放路径、文件格式
• 文件内容的信息：面数、有没有UV、有没有骨骼、多少根、在level 里的世界坐标、灯光的亮度、相机的景深
• 人为添加的信息：“这个文件我增加了地面模型”、“这个版本把角色的腿拉长了一些”
• 文件的依赖关系：模型文件依赖的贴图文件们、动画 reference了哪个绑定文件、关卡里面放置的资产们
• 你想记录的其他信息：这个文件的质检结果
  

一定要根据你们的需要，选择真的要经常查看的 Metadata

存放方式

这两种Data，存放方式有所差别。

Data

Data  通常会比较大，毫无疑问，是存放在文件存储系统，比如我们的硬盘、 NAS 、百度网盘、 P4V 、 SVN 、 Git  等等地方。

Data 文件的存储，在视效行业，基本采用 NAS 。

存储是影视公司的头等大事，它涉及访问速度、写入效率、快照系统、日志系统、权限管理、吞吐量、存储带宽、协议延迟、冷热数据分层、分布式存储等等，总而言之，不是简简单单的找个地方放文件就行了，是个很花钱的工作。

而游戏这边，美术资产分为：

• 进引擎之前的，就是.max、.fbx、.sd、.spp等等文件。这跟影视的没有任何区别。
• 进引擎之后的，就是游戏引擎项目工程了。
  

进引擎之前的文件

我所见过的管理软件有 P4V 、 Git 、 SVN 、Alienbrain 以及，只存放在美术本地硬盘上... ...

就算是使用了上述的存储管理，也并不是每个工程文件版本都上传的，大部分还是项目组强制要求，必须至少传一个最终版，上下游交接的文件倒还是有上传的。

影视公司的理念：Artist 制作的所有文件，都是公司的数字资产，必须 publish 到存储服务器！

当然啦，这是缺少文件夹放置规范和自动化工具，换位思考一下，没有一键无脑上传工具，你让我每个版本都上传，我也觉得很烦。

进引擎之前的文件存储方式，建议使用：

NAS ，推荐指数，五颗星，下面一个段落专门讲一下。

P4V ，推荐指数，三颗星。专门给游戏行业设计的。尤其是，如果引擎工程也使用 P4V 了的话，我不清楚它的收费模式，但从美术角度讲，可以减少一个需要理解的系统。如果有人能说服我游戏公司真的不能用 NAS ，那么 P4V 可以变成四颗星。

云储存 ，推荐指数，一颗星。类似百度网盘，但不要用百度网盘！如果你不知道为什么就证明你根本不适合它。对象存储这块，影视有强大的、专业的、专门服务TD 的 IT，都还没敢全换，只敢稍微尝试一下（跟外包进行文件交接），除非你能找来核心开发者专门来给你服务。

SVN 、 Git ，推荐指数，零颗星。这俩就不是干这个事的！相当于你让一个模型师去设计汽车的发动机，原因是他们都用 Max 来建模。就我上面提到的存储要涉及的功能特性，他们两位能有的寥寥无几。

单独介绍一下 NAS


使用方式：每个美术，把 NAS 服务器映射为统一的一个盘符，比如 x:/ ,相当于美术插了一块“移动”硬盘，跟 D 盘一样。只是这块盘，每个人都有，而且都是同一个。

入门：美术 A 创建了个 x:/aaa/bbb.txt ，美术 B 那里马上也有了 x:/aaa/bbb.txt

高级：美术 A 建了个模型 x:/prop_desk_model_v001.mb ，然后里面引用了几张贴图 x:/prop_desk_normal.tga x:/prop_desk_diffuse.tga ，保存。美术 B 此时打开x:/prop_desk_model_v001.mb，不会有任何问题，全程没有上传下载的步骤。这里只是简单举例，影视并不是这么粗暴使用的，但就是这个理儿。

在上文中提到，不能责怪游戏TA 工具部署那么繁琐，影视的工具、Pipeline系统代码直接部署在NAS 上，把 NAS 上的代码文件更新了，工具就更新了（ps：工具里不要长时间 open一个代码里面的文件，不close），然后这个文件夹权限锁死，只有自动部署的CI 机器有权限写入，防止美术误删误改。

另外有一点，因为文件都放在了 NAS 上，如果网速够快，美术直接在 NAS 上制作，本地的硬盘就不会被占了，只需扩容 NAS 即可。

对比一下 P4V ，美术制作过程中的文件都在本地，要是跟其他人交换文件，首先需要别人上传（这个上传过程可不简单），还得把别人的文件下载到他本地，也就是说，同一个文件，出现在了多个硬盘里，不浪费吗？我见过一个项目才是初期，打开美术的资源管理器，一片红彤彤的硬盘空间告警，然后每个人都去再次申请增加个人硬盘，不浪费吗？

P4V 主打的版本管理，在 DCC这里没用，二进制文件merge 不了，就算是非二进制文件也 merge 不了。（你让美术去解决两个sd文件的冲突？美术打爆你的狗头！）

你可能说，那我就喜欢我依赖的文件，一直都叫 prop_desk_model，可以自动更新 ，你说的 NAS 存储，它今天叫 prop_desk_model_v0002 ，明天又多出一个新版本叫 prop_desk_model_v0003 ，我还得手动更新呢。

这位客官请留步，首先，谁告诉你 NAS 不能搞文件一直叫 prop_desk_model ，而且永远是最新版。symbolic link 了解一下。

其次，这个更新的确有自动更新，和手动更新两种，但你 P4V 也不是自动更新的呀（不二次开发的话），也得点一下更新按钮。

最后，我们不使用 symbolic link 是因为掉过坑。美术 B 用了美术 A 的文件，干的好好的，第二天，文件打不开了，经排查，是美术 A 更新的文件导致的。然后有一天美术C 也要用美术 A 的文件，并提出个修改，美术A 修改了，但是美术 B 并不需要这个修改，又悲剧了......

所以，我们最后选择了每个版本都是单独的文件，通过文件名里面带着版本号来进行管理。这个也符合美术的直觉。

Pipeline 系统自动获取是否有新版本，询问美术是否更新，然后美术可以一键更新，美术也可以随时回溯到任意版本，数据隔离美滋滋。

说了这么多，但 NAS 在游戏这边闻所未闻，除了大公司是有一些 IT 安全方面的考量，中小公司我完全不了解。

的确，游戏行业进引擎之前的文件，没有影视整个公司的多（不能跟项目比，影视有的项目也可小了），那你 NAS 硬盘可以买少点啊！

难道是因为访问速度？那我们可以在本地硬盘制作，完成后 publish 到 NAS 上啊。（请明白的人帮忙解惑，感激不尽。）

进引擎之后的文件

游戏项目工程，必须必须必须选择一个有版本管理功能的软件，如 P4V 、 SVN 、 Git，这一点大家都没有疑问。

Metadata

Matadata  则存在两种方式，以 json  或者 xml  文件形式，一般存放在它要描述的 Data 旁边，看起来可能是这样：

prop_desk_model_v002.max

prop_desk_model_v002.json

另一种方式，则是将 Metadata 存入数据库里面。


看你们的实际需求吧。

你非要问我的意见，那我肯定是选择数据库。

为啥不用“存放在文件中”方式呢，当我们要查看、要搜索的时候，比如过滤出模型面数超过2千的武器，这种方式基本就是去递归扫描武器文件夹里面，模型文件旁边的 Metadata文件，打开、读取，哎呀不符合，下一个.....资产量稍微上去一点，可能几分钟、十几分钟过去了，突然我觉得，我也不是那么的想知道超过2千面数的武器有哪些了。雪上加霜的是，如果是存放在了 P4V 、 SVN 、Git ，本地都没有下载全部资产，还怎么搜索！

那我就去 P4V 服务器上搜嘛！——你这是把存放文件中的唯一优点也舍弃了。

另外，前文也提到：项目管理系统的数据库要支持一定程度的自定义：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 column。

ShotGrid  和 Ftrack 都支持数据库自定义（可能程度不一样），一鱼三吃，白得一个数据库！而且 UI、API、账号权限管理...存放在数据库方式的缺点，全解决了，还不用额外花钱！

除此之外可以省去TD 一大部分工作量，还能拿它去当人才库、资产库、材质库、日报管理、Pipeline团队的开发管理、各种工具的后台。

书归正传。还有个问题。

Data 和 Metadata  有时候不是那么好区分，尤其是那种整合拼装其他二进制文件的软件 ，同时也不把引用的文件内容封装写入到自己的工程文件里面的，比如 Nuke Studio、Substance Designer 等。还有，游戏引擎的项目工程！

这时候，我们就要发自内心地好好想想，到底哪些数据，是我们不想开 data 文件，就想知道的。

这事做到极致的就是达芬奇软件（DaVinci Resolve），它的工程文件就是个数据库！

命名规范

这包含文件命名规范和文件夹规范。具体如何去制定就再说吧......看有没有人愿意看

这里就提一下它的重要性。

规范命名主要的目的是，给资产文件提供一个全局唯一的标识。

• 当我们提到一个资产的时候，就知道在哪里可以找到对于的文件。
• 当我们看到文件的名字，就可以确定资产的位置和类型。
• 有了规范的层级和命名，Pipeline 工具就可以自动化帮你上传下载、导入导出。
  

Metadata 怎么记录

最好是美术使用 Pipeline 工具，在文件被上传/同步到服务器上时，自动提取出来，自动上传到咱们的Metadata 数据库里。

额外的也需要用户输入，比如本次文件修改的内容。虽然我过往的经验是，搜集上来的都是“修改了一下”、“1111”这种无效信息。但我们可以在填写的输入框里，自动填充一下模板，引导美术大大们写上合适的内容。


来源：腾讯游戏学堂