为何游戏优化烂？#
经常玩游戏的水友应该有所体会，近两年很多游戏的优化可谓是烂到极致。
因为这两天我想进行独立游戏的开发，所以顺便搜了一下有关于优化方向的资料，这一篇文章，就和大家分享一下，为何游戏优化烂！
TL; DR#
因为游戏规模和引擎复杂度迅速膨胀，但开发者在赶工、依赖新技术和硬件兜底的心态下，往往没把持续优化当核心任务，导致硬件资源没吃满却依然卡顿。
当然如果真的只是这些，那我也不会单独写一篇文章了，我们先来定义一下，什么是优化差
优化#
帧数不高？
游戏卡顿？
网络差？
究竟什么是优化差？
瓶颈#
传统的 GPU 瓶颈，即显卡满载运行，成为帧率上限的决定因素。已不再是唯一，甚至不是最常见的性能问题，现代游戏的瓶颈呈现出多样化和隐蔽化的趋势。
单线程 CPU 瓶颈是其中最普遍的元凶之一。
尽管现代 CPU 拥有多个核心，但许多游戏引擎的核心逻辑循环，如物理计算、AI 决策、资源管理以及向 GPU 提交渲染指令（Draw Calls）等关键任务，仍然高度依赖于一个主线程或渲染线程。
任务管理器的 CPU 总体使用率是一个具有欺骗性的指标，因为它平均了所有核心的负载。如果这个关键的单线程在其分配的核心上达到 100% 的利用率，那么整个游戏管线就会被迫等待，无论其他核心多么空闲。
这就好比一条拥有八车道的高速公路，其中一条车道发生了严重堵塞，即便其他七条车道畅通无阻，整条公路的通行效率依然会急剧下降。最终反映在监控数据上，就是 CPU 总体占用率不高（例如 25%），但游戏帧率已达上限，并伴随因指令提交不及时而产生的卡顿。
内存与缓存延迟是另一个潜在的性能杀手。
游戏的流畅运行依赖于数据在不同存储层级间的高效流转，包括系统内存（RAM）、CPU 的多级缓存（L1, L2, L3）以及显存（VRAM）。
如果数据无法及时送达处理器，CPU 和 GPU 就会进入等待状态，产生空闲周期，从而导致性能下降和卡顿。
例如，玩家未在 BIOS 中开启内存的 XMP（Extreme Memory Profile），导致内存运行在远低于其标称的频率上，或者游戏代码本身的数据访问模式效率低下，都会造成这种瓶颈。
I/O 与存储瓶颈同样不容忽视。
随着游戏世界日益庞大和精细，实时从硬盘（HDD）、固态硬盘（SSD）中读取海量纹理、模型等资源的能力，直接影响着游戏体验，这一点在开放世界游戏中尤为突出，存储设备的读写速度成为决定游戏能否无缝加载新区域的关键。
遍历性卡顿#
遍历性卡顿（Traversal Stutter）是沙盒开放世界或半开放世界游戏中一种极为常见的问题。
当玩家在游戏世界中快速移动，从一个区域进入另一个区域时，游戏画面发生的短暂冻结或明显的帧率骤降便是遍历性卡顿。
从技术上讲，这种卡顿的根源在于游戏引擎的关卡流式传输（Level Streaming）或世界分区（World Partition）系统。
为了在有限的内存中容纳庞大的游戏世界，引擎并不会一次性将所有地图资源加载进来，而是根据玩家的位置动态地从存储设备中加载即将进入区域的资源，并卸载已经远离的区域。
当这个加载过程不够迅速，或者与游戏主线程发生了冲突，导致渲染管线需要等待必要的资源（如高分辨率纹理、复杂的几何模型或关键的脚本数据）就位时，遍历性卡顿便会发生。
（有一说一我遇见过最严重的就是星空，捏脸的时候改个数据就卡一下，只能说真的厉害）
着色器编译#
在所有类型的卡顿中，由着色器编译（Shader Compilation）引发的卡顿或许是最令 PC 玩家困扰的一种，因为它几乎与硬件性能无关，即使在最顶级的 PC 上也会发生。
着色器是运行在 GPU 上的一系列小程序，它们负责定义游戏中所有物体表面的最终外观，包括颜色、光照、阴影、反射、透明度等 。而编译则是将开发者编写的高级着色器代码（如 HLSL）转换成特定 GPU 能够直接执行的底层机器码的过程。
问题的核心在于 PC 与主机平台在硬件架构上的巨大差异。
游戏主机（如 PlayStation 5 或 Xbox Series X/S）拥有固定且统一的硬件规格。
开发者可以在游戏开发阶段就针对这唯一的GPU型号，将所有需要的着色器预先编译好，并将这些编译完成的机器码直接打包进游戏本体中。
玩家下载游戏后，GPU可以直接运行这些现成的代码，不存在运行时编译的需求。
然而，PC平台则完全不同。市面上存在着来自 NVIDIA、AMD、Intel 三家厂商，跨越多个世代，数以千计的不同型号的 GPU，每一种都有其独特的指令集。
为某一款 NVIDIA GPU 编译的着色器机器码无法在 AMD 的 GPU 上运行。因此，PC 游戏不能直接分发最终的机器码，而是携带一种中间形态的、平台无关的字节码（Bytecode）。
当玩家在自己的电脑上运行游戏时，显卡驱动程序需要实时地将这些字节码翻译成当前 GPU 能够理解的机器码。这个翻译过程，就是着色器编译。
（关于机器码和字节码，我觉得各位水友应该能理解🤔）
除此之外，在旧的图形 API（如DirectX 11）时代，大部分编译工作由驱动程序在后台尝试管理，但效率不高。
而 DirectX 12 和 Vulkan 等现代 API 为了追求更高的效率和更底层的硬件控制，将着色器编译的管理责任更多地交还给了游戏开发者。
开发者需要通过一种名为管线状态对象（Pipeline State Object, PSO）的机制，提前告知驱动程序即将需要哪些着色器和渲染状态的组合。
如果开发者没有在游戏加载界面等合适的时机，通过预缓存（Pre-caching）机制，将游戏中可能用到的所有 PSO 都提前编译好，那么当游戏进行中首次遇到一个新的特效、一个新的敌人或一个新的场景时，引擎就只能向驱动程序请求编译，这个过程会阻塞整个渲染管线，导致长达数十甚至数百毫秒的停顿，从而引发一次剧烈且无法避免的卡顿。
（木卫四协议应该是比较有名的，还有编辑配置文件开启预加载，也是真的厉害）
惯坏了厂家#
单线程瓶颈、遍历性卡顿和着色器编译这三类问题，表面上看是孤立的技术故障，但深究其根源，它们共同指向了一个更大的问题。
现代 PC 游戏开发流程中普遍存在的主机中心问题。
这些问题（单线程瓶颈、遍历性卡顿和着色器编译）之所以在 PC 上集中爆发，恰恰是因为它们都触及了 PC 与主机在核心架构上的根本性差异。
游戏的核心工程决策、系统架构和性能目标都是围绕主机的固定范式建立的，PC 平台特有的硬件多样性、驱动复杂性、API管理责任，则在开发过程中被低估、资源投入不足，或被推迟到开发周期的末尾才仓促应对。
由于PC版本在发售时常带有根本性的技术缺陷，开发者越来越依赖于发售后通过补丁来亡羊补牢。
这种模式逐渐常态化，使得发布技术上未完成的游戏成为一种可接受的商业行为，这不仅将质量保证的责任从开发工作室转移给了付费玩家，也进一步强化了外界对于 PC 优化是低优先级事项的认知。
这种状况进而催生了一个恶性循环，最终导致了当前 PC 游戏优化水平普遍下降的局面。
所以，什么是优化差？#
虽然很难一言蔽之，但是我们可以将，突然的卡顿，对硬件的不当使用行为，统称为优化不佳。换句话说，当 CPU/GPU 占用率很低的同时，游戏非常的卡，就可以算是优化差。
当然，这里并没有讨论联机游戏的优化问题，其实很多时候联机的优化差并不是因为土豆服务器，而是因为客户端与服务器端的连接逻辑有问题。
Unreal Engine 5#
UE5，的两大核心技术，Nanite 虚拟化几何体和 Lumen 动态全局光照与反射，为游戏开发者描绘了一幅前所未有的、接近电影级CG画质的蓝图。
然而，这场视觉盛宴的背后，是巨大的性能开销。UE5 在推动行业进步的同时，也从根本上改变了性能与画质的平衡点。
（虽然这一切 UE5 可能只是个必定的产品，或者因为我主要知道的影响画面的游戏引擎是 UE5，但不得不说它作为高质量画质的、一大有名的游戏引擎，可以单独拉出来说说）
Nanite#
Nanite的核心理念是解决长期困扰游戏美术师的多边形预算问题。
在传统流程中，美术师需要为同一个模型手动创建多个不同精细度的版本，即细节层次（Level of Detail, LOD），以确保远处的物体不会因为渲染过多的、肉眼无法分辨的细节而浪费性能。
Nanite 通过其虚拟化微多边形几何体系统，实现了这一过程的自动化和智能化。
它能够实时地、以像素级的精度渲染海量的几何细节，只处理摄像机能够感知到的部分，从而理论上允许开发者直接使用影视级的、拥有数百万甚至数千万多边形的模型，极大地解放了艺术创作力，并节省了大量的 LOD 制作时间。
然而，Nanite 的强大功能并非没有代价。
它并非一个免费的性能优化工具，而是引入了一套全新的渲染管线，这套管线本身就存在着不可忽视的基准性能开销。
各种测试已经随处可见，对于那些已经通过传统 LOD 方法进行了良好优化的场景，或者由大量低多边形实例构成的场景，强行启用 Nanite 有时反而会导致性能下降。
Nanite 的优势在于处理极端复杂的、前所未有的几何密度，但在中低复杂度的场景下，其固有的管理和调度开销可能会超过传统渲染方法的效率。
此外，当前版本的 Nanite 仍存在诸多技术限制。例如，它对骨骼动画网格（Skeletal Mesh）的支持仍处于实验阶段，对透明、半透明等特定材质类型不兼容，并且其高效的流式数据加载能力高度依赖于高速 SSD 作为存储介质。
这意味着开发者在使用 Nanite 时必须理解其适用范围，并不能将其视为解决所有几何渲染问题的万金油。
Lumen#
Lumen 是 UE5 的另一大支柱，它是一个全动态的全局光照（Global Illumination, GI）和反射系统。
在 Lumen 出现之前，游戏中的间接光照（即光线在物体表面多次反弹形成的环境光）大多需要通过烘焙（Baking）的方式预先计算并存储在光照贴图中。这种方法虽然高效，但完全是静态的，无法响应场景中的任何动态变化。
Lumen 彻底改变了这一点，它能够实时计算光线的无限次反弹，产生高度逼真的色彩溢出、柔和阴影和环境光遮蔽效果，使得动态光源、可破坏环境和动态时间变化下的光照表现达到了前所未有的真实感（取自 UE5 宣传语）。
根据 Epic Games 官方发布的技术文档，Lumen 的性能目标从设计之初就锚定了次世代游戏主机（PS5, Xbox Series X/S），其目标是在这些主机上以 30 FPS 或 60 FPS 运行，但其内部渲染分辨率仅为 1080p。
最终输出4K画面则严重依赖于引擎内置的时间超级分辨率技术（Temporal Super Resolution, TSR）进行升频 。
（换句话说，PS4 Pro 开始就在狂推的 4K，到今年已经快 10 年了，结果我们还在体验原生 1080p 🤣）
为了在不同硬件上提供可伸缩的性能，Lumen 提供了两种主要的光线追踪模式。
软件光线追踪（Software Ray Tracing）是默认选项，它不依赖于显卡的光追核心，而是利用距离场（Distance Fields）来近似计算，速度更快，但精度和质量相对较低。
硬件光线追踪（Hardware Ray Tracing）则利用现代 GPU（如 NVIDIA RTX 和 AMD RDNA2+ 系列）的专用光追单元，能够提供更精确、更高质量的光照和反射效果，但性能开销也随之剧增，并且对场景的复杂度和物体遮挡关系极为敏感。
超分#
将 Nanite 和 Lumen 综合来看，要在主流的高分辨率（如 1440p 或 4K）下，以流畅的帧率（60 FPS 以上）运行一款同时开启这两大核心功能的 UE5 游戏，Upscaling 技术已从一个可选项，演变成了一个事实上的必需品 。
那么，在追求顶级画质的道路上，死磕原生分辨率性能是错的吗？更明智的选择真的是充分利用引擎内置的、以超分为导向的先进功能吗？
DLSS / FSR#
超分，或者说 Upscaling 技术，特别是 NVIDIA 的 DLSS 和 AMD 的 FSR，已成为现代 PC 游戏领域一个无法回避的话题。
这项技术究竟是弥补优化不足的拐杖，还是驱动下一代图形技术发展的必要核心？
必需品#
超分技术的定位在短短几年内发生了根本性的转变。在早期，DLSS 和 FSR 被普遍视为一种性能增强工具，主要面向那些使用中低端或老旧硬件的玩家，帮助他们在可接受的画质下获得更流畅的帧率。
然而，随着游戏图形复杂度的爆炸式增长，尤其是在光线追踪等技术普及之后，超分技术的角色已悄然改变。
如今，即便是拥有顶级硬件的玩家，也发现在许多新发售的3A大作中，开启超分几乎是获得理想体验的唯一途径。
这种转变也并非偶然，而是有意为之的设计选择，越来越多的游戏在开发阶段就将超分进技术纳入了性能考量的基准线。
例如，《遗迹2》（Remnant 2）的开发 Gunfire Games 就曾公开表示，他们在设计游戏时就已经考虑到了升频技术的运用。
这意味着，游戏的性能目标不再是原生分辨率下的 60 FPS，而是在开启 DLSS/FSR 质量模式下的 60 FPS。
这种设计理念的转变，标志着超分技术已经从一个辅助功能，正式升级为现代游戏渲染管线中一个不可或缺的核心组件。
现实#
理想很好，然而现实很骨感。在玩家社群中，一个普遍且强烈的观点是，超分技术正在被开发者滥用，成为掩盖糟糕优化的遮羞布 。
开发者不再需要投入大量时间和资源去进行艰苦的底层优化，以确保游戏在原生分辨率下流畅运行，他们只需简单地集成 DLSS 或 FSR，然后将性能达标的责任推给这些技术 。
尽管技术宣传中常强调超分技术能在几乎没有画质损失的情况下提升性能，但实际体验却截然相反。
尤其是在动态画面中，超分技术固有的视觉瑕疵会变得尤为明显。
- 动态伪影与鬼影：在高速运动的物体边缘，尤其是在复杂的背景前，超分算法常常难以完美重建图像，导致出现明显的鬼影（Ghosting）或拖影。这种现象在许多游戏中都存在，严重破坏了画面的稳定性和沉浸感。
- 细节丢失与模糊感：超分的本质是从有限的像素信息中猜测出高分辨率图像。这个过程不可避免地会导致细节的丢失或错误重建，尤其是在精细的纹理（如织物、栅栏）上，会产生一种不自然的闪烁。开启超分后的画面，尤其是在 1080p 和 1440p 这些主流分辨率下，会呈现出一种模糊或油画感，远不如原生分辨率那样清晰锐利。
因此，对许多玩家而言，超分技术提供的并非免费的午餐，而是一场用画质和操控响应换取帧率的浮士德式交易。他们并未获得更好的画面，而是被迫在一个充满视觉瑕疵的画面和一个卡顿到无法游玩的画面之间做出选择。
（DLSS 4 虽然有改善，但是对于拿 DLSS 得到的帧数算为“算力升级”……还是太厉害了！）
人#
不管是玩游戏还是做游戏，说到底终究是人在玩人在做。PC 游戏优化问题的根源，最终可以追溯到 3A 游戏产业的经济结构和生产模式。
玩家在屏幕上体验到的技术缺陷，往往是开发过程中一系列因经济和排期压力而做出的妥协与权衡的最终体现。
成本#
现代3A游戏的开发，已经演变成一场规模堪比好莱坞大片的豪赌。
曾几何时，一款 3A 游戏的开发预算在 5000 万至 1.5 亿美元之间已属惊人。
而如今，2 亿至 3 亿美元的预算已成常态，若将市场营销费用计算在内，顶级项目的总成本甚至可以轻松突破 5 亿，乃至接近 10 亿美元。
如此巨大的前期投入，给发行商和投资者带来了难以想象的财务压力。
游戏的发布日期不再仅仅是一个技术问题，而是一个与公司财报季度、节假日销售旺季和市场营销计划紧密绑定的商业决策。任何延期都可能引发股价波动和巨大的经济损失。
在这种不惜一切代价按时发售的指令下，游戏的技术完备度往往要为商业时间表让路。
（什么？跳票？可想而知产品规划的有多垃圾，这就是从营销到开发部门没有连通，是一个公司从根本的漏洞，这种公司做出来的东西，除了是一坨之外还能是什么呢？）
压榨#
当开发时间表与项目实际所需时间发生冲突时，压榨（Crunch）便应运而生。
在游戏行业中，压榨特指在项目后期，为了赶上最后期限而进行的强制性、长时间的加班工作。这是一种被行业默许甚至常态化的做法，员工每周工作80-100小时的情况并不少见。
长时间的压榨对游戏质量的损害是直接且致命的。当然，我们只讨论优化，所以不论一个游戏好玩与否。
性能优化是一个需要耐心和精细操作的系统性工程。它要求开发者通过专业的性能分析工具，定位性能瓶颈，然后重构代码、调整算法或优化资源。
在一个以压榨为主旋律、以实现功能为最高优先级的开发周期中，这种耗时的深度优化工作几乎总是被推迟到项目的最后阶段。
而到了那个时候，通常已经没有足够的时间、精力和资源去妥善处理。
更重要的是，许多深层次的性能问题根植于项目的早期架构决策，若要修复，可能需要对核心系统进行大规模重写，这在游戏发售前几周是完全不可能实现的。
垃圾！#
一款优化不佳的3A游戏，其根源往往并非简单的技术妥协，而是一个公司从产品规划到最终交付的全方位、系统性的失能。
当市场营销部门与开发部门之间存在巨大的鸿沟，当产品规划本身就建立在不切实际的幻想之上时，最终交付给玩家的，除了是一个技术上千疮百孔的半成品之外，还能是什么呢？
这个失败的链条始于产品规划阶段，市场部门基于概念图和早期演示，向公众和投资者兜售一个宏大而完美的愿景，并以此为基础定下不容动摇的发布日期。
然而，这个愿景往往与开发团队的实际生产能力严重脱节，开发团队被迫接受一个从一开始就注定无法在规定时间和预算内高质量完成的项目范围。这并非雄心壮志，而是一种源于高层决策的、制度性的规划失败。
随着开发深入，最初规划的漏洞开始暴露，技术难题和范围蔓延不断的累积技术债务。但由于发布日期与公司的财务报表紧密挂钩，延期几乎是不可能的选项。
于是，整个开发团队被推入压榨的深渊，其工作重心不再是创造一个伟大的游戏，而是不惜一切代价地拼凑出一个可交付的产品。在这个过程中，性能优化，尤其是针对复杂 PC 平台的深度优化，这种耗时且在营销宣传中没有用的工作，理所当然地成为了最先被牺牲的祭品。
因此，玩家在发售日拿到的游戏，正是这种公司内部失调的公开展示。它是一个被营销过度包装、被不切实际的规划所扭曲的产物。
它在功能上或许勉强完整，但在技术质量上却是一个彻头彻尾的未完成品。所谓的首日补丁和后续更新，不过是将本应由公司承担的质量保证责任，转嫁给了已经付费的玩家而已。
当前的商业模式，尤其是预购 + 在线服务，非但没有惩罚这种行为，反而为其提供了温床。比如圣歌，发行商可以在游戏的真实技术状况被揭露之前，通过预购锁定绝大部分收入。
而未来会修复的空洞承诺，则成了安抚玩家情绪的常规公关手段，谁知道会不会关服呢？
这种模式使得公司无需为产品规划的失败和开发过程的管理混乱承担直接的、即时的后果。整个系统在财务上不仅容忍，甚至在变相鼓励这种从根源上就存在漏洞的公司，持续不断地向市场输出赛博垃圾。
结语#
优化不好，它永远不应该是玩家看到游戏后的第一反应。游戏注重的是好玩，如果连优化不好这个议题都能被端上来，那么可想而知如今的游戏有多么糟糕。
画面美术永远是加分项，当年在 8 位机上能玩到的游戏，可以没日没夜的游玩，真的是画面表现好吗？星际拓荒卡通的风格，却能被大量玩家一致好评，真的是画面表现好吗？
游戏，好玩才是一切。
（优化应该在立项的时候就开始，可能很多人都认为这应该是最后的工作，实际上一旦开始，之后的优化将无法简单靠补丁解决，类似僵毁，EFT 等）