声明 | 本文不含商业合作

整理 | 鳗鱼

2月14日，2022年度中国游戏产业年会在广州召开。在国际观察——游戏制作工业化升级趋势主题论坛上，腾讯光子TA pipeline负责人刘纯一、字节跳动研发工程师徐国梁、以及欧特克公司的技术专家沈映、刘靖就「工业化」相关主题进行了讨论。

他们从怎么理解游戏工业化、如何推进项目、管理团队，再到对搭建中台等多个维度进行讨论，几位从业者分享了在探索工业化过程中积累的经验和观察到的问题。

徐国梁提到，在执行工业化标准时一定要考虑到「人」，如果在没感受到工业化的同时解决掉很多问题，这其实就是比较好的方向。而理想中的项目高速迭代就像在《魔兽世界》里打团本，有人指挥、多人发力，人与人之间是信息互通的。

刘纯一则以光子自研的工具架lightbox为例，讲述了如何用工具来部署开发环境、协助协作开发。并且以中台为例，讲述在开发工具的时候，应该要从使用者而不是开发者的角度去考量使用习惯。

以下为整理后的讨论内容，内容有经过筛选调整。

徐国梁：工业化其实是一个很宽泛的概念，我认为工业化包括以下几个点。

1、工业化之所以包含「化」这个字就代表是一个进行时的东西。并且以我的经验来看，这个进行时是没有终点的进行时，并不是说达到什么程度就完成工业化了，而是要一个要持续进行、与时俱进的工程项目。

2、游戏美术内容的创作工业化并不适合所有游戏。比如说一两个人想要做一个非常小、探索性质的项目，做工业化性质的开发可能是没有任何好处的。所以说核心点在于，工业化的目的还是在于生产产品，当从创作作品过渡到生产产品的时候，这就需要做工业化这样一件事。

3、生产产品就要要求量产。这意味着提高生产效率、或者说是保证质量、激发创意，做出以前做不出来的东西。

那么我认为工业化升级主要包括这两点，一个是做好自动化、工具化、智能化，另一个则是做好信息化、智能化的管理，把协作这一块也做好。

刘纯一：在游戏行业的追求工业化升级其实是让开发者去摆脱传统流程的瓶颈和束缚，从而提高工作效率。光子工作室群在顺应游戏出海化、精品化的大趋势，正在搭建全球的海外工作室。TA在美术管线侧做了很多尝试，我认为工业化涉及两个方面。

第一个是流程。美术流程、打包流程、测试流程其实都可以工业化，美术流程更是绕不开的话题。 另一个方面就是要依靠一些新的技术，去减少手工性的重复性劳动，从而去解放美术同学的时间、提高开发效率，包括PCG技术、照扫技术等等。

沈映：概括地说，我们认为的工业化就是利用管理、利用技术去大规模地实现高品质、高效率的游戏制作。

徐国梁：游戏美术的方向和传统的互联网行业的工业化、信息化是有明显区别的，因为其中有很强的创作性质在里面，所以要解决好这部分的问题。

第一，「统一标准」是工业化中非常基本的底层逻辑，有了统一标准才能让更多人参与进来，是让复杂项目能够顺利完成的基石。

第二，游戏行业是一个复杂的行业，这并不是说让一群艺术家聚集在一起创作这么简单。游戏创作出来的美术资源最终都是要打包成一个软件产品的。这里面涉及到软件、硬件技术的融合，这一块是需要投入很大的精力的。

创立标准我认为有两个部分。第一个部分就是行业需要形成标准，第二部分就是就是针对项目，在项目内的实施建立大量的标准。

首先，行业标准得要是行业的共识。因为只有形成领域共识，这个行业标准才稳定，对于整个行业的人才发展都是有帮助的，如果标准是具有流动性的话是对行业没有好处的。

最基本的状态是以最佳实践为范本，比如说今天在游戏制作中用MAYA来做动画这一环节、用Motionbuilder来做动捕都已经成为事实标准，这些都可以很好地成为行业标准。

其次，对于项目标准而言，其实要根据项目的实际情况而定。这边分享我认为指定项目标准的三个原则。

1、项目标准必须是服务项目的，不能生搬硬套，不能说因为见过其他公司有一套非常好的流程就直接套用，因为可能项目本身就和别人不一样。

2、项目标准必须是服务团队的，也就是说什么样的人用什么样的工具。就像穿鞋一样，鞋的大小得要合脚才行。

3、一定要全局优先，也就是自上而下的设计。有经验的从业者应该理解，自下而上的形式可能会造成很大的排斥性。

刘靖：我们这边有ShotGrid这个流程管理的平台，平时也有用户会向我们问到别人的设置是什么，我是不是可以直拿来用？实际这个确实不能照搬，得要根据自己项目的特点来定制测试项目的流程。

我们这边曾经有个例子，就是《最终幻想》的片子曾经由60多个工作室一起为项目提供服务。最终制作方在ShotGrid上设计了一份操作手册并发给这60多个Studio，让他们用统一的标准来完成这个片子。结果《最终幻想》的粉丝也能看到片子有非常高的质量。

沈映：欧特克也是在DCC（Digital Content Creation，数字内容生成）的流程上一直在探索标准的问题。因为3D MAX和MAYA在流程当中经常被当作平台来使用，所以这个数字资产是流动的，它会从流程当中的一个应用环境流到另一个环境当中，标准也就显得非常重要的。

经过多年的探索，我们的FBX格式到现在还是一个非常重要的承载数字资产的格式。但是我们也有USD作为最新的解决方案，这要感谢我们的用户Pixar（皮克斯）。Pixar是我们的MAYA用户，在做动漫电影的环境当中，根据项目需求并研发出USD这个解决方案，现在也被整个行业认可。并且不仅仅是Autodesk，还有很多其他软件厂商和用户都加入进来去研发USD。

USD之所以能够成为标准，就是因为具有三大优势，比如对大数据的承载特别高效、适合团队协作、以及已经得到行业认可并成为了一种通用格式。

我还想强调一点的是，作为数字资产在流程中流动，它之所以能够成为标准就是因为它能适应各个节点的需求。因为数字资产是非常重的数据包，在不同的节点，有的人需要看材质、有的需要看动画、有的需要看模型，存在不同的需求。所以就需要有不同形式去适应不同节点的需求。

USD最大的优势就是「变量架构」。熟悉MAYA的用户可能知道，我们以前有Alembic的装配解决方案，实际上USD从作用上就可以代替原来MAYA的Alembic解决方案。当时这个Alembic只是MAYA流程中的解决方案，而USD就可以变成整个行业的解决方案。按照这个装配思路去对资产做不同形式、不同版本的变量来适应各个流程当中的需求。

刘纯一：USD集成2020的时候我们TA也做过测试。一个高模用传统的方式打开大概需要半个多小时，占用内存也是高达100多个G，用USD打开的话只需要5分钟，我们也在关注Animal Logic以及Omniverse Scene在广泛引用USD的pipeline，希望USD的解决方案能够应用到实际项目的生产当中。

徐国梁：对于我们pipeline方向来说，比较好的方法就是将标准转换成一个可执行的流程，这对于我们来说非常重要。我认为主要分为两个部分，一个是如何设计和开发一个流程，当中有什么需要关注的？第二个就是在执行流程当中我们需要注意哪些点？因为时间有限，这里只介绍原则性的思路。

1、和制定项目标准的原则一样，它得是适合团队的、可执行的，而且最好是一个被验证过的流程。尤其在大型项目中，非常忌讳用一个完全拍脑袋想出来的流程直接去实施，这是非常容易失败的。

2、流程一定考虑人，尽量做到无痛。尤其是在pipeline、TA或是TD是非常需要注意的一个点。最好的工业化就是去工业化，如果说你感受不到工业化在身边，但事实上已经默默解决了很多问题，这就是一个比较好的方向。

3、流程必须得要先于制作。有的时候项目已经在运行了，这时候提出梳理一个流程来支撑是非常困难的。流程其实是一些经验化、标准化的表达，不能中途去修改。我以前一个项目做到一般，忽然要改美术制作流程，这时候我们来自国外大厂的一位总监就说，这相当于飞机在天上飞着，现在要给发动机和引擎给换了。所以这是一件非常危险的行为。

4、流程设计是需要非常多的经验的，不能光靠开发者，还得发动起来艺术家。在想象当中，大都是你做第一个环节、我再用另一个软件做二个环节，然后就这样串起来。事实上这些都是主流程，除此之外比如一个人要做一个表情，要在几个软件当中来回导，这些都要尽可能去考虑。

除了原则性思路之外，我再介绍一下设计开发流程中主要要做的重点工作。

第一部分是协作规范，也就是人与人之间要怎么解决。我们不能光考虑数据怎么流通、软件之间怎么打通就完了。协作这一块尤其是跨地区、跨公司的情况，一般情况下需要制定比较好的接口人制度，包括上下文同步。像是刚才介绍的ShotGrid在上下文同步方面就非常有用，我们不是每次发邮件都要带一个Excel，每次Excel更新之后都要重新发邮件，这是非常不合理的。

第二部分就是要对项目执行进行追踪。不能说做了pipeline以后，所有事情都给予工具了，之后就按照工具走。实际必须要知道具体实施的好坏，也就是对执行的追踪。一方面我们可以利用像ShotGrid这样的产品对元数据和任务状态进行追踪，另一方面就是通过计划和报表来实时输出流程的健康情况。

第三部分就是对于流程的执行。比如说有的人会觉得做了工具之后就完工了，其实这是完全不对的。现在的软件都是非常需要维护的，所以对于流程的执行非常重要。

总结一下，也就是分成以下三个步骤。

第一步是交付，也就是说你的产品不仅要有一个软件出来，还要有对应的文档和培训；

第二步是监控， 除了要监控项目的执行之外，还要监控自己程序的运行情况，比如说对工具功能的热度、错误率进行收集；

第三步也是最重要的部分就是维护，也就是得随时能够监听所有用户反馈的工单。这在一些大厂会有一些非常有意思的叫法，比如叫做clinic，也就是诊所，换而言之就是有什么问题都到诊所里来。

最后我还想分享我关于pipeline设计和执行当中遗留的问题。

一个是信息熵的困扰。因为信息总是会膨胀的，像是我们最初用ShotGrid的时候就有一个感受，比方说去和制作人沟通，当发生了什么事情之后需要通知到什么人，制作人就会尽可能罗列出可通知的情况。后来从那一天起，我的邮箱每天都是99+，也不知道里面都有什么，有的重要、有的不重要。所以说我觉得信息分层会是未来一个开放性的话题。

还有一个是信息来回传递的问题。尤其是两个公司之间不能实现艺术家和艺术家的直接沟通，都通过接口人的话会在传递信息的过程中出现信息变情，这也是很大的一个问题。

刘纯一：刚刚在流程上进行了分享，那么我就从工具方面进行一些介绍。因为要保证品质的统一就首先要保证艺术家在同样的环境下开展工作，这就需要一个快速分发工具、软件和插件的平台，并且能够做到快速更新；其次就是美术标准要具体到UV、面数等，那就需要一个对美术资产进行管理、检查和发布的工具。

在我们光子内部就有这样一个自研的工具架Lightbox。这是一个内容协作开发以及工具分发的平台，在项目开始的时候我们项目组就会接入这个，中心的TA会根据项目的情况去配置定制化的工具架。

美术同学通过这种方式打开工具就能保证一些基础配置，比如说帧率、渲染分辨率是一样的，从而打造相同的工作环境。另外对于策划以及其他工种的同学，我们也会有对应的工具下放到他们手上。

徐国梁：异地协作其实已经越来越统一了。早年可能更多的工作室选择自己去解决问题，但现在随着行业的解决方案越来越统一，大家都能够用比较标准的方式去进行异地协作。这边我也分享几个观点。

首先关于异地协作还是绕不开标准的问题，这里分为几个要点。

1、技术标准先行。很多人在提到标准之后希望将所有交付的东西都考虑进去，但事实在协作过程中往往鞭长不及，而且不同的公司对人员的配置方式也是不一样的，所以不一定能满足所有要求。

那么最重要的就是技术性的标准，也就是说不管内容制作的质量怎么样，首先它必须符合我的规格，否则就无法迁入到我自己的流程当中去。

2、考虑好交付标准。尤其是在没有办法将所有的工具链共享给所有的供应商的时候，除非你连他们怎么制作都能很好地限制，这是和内容制作是不一样的。

3、尽可能将定好地规范流程进行程序化，并做成一个工具。比如交付的时候的质检、检测、自动化的发布、自动化选择导出格式等。因为这些本来程序能做的事情，如果交给人去做就很容易出纰漏，如果纰漏隐藏得越深，对项目的影响就越深远。

还有就是没有太多跨地区协作经验的制作人或团队都会面临一个问题，那就是可能没有办法一开始就定一个非常靠谱的流程或者标准。这时候就需要关注对标准的维护，比如说我们需要每隔多长时间进行充分地沟通，让所有团队保持上下文的一致性，这点也非常重要。

关于技术协作这一块其实Autodesk已经做得比较完备了。比如说信息对等这方面，在MAYA里就可以和其他艺术家进行实时的交换信息。还有一个就是review，我们美术这一块其实特别在意review，现在能远程review也能解决到很多问题。

刘纯一：先不说异地协作，我们在本地工作的时候，一开始因为lightbox工具架的基建不完善，所以对于美术同学或者艺术家来说，它具有很高的学习成本，比如要学习工具架的文件规则、命名规则等。随着这种基建越来越完善，我们的项目也会更顺利，不管说对于国内项目还是海外工作室的项目来说。

而lightbox还有遇到一个问题。现在我们的工具是可以分发到全球的海外工作室中的，但是关于数据合规、以及跨洲的网络速度其实是现在我们会遇到的瓶颈。

刘靖：欧特克在这方面也有尝试提供解决方案。刚才提到的卡点其实在于访问媒体文件、或者拷贝文件的时候，像左图显示的，跨洲需要经过多个路由的路线传递。我们想到的解决办法如右图，比如说我们可以在美洲找一个美洲的数据存储中心、在亚洲找亚洲的数据存储中心，然后完成数据的同步。这样就能100%解决卡点的问题。

沈映：我再补充一点DCC这一方面的。我觉得异地协作的时候很重要的就是利用web、利用网页去做review，这是非常方便的。所以我们也在把USD技术拓展到web 3D端，利用网页去做review和3D资产。

刘纯一：我们这边在迭代的时候经常遇到一个管理难点。也就是之前传统流程的一个痛点。就是我们的一个需求分配到一个具体的同事当中，怎么样去review这个需求的完成情况、以及在review之后快速触发上下游的衔接。

这个过程在传统流程中我们是靠Excel人力堆叠的方式去进行的，但这个方式其实非常耗时间和人力成本。现在我们光子一些项目用了ShotGrid来做项目资产管理和迭代、review的环节，这帮助我们节省了很多时间。包括我们TA也是基于此做了很多二次开发。

徐国梁：对于高效迭代来说，我也有一些基本的想法。其实高效迭代有一个非常重要的地方在于能够更早地review、更早地看到结果。其实我们DCC技术最核心的进步点就在于能够提前预览到以前需要经过很多步骤才能看到的东西，这也就是我们所说的后期前置。所以在寻求短时间预览的方面，我也能看到行业前沿有很多探索。

我比较看好刚才提到的USD等解决方案能够把我们各方面串在一起。我们以前做一个游戏资产就像是你上来弄、弄完之后我再上来弄。而我们期望的一个状况就像是在玩《魔兽世界》，大家同时上线，在一个人指挥下一起打团，每个人能看到Boss的进度是一样的，这是一个比较好的状态。

徐国梁：对于做TA的人都知道，对DCC进行二次开发算是工作的大头。这是非常正常的情况，因为不同类型的项目所依赖的工具肯定是不一样的，所以定制化是绕不过去的一个点。

比如说一个射击类的和一个策略类的游戏，连第一人称和第三人称都不一样，所以可能很难做出相同的工具去通吃，这也不太现实。尤其是不同公司的人，他们需要的东西也可能是不一样的。

从思路上来说，定制化工具和通用工具也是不冲突的，我的想法是要依项目需求而定。

比如说在pipeline这方面，需要多考虑环节和环节之间、DCC和DCC之间怎么打通的问题，怎么样做到无痛的信息传递。

另外就是解决自动化生成的问题。在pipeline这块我们经常会提到，是不是每一次组装一个新的文件都要从零开始制作，比如打开一个空的MAYA然后开始制作。其实如果做的比较好的话，是玩去哪可以做好初始化的，比如说到了某一个环节，我会自动将之前那些环节为他准备的东西自动整合到一起。

最后自动化除了说一键生成之类的自动化之外，更重要的是另一种完全不用参与的、无感的自动化。这也就是我们所说的事件驱动的自动化，就是当某件事情发生了之后，系统会自动完成一些操作，这部分的自动化也是非常值得去做的。

当然定制化开发的大头可能还不在我说的pipeline当中，可能还包括大量的材质、特效、动作等渲染这些方面。

刘纯一：在这方面我来分享一下我们工作室群的定制化流程工具、以及刚才提到的lightbox。首先我们是基于ShotGrid做了很多二次开发，并且结合我们日常工作开发了企业微信的机器人，以及我们自研了一个桌面端应用专门给美术同学提供。

通过这一套工具，首先对于APM来说，它能够做到自动排期、统计工作量、帮助追踪这个任务的上下游关系，可以减少很多以前管理Excel的人工失误。

对于美术同学来说，他们可以通过桌面端应用来说查看focus的任务、以及这个任务的上下游衔接关系、现在进行到哪一步。它还可以在企业微信快速地看到美术总监在拼装中的一些反馈。再进一步也能通过自研的桌面工具进行完成任务的批量上传，也就是我们说的publish流程。

对于CP方来说，我们现在基于ShotGrid创建了一些外部站点，方便把一些关键数据同步给他们， 帮助他们review资产的同时做到数据的安全隔离。

对于IP方来说，因为我们会有很多跨部门沟通合作，这也可以IP方去看到我们的资产，我们基于ShotGrid把关键数据和Google文档做了交互和打通。这是在流程这一方面的作用。

lightbox是我们自研的一个工具部署分发，但不仅仅如此，它还是一个协作开发的平台。像是刚才国梁提到的无感，比如说我这个lightbox在后台更新其实对美术朋友来说是无感的，我不需要再去戳他一下，说我重新发布了一个，然后他再重新下载。

对于我们TA来说能解决的问题也更大了。比如说我之前开发一个动画Retarget的工具，我需要装一个NoneType的库，那我自己装好这个库之后，还要到美术同学的机器上再去装一遍。而且这个库要求我们的MAYA版本、python版本都是一样的，它才能有效，不然会有很多的兼容问题。

那么这个工具因为集成了很多开源代码库，包括NoneType的，那我就可以直接引用这个库。对于美术同学来说也减少了安装成本，他只要通过这个工具启动MAYA，后台就会自动把环境配置好，也就是做到开箱即用。

这个就解决了以前给项目组分发工具、以及TA协作的痛点。包括像后续MAYA2023、2024其实底层都是用python 3，那么我们以前有很多基于python 2的工具，如果想要升级的话通过这个平台就能做到代码规范。

徐国梁：我认为版本控制本身是一个非常重要的话题。因为我们迭代会不断修改东西，而且这种修改不是对整个项目进行修改，而是对某一个细节进行修改，这就会导致不同的细节。比如说某一个非常重要的道具，它可能被修改了几千次；某一个不太重要的场景元素，比如说一棵树只修改过两次，这就会形成很大的落差。

对于版本管理我想到几个要点。

1、我们要先有工程的概念才能有版本的概念。如果说一上来就做版本控制其实是非常不合宜的。我们基本上都需要通过MAYA或者unreal等先弄一个工程。就算不用这些工程的话其实也需要一个自己定义好的工程、并且有一套很好的自动化管理工程的能力。

2、在内部沟通中，和PMO或者艺术家之间可能会面临一个内部争论，就是究竟应该面向交付版本去设计内部版本、还是面对制作去设计内部版本？其实我认为这一块要尽可能摘开，我的想法是内容生产就是要面向制作来设计版本，然后交付的时候只要把当时的结果塌陷成一个版本再交付就好了。

3、美术素材的版本控制其实和代码的版本控制是不太一样的。原因在于美术资产非常大、难以存储。所以一般如果使用Git的话可能需要安装一些支撑性的插件、SVN也要做好二次开发才比较好。

我的经验是有一款软件叫Perforce，有时候我们也会简称为P4，在美术资产管理方面还是做的不错的。

4、还有就是我认为控制当中最大的难点。其实管理版本更多的是版本更新的问题，也就是说依赖关系是非常重要的。比如说A依赖B，B更新了之后，正在做A的人要第一时间、并且妥善地收到这个更新。

刘纯一：我们这边根据不同项目的要求都有不太一样的情况。像是Git、SVN、p4还有ShotGrid我们都有用。我们TA开发工具的话一般用Git比较多，也是用lightbox那一套代码规范，然后迭代完之后每个版本会有自己的单元测试，包括上传之后会触发我们内部CI自动去帮我们构建这样的流程。

刘纯一：我们这边其实还是比较传统的方式，可能会根据项目的人才结构做一些微调。

徐国梁：我认为专业化细分是具有一定优势的。首先就是专业的人做专业的事，另外在专业的同时也更加专注，因为不用某一个人同时操心很多地方，从而将自己的工作内容做的更高效和精细。

但也可能存在一些问题，比如说过度细分的话就可能会遇到弱于串联的情况。尤其是细分不合理的时候，可能会出现三不管的事情，像是某一件事会让模型组觉得不是我的事、绑定师觉得不是我的事，最后就变成了一件一亩三分地的问题。

还有就是细分也不是适合每一个环节的。我看到很多优秀的工作室做的游戏或是美术作品，可能就是1、2个全能型的艺术家加上全站型的程序员就组成了团队，这也具有不可替代的优势。

如果说要建立一个团队并进行分工的话，我认为要考虑的有3点。

1、根据团队风格来考虑。有的时候核心艺术家、或者是骨干总监对于生产流程的影响是非常大的，你一定不能忽视他的存在。可能在大型团队中更换总监，我们都希望他能融入我们这一套流程中来；但对于新兴、尤其是创意性很强的项目，那就要适应团队的人。

2、根据基础设施来考虑。有时候没有中央存储这些设施，想要细分一个专业去管这个也是不现实的。

3、根据项目风格来考虑。比如现在和第一个项目有不同的风格，可能分工需要考虑的也不一样。

那么对于分工来说，其实和建立标准一样都需要遵循自上而下的原则。必须要有一个人同时cover这些事情，才能把这些事项拆开，否则这个不叫分工，只是斩断了它们之间的联络，反而会把事情变得复杂和难以管理。

关于分工颗粒度，也就是要分到什么程度也是非常值得思考的。

我的第一个想法是要因专业而分。比如做模型的人可能可以学习材质贴图这些知识，因为他们存在技术相似，就适合到一起去。

但是不能让完全不相干的两个人分到一起，即使他同时会两个领域的技能也不应该这样分。因为这样可能会导致后续找不到跨专业的人，所以按专业去分是更加合理的。

第二个就是根据项目对效率的要求而分，如果这是一个大型项目、对效率要求很高，那么就应当适当地细分更清晰一点。

刘靖：这个感觉很像《摩登时代》里面，拧螺丝的就拧螺丝。原来我在影视行业里遇到，制片对于这种细分其实是很细很细的，特别是大厂的人，他们是为了保证每天的数据能正常收下来，保证项目标准能够正常推行下去。

原来传统流程可能都是靠TA、TD去把这些事干了，但是他们其实有自己的开发任务，所以也会造成分心，确实应该让具有专业特征的人去做各自的事情。

刘纯一：中台第一个好处就是对一些工业化的工具和技术是有储备的。在一些新项目刚开始的时候，我们就可以参与进去，把我们一些其他经验拿过来用，这样就减少了很多试错成本。

同时像光子中台里面有很多一些平台技术，比如说PCG、照扫、动捕，我们都是先在中台孵化，然后推广到项目再去落地的，这是最大的好处。此外光子的美术中心在广州、成都、重庆都有光子创新研发基地，会联合很多供应商的力量去帮助我们承接大规模的资产制作。

我另外分享一个中台的弊端。我自己曾经是参与工具开发的，经常就会走入一个误区，就是我们在开发工具的时候经常会从我们TA的使用习惯去思考的，而不是从使用工具的人的使用习惯思考的，这就会造成一些瓶颈。

因为你要考虑他们的使用习惯以及学习成本，这最终会决定这个工具使用的上线情况。也就是说，我们不能过于重视工业化，因为重视这个效率而忽略掉创意，因为我们本质还是要为他们服务、用来激发创意的。

徐国梁：纯一介绍了很多关于技术性中台这方面，那么其实在游戏美术这方面也是很常见的。

中台的优点显而易见，一个就是通用性，另一个就是节约资源。另外中台还有个好处就是它处于各个项目中间，所以能够以全局视角去看待一些问题，比如说在建立标准、沉淀技术、然后做一些解决方案。

甚至中台还能够带动或者激发一些小型团队，从而让他们快速地去完成工作。因为小型工作室可能势单力薄，但是在依附在一个公司中台的话，他们就只需要专注在自己创意那一部分就好。

缺点的话，我这边也总结了一些问题。

1、不利于开发中的项目去争取资源。比方说有时候你认为这个项目非常重要，但中台已经饱和了，它需要跑一些非常重要、或者更能赚钱的项目。这在开发中你还没有证明自己之前，你可能没办法很依赖中台。

2、中台其实是不灵活的。因为它处于项目中间，所以不太能够向某一方面去倾斜。所以说，当你的项目非常特别、或者有新技术引入的时候，中台不一定更能够跟上你的脚步去灵活应对。

3、中台常常照顾不到一些定制化的需求。它开发出来的东西很多时候跟你想要的东西只差一点点，那么你作为一个接受它的对接人或是TA的话，你会发现基于中台的二次开发其实可能会需要不低的成本，这时候就会显得鸡肋。

4、还有一个非常严重的问题，就是如果中台创建的底层基础出现了问题，那么它的影响面是最大的，这会让在这个基础上的全局都会影响到。

另外我还给观察到，可能有的项目因为管理上的需求而强推这个工具，最终反而造成了很多浪费。

总结来说，中台是一套非常好的组织架构的方式，但是它同时也需要企业有很强的资质能力才能把它玩得转，从而灵活地应对问题。

徐国梁：我这边观察到游戏行业其实是向两端发展的。一方面，大型工作室成立中台，并且实现量产；另一方面，很多项目开始走向众包，就是需要很多服务团队来帮助我们制作内容，这样就可以在短期内制作出高质量的内容。

这其实和刚才讨论到异地协作的话题相似，重点也是解决众包的问题。我觉得这种结构是一个比较好、也是未来的一个发展方向。虽然两者在技艺方面感觉是相反的，但它们其实是可以共存的两种状态。

徐国梁：对于我们来说，其实更多的是思考人才系统的问题。说实话其实国内在这一部分发展比较晚，因为国外很早就有一个比较好的游戏市场，所以像是暴雪、育碧这些公司其实做工业化是比较早的。

我个人觉得人才储备是一个全社会、系统性的问题。人才和产品的质量处在螺旋式的上升， 只有有更好的项目，才会促使产生更好的人才。比方说如果让我们的人直接靠培训班培训，或者是从高校里让一些没做过实际项目的人去带项目，往往是没有足够的实战能力的。

对于怎么样形成一个好的人才系统，首先第一个就是把游戏做出来，可以赚很多的钱、或者是我们知道自己追求什么样的标杆，从而形成一个行业共识，然后用这个行业标准共识去影响培养人才这一侧。

同时我们要有一套好的师资人才通道。因为随着游戏的发展，肯定有越来越多资深的行业人员，可能因为年纪大了不适合走出去，那么也可能会愿意退出来传授他自己的经验，从而形成一套健康的系统。

一旦这个系统没有形成就会非常危险，它可能会只是一个临时被市场刺激出来的东西，是不利于健康发展的。

第二，对于企业内部来说最重要的是技术储备和人才储备。尤其是研发方面，可能有一些技术现在用不上，但是将来的时候可能会用上这些沉淀出来的储备。

我前段时间看了比亚迪的纪录片，他们老板讲到比亚迪有一个比较好的发展方式，叫做「技术鱼塘」，就是说等到公司需要他们的时候，就去鱼塘里捞一捞，可能就能捞到救命鱼。对于企业来说，可能储备的某一个技术就能救到企业的命。所以在储备方面既要储备平时用到的、也要储备未来探索可能用得上的。

刘纯一：我分享一些我们美术中台关于TA向的人才培养机制。比如我们有一些TA的知识库，方便一些新同学进行快速地自我成长。包括他在项目里也会有人去带他，一步一步了解项目流程。也就所谓的人才和项目共同成长，这是最后的一个方案。

在技术储备方面，我们中台有一些空余人力会去做前沿技术的研究，比如说我们对USD、新的渲染框架等都会提前做预演、评估其可能性，以及出一些可定性的方案。

在人才培养方面，光子在海外工作室找了很多具备国际视野的高手，这样也可以促进国内外的交流。比如他们经常会在内部举办讲座，分享关于国外大厂在流程或者美术制作上的经验。

最后比较重要的，就是我们从校招这个最前端的阶段培养人才。包括我们和浙江大学、四川音乐学院、广美、成都美术学院都有合作，专门有一些资深TA去给他们上课、或者共同制定一些课程，对口培养我们的人才，在最前沿储备骨干力量。