游戏技术中台要想起作用，没有3年很难_风闻

　　本文由某二次元公司技术中台负责人费洪晖投稿，授权游戏葡萄发布。

　　网上一直流传中台的概念起源的事，据说是源于芬兰的一家游戏公司Supercell。当年马云参观了Supercell之后，受到Supercell大中台的启发，回来后就在阿里大搞中台。

　　我一直对这件事挺好奇的，所以有一次我特意去问了Supercell的一位朋友，他表示有点扯淡，其实Supercell并没有所谓的大中台，有也只是比较小的一些中台，比如引擎工具类的技术中台。至于这个消息是从哪里传出来的，我不知道，完全不重要，重要的是中台确实有它的价值，从而发展到如今各家大中型公司都在搞中台。

　　互联网中台

　　那么先来随便扯一扯互联网的中台。国内的互联网大公司，这几年基本已经陆陆续续搭建了中台，还有很多中小企业，也在追随互联网大公司的步伐，开始尝试中台化。

　　中台的概念的核心比较简单：公用资源，避免重复造轮子，从而提升工程效率，降低时间经济成本。但是中台的边界却没有明确的定义，而且实行起来会有各种问题。当中台的概念被炒了起来，很多似是而非的东西都在往中台上面凑，很多不应该属于中台的范畴却被错误地划入了中台，从而导致最后中台搭建失败，所以行业内也出现了一些反对的声音，说中台不利于事情的开展，不利于产品的把控，中台无用论等等。

　　游戏行业中台现状

　　游戏行业的中台跟互联网公司有一定的类似，因为游戏公司的产品基本都带有联网属性，所以有一定的关联，但是毕竟不是纯粹的互联网公司，所以很多概念其实还是不大一样。

　　我从事游戏研发工作已经差不多12年了，虽然做游戏行业技术中台也有好几年了，也经历过从0开始搭建一个技术中台，趟过不少坑，踩过不少雷，但是可能还是有很多理解不到位的地方，所以如果说的不妥，还请大佬们轻拍。

　　当前的游戏公司，腾讯，网易，巨人，盛大，游族，完美，心动等都拥有不小的中台，中台的概念涉及到的不仅仅是技术，还有美术，UI/UX, 项目管理， IP文案， 音频音效等等，有些公司甚至在打造大中台，小前台，从而提高前台部门项目的灵活性，以及中台部门的健壮性。

　　除去这些上市大公司，发展中的中小型公司也陆陆续续在打造中台，比如鹰角，紫龙，叠纸等等。网易，腾讯之类的大公司的中台目前发展已经相对比较成熟了，但是像其他类公司的中台基本也是最近2，3年之间兴起的，当一个中台真正能发挥大作用也需要一定时间的积累。比如技术中台，如果打造某一个框架，首先框架开发可能需要不少于1年时间，然后经过项目的优化与迭代，可能又是一年多甚至2年时间。

　　所以当一个技术中台真正发挥作用，没有3年是很难做到的，而且技术中台也需要时间去积累口碑，树立权威。跟互联网中台类似，游戏行业中台我也经常听到很多声音，指有些游戏公司的中台，尤其技术中台，做的一些事情比较独立，甚至有点边缘化，与核心产品核心内容相距比较远。其实中台不像前台业务，不直接创造经济价值，有些时候确实会受到不少的挑战。

　　技术中台的目的

　　虽然游戏公司技术中台问题很多，为什么还有这么多公司要去搭技术中台？我主要是觉得中台的目的还是比较美好的，我归纳为3点：

　　提高人效，技术内容做乘法，避免重复造轮子，从而降低成本。

　　积累不同项目的经验，沉淀核心技术，开发流程及工具，提升技术壁垒，缩短研发周期。

　　预研新技术，提高产品品质上限。

　　不管是技术中台自己预研的产品，整理的工作流，沉淀的经验及问题解决方案，还是打造的工具链，都具有通用性，或者可以做少量修改就可以很快在项目中使用的。

　　虽然通用化过程可能比较难和耗时，但是对于产品研发效率的提升还是有很大的帮助。一个产品可以同时用在多个项目，大家也不用各自都搞类似的研发从而浪费人力与财力。而且由于不同技术人员可能会参与不同的项目研发，因为同属于技术中台，便于分享问题与经验，对于疑难杂症也许可以很快的寻找到一个解决方案。因为你碰到的问题可能其他项目已经解决了。

　　游戏技术中台的构成

　　技术中台的拆分有各式各样的形式，大部分公司都会有有以下一些部门组成：

　　引擎部门。引擎部门是比较核心的部门，而且最容易中台化，比如渲染的框架，物理的算法，动画的优化，引擎底层的架构，优化的经验等等，都可以以中台组件化，经验化的形式进行。引擎相关的人力从前期参与，到中期的量产，再到中后期的优化与问题解决都需要重度参与。但是到了项目后期，临近上线或者上线后，引擎部门的工作已经完成的差不多了。基本可以撤回大部分团队，留少量的人力继续维护，其他人可以快速进行其他项目的开发，从而达到人力的最优化使用。

　　技术美术部门。TA部门的情况跟引擎部门差不多，前期负责性能预算的执行，美术方向及效果的尝试，美术的培训及一些工作流及工具的制定，到中后期实现特殊的渲染效果，到尾期也可以撤回大部分人力，留少量人力维护和支持。

　　程序框架部门。程序框架部门用于实现公用的一些组件，工具及相关SDK，比如服务端框架，技能框架，等等。当然这些需求应该大部分都是来自项目，所以技术人员应该参与到项目的研发中，然后再沉淀成通用化的产品，到第二个项目去迭代更新。可以根据游戏品类的不同，实现分开的多套方案与框架。等框架完善了，成熟了，后面产品的研发就大大减少了研发周期，而且由于框架经过几个产品的迭代，质量上也会有很好的保证。

　　工程效率部门。工程效率部是指那些可以提升研发效率，解决研发流程向的问题的部门。比如说CI/CD的搭建与实现，版本控制工具的二次开发工具，甚至一些自动化相关的测试与开发也可以放入该部门，比如自动化测试等。因为这些内容每个项目的需求都大同小异。

　　AI部门。游戏行业的AI应用其实很多， 比如：

　　游戏内容生产：用AI生成模型，生成贴图，优化动作；

　　自动化测试；

　　游戏AI：表现出更逼真，更拟人的NPC；

　　AI图形效果提升：AI实时光追, AI抗锯齿（DLSS)；

　　AI游戏运维与运营: 动态定价，动态游戏活动推广等；

　　AI在游戏行业的应用已经有不少国外的3A游戏公司和国内的大公司在尝试和研究。从最近几年的GDC来看，AI相关的讲座逐年增多，一年比一年火热。但是AI部门还是仅仅存在于大公司或者少量其他公司。也有可能是AI这一块人才不多，而且互联网公司的AI相关的职位也许更香。

　　游戏安全部门。游戏安全相关的人才真的是“屈指可数”，仅仅存在于大公司。所以放在中台用作通用加密，加壳软件的开发,外挂的防护及开展游戏安全相关的培训，增强其他工程师的安全意识等等。

　　其他部门。

　　杜绝避门造车，直面与项目组的冲突

　　作为技术中台，我一直提倡几乎所有的需求是需要来自前台项目，满足项目需求为出发点做研发，只允许一小部分在目前项目研发的前提下做前沿性的思考与预研，杜绝闭门造车。

　　其中很重要的一部分工作是要跟项目组有很深度的合作，以满足项目的需求为前提，来做日常性的工作安排。所以技术中台的相关人就需要进入项目，与前台人员一起进行深度的开发合作。合作初时，中台人员也许是进入了一个完全陌生的环境，困难重重，项目不熟，人不熟，其中的难点更多。以下是我之前碰到的一些问题：

　　1. 天然不信任感

　　不管是项目组还是技术中台部门，由于互相的不了解与一些信息的不对称，都会觉得对方的团队很弱（做技术的人有种天然的不服精神）。所以在合作过程中，互相挑战是难免的，刚开始的几次沟通，双方都会小心翼翼，互相质疑。另外对新进入的项目各种不熟悉，技术中台部门会小心翼翼地展开工作，生怕出了什么岔子，从而导致进度的推进不是很理想。

　　2. 绩效的不一致性

　　使用别人的方案和技术永远是被动的，如果你帮别人实现了方案，那么可能自然而然地认为这是别人的成果与业绩。主程或者技术总监很有可能觉得自己的团队没有什么输出和成果。所以在合作过程中，推行技术中台部门的方案存在着种种的阻力，即使方案可行，在执行过程中也存在着种种的隐性的延期与不配合。

　　3. 信息沟通的延时性与不全面

　　有些技术中台会存在远程支持，就是部门的人不跟项目组的坐一起，甚至异地支持（我们之前就有国外的技术人员支持上海这边的项目）。由于远程支持，有些信息在沟通的时候，难免对接不到位或者反馈延迟。因为你不能保证在沟通的时候对方会不会被其他事情打断，或者不知道对方是否能及时跟你沟通。又由于沟通不在同一地方，技术中台团队原以为很不错的方案，往往是项目组上次讨论抛弃的方案。

　　由于对项目本身了解的片面性，这种情况会经常出现。比如，我们之前在支持一个项目时讨论动画的优化方案时，我们尝试过各种方案，比如2D序列帧，动画烘焙到贴图上，GPU Instance+Skinning方案等等，由于项目需要拉近镜头，内存有限和支持opengl es2等原因，这种方案很自然地就被毙掉了。而且这些沟通的问题往往会导致你下一次合作的某个障碍。另外在远程沟通中，身体语言这一沟通中的重要一环缺失，在沟通的成效上会有不少的影响。

　　4. 决策的干扰因素过多

　　在项目组中支持，方案的决策是最难的，除非已经树立了技术权威，不然动了任何一方的内容都会有不少的反对。比如优化了一个地形，美术觉得，不行，这画质降得太厉害了。优化了一个动画，程序觉得不行，这内存增得太多了。

　　当然在不影响其他因素的情况下优化是最理想的，而往往游戏优化中会有各种权衡：画质和性能的权衡，内存和性能的权衡，研发时间和功能复杂度的权衡等等，鱼和熊掌不可兼得，有时候你不得不损坏一方利益去保证整体的效果。所以在方案的取舍过程中会有不少的干扰因素影响实施的推进。

　　5. 方案落地的困难

　　在支持的过程中，我们会提出各种方案及测试结果，但是在落地的过程中经常执行不到位。甚至一个测试的方案前前后后多次出现在讨论大会上，看似很简单的一个方案，却迟迟没有落地。因为项目组在研发的阶段，方案的执行人受其他任务的干扰比较大，由于执行人员会有“那是他们部门主导的任务，优先级不高”等类似的内心想法，方案的执行就很容易不被重视，从而导致延期甚至中止。

　　如何缓解冲突

　　1. 明确目的的重要性，并得到高层的支持

　　首先要跟工作室老大，项目制作人达成一致，明确我们这个支持工作的重要性。并且得到高层的强力支持。这样的话对进入项目支持的人的自信，和工作的开展都有很大的帮助。

　　2. 选择更好的合作方式

　　我是比较提倡中台的人跟前台项目组坐一起，或者靠近，有利于人员的沟通和融入项目的开发氛围。减少项目组的人帮你当做“外人”从而导致的各种不利。使中台的人完全成为项目的一份子，而不是遥不可及的专家。

　　3. 树立一个共同的目标与研发周期，利益捆绑

　　一定要明确共同的目标和研发周期，把前中台相关人的利益捆绑在一起，这样大家才会一心朝着共同目标努力。相关人员也更容易理清事情的优先级。为了大家的共同利益，更为了自己的成绩，一起努力。从而也为了防止出了问题而导致的互相甩锅的情况发生。另外工作的最终效果一定要体现在数据或者具体的内容上，一份报告，一次真机演示等等。比如优化，我们需要拿QA的客户端性能测试报告去衡量最终的效果。

　　4. 保持良好的私交

　　比如一起吃个饭，一起聊聊天，一起抽个烟等一切私底下的交好，都有助于我们在项目组中获得更好的支持，从而便于工作的开展。

　　5. 处理好前中台的利益分配

　　这一点真的很重要，很多人进入一个项目都是为了更多的奖金或者能够分到一点成功项目的红利。如果没有利益的驱动，对于中台的人员会少了很多激励与动力。有些公司的中台的人可能永远是一个固定的工资，比如16薪，那么对于他们努力不努力，在利益的回报上是差不多的，所以项目组的人也许还在加班加点赶进度，他们可能早早的下班回家了。

　　其他注意的问题

　　1. 如果是深入项目合作的人员，务必降低姿态，以一种服务的精神参与开发，把自己当作项目的成员。

　　2. 很多问题是问出来的，而不是前台主动反馈出来的。

　　3. 如果技术中台推行的不好，很容易就成为了一个人力外包的部门，前台部门发现人手不够或者进度来不及了，就跟技术中台要人，技术中台的人过去也就补充个人力，做着不利于技术中台的工作内容，然后又由于没有特殊的技术产出，前台又会觉得中台的作用也不过如此。所以该说不的时候就坚决说不，千万别偏离了自己的核心价值观与正确方向。

　　4. 多开展技术分享，调动大家分享技术与学习技术的热情，有助于在内部形成工程师文化的氛围，对于吸引人才，稳定人才也能起一个很好的辅助作用。