游戏工业化？——Pipeline 基本概念之数据管理

上一篇 我们讲了 Production Management，提到让大家投票选择可以满足要求的软件，投票五花八门，我们收敛一下，在影视行业，体量大点的公司，选用的基本是ShotGrid 或 Ftrack，而中小型公司市场，则基本被 CGTeamwork 所垄断（壮哉我大国产软件！！），当然，据后台留言，也有用 excel 管的（在此声明，我绝对没有看不起 Excel 的意思，我认为 Excel 是人类最伟大的发明之一，我开发的最多的、且最受欢迎的插件，都是关于 Excel 的！）。

今天我们来讨论数据管理，是我鸽了你们吗？不，是我在写着写着，还没提到具体的美术流程，就又三千多字了。简略一笔带过吧，又怕没解释到位，造成信息不对等。想想我没必要非得立什么必须三篇写完这种目标，尽量说明白才是目的，所以您受累，再等等下一篇资产管理。

以下是正文。

我们从一个我最近被问道的问题说起：

那我的工程文件，是上传到 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 。

存储是影视公司的头等大事，它涉及访问速度、写入效率、快照系统、日志系统、权限管理、吞吐量、存储带宽、协议延迟、冷热数据分层、分布式存储等等，总而言之，不是简简单单的找个地方放文件就行了，是个很花钱的东东，这一块是我的知识盲区，我 IT 野哥当年是跟我科普的：

情景重现

IT 大哥：要不是咱们公司咬咬牙买了 isilon，旧存储根本扛不住《上海堡垒》项目啊。

（你别笑... ...《上海堡垒》视效量很大的）

我：为啥呀，多买几百块硬盘不就行了呗！

IT 大哥：咱们旧存储服务器相当于老式火车，车厢全靠火车头带，能挂载多少节有极限，不是想扩容就无限扩的；刚买的这个是复兴号，每节车厢都自带动力，想扩容多少都没问题。

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

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

进引擎之前的文件

我在游戏这边见过的管理软件有 P4V 、 Git 、 SVN 、Alienbrain 以及，emmm....没有[摊手]，只存放在美术本地硬盘上... ...

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

提示

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

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

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

• NAS ，推荐指数，五颗星，下面一个段落专门讲一下。
• P4V ，推荐指数，三颗星。专门给游戏行业设计的。尤其是，如果引擎工程也使用 P4V 了的话，我不清楚它的收费模式，但从美术角度讲，可以减少一个需要理解的系统。如果有人能说服我游戏公司真的不能用 NAS ，那么 P4V 可以提升到四颗星。
• 云储存 ，推荐指数，一颗星。类似百度网盘，但不要用百度网盘！如果你不知道为什么就证明你根本不适合它。对象存储这块，影视有强大的、专业的、专门服务TD 的 IT，都还没敢全换，只敢稍微尝试一下（跟外包进行文件交接），除非你能找来阿里云、腾讯云存储的核心开发者专门来给你服务。
• SVN 、 Git ，推荐指数，零颗星。这俩就不是干这个事的！相当于你让一个模型师去设计汽车的发动机，原因是他们都用3ds 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 存入数据库里面。

	优点	缺点
存放在文件中	易用；渲染农场访问不会拥挤；	要么是海量小文件（每个资产的每个版本对应一个文件）；要么是少量的巨大文件（一个资产一个文件）。造成访问和查询非常慢，而且风险大，有文件编辑占用等等问题
存放在数据库中	支持数据量大；查询超快；可以校验质检，确保数据有效性；什么冷备热备灾备的，一直可用；随时应对用户量的变化，横向竖向扩展都没问题	比文本文件复杂；要是挂了，信息可就丢失了；部署啊，服务器啊，这些工作都需要做；如果外网能访问，还要做账号权限管理；还得提供 UI，或者API；

看你们的实际需求吧。

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

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

那我就去 P4V 服务器上搜嘛！

还记得我上篇文章提到过：

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

正所谓：

此物只应天上有，人间难得几回寻

严正声明， ShotGrid 和 Ftrack 与本人无任何交易！

非说有点私心的话就是希望项目用了，就可以省去TD 一大部分工作量，还能拿它去当人才库、资产库、材质库、日报管理、Pipeline团队的开发管理、各种工具的后台。

书归正题。还有个问题。

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

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

题外话

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

命名规范

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

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

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

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

Metadata 怎么记录

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

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

讲到这里，你的头脑已经有点发胀，我们该怎么管理啊？！没有头绪啊！从哪儿下手啊？！

敬请期待下一篇“资产管理”。

四千五百多字，辛苦大家阅读了。鞠躬。

差点忘了.... 开头的问题，你知道答案了吗？