天美十二周年，Shadow与天美游戏的难忘故事

发表时间：2021-01-05 08:03:51 作者：编辑部 来源：游戏王国 浏览：次

在上一篇文章中，小编为您详细介绍了关于《蚂蚁庄园艳阳天大雪纷飞蚂蚁庄园今日答案12.18[多图]》相关知识。本篇中小编将再为您讲解标题天美十二周年，Shadow与天美游戏的难忘故事。

作者：Shadow
腾讯科技（深圳）有限公司天美J3工作室技术总监

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

大家好，我是Shadow，现任天美J3工作室技术总监，参与研发的《使命召唤手游（CoDM）》也将在这个月与大家见面。

有幸受邀答题，也希望借此机会，与大家分享这些年自己在天美的成长经历。

一、接触编程，为爱入“坑”

我的编程学习开始于很小的年纪，1995年，还在上小学的我有幸加入了计算机实验班，学习风靡一时的Logo语言。这使当时的我从中不光学到了编程的入门知识，也学到许多形象直观的几何知识。而这便是我与编程的起源。

因为在学校中学习的基础编程知识和因为游戏所得的编程方面的实践，2003年高中毕业后，我便很自然地选了软件工程专业，在大学中我还通过做一些web开发，小赚了一笔。因此2007年毕业之后自然还是选择继续走编程这条路，由于对游戏行业的热忱，进入比较知名的国内游戏厂商——西山居。参与了《剑网3》的工具组负责测试工具的开发工作。

二、“硬刚”难点，精进技术

2009年，整个游戏开发圈的氛围很好，许多工程师会在社区里分享自己的经验，甚至把自己的心得汇编成册，我也从中结识到许多优秀的同行，当时在社区上认识了一些腾讯的朋友，后来经推荐，于2011年加入了腾讯，进入了《逆战》（当时叫“T-game”）项目组。

在过往的经历中，我开发过测试工具，也做过Gameplay开发，加入腾讯时，由于想要尝试不同的领域，游戏引擎似乎是一个不错的方向。当时的leader告诉我：“项目组刚好缺一个做引擎和底层系统的工程师，你可以试试”。虽然这样的机会出现在了面前，但我内心十分忐忑——当时的我对Unreal（虚幻）引擎一无所知；然而最终我仍是决定硬着头皮，抓住这个机会。

利用正式入职前一个月在家的时间，我通过各种渠道将虚幻3引擎的源码翻来覆去地研究。面对困难，拖延和逃避最终只会让心态变糟，不如尽量提前做一些准备工作，会让自己更有底气。这样的习惯在我的工作实践中被证明是有用的。

起初，主要的困难还是来源于对引擎不够了解，而在团队里，每个人都有自己研究和专精的领域，可能只有我一个人负责引擎，所以只能拼命自学。尤记得接触游戏引擎的前半年，每天都会学到晚上11点半。不将当日的技术问题解决，是无法安心入睡的。每天思考的都是引擎相关的各种难题，许多解决方案也都是偶尔刷牙时灵光一现想到的。

2012年，入职半年之后，我对于虚幻3引擎已经有一定的熟悉程度，其他同事遇到的疑难杂症，比如性能优化问题、动态加载方案问题、内存控制问题，以及不明崩溃问题，都会找我寻求协助。而我通过这样的方式，也在不知不觉中实现了技术沉淀，掌握了大量引擎相关的一线技术，例如：如何优化引擎性能，如何架构引擎底层，如何实现一些特定特性等。

2012年，解决大规模怪物性能问题

初入T-game项目组，我帮助《逆战》解决了当时出现的内存膨胀问题。网游和单机游戏不同，单机游戏的资源总量往往是定好的，但网游会随着运营的深入而不断增加，例如：《逆战》起初可能只有200多种武器，但随着版本迭代，可能会出现500种武器，甚至上千种武器。当资源变多后，如果游戏内存没有提前规划清晰，就可能会出现崩溃现象。

针对这个问题，我们专门做了比较完善的内存加载控制的方案。当时的方案现在看来仍旧不够完美，但思路上已经是比较先进的了，也确实解决了《逆战》内存控制的问题。

回头来看，《逆战》这个项目对我有相当大的意义，在那几年个人的技术积累是非常快的，在思考层面上，也从原来比较粗暴的单纯解决问题，转化成为系统性思考。在长远的层面上，往更深度、底层的地方探索，追求更高的技术境界。

很多难题看似没有眉目，但当你拥有一套系统性的思考框架时，把每个小的细节放在这个框架下，通过一些端倪像侦探一样不断反推，可能就会找到突破口。

很多技术同学遇到问题会尝试网络上现有的解决方案，如果发现行不通，就会得出这个技术难题目前无法解决的结论，或者通过“规避”的方式，“绕过”技术问题。之所以这样，一方面是对困难有畏惧心理，另一方面思路依然锻炼不够，比较闭塞。我们要学会不仅要用自己现存的知识去推导，思维的广度与灵活度的边界还需要拓展。

要想拓宽边界，我认为需要通过解决一些看起来没法解决的问题才能实现。“硬刚”难点这个过程可能会很漫长，但很有价值。以《逆战》这个例子来说，查找问题原因可能花了1-2天的时间，但一旦想明白了，解决问题不过几分钟的事情。当这次迈过去了，以后同类的问题就再也难不倒自己。

有了系统性的思维和解决问题的经验后，在遇到问题时也会很镇定，相信自己一定能够解决，在解决问题时就会很有条理，不会慌张。

对一个20多岁的人来说，只要能把单一的问题解决好，可能就会在职场中获得一席之地。但对一个30多岁的人来说，一定要成为某个领域中的专家，在某个地方有很深的积累，才能继续在技术领域上做下去，否则越往后面走会越发困难。我在腾讯晋升速度算比较快的，可能与我一开始就想明白了这个问题有关，从一开始就把目光放得更长。

三、初领团队，攻研手游

2015年4月底，现在的leader邀请我参与《穿越火线》手游的制作，让我有了搭建客户端团队的机会, 2015年10月《穿越火线手游（CFM）》便正式上线。

这个速度现在看来依然是非常快的，在做《CFM》的时候，比起技术上的困难，更难的是如何根据当下需求组建出合适的团队。那时市场上没有成功的射击类手游案例，团队内大多数人也都没有成功的手游项目经验；所以大家面对的都是一个未知的领域。

2015年试验使用3Dtouth技术

当时我们花了不少时间从头制定各种方案，解决了很多比较核心的问题，比如自由移动射击游戏中网络同步的问题；高、中、低配机型的性能优化问题等；在《CFM》项目的后半阶段，我们在游戏内也做了各种各样的模式，比如“战术竞技”模式。

在做《CFM》的“战术竞技”模式时，由于J3工作室还没有技术美术（TA）同学，缺少次世代的制作经验，并且没有能够借鉴的同类型手游，因此我们使用了《CFM》的开发方式并借鉴了传统MMORPG的经验去实现玩法。其实，当时做的不是一个大世界的射击游戏，而是用MMORPG的技术去实现这种玩法。当时使用了很多“古老”的方式，例如：在大世界烘焙的阶段，我们经常会在场景美术同学旁边架起一张行军床，去解决一个个的问题，那时基本处于是通宵等版本的阶段，非常耗时耗力。

使用软件光栅化解决开放世界性能问题

我一直相信管理好一个团队，首先还是要去识别出不同的人才。只有知道每个员工适合做什么，特点是什么，才能把他们安排到恰当的岗位上，并促使他们去主动思考，给自己定下目标，向着这个目标进步。

我当时告诉团队的同学，每半年他们应该及时反思，自己完成了一项工作后，里面所采用的技术是否是业界领先的？做出的方案是不是最好的？是否对项目和对自己都有一个长期的技术布局？如果答案是肯定的，那么才说明你在这一阶段中，确实得到了提升。2016年，CFM已经开始实现PBR的制作管线：

国内最先使用PBR技术的手游团队

我在管理团队上一直会有意识地建立“二级梯队”——当一个团队越来越大，很难自己一个人把所有事情都管理的井井有条，这时候团队有同学主动站出来，帮助理顺整个团队。有的同学可能擅长管理Gameplay开发工作，有的同学可以管引擎和渲染方案，有的同学能够做好日常的系统，还有的同学可以解决一些疑难问题。这些同学需要自己有意识地做一些授权，让他们去多承担一些核心工作，这样他们会在这块领域中，做得越来越好，团队中的技术人才也就逐渐培养起来了。

其次，新加入团队的同学，一定要是和目前团队中的同学是不同的，这个不同可能是他拥有团队目前所没有的技术，也可能是他能够完成一些团队不擅长的事情，比如对外沟通等。这样团队才会变得更好。

如果团队招一个人只是为了提升一些工作量，那为什么不想想，是否可以通过更好的工作模式和效率工具，来提升工作量？一个团队的发展无论是思维模式上，还是工作产能上是一定会遇到瓶颈的，只有外面的新想法，才能打破一个圈子里的固有思维。

因此，从一个leader的层面而言，CFM对我意义也很大。在这个项目中，我学到了如何真正管理好一个团队，如何帮助大家成长。当时CFM团队培养出了一批技术人才，现在他们很多都在公司里面的不同项目中扮演着中坚的角色。

每个人都不可避免会有不了解的领域，多从身边的同学身上去学习，可以形成一个互相带动的良性氛围。

对团队而言，团队性学习可以避免知识盲区；对个人而言，团队性学习也同样有价值。团队内的每个人在各自负责的板块如果做到了业界顶尖，那么即使从团队内抽出来，他的能力也可以在业界中处于一个比较好的位置。

为了推行团队性学习，在每年年初，团队会订立引擎组的技术Roadmap，明确在这个阶段要实现什么，要达到怎样的目标。之后组员会在Roadmap的各个关键指标中，定义自己的目标，例如，我自己的探索方向，就是下一代CI的构建方案。

再比如虚幻引擎方面，就要先对引擎流程做梳理，然后对差异性打包，从各个方面思考，基于大的目标完成目标拆解。拆解出来之后，我们会用2-3周时间，确定出我们引擎组的Roadmap，之后就进入执行阶段。

当然引擎组的工作很多来源于项目的一些需求，我们会把项目需求跟Roadmap技术布局结合，分配到每一个人身上，之后确定优先级，确定每周的迭代。让大家有40%-50%的时间能做自己的技术研究，有60%的时间左右去支撑一些项目落地。

这样既能保证技术前沿的东西能得到研究和发展，也能保证所有项目都做得更好。同时，我们也会探索适合于中台团队的项目管理，或者说团队管理方式。

四、引领进步，使命召唤

《CFM》上线后，在2016年的上半年完成了《使命召唤手游（CoDM）》的DEMO，并帮助项目组的后续开发扩充了人力。直到2018年，这时项目在设计方向上有了一些变化，需要做相关的技术更新以确保游戏能顺利上线。

我18年重新回归CoDM项目组的时候，当时整个项目处于渲染方案、整体画面水平都需要做一定程度的更新。因为，和同时期的同类型游戏相比，如果画面上还处于相同水平，那么《使命召唤手游（CoDM）》将没有任何竞争力。既然《使命召唤手游（CoDM）》要在2019年上线，那么游戏的整个品质，包括画面呈现，甚至是手感，都要去升级，要做就把它做到业界里面最顶尖的水平。

我们当时学习了很多的技术方案，例如：渲染方案、PBR方案，以及GDC的技术分享等。

复刻主机级画面

作为技术人员，以前思考更多的是实现和满足玩法需求，对于品质、画面，制作管线上的理解会比较浅，只要采用人海战术能够实现玩法便算是解决了问题，完成了需求。但在《使命召唤手游（CoDM）》中，我们树立了明确的目标，要成为业界最好画面的手游。面对这样的命题，对于美术制作，技术美术（TA）和图形程序的要求当然会越来越高。

为了达到这一目标，我们开始研究使用的技术方案，对使命召唤在端游上的技术进行拆分。同时在PBR上，我们着眼于最先进的生产管线的打造。甚至在制作每一张贴图、每一张材质、每一个效果的时候，我们都会一起讨论，这是以前都没有出现过的。我们逐渐学习到了新的制作理念、逐渐改变了团队的研发方式。

不断探索新做法：多层地貌优化地形效果

在过往的游戏研发过程中，各个职位的同学是比较割裂的，游戏的研发是各职位同学各司其职完成各自的功能，最后融合产出一个玩法正确但是品质不高的游戏。早期的技术方案是某一个技术功能和技术点的实现，例如：为了满足游戏性能的需要，我们会要求美术将画面进行精简，直到能够符合性能的要求。这其实也就是采用“规避”的方式解决问题，问题虽然看似解决了，但实际上还存在，只是没有暴露出来。

而现在我们探讨更多的是管线和工具，我们的工作流应该是怎么样的。例如：哪些功能应该是由技术美术（TA）同学负责，TA跟美术同学的配合，画面精细程度，做Showcase的阶段、在不损害任何画质的基础上去优化性能等等。

程序化生成贯穿于整个制作流程

在研发《使命召唤手游（CoDM）》的过程中，也感受到了动视对游戏IP打造的认知，往往比腾讯更高，因此在合作中也会遇到各种困难需要解决。

CoDM的团队规模也是我第一次面对的，我们必须去面对大团队合作的问题。也正因此，通过项目的历练，整个思维方法，从技术性的思考方式，变成了更偏工程性的思考方式，也就是更关注项目整体的工作流和工具流，关注如何保证版本稳定，如何保证后续运营的代码更新量较少，这都是在技术思考中融入了产品和项目管理元素的体现。

CoDM的开发人数众多，在多人提交代码时，如何确保开发规范？测试更是达到了百人，如何通过一个可靠的机制将团队运作起来？全球各个地区版本发布如何进行？每个角色、每个人的任务、需求都不同，想把这些难题划分清楚，需要很可靠的项目管理模式。我们会定期开展晨会，确保各个模块的负责人能够定期交流，让信息在项目组内部流通起来；同时建立更“共通”的工作模式和流程，改变原本单人单点突破的原始生产模式。

我们甚至组建了一个“Unity联合团队”，设计了几个大的目标，大家朝着“业界顶尖”的目标去落实。后来用了前沿技术方案和Unity引擎上做结合的方案，对Unity底层的很多渲染方案进行了重写，打造出了如今《使命召唤手游（CoDM）》用的引擎。

经过《使命召唤手游（CoDM）》这个项目，我认为未来的一个趋势是，引擎组必将从1.0时代升级到2.0时代。

所谓1.0时代，就是每个项目组里实现的功能，都是无法复用的，更不用提中间件的概念，所有的东西都只是为了这个项目而服务，每次都等同于从零开始重新开发。团队之前遇到问题时，通常是靠不断增加人力，招纳优秀人才来解决。但这样的模式，对团队人才本身是没有好处的。人才从一个项目转移到另一个项目，其实没有根本性质的提升。1.0时代的引擎组就是支持项目，项目需要什么，我们做什么。为了改变这个现象，引擎组升级计划势在必行。

在整体引擎中台里面，我们为手游实现挺多令人兴奋的技术：

自研烘焙器提升画面效果

2.0时代，我们通过Roadmap牵引、OKR制度以及项目需求管理流程，让很多东西变得更加有体系化，而不是纯粹“打游击”。

在未来，引擎组的定位是介于大中台之间的小中台，其实是为了更好地服务项目，也会在不同的阶段去思考不同的工作方式。例如，在项目的攻坚阶段，引擎组可以做到全力支援项目组，在有限的时间内获得成功；而过了项目攻坚阶段后，我们会思考未来2-3年内应该做何种技术布局。

在特定游戏品类下，大的技术命题可能是较为主观的判断，但是较好把握。我们也会通过Roadmap制度的牵引，在组内去客观分析我们需要储备的技术能力，之后去提前布局与在项目中实践落地。

五、华丽转身，永远引领下一代产品

2020年，身份有了一定的变化，继续作为管理者负责引擎中台，也担任工作室下一代新项目制作人的角色。值得兴奋的是，团队能够抛开包袱使用下一代技术去完成一款产品，团队每天都在进步，每天都会因为一些新颖的feature的实现而尖叫，同时团队也在期待更多新人同学加入。

不知不觉来到天美已经接近九年，也遇到了很多才华横溢的同事，在思维的碰撞中得到了很多成长与启发。身为技术人，我感触最深的一点在于，我们不妨用一种产品的思维去客观看待整体，深入思考能够改进的地方。

比如个人成长上，可以把自己当成一个产品，设置一个长期目标，部署进度节点来检验自己的进步，倒逼自己成长；团队管理层面，可以从管理人员变成管理流程，优化工具和路径来提升效率；而在项目研运上，也可以跳出框架，思考是否存在让所有项目都能通用的技术方案，搭建一个成熟的引擎中台 ......

这并不容易，就像近年有句话说“多数人为了逃避真正的思考，愿意做任何事情”，但只有通过不断的反省和优化，我们才有可能进步，成为更理想的自己，这是我在天美学到的重要一课。

对于有志在游戏研发行业打拼的技术同学，我希望能努力共勉，《使命召唤手游（CoDM）》也随时欢迎充满热忱的人才加入。

有兴趣的同学可以发简历到邮箱：queentychen@tencent.com

来源：知乎
原文：https://www.zhihu.com/question/432832171/answer/1605176255

编后语：关于《天美十二周年，Shadow与天美游戏的难忘故事》关于知识就介绍到这里，希望本站内容能让您有所收获，如有疑问可跟帖留言，值班小编第一时间回复。下一篇内容是有关《幻书启世录异版是什么意思？异版和普通版幻书强度对比介绍[多图]》，感兴趣的同学可以点击进去看看。

资源转载网络，如有侵权联系删除。