声明：本文源自微信公众号《游戏葡萄》，作者修理，经站长之家授权转载发布。《明日方舟：终末地》（以下简称终末地）终于正式上线。作为鹰角历时六年多打造的全新旗舰作品，其意义非凡。无论是产品规格体量，还是全球多平台（PS5、PC及移动端）的发行策略，都实现了突破性的飞跃。正如游戏制作人海猫络合物在公测前瞻节目中所言：“从最初的构想到即将正式与大家见面，这条路并不算短，也谈不上轻松。”对于行业而言，作为曾开启新一代二次元手游内容范式的标杆，鹰角在面对当下时代命题所给出的这份答卷，市场究竟会做何反应，成为众人关注的焦点。一周前，终末地的全球预约人数突破3500万。在游戏的巨舰启航前的三次测试过程中，玩家们围绕美术表现、玩法设计和剧情演绎展开了热烈讨论。这些，正是大家过去提起鹰角这家公司时，最先映入脑海的几个关键词。然而，在葡萄君完整体验三测开放的所有内容后，我们最好奇也最感慨的部分，反而是技术——这或许是鹰角成立以来技术跨度最大的一次尝试。毕竟，2019年上线的《明日方舟》是一款2D游戏，项目成本相对3D游戏并不高，是当年二次元公司以小搏大的典型案例。没有多少人会觉得它在技术上有什么难以逾越的鸿沟。而到了终末地，无论是PBR与NPR的混合渲染实现，还是多角色同屏的视听逻辑；无论是无处不在的水体交互，还是完全动态的工厂基建……对一个多端大型3D游戏来说，都是相当严苛的技术考验。更何况，鹰角还需要在这个项目中，第一次尝试全球全平台同步发行。显然，在终末地各种显性内容的背后，鹰角的技术管线——这个对大多数玩家而言既不生动也不刺激、但却具有基石作用的模块，同样正处在高速迭代的状态中。为此，公测前夕，葡萄君与鹰角联合创始人&CEO hyf、以及CTO顾煜，进行了一次深入的技术专访。在交流过程中，我几乎没看出什么即将大功告成的兴奋，反而听到了不少关于取舍、痛苦以及“做得还不够”的复盘。一家二次元公司在跨越3D工业化门槛时，要付出多少代价？在这场对话中，他们没有炫耀太多黑科技，而是向我讲述了鹰角技术进化过程中的不同切面。以下对谈为方便阅读，内容经过整理和调整。
**跨越：始于稳健，终于自洽**
葡萄君：先聊聊终末地的技术选型吧，它有什么特殊之处吗？
hyf：它的特殊在于项目选择的方向，行业里鲜有人涉足。第一，同样是PBR和NPR结合的写实二次元，风格根据两者不同的配比，会很不一样。而基于我们自己的美术表现诉求，终末地要比市面上绝大部分同类游戏都更偏向写实，这意味着我们需要更精细的画面表现，以及将风格化的角色融入进更加写实的场景当中。第二，对于工厂玩法，我们会希望它能更偏沙盒化，让玩家除了在相对集中的区域里搭建流水线外，也能在世界中自由建造，并使用矿机、滑索、战斗辅助设施等等。第三，我们想做高内容密度的箱庭体验，也因此在地图中做了大量的可交互物和玩法设计。同时，我们在一开始就希望箱庭与箱庭之间能够无缝加载，实现更加顺畅的游戏体验——因为如果是“有缝”地图，就会阻断沙盒自由建造的沉浸体验，玩家就没法横跨地图去建造滑索和拉电线。这些方向所带来的性能负载，对技术团队提出了前所未有的挑战。
葡萄君：去挑战这些模块，对于鹰角的定位以及意义是什么？
hyf：首先一定是项目本身需要。其次，我们确实也希望积累3D产品开发经验，探索大规模研发流程管线，把公司的团队、管线、技术、工具储备等各方面，都往前推到行业头部的水平，为鹰角未来更进一步的3D项目“打个板”。
葡萄君：那为什么要继续使用Unity？而不是更加热门的虚幻引擎？
顾煜：终末地作为鹰角第一个3D大型项目，又有这么多新的技术挑战，所以选择鹰角此前已经有更多积累的Unity，风险会更加可控。其实公司也有一些新的项目在用UE，这个主要看整体规划。业内有一个共识，对于50人以内的项目来说，Unity非常友好，因为效率很高；100人项目则两边差不多，200人规模的团队，UE的工具链、管线和渲染效果会更适用一些。而对于终末地这个规模的项目而言，不论选择哪种引擎，都有非常多需要深度定制、改造、优化的部分，我们也是一开始就做好了要深度改造的打算，所以它们原生状态下的差距其实没那么重要。
hyf：就像刚刚说的，项目已经有很多巨大的挑战了，如果我们还要同时去尝试探索一个当时还不够熟悉的引擎，那相当于是把两个挑战叠加在一起了。而我的做事风格，倾向于选择更加偏向稳健、务实的做法。
葡萄君：听上去很保守，但从实际呈现来看，终末地给人的感觉还是很激进。
hyf：你的最终愿景可以远大，但你每个阶段性的目标得务实。比如刚才说的，我们虽然很早就想好最后要打通无缝箱庭地图，但技术测试的时候并没有直接把无缝端上来，而是先验证了箱庭玩法，觉得团队可以做，才去做了进一步的改造。
顾煜：项目的规模和野心，都是逐步增大的。我们并不想好高骛远，定一个达不到的目标。只是随着团队的成长，产品达到了更高的质量，大家自然就会想做得更好。
葡萄君：但这个“更好”应该有所限度？你们会怎么定位项目想要追求的品质标准？它要做到比当下所有产品都好吗？
hyf：虽然我是技术出身，但我不会单独去追求某个更高的技术指标、更高的质量标准，也不会盲目地用“技术局限性”为理由去简化一些策划需求，而是关注游戏有没有这个需要，或者说是否“自洽”。就像“写实”这个维度，并不是说要做到极致，才是最好的。比如我们要平衡项目特色的风格与气质，所以会在写实的服装材质上，去保留手绘笔触的处理。再比如说场景里小摆件、交互物的密度之所以很高，不是单纯说要比别的产品更多，而是因为写实风格的箱庭关卡不像开放世界有那么开阔的可探索区域，内容密度不够的话，玩家很容易觉得单调，进而撑不起游戏的沉浸感和可信度。另外一方面，像是我们工厂玩法里面有那么多建模精致、带有不同生产动画效果的建筑物，如果单纯考虑技术指标的合理性，我们应该去做简化，但由于游戏是越肩视角，当玩家走近一个建筑时，如果发现它的质量较低，就很容易出戏。所以我们做了一套比较复杂的分层机制。让玩家近看时，建筑的模型品质足够好，材质也能有一些半透明的高级效果，同时拉远后，画面又能简化到一个性能能够承载的状态。以上这些都是我们基于“自洽”逻辑而去攻克的技术课题，而这种对“自洽”的追求，我们只跟自己比。别人可能不是做不了，只是别人不需要这样做。
葡萄君：具体来说，这个“自洽”的标准是怎么定下来的？比如说PC和主机版的武陵城300万-500万的渲染面数，这是基于写实风格呈现的基础要求吗？
顾煜：行业常见的做法有两种，一种是正推，给出一个多边形的预算，同屏就只能这么多面，你不能超过它。这样性能是可控的，但就把压力给到了美术，他需要根据预算反复调整。另一种是反推，美术先做，然后程序再进行性能评估和优化。这个做法最大的好处是，效果可能会更好，因为性能并不是一个很简单的算术题，你多边形多一点，但结构、材质、光影可能更简单，那也可以超，程序来优化就行。但它的缺点在于，美术如果过于放开，可能会导致后期引来一波大的返工，就是程序怎么都优化不下来，你只能回头再减下去。我们折中的做法是，先给出一个比较宽松的正推指标，让美术开发有更大的自由度，同时在后期引入大量的性能测试调优，来解决性能热点，以此达到更好的效果。所以像300万-500万的数量级，是一个在研发过程中逐渐推敲出来的结果，而不是一开始确定的。
葡萄君：这其中的取舍是不是也涉及到性价比？可能某些部分做好了，玩家能很明显就感知到品质感。
hyf：有些东西是必须要达到一个很高的指标，比如说画面的渲染风格肯定是最显性的，它能直接抓住玩家的眼睛。但有些东西光是达到基础指标就已经很困难了，像终末地这样的工业化玩法和内容密度，要想达到和市面上第一梯队游戏一样的流畅度，得要付出更多的努力才行。终末地的雨水效果
葡萄君：以目前的标准来说，终末地称得上是下一代产品吗？
hyf：“代际”或者说“某个世代”这类概念其实最早主要源于主机市场，是在说面向下一代主机平台的作品。但在跨平台领域，这个词的定义很模糊，如果单独提可能会产生歧义。从鹰角自己的技术管线发展角度，对比《明日方舟》来说，终末地确实是一个在技术、视听体验上有着飞跃式进步的作品。
葡萄君：毕竟《明日方舟》还只是一个2D游戏。
hyf：其实严格来说，《明日方舟》不算是一个纯2D游戏，其中的罗德岛基建、关卡场景走的都是3D管线。鹰角创立之初，就有一个大的愿景，希望未来能做高品质的3D项目，于是《明日方舟》尝试了一些3D开发的环节，比如3D场景美术、TA（技术美术）、客户端开发、渲染引擎等等。通过这些模块，我们积累了很多可以衍生到大型3D游戏里的基本流程，也逐步验证和明确对于3D开发的一些认知，包括团队之间的磨合。这些都是很宝贵的经验。《明日方舟》阵痛：管线改动牵一发动全身
葡萄君：在整个研发过程中，终末地的开发卡点主要来自什么地方？
顾煜：有一个很大的卡点来自于组织大规模团队研发的管线流程。游戏开发与传统工业流水线有着本质的区别——每一个步骤都是不确定的，非常依赖于创作者的主观判断。像终末地这几年里做了很多技术改动，每一条都是牵一发而动全身的，都会对团队已有的工作造成冲击，甚至需要推翻重做。所以在外界看来，我们做出了一个品相不错的游戏产品，但在内部，我觉得对团队更有价值的是，我们打造了一整套全新的大型3D项目研发管线。有了这个基础，才能确保团队在未来可以持续产出高质量的内容。
葡萄君：有没有具体的例子？
顾煜：就拿宏山地图的竹林来说吧，它的多边形数量明显超标了。这就需要美术先要大致定一些基准，玩家在不同位置，不同的视角下能看见的东西有哪些。随后，技术团队需依据这些基准进行详细的数据采集:涵盖CPU与GPU的开销、贴图及显存内存的资源占用，以及不同算法模块的性能消耗。然后让关卡美术去调整布局，这又会倒推到更前面的步骤，我们要跟关卡策划商量，剧情发展里的竹林位置能不能变动。引擎和TA也没闲着，会去做很多底层优化，模型也会去做一些取巧的东西，比如说竹林的阴影不是由每棵竹子单独投出来的，而是做了一个专门用来的投影的遮罩（顶盖），这能节约很多性能。
葡萄君：这种技术与策划、美术的拉扯，一般最后听谁的？
hyf：可能传统情况下，大家会觉得这是一个双方拉锯的过程，技术同学比较保守，说这不能做，那不能做。但我们项目有一个特色，就是技术也想要挑战自己，所以最后可能变成双方互相推高要求…..
葡萄君：于是最后你们彻底改造了Unity底层引擎。
顾煜：这是一个愚公移山的过程。有几个大的触发因素，每次都导致一部分的重构和改造，两三年积累下来，就有非常多的成果了。第一是游戏玩法需求，从箱庭地图，到无缝箱庭地图，都需要对底层资源的加载、串流做改动；第二是性能需求，大规模的场景和工厂，需要各种引擎优化，来释放更多的CPU算力到玩法逻辑上；第三是渲染需求，这个就很好理解了，比如说光追和DLSS。另外，管线流程的落地工作，也会造成大量工作。以我们的多人协作美术管线为例，我们需要为复杂的地图编辑，引入多开发者并行工作的能力。本来关卡编辑制作就是非常复杂的，游戏研发的各种内容都在这个环节被整合起来，需要多工种协作。而引入并行工作能力，会让这个过程变得更为复杂，打一个不恰当的比方，多人在网页上共同编辑一篇长文的难度，远大于单人写一篇长文。我们即使有了心理准备，在实际开发中，依然遇到了很多问题。这部分工作，开始投入4人做前期研发，大半年后初步完成。然后我们投入了6人进行落地的尝试，并和美术、策划一起尝试用新的工具，修改流程中的卡点，花费了半年时间。最终我们又持续跟进内容制作人员的工作过程，找到影响效率的痛点，持续迭代改善工具，又花了半年时间。这些流程变革中的阵痛，源于技术迭代的固有周期。从功能实现到验证效果，往往是一个漫长的过程，期间还会伴随大量的反复与磨合。
葡萄君：这其中最难的部分是哪？
顾煜：技术的决策很难。你知道这个改动方向对项目一定有帮助，但你不知道有多大的帮助，它是否对得起它的代价。这需要我们做一个更前置的判断。很多时候，代价能一眼看到，但提升就说不定了，可能是15-20%，也可能只有3%。那如果是后者，我就会觉得不是很值得，因为付出代价的不只是技术团队，上下游的团队也要付出代价。对于落地的判断也很难，有时候某个技术同学卡住了，你没法确定他只是暂时性的，多给他两个礼拜就能搞定了，还是真的完全没办法了，需要给他调配更多的资源。
葡萄君：那你一般怎么做这个判断？
顾煜：这个得分情况来看了，针对一些关键技术点，如果真搞不定了，我们会有一个撤退方案。然后在这个过程中，我们会持续去做判断，每个礼拜讨论三四次，直到某个必须要做出决策的时间点。像之前的全面测试，其实还是有一些东西被砍掉了，比如说光照压缩技术，因为实在是做不完了。
葡萄君：想听听撤退方案。
hyf：一测的地图加载方式，就是二测无缝地图的撤退方案。就如果我们最后没能完成无缝这个技术挑战，那么终末地地图之间的关系，大概就会采用一测的方案了。所以我们的逻辑更多还是小步快跑，分阶段的去做事情。假如是要做一个开放世界项目，那么在第一个版本的时候，就得把无缝地图这个技术给搞定了。攻坚：从四人同屏战斗，到实时运算工厂
葡萄君：来说说几个核心玩法的挑战吧，感觉都不太容易，比如说四人小队同屏战斗。
顾煜：四人小队的难点主要在于性能分配，它意味着我们要给更多渲染的资源预算到角色上，这大大压缩了其他模块的资源，比如场景和特效等。此外，队友要有可信的表现，也是一个难点。比如队友如何在冒险中自然地和玩家对话、开玩笑，如何帮助玩家采集资源，在战斗中合理走位和释放技能，在箱庭中找到秘密并走过去提醒玩家，这里有非常多的细节，稍有不慎就很容易出戏。
hyf：另外四个人小队还涉及到另一个问题，就是画面重点的分配。比如说战斗特效很华丽，那么四个人的光污染就会乘以4倍，你根本看不清场景。那么我们就要在特效调度上，把主控角色和AI队友做出区别。我们还曾讨论过一个问题:跑图探索的时候，玩家的三个队友是在视野里，还是不在视野里面比较好?全部在视野里，你会觉得很乱;但长时间不在，又会觉得没有陪伴感。所以我们做了一套针对性的系统，让队友会时不时在你的视野里出现、既不会让你觉得平淡，又不会一直干扰你。前面提到了队友会自然地和玩家对话、开玩笑，其实在四人同屏的语境里面，我们有更多的空间去塑造多个角色之间的关系，所以还设计了很多队友间的对话。这个其实也是欧美3A游戏里面会涉及的，自然化的叙事方法。游戏里诸如此类的细节设计还有很多，它们未必是在技术上有多难实现，但它在工程里要怎么定下来，到底是多少比例，都需要一点点去调整。
葡萄君：基建玩法的挑战应该也不只是性能消耗吧。
顾煜：是的，还有服务器的压力。因为终末地的工厂在玩家离线状态时也在运算，服务器需要不停进行校验运算。一个32Core64G的服务器，在算复杂工厂时，可能只能同时算3000个玩家——每个玩家在线运算的服务器工厂节点平均可达到2000个以上。这个量非常大。所以如何在大规模和密集型的复杂状态机中获得更高的单机承载是我们主要解决的问题。针对这个问题，我们采用了内存复用和管理优化，事件聚合，Tick分级，GC优化，PGO优化等多种优化方式，将单机复杂工厂场景的稳定在线人数，从3000人提高到了4000人，单人每秒工厂核心的运算时间保持在1ms左右。
葡萄君：但玩家规模上来后，还能顶住吗？
顾煜：我们会对离线运算做分级，在玩家活跃期里会调用最高的运算频率，如果玩家几天没上线，就会用相对精简的频率去估算，以此推