Tim Sweeney终于在2025年的夏季对商用游戏引擎的优化问题做出了回应，但这份回应并没有令所有人满意。
电子游戏的优化问题在这几年间，几乎快要成为玩家社群内的常驻话题。从2023年采用Remedy自研Northlight引擎的《心灵杀手2》（Alan Wake 2），到采用UE5的《四海兄弟：故乡》（Mafia: The Old Country）等知名IP的最新续作或重制版，似乎都因为游戏的优化问题导致了一些口碑上的瑕疵。当然，也有一些游戏，像是《潜行者2：切尔诺贝利之心》（S.T.A.L.K.E.R. 2: Heart of Chornobyl），在经过了开发者的不懈努力下，终于将游戏修复到了“可玩”的程度，以及采用了id Tech 7引擎的《夺宝奇兵：古老之圈》（Indiana Jones and the Great Circle）在首发期间就保证了非常流畅的性能。但这些优化不错的产品，似乎并没有普遍让玩家社区感受到图像技术的进步。
即将推出的游戏正在对玩家的电脑配置提出更高的要求。采用Chrome Engine 6开发的《消逝的光芒：困兽》（Dying Light The Beast）在其配置要求里提到，若想在1440P分辨率中画质下，以60帧运行游戏，一张RTX 3070Ti或RX 6750XT显卡就成为了刚需；若想以高画质流畅运行游戏，就需要一张显存不少于12GB，并且能够支持各类智能抗锯齿，和多帧生成技术的“甜品级”显卡了。
通过民间的技术解析，我们能够大致了解到，Xbox Series X和PS5的理论硬件配置和RTX 3070以及RX 6750XT不相上下；而家用机相较该定位的显卡，有着容量更大，速度更快的显存。不过，即便如此，像是《黑神话：悟空》（Black Myth Wukong）在首发阶段，在基础版PS5主机上的表现还是呈现了口碑褒贬不一的态势。此后接连发生的，包括在家用机平台和中端PC平台上同时出现的游戏卡顿和掉帧问题；而且，许多优化还不错的新游戏，不论PC还是家用机，不论玩家怎么调整设置，画面上总是会留下一层无法消除的模糊感，这种诡异的观感也是玩家们普遍感受到新游戏缺乏优秀性能表现的原因之一。
所以，现代游戏到底出了什么问题，会让许多玩家明显感知到游戏的卡顿和掉帧？虽然这并非最完善的答案，但是好奇的社区还是从游戏引擎本身和开发者的工作流程中发掘出来了一些蛛丝马迹。
就拿最常被爆出优化问题的UE5来开刀吧。
不得不说，这是一款划时代的商用化游戏开发引擎。新的功能和技术能够让开发者更加自由地施展自己的想象力，扩大自己的创作空间。绝大多数稀奇古怪的视觉奇观和游戏机制，都能够通过UE开发者生态提供的海量资产，新的动画绑定工具、蓝图编程、协作系统等工具和技术实现；借助Lumen和Nanite，也可以在独家资源有限的前提下，生成极为惊人的游戏场景。
但是笔者在不止一个内容和社媒平台上看到过“UE5.3x/5.4x的开发处处是坑”的讨论。就像Microsoft Office和Adobe Creative Cloud这些生产力套件一样，一款游戏引擎内置的功能越多，其复杂程度就会不可避免地成倍增加。
以Nanite功能为例。在默认条件下，UE5对于Nanite物体生成有着相对比较严格的限制，比如物体的渲染面数上限、中远距离物体精细度优化等等。但如果仅仅采用UE5自带的优化措施，在一些强调长视距视觉奇观，或仅仅是为了让画面看上去更加丰富，开发者往往会将相关参数调成“1”，或直接解除渲染限制。这些都是UE5开发引擎中的功能，开发者可以自行决定是否开关或者进行修改。
但这就会直接暴露Nanite的底层问题。在早期的UE5版本中，Nanite虚拟几何体的每个网格的大致渲染时间是原生网格的两倍，并且在较高复杂度的场景下，Nanite下的部分几何体在远视距条件下依旧保持了完整的三角形数量，就会导致GPU需要去反复渲染那些可能已经在画面上已经无法分辨的极小物体或细节，平白无故浪费显卡的性能；而在使用引擎自带的LOD工具时，Nanite建模并不会按照“近大远小”的方式合并或堆叠面数，而是继续采用建模最细致的状态进行渲染。因此，如果在超长视距，且所有在视距内的Nanite模型都需要完整渲染的前提下，GPU仅是渲染出来画面内容就会非常吃力，此时就更不要提游戏是否能在更差的硬件条件下流畅运行的情况了。
即便Epic官方已经在新的UE5.6开发文档中承诺，和Nanite相关的问题已经进行了更大幅度的优化和错误修正，使得该功能可以在更低资源开销下实现其价值，但对于已经上市，且优化感人的UE5游戏来说，这些价值就变得无足轻重。
说到开发文档，这也是UE5和其他商用游戏引擎，经常被开发者诟病的关键环节。除了常见的文档版本跟不上目前最新版本的引擎之外，这些引擎的文档往往还散落在官方技术博客、开发演示、视频平台账号内容，甚至是代码库中的随机片段中，并且这些内容还缺乏索引。除此之外，一部分引擎文档的可读性对于理解程度不同的开发者造成了不小的困扰，一些功能缺乏直观的实例和demo教学，也会让部分开发者抓耳挠腮。
新的商用游戏引擎还有其他问题，就是对通用型上采样技术的滥用。这里指的就是TAA时间抗锯齿，和TAAU时间抗锯齿上采样。这些技术可以在原生分辨率降低的前提下执行抗锯齿或上采样的工作，用于抵消部分特效或建模优化时带来的屏幕闪烁问题。但TAA和TAAU的劣势在于，如果在开发中错误使用了这几种功能，或与其他超采样技术进行了错误的重叠，就会让运动中的画面增加一层诡异的油腻感和模糊感，这种观感在更低的原生分辨率下尤甚。这也正是近几年游戏的画面并没有随技术获得提升的关键原因。
虽然，当前的商业化游戏开发引擎有着这样那样的问题，不可否认的是，这些工具给了开发者极大的发挥空间，让他们能够随心所欲地开发他们想要开发的东西——尽管其中的学习过程很艰难。
而这，就牵扯出来一个非常主观的问题：开发者们是否正在利用这些强大的游戏引擎，开发者本不属于他们开发能力范畴的“超规模”游戏？并且，这不仅是针对个人开发者和小型开发团队，也是对顶级规模的大型开发团队发出的疑问。
在笔者接触到的开发者朋友中，有一种观点认为，当下的顶级游戏开发团队，已经走入了开发“超规模”游戏的陷阱中。顶级游戏的项目不仅极端复杂，牵扯部门和承包商数量极多，开发成本居高不下。然而，平心而论，当前顶级游戏不论在画面、特效、材质精度、美术、音乐方面并没有更加长足的进步，提升非常有限；这些游戏在玩法和机制上也没有让玩家眼前一亮的创新，只能凭借素材大量堆砌的视觉奇观，和光怪陆离的背景故事来刺激消费者的购买欲望。
当然，近期并不乏成功的“超规模”游戏：《光与影：33号远征队》（Clair Obscur: Expedition 33，以下简称“33远征队”）。一家33名员工中只有4名程序员，并且还要兼职关卡设计的小规模开发团队，创造了330万份销量，约4230万美元的商业成功。但若以悲观角度来看，从游戏媒体不断地对其报道，足以说明在“超规格”开发状态下，当前也只有《33远征队》这一款游戏达成了可能本不属于Sandfall Interactive的成就。
在更大规模的游戏能够获得更多的曝光，并因此能够增加预售和总体销量的可能下，我们至少不能否认的一种可能性是，不同规模的开发团队正在尝试，或已经开始开发属于各自领域的“超规模”游戏。现在还很难确定，这种情况是否正在成为游戏开发工业的常态，唯有时间能够给我们答案。
结合上文关于现代游戏开发引擎的讨论，另一种观点呼之欲出：随着游戏引擎抽象能力的不断提升，开发者在利用新引擎开发游戏时，自身积累的技术债务也在不断增加，随着开发流程的深入，如果开发者和开发团队在此前没有清理掉过往的技术债务，这些债务会在某个开发环节突然爆发，轻则拖延开发进度，重则直接拖垮整个项目；更不要提一个刚刚入门游戏开发的新人或爱好者，在对抽象程度如此高的现代游戏引擎没有太多认知的前提下开发游戏，其中遭遇的开发问题和优化问题，都将是阻挠新人开发者热情和项目进度的“老大难”。
这很难说。
如果开发团队能够清晰认识到利用现代游戏引擎积累的技术债务，那么只需要理清之前的问题和现象并逐个击破，那么在未来，团队就能更好地控制项目的整体规模，做好优化，开发出优质，扎实的游戏产品。
引擎开发方和大型游戏团队通力合作，在第三方用例中取得更多的实战经验，是屡试不爽的行业惯例。CDPR团队正在与Epic团队密切配合，在新的UE5.6基础之上，针对CDPR在《巫师4》（The Witcher IV）中遇到的问题进行特别优化，最大化引擎在该项目中的能力。
要么就是采用自研引擎，比如DICE的寒霜（Frostbite）引擎。虽然该引擎在像是《圣歌》（Anthem）这样的网游中不能很好地发挥作用——毕竟Bioware过往并没有使用寒霜进行开发的经验——但在DICE的手中却能让《战地6》（Battlefield 6）在更多跟不上时代的硬件上运行；并且，DICE也将游戏规模控制在了几个开发团队能够完全掌握的范围之内，这就使得游戏仅仅是在公开测试阶段，就体现出了超出玩家群体想像的扎实手感，和完善的《战地》游戏体验。
《天国：拯救2》（Kingdom Come Deliverance II）或许更聪明一点，采用了年代更久远的CryEngine进行开发。没有实时全局光照，没有虚拟几何体等现代技术，但战马工作室凭借对CryEngine的成熟运用，依旧让《天国：拯救2》的世界看起来生机勃勃。并且，若想让这款游戏以1440P中画质60帧运行，2021年推出的RTX 3060Ti显卡就能够满足这一条件。不过相应的，《天国：拯救2》对CPU和内存的要求稍高，但其实大多数玩家完全无需升级到指定的CPU和内存，也可以满足《天国：拯救2》的配置要求。
或者，如果真的想要随心所欲地开发游戏，“不依赖游戏引擎”也不是不可以。可能很多人不熟悉Noel Berry这个名字，但一定听过大名鼎鼎的《蔚蓝》（Celeste）。没错，《蔚蓝》没有直接使用任何高度集成的游戏引擎，而是通过传统的C#及其套件和运行库，配合开源的MonoGame游戏引擎、Blender建模工具，以及一系列低成本的音视效工具，在非Windows系统上实现了跨平台开发。
所以，如果你确实有一个非常绝妙的想法，也完全可以在不依赖特定的游戏引擎的前提下，产出惊艳之作。
（头图来源：Wallpaper Abyss）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。