游戏美术生产工业化:项目管理-u0026数据管理

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

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

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

游戏美术生产工业化:项目管理-u0026数据管理

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

游戏美术生产工业化:项目管理-u0026数据管理

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

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

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

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

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

开发和维护 Pipeline 系统的人,在影视行业,叫做 Pipeline TD(Technical Director)。

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

游戏美术生产工业化:项目管理-u0026数据管理

[ 图源:https://www.illuminationmacguff.com ]

可以看到,(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 的制作实际制作时长,用来衡量工作效率或者是任务预算是否合适)

大概的关系是:

游戏美术生产工业化:项目管理-u0026数据管理

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

另外要有多样的 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 的组长或总监)

大概的关系是:

游戏美术生产工业化:项目管理-u0026数据管理

影视的几种 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 、jsonyaml 等,可以理解为用记事本打开,里面都是人类可读的单词符号,偶尔你还能“哟这不是我的节点名字嘛”

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

游戏美术生产工业化:项目管理-u0026数据管理

使用方式:每个美术,把 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 存入数据库里面。

游戏美术生产工业化:项目管理-u0026数据管理

看你们的实际需求吧。

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

为啥不用“存放在文件中”方式呢,当我们要查看、要搜索的时候,比如过滤出模型面数超过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”这种无效信息。但我们可以在填写的输入框里,自动填充一下模板,引导美术大大们写上合适的内容。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年12月18日 上午8:44
下一篇 2022年12月18日 上午8:46

相关推荐