近日,由国家新闻出版署主管,中国音像与数字出版协会等承办的2022年度中国游戏产业年会在广州举办。
在“国际观察——游戏制作工业化升级趋势”主题分论坛上,字节跳动研发工程师徐国梁结合自身经历,从行业标准、技术、人才培养等多个维度,分享讨论了游戏行业在工业化路上需要解决的问题、面临的困难以及自身的观点和经验。
游戏产业的工业化升级是什么?
徐国梁认为,工业化是一个很宽泛的概念,目前可以从几个方面来认知。
第一,工业化既然有“化”字,证明它是一个进行时的东西,且是没有终点的进行时。并不是说我们达到了什么程度,工业化就完成了,这是一个要持续进行、与时俱进的工程项目。
第二,游戏美术内容创作的工业化,并不适合所有游戏。“比如说一两个人想去做非常小的,带有探索性质的项目,它去做很多工业化的建设,可能对它的游戏开发是没有任何好处的,这也是有可能的。”
因此,核心点在于:工业化的目的是什么?本质上,这其实是要解决生产产品这件事。
也就是说,从创作作品变为生产产品时,才需要做工业化这件事。同时既然是生产产品,自然会更多地提到量产。要提高效率,或者保证质量,甚至是激发创意,做出以前做不出来的东西。
在他看来,工业化升级主要就是两个点:“一是做好更多的自动化、工具化、智能化;第二个就是做好信息化、正规化的管理,把协作这一方面也做好。”
怎样建立游戏美术的工业化标准?
随后,围绕游戏美术的工业化标准,徐国梁谈到,这同传统的工业,或者互联网行业的信息化、工业化有着明显的区别。即它有很强的创作性质,这也是必须要解决好的问题。
在他看来,统一标准是工业化中一个非常底层、基本的逻辑。“有了统一的标准才能让更多人参与进来,是复杂项目能够顺利完成的基石。”
但同时,游戏行业是一个相当复杂的行业,并非一群艺术家一起创作这么简单。游戏创作出来的美术资源,最终都要打包成一个软件产品,里面涉及软件硬件等技术的融合,需要投入相当大的精力。
“我觉得创建标准有两个部分——第一是行业需要形成的标准;第二是针对项目的实施,也要在项目内建立大量的标准。”徐国梁说。
首先是行业标准,这应该是领域的共识。只有形成了领域共识,行业标准才会稳定,并对整个行业的人才的发展提供帮助的。“如果总是在改变、具有流动性的话,可能对行业没有好处。”
“而行业标准最基本的状态就是以最佳实践为范本,比如欧特克的一些方案,或者是在游戏当中用Maya来做动画这个环节、用MotionBuilder做动捕等,已经成为了一些事实标准,那么这些事实标准其实就能很好地组成我们的行业标准。”
其次对于项目标准,徐国梁也根据自己的经验,总结了制定标准的三个原则:
一、项目标准必须服务项目,即不能生搬硬套。我们以前会说我从某某某公司见过一个特别好的流程,是不是搬过来之后,我们就像那家公司一样,但这其实是非常不确定的,因为我们项目可能跟人家就不一样,生搬硬套是很大的问题。
二、项目标准必须服务团队,即什么样的人用什么样的工具。就像穿鞋一样,鞋的大小得合脚才行,要保证它落得了地,是非常核心的点。
三、项目标准一定一定要全局优先,也就是自上而下的设计。我觉得有这方面的经验的人,应该就能够体会,从自下而上,也就是说我这有个好点,他有个好点,然后攒在一起,很有可能会产生很大的排斥性。自上而下是第三个核心原则。
如何利用工业化标准保证品质?
当然,标准的建立并不等同于工业化升级的成功。客观来说,在工业化标准落地执行、团队沟通协作确保品质的过程中,同样存在不少困难和痛点。
对此,徐国梁表示:“我是做Pipeline方向的,我们的方法就是将标准转换成一个可执行的流程。所以我认为主要可以分成两个部分,一是如何设计和开发流程,有哪些需要关注的;二就是在执行流程当中,我们需要注意哪些点。”
在设计项目流程中,首先,和制定项目标准原则一样,它必须要适合团队的执行,且最好是一个被验证过的流程。“尤其是在大型项目中,我们非常忌讳用一个完全是拍脑袋想出来的流程直接去实施,这是非常容易失败的。”
其次,流程一定要尽量“无统”。“尤其是我们做Pipeline这一方面,TA或者TD我们非常需要去注意的。‘最好的工业化就是去工业化’,你感觉不到工业化在你身边,但事实上它已经默默地帮你解决了很多问题,这是一个比较好的方向。”
再者,流程必须先于制作。很多时候项目已经在运行中,这时才想要梳理一个流程来支撑项目,其实是非常困难的。流程是经验化的表达,是一个标准化的东西,不能中途更改。
徐国梁举例说:“我们以前一个项目做了一半,忽然要改美术制作流程,这时候我们一些来自国外大厂的总监,他们就会说你这个就相当于飞机正在天上飞着,你要把发动机给换了,你要把引擎给换了,这是非常危险的事情。”
最后,流程的设定需要大量经验,不能光靠开发者,还得发动艺术家,要尽可能地覆盖Common Task。
“我们想象当中都是马上做第一环节,我用哪个软件,做第二环节,用哪些软件,这样串起来。但事实上这些都是主流程,还有很多Common Task,比如说要做一个表情,来回在几个软件当中倒的这种情况,你都要尽可能去考虑。”
该流程结束后,紧接着就是设计开发流程。他强调,这是开发者主要要做的重点工作。
先是协作规范,即人和人应该怎么去解决。开发者不能光考虑数据怎么流通、软件之间怎么打通。更多要考虑协作,尤其是跨地区、跨多个公司的情况,多个工作室的协作、部门之间的协作等。
“我们一般情况下要制定比较好的接口人制度,比如非常有用的ShotGrid,在上下文同步上就非常有用。如果每次发一封邮件里面都要带一个Excel,然后每次 Excel的更新都要重新发邮件,这样的流程是非常不合理的,ShotGrid就可以解决。”
然后,是要对项目的执行进行追踪。执行的追踪是非常重要的,“你不能说我做了Pipeline,所有东西都给你工具了,你就按工具走,它具体实施的好坏你必须得知道。”徐国梁说道。
一是利用ShotGrid这样的产品去对原始数据状态进行追踪,并对计划和报表进行追踪,要能够实时地输出项目执行的健康情况;二是流程的执行。
“制定了流程后,很多人说我作为一个PipelineTD或者我工具TA,做了工具我就完工了,其实这是完全不对的。”他进一步提到,“现在的软件都非常需要维护,对于流程的执行这一块非常重要,我大概分成三个步骤。”
第一步是交付,意味着产品不光要有软件,还要有对应的文档及培训。
第二步是监控,除了要监控项目的执行,还得监控自己的程序运行的情况,比如对程序不同功能的热度,以及它的错误率等的收集。
第三步是最重要的部分——维护,开发者需要随时能够监听所有用户反馈的工单。“在一些大厂他们会有一些非常有意思的说法,比如诊所,就是你这边有什么问题就到诊所来去解决。这一部分,我觉得是非常重要的。”
而在关于保持品质方面,徐国梁特地提到:“现在Pipeline的设计和执行当中非常难的地方,即沟通的信息熵总是会膨胀。”
“我们最初的时候就有这样的感受,你跟制片人去谈的时候,什么事情发生了你需要通知到谁,他都会尽可能地罗列出可通知的对象。后来从那天起,我的邮箱里每天都是99+,我也不知道99+里哪些重要,所以说信息轰炸,或者说对信息的分享方面,是未来一个开放性的话题。”
此外,还有信息地来回传递,尤其是有两个公司之间不能艺术家到艺术家的直接沟通,都是接口人的话,传递信息的过程中,信息变形也是很大的问题。“这是我想提出来,以后去思考的一些问题。”徐国梁如是说。
如何解决异地协作的问题?
异地协作,如今已经愈发普遍。早年间,多数工作室可能更愿意自己解决所有问题,但随着行业的解决方案愈发标准、统一,直接导致异地协作的数量日益增长。徐国梁透露,自己接触异地协作已久,也一直关注异地协作如何解决的问题。
关于如何解决异地协作的问题,他认为:第一是要优先考虑项目标准的问题。
技术性标准必须得先行,多数人一提到标准,可能会把所有需要交付的东西都考虑进去。但事实上,在协作的过程中往往是鞭长莫及,且不同的公司人员配置方式也不一样,这方面其实可能没有办法达到。
相比之下,重要的是需要把技术性标准确定。也就是说,不管质量做得怎么样,但是它必须得符合规格,否则无法嵌入到流程当中。因此,技术标准先行是第一要点。
第二,如果开发者没有办法共享所有的供应链,给到所有的下游供应商,那么最好先定义清楚交付标准。
外包和内部做绝对是不一样的,如果开发者连他们怎么做都能限制得很好,这时候自然可以不作考虑。但如果不是这样的话,最好考虑清楚交付标准。
第三,尽可能地将定好的规范流程程序化,做成一个工具。程序能做的事情让人去做,很容易出纰漏。一旦出现纰漏,越是隐藏得深的错误,对项目的影响越深远。因此,要前期杜绝,彻底地维护自己的规范。
在徐国梁看来,没有太多跨地区协作经验的制作人或者是团队,都会面临一个问题,即没有办法一开始就定义一个非常靠谱的Pipeline流程或者标准。他指出,这时候其实需要关注标准的维护。也就是每隔一段时间进行充分的沟通,让所有的团队都能够保持上下文的一致性。
异地协作依赖的技术方面,徐国梁指出:“欧特克做的都是比较完备的,我想到的主要是通讯、信息方面的,就比如ShotGrid,我记得ShotGrid里有个功能允许我直接在玛雅里面跟我协作的其他艺术家实时交换信息,我觉得这些都做得很好。然后还有Review,其实美术这一块特别在意Review,所以能够远程Review也会解决很多问题。”
再就是数据共享,大家能够在同一个平台上工作,这一点比较重要。
怎样追求高效迭代和版本控制?
无论是相互间的沟通协作,还是想要追求高品质,都避免不了反复修改的过程。因此,高效迭代也成为工业化升级中不可避免的一个重要挑战。
徐国梁也表示:“其实高效迭代非常重要,你最好能够更早Review、更早地看到结果。其实我们现在最核心CG技术的进步就在于,已经可以越来越提前地预览到,以前需要经历线性流程的很多步骤才能够看到的东西。”
其中的核心点在于“后期前置”,即能够尽早地看到后期才能看到东西,要寻求第一时间的预览。
而他则将这形象地解释为“游戏打团”般的状态:“我们以前会想现在做一个片子,就像做一个游戏资产,是你上来弄完了之后我再上来,但是现在我们期望的状况就像玩《魔兽世界》,大家同时上线,一个人指挥,然后大家就打团一样,每个人都能够实时看到Boss的进度,这是一个比较好的状态,我主要关注的也是这个点。”
与此同时,徐国梁提到:迭代过程中,版本控制是一个非常重要的话题。
迭代意味着不断地去修改,这种修改并不是针对整个项目,是对某一个细节进行修改,这就会导致不同的细节。“比如某一个非常重要的道具,可能被修改了几千次,而某一个不太重要的场景元素,一棵树可能只被修改过两次。这样的话就会形成很大的落差,所以怎么管理好是非常重要的。”
在他看来,首先要先有工程的概念才能有版本的概念。如果一上来只做版本控制,是非常不合宜的。现在使用工具基本上会先创建一个工程,即便不用这些工具和相关工程,开发者肯定也有一个自己定义好的工程,并且有一套很好的自动化管理工程的能力,因此应该先有工程。
第二是针对版本,很多时候会在内部有很大的争论。“到底我面向交互版本去设计内部版本,还是要面向制作去设计内部版本。其实我的想法基于内容生产,就是要面向制作来设计版本,然后交付的时候其实是把我们的结果塌陷成一个版本交给他就好。”
第三,具体到版本控制,美术资源的版本控制和代码版本控制不一样。有过编程经历的开发者都懂得要做版本控制,git或svn等。但在游戏行业,它更多是美术资产。“这个东西非常大且难以存储,所以一般情况下,如果你使用Git,可能要安装一些相关的支撑性的插件,SVN也要做好自己的二次开发。”
第四,版本控制最大的难点,更多是版本更新的问题。依赖关系是非常重要的,比如A依赖的B更新了,那么正在做A的那个人,得第一时间妥善地收到,这一方面是非常需要去解决的。
绕不开的定制化工具
“其实做TA的人都知道,对DCC进行二次开发,这是非常正常的情况,因为不同类型的项目它依赖的工具肯定是不一样的。”徐国梁提到:“所以工具定制化是绕不过去的点。”
比如,FPS和策略类项目,第一人称、第三人称都不一样,很难做出相同通用的工具,不太现实。虽然它其实和通用工具不冲突,但也存在非常重要的博弈。尤其是不同的公司人也不一样,需要的东西可能也不一样,这是思路不同的问题。
徐国梁表示:“我的想法就是一切以项目需求而定,一些比较公开和通用的内容开发,比如你的Pipeline,可能更多是考虑环节和环节之间等,很多通用工具能解决很多问题。”但他也认为,可以做一些自动化的东西,比如自动化生成文件。
Pipeline方面经常会提到:每一次组装新的文件,制作都是从0开始,打开一个空的Maya,然后开始工作。其实不是这样,如果做得比较好的话,是可以完全做好初始化的,比如到某一个环节,会自动地将之前环节为他准备的东西自动整合在一起,这些都是非常值得去做的。
其实除了“一键XXX”这种自动化之外,更重要的是一个你完全不用参与流感的自动化,也就是事件驱动的自动化,即特定事情发生的时候,系统会自动完成一些工作,这方面的自动化也是非常值得去做的。
“当然定制化开发的大头可能还不在我说的Pipeline上,主要可能还包含了各种TA做的大量的材质、特效、动作等渲染方面的工具。”
如何实现专业化分工?
众所周知,工业化升级意味着必然有一个成熟的体系,其中,专业化分工是绕不开的部分。
徐国梁也认为,专业化细分是具备一定优势。第一是专业的人做专业的事;第二,专业的同时人员也能更专注,不用一个人操心很多地方,能够专注把擅长的方面做得更高效、更精致。
不过,他也指出,细分同样存在问题。首先,过度细分后会遇到弱于串联,尤其是细分的不合理。
“像腾讯可能有比较成熟的细分方式,这时候细分之后,它总是能搭得上手,但是如果细分得不是很合理,其实就会出现三不管。比如一件事,模型组觉得不是我的事,绑定师觉得也不是我的事,就会变成了一个三不管地带,一亩三分地的问题其实还蛮严重的。”
除了弱于串联效果会减分,细分还有一个短板:它不适合每一个环节。很多很优秀的工作室的游戏或美术作品,可能是一两个全能型的艺术家,加上全栈型的程序员组成的,这也具备独有的、不可替代的优势。
而徐国梁更多谈到的其实是,如果真的要建立一个团队、想去做分工,需要考虑哪些东西?
第一是团队风格,有时候核心或者骨干的艺术家、总监对生产流程的影响是非常大的,尤其是新的团队一定不能忽视它的存在。“越是大型的团队,无论换哪个总监,我们当然都希望他融入我们的流程当中去,但是对于新兴的尤其是创意性很强的项目,你就需要流程来适应你的人,这一点是非常重要的。”
第二是根据基础设施来考虑,有时候可能没有中央存储等很多东西,这时候去细分这样的专门的岗位,也是一个不现实、不可落地的点。
第三是项目风格。不同项目风格它需要考虑的不一样。
与之相对,分工方面特别值得考虑的重点,还是关于标准如何制定这件事:自上而下。
分工一定要有好的Supervisor,让这个Supervisor同时负责几个部分,才能把不同工作拆开。如果没有一个人去cover整件事情,直接把它拆开了,这不是分工,而是斩断了他们之间的联络,会把一件事情变得复杂,难以去管理。
关于分工的颗粒度,也就是分到什么程度为止,其实非常值得思考。
首先,是需要因专业而分的。有时做模型的人有可能可以学习相关技术,比如材质贴图,因为他可能也要画UV等类似的技术,这种可能就适合分到一起去。但不能是完全不相干的两个工作,就算这个人同时会两个工作,也不应该去这样去分,因为后续可能找不到跨专业的人。
其次就需要根据项目对效率的要求。如果是大型项目,对效率要求很高,那么就应当适当地细分、更清晰一些。
中台的优点与不足
提到中台,更多想到的可能是技术性中台。但其实,在游戏美术上,美术中台也是相当常见。徐国梁提到,过去曾服务过国内一家较大的游戏公司,他们以美术中台着称,因此自己也有很多心得体会。
他直接点出,中台优点显而易见,一个是通用性,另一个则是节约资源。
同时中台的好处还在于,它在各个项目中间,能够以更全局视角看一些问题,比较有利于内部标准的建立和完善。不仅是沉淀技术,做一些解决方案,甚至还能够带动或激发一些小型团队快速完成工作。
缺点方面,首先是不利于开发中的项目争取资源。“有时候你觉得这个项目非常重要,但中台可能已经饱和了,它需要保证一些非常重要、挣钱很多的项目,而你在开发中,还没有证明自己之前,你对中台的依赖就没有办法很大。”
其次,中台往往是不灵活的。因为它是站在项目中间的部门,不太能够向某一方倾斜。当项目非常特别、有很多的新技术引入的时候,中台不一定能跟上你的脚步,灵活应对。因此,中台常常照顾不到一些定制化的需求。
再者就是中台开发的很多东西,有时虽然和你想要的东西只差一点,但它推给你后,作为一个接手的TA,会发现基于中台进行二次开发,成本其实不一定很低,这是一个相当常见的问题。
此外,中台推出的工具可能不适合项目,但是由于管理上的需求会强推这个工具,这时反而造成了很多浪费。
最后是非常严重的问题,如果中台创建的底层基础出现问题,它的影响面是最大的,会把所有建立在这个基础上的全局都影响到。
换而言之,虽然中台是非常出色的一套组织架构的方式,但同时也要求企业具备很强的资质能力,才能够把它玩得转、能够更加灵活地去应对问题。
而在中台之外,徐国梁还认为,众包未来会是游戏行业发展的另一大方向。
在他眼中,游戏行业其实是向两端发展,一方面大型工作室成立中台,实现量产,实现产品化。另一方面很多的项目也开始走向众包,需要很多的服务团队来制作内容,从而在短期内做出非常高质量的内容。如异地协作,重点解决的其实是众包问题。
“我觉得这种结构是比较好的,也是未来的发展的方向,这两者虽然设计上是相反的,但其实是可以共存的状态。”
大厂如何看待人才储备?
随着游戏产业实现工业化升级和专业化分工,人才的重要性也愈发凸显。相对地,人才的培养和储备成为越来越多游戏企业、尤其是大厂关注的话题。而徐国梁认为,这方面其实不只是考虑大企业,更多应该考虑人才系统
他认为,人才储备是个系统性的问题,是全社会的系统性问题。人才和产品的质量是螺旋上升的状态,只有有更好的项目,才会促使产生更好的人才。这中间是有一个机制的。
“举一个我看到的问题,如果我们都是靠培训班直接培训,或者高校里由没有做过实际项目的研究生毕业就去做老师,他们带的学生,往往出来就业时没有足够的实战能力。”
因此,人才的储备,需要很好的人才系统。游戏做出来可以赚很多的钱,也要知道我们追求什么样的标杆,形成一个行业的共识、建设标准,用行业标准共识影响培养人才这一侧。同时也要有好的师资的人才通道,游戏的发展,人员参与肯定会越来越多。资深人员年纪大了可能会退出行业,去传授他人经验,这时形成一个系统才能健康地发展。
而对于企业内部、尤其是大厂内部,徐国梁谈到:“包括腾讯光子工作室的TA等团队,我觉得特别好,因为他们做了大量的探索性质的事情,尤其在研发上。最重要的是要有一些我现在可能用不上,但是将来可能要用上的探索,以及技术储备、沉淀出来的东西。”
对此,他指出了之前看过的比亚迪纪录片。其中提到,比亚迪的发展方式就是技术鱼塘,等到公司需要的时候,去鱼塘里捞一捞,可能会捞到救命鱼,可能某个技术的储备就能救企业的命。
“我觉得储备人才也是这样,要储备我们平常要用得到的,也要储备一些我们未来的。”