企业官网建设流程全解析

1. 暂停游戏不只是按个P键那么简单

很多人第一次在虚幻引擎里做暂停功能，脑子里想的就是“按P调用SetGamePaused，完事”。我当初也这么以为，直到在一个动作项目里被暂停功能反复折磨了整整两天，才发现这件事远比想象中复杂。暂停游戏这个需求，表面上看是让游戏世界停下来，实际上它牵扯到时间膨胀、输入模式切换、UI焦点管理、网络同步、音频处理、动画状态机冻结等一连串连锁反应。你按下的那一下暂停键，背后是整个引擎运行时状态的一次集体切换。

这篇文章面向的是已经能跑通基础蓝图或C++逻辑、准备把暂停功能做扎实的虚幻引擎开发者。不管你是做单机动作游戏、解谜游戏，还是带暂停菜单的多人联机项目，这里面的坑你大概率都会遇到。我会从暂停的底层机制讲起，把SetGamePaused到底做了什么、为什么有些东西暂停了有些没暂停、暂停菜单怎么做才不会出现鼠标丢失或按钮点不动的问题，一步步拆开讲清楚。核心关键词就一个：虚幻引擎暂停游戏，但围绕它的每一个细节，我都会给你能直接抄作业的方案。

先说一个反直觉的结论：SetGamePaused(true)并不会让所有东西停下来。很多新手以为调用了这个函数，整个世界就冻结了，结果发现粒子还在飘、音频还在响、某些Actor的Tick还在跑。这不是引擎有bug，而是你对“暂停”这个概念的理解和引擎的实现之间有偏差。虚幻引擎的暂停，本质上是把游戏世界的时间膨胀（Time Dilation）设为极低值，同时暂停部分Tick逻辑，但它对不同类型的对象、不同的Tick组、不同的网络角色，处理方式是不一样的。理解这一点，是做好暂停功能的前提。

我在实际项目里见过太多暂停功能的翻车现场：暂停后鼠标出不来、暂停菜单的按钮点不了、恢复游戏后角色瞬移、联机时一个玩家暂停导致所有人卡住、暂停时背景音乐还在嗨。这些问题单独看都不难解决，但它们背后的原因各不相同，需要你分别从输入系统、UI框架、时间管理、网络架构几个维度去处理。接下来的内容，我会按照“先搞懂机制，再动手实现，最后处理边界情况”的顺序，把暂停游戏这件事彻底讲透。

2. SetGamePaused背后到底发生了什么

2.1 时间膨胀与Tick组的双重控制

要理解虚幻引擎的暂停机制，你得先知道引擎是怎么管理“时间”的。虚幻引擎里有一个全局的时间膨胀系数，默认是1.0，代表正常速度。当你调用UGameplayStatics::SetGamePaused(WorldContextObject, true)时，引擎会把这个世界的时间膨胀设成一个极小的值（不是0，而是一个接近0的数），同时把bIsPaused标志置为true。这个极小值的存在意味着时间并没有完全停止，只是慢到几乎察觉不到，这样做的目的是避免某些依赖时间计算的逻辑出现除零或死循环。

但光有时间膨胀还不够。虚幻引擎的Actor Tick是按照Tick组（Tick Group）来组织的，不同的Tick组在帧循环的不同阶段执行。暂停时，引擎会跳过大部分Tick组的执行，但并不是所有。比如TG_PrePhysics和TG_DuringPhysics这些组会被暂停，但某些标记为bTickEvenWhenPaused的Actor仍然会继续Tick。这就是为什么你暂停游戏后，某些东西还在动——它们要么设置了暂停时仍然Tick，要么根本不受时间膨胀影响。

这里有个关键点：时间膨胀影响的是DeltaTime，而Tick是否执行是另一回事。一个Actor如果Tick还在跑，但DeltaTime接近0，它的逻辑虽然执行了，但基于时间的位移、插值、动画推进都会几乎停滞。可如果这个Actor的逻辑不依赖DeltaTime，比如它每帧直接设置位置，那它看起来就还在动。理解这个区别，你就能判断哪些东西该在暂停时手动处理。

2.2 为什么音频和粒子系统常常“不听话”

音频组件在暂停时的行为，是新手最容易困惑的地方之一。默认情况下，UAudioComponent在游戏暂停时不会自动暂停，因为音频系统有自己独立的时间管理。你暂停了游戏，背景音乐还在放，音效还在响，这在很多场景下是不合理的。解决办法是给音频组件设置bIsUISound或者手动在暂停时调用SetPaused。但更优雅的做法是使用音频混合器（Audio Mixer）的暂停功能，或者通过UGameplayStatics::SetGlobalPaused配合音频类的自定义逻辑。

粒子系统的情况类似。UParticleSystemComponent和Niagara组件默认会受时间膨胀影响，但因为它们的更新逻辑可能挂在不同的Tick组上，实际表现会有差异。我实测下来，Niagara在暂停时的表现比老粒子系统更可控，因为它的Tick依赖DeltaTime更纯粹。如果你发现暂停后粒子还在飘，先检查它的Tick组设置，再确认它的更新是否依赖了不受暂停影响的时间源。

2.3 网络环境下的暂停是个伪命题

如果你做的是多人联机游戏，那“暂停游戏”这个概念本身就需要重新定义。在客户端-服务器架构下，服务器是不会因为你一个客户端暂停就停下来的。SetGamePaused在联机环境里的行为是本地暂停，也就是说只有调用它的那个客户端会暂停，服务器和其他客户端照常运行。这在合作游戏里会导致严重的问题：你暂停了，但队友还在动，怪物还在打你。

正确的做法是区分单机暂停和联机暂停菜单。单机游戏可以直接暂停整个世界；联机游戏通常只暂停输入和本地UI，游戏世界继续运行，或者由服务器统一决定是否暂停（比如所有玩家都打开菜单时才暂停）。我在一个合作项目里就踩过这个坑，最初直接调用了SetGamePaused，结果测试时发现暂停的玩家角色站在原地挨打，因为服务器根本没停。后来改成只暂停本地输入和显示菜单，游戏逻辑继续跑，问题才解决。

3. 从零搭建一个靠谱的暂停系统

3.1 输入模式切换：别让鼠标成为你的噩梦

暂停菜单做出来之后，第一个要解决的问题就是鼠标。游戏进行时，你可能用的是GameOnly输入模式，鼠标被锁定在游戏窗口里。暂停后要显示菜单，就得切换到GameAndUI或UIOnly模式，让鼠标能自由移动去点击按钮。这个切换如果没做好，就会出现鼠标看不见、点不到按钮、或者菜单关了之后鼠标还在的情况。

具体操作是在暂停时调用PC->SetInputMode(FInputModeGameAndUI())，并设置bShowMouseCursor = true。恢复游戏时再切回FInputModeGameOnly()，把鼠标隐藏。这里有个细节：FInputModeGameAndUI的SetLockMouseToViewportBehavior参数决定了鼠标是否被限制在视口内，做暂停菜单时通常设为DoNotLock，让鼠标能自由移动。另外，切换输入模式后，记得检查你的UI是否设置了正确的焦点，否则键盘导航会失效。

我踩过的一个坑是：暂停菜单用了UIOnly模式，结果恢复游戏后玩家的移动输入全部失效了，因为输入模式没有正确切回来。后来我养成了一个习惯，把输入模式的切换封装成一个函数，暂停和恢复都走同一个入口，确保状态不会错乱。这个函数大概长这样：

void AMyPlayerController::SetPauseState(bool bPaused) { if (bPaused) { SetInputMode(FInputModeGameAndUI().SetLockMouseToViewportBehavior(EMouseLockMode::DoNotLock)); bShowMouseCursor = true; } else { SetInputMode(FInputModeGameOnly()); bShowMouseCursor = false; } }

3.2 暂停菜单的UI焦点与按钮响应

暂停菜单的UI做出来只是第一步，让它能正常响应才是关键。虚幻引擎的UMG系统在暂停状态下有个特性：UI的Tick默认不受游戏暂停影响，这本来是好事，意味着你的菜单动画、按钮悬停效果还能正常工作。但前提是你的UI没有依赖游戏世界的时间。如果你在UI里用了自定义的时间计算，暂停后可能会卡住。

按钮点不了的问题，十有八九是焦点没设置对。在暂停菜单显示时，调用SetKeyboardFocus()把焦点给到菜单的根控件或者第一个按钮。如果用的是UIOnly模式，还要确保bShowMouseCursor为true，否则鼠标虽然能移动但点击事件可能不触发。另外，UMG按钮的OnClicked事件在暂停时是正常触发的，但如果你的按钮逻辑里调用了需要游戏世界运行的东西，比如生成Actor、播放世界粒子，那就会出问题，因为世界是暂停的。

还有一个容易被忽略的点：暂停菜单的动画。如果你用UMG的动画序列做菜单淡入淡出，这些动画默认使用实时时间，暂停时也能播。但如果你在动画里驱动了游戏世界里的东西，比如让某个3D模型旋转，那就会卡住。我的建议是暂停菜单尽量用纯UI动画，不要和游戏世界产生耦合。

3.3 恢复游戏时的状态还原

恢复游戏比暂停更容易出问题。最常见的是角色瞬移：暂停期间，如果你在UI里做了某些操作导致角色位置被修改，恢复后角色会突然跳过去。另一个常见问题是输入丢失：恢复后玩家的移动、跳跃全部失效，必须重新点一下窗口才能恢复。这通常是因为输入模式没有正确切回GameOnly，或者UI的焦点没有释放。

我的做法是在恢复游戏时做三件事：第一，把输入模式切回GameOnly并隐藏鼠标；第二，调用SetKeyboardFocus()把焦点还给游戏视口；第三，检查玩家的输入组件是否还处于禁用状态。如果你在暂停时禁用了玩家的输入（比如DisableInput），恢复时一定要记得EnableInput。我见过有项目在暂停时禁用了输入，恢复时忘了开，结果玩家以为游戏卡死了。

还有一个细节是时间膨胀的恢复。如果你在暂停时手动修改过时间膨胀（比如做了慢动作效果），恢复时要确保把它设回1.0。SetGamePaused(false)会自动恢复引擎层面的时间膨胀，但你自己设置的那些需要手动清理。我建议用一个统一的暂停管理器来记录暂停前的状态，恢复时逐一还原，避免遗漏。

4. 那些让暂停功能翻车的边界情况

4.1 暂停时仍然需要运行的东西

有些东西在暂停时是必须继续运行的，最典型的就是暂停菜单本身和相关的UI逻辑。虚幻引擎默认会让UMG的Tick在暂停时继续执行，这一点是符合预期的。但如果你在暂停时还需要做其他事情，比如网络心跳、存档写入、后台加载，那就需要把这些逻辑放到不受暂停影响的Tick组里，或者用bTickEvenWhenPaused标记。

设置bTickEvenWhenPaused的方法很简单，在Actor的构造函数里设置PrimaryActorTick.bTickEvenWhenPaused = true即可。但要注意，这个Actor的Tick虽然会执行，但DeltaTime仍然是接近0的，所以你不能依赖DeltaTime做时间相关的计算。如果你的逻辑需要真实时间，得用FPlatformTime::Seconds()或者FApp::GetDeltaTime()来获取不受暂停影响的时间。

我在一个项目里做过暂停时的后台存档功能，最初把存档逻辑放在了玩家角色的Tick里，结果暂停后存档就停了。后来把存档逻辑抽到一个独立的Actor里，设置bTickEvenWhenPaused = true，并且用真实时间做超时判断，才解决了问题。这个经验告诉我，暂停时还需要运行的东西，一定要提前规划好它们的Tick策略。

4.2 动画蓝图和状态机的冻结问题

动画蓝图在暂停时的行为，取决于它的更新模式。默认情况下，动画蓝图的更新会受时间膨胀影响，暂停后动画会冻结在当前帧。这通常是符合预期的，但有些情况下你会希望动画继续播放，比如暂停菜单里角色做一个待机动作。这时候就需要把动画蓝图设置为不受暂停影响，或者用SetPlayRate配合真实时间手动驱动。

更麻烦的是动画状态机的过渡。如果你在暂停的瞬间角色正好处于状态过渡中，恢复后可能会出现动画跳变或者卡在过渡状态。我遇到过最诡异的一次是暂停恢复后角色一直保持着一个奇怪的姿势，原因是状态机的过渡规则依赖了某个在暂停期间被修改的变量。解决办法是在暂停时记录动画状态，恢复时强制刷新一次状态机，或者避免在暂停期间修改影响动画状态的变量。

对于用C++驱动的动画逻辑，还要注意TickComponent里的时间计算。如果你在动画组件的Tick里用了DeltaTime做插值，暂停时DeltaTime接近0，插值会几乎停止，这是正常的。但如果你用了累加时间做周期性的动作，暂停后累加时间不再增长，恢复后动作会从暂停点继续，这通常也是符合预期的。关键是要确保你的动画逻辑对DeltaTime的变化是鲁棒的。

4.3 联机同步与暂停的冲突处理

联机游戏里的暂停，核心原则是：暂停是本地行为，不要试图暂停服务器。在客户端调用SetGamePaused只会影响本地，服务器和其他客户端不受影响。如果你的游戏需要“所有人都暂停”的效果，那应该由服务器来协调，比如所有玩家都发送“准备暂停”的请求，服务器确认后通知所有人进入暂停菜单。

但即使是这样，服务器上的游戏逻辑通常也不应该暂停，因为服务器还要处理网络同步、AI逻辑等。更常见的做法是：联机游戏不做真正的暂停，只做本地输入暂停加菜单显示。玩家的角色在服务器上仍然存在，但不再接收该玩家的输入，相当于挂机。这样其他玩家看到的就是这个玩家站在原地不动，而不是整个世界卡住。

我在一个联机项目里实现过“投票暂停”功能，流程是这样的：玩家A打开暂停菜单，发送暂停请求到服务器；服务器广播给所有玩家，显示“玩家A请求暂停”的提示；如果所有玩家都同意，服务器通知所有人打开暂停菜单，同时冻结所有角色的输入；恢复时同样由服务器统一通知。这套流程比直接调用SetGamePaused复杂得多，但它是联机环境下唯一靠谱的方案。单机游戏可以偷懒，联机游戏不行。

5. 暂停功能的性能与体验优化

5.1 暂停时的资源管理与内存考量

暂停游戏时，虽然世界停下来了，但内存里的资源并没有释放。如果你在一个大型开放世界游戏里暂停，所有的纹理、网格、音频都还占着内存。这本身不是问题，但如果你在暂停时打开了一个复杂的菜单，加载了大量UI资源，可能会导致内存峰值。我的建议是暂停菜单的资源尽量轻量，不要在里面加载大图或者复杂的3D预览。

另一个考虑是暂停时的垃圾回收。虚幻引擎的GC在暂停时仍然会运行，如果你在暂停期间产生了大量临时对象（比如UI里的字符串拼接），可能会触发GC导致卡顿。虽然这种情况不常见，但在低端设备上值得注意。优化方法是尽量复用UI控件，避免在暂停菜单的Tick里频繁创建对象。

还有一点是音频的暂停策略。如果你在暂停时暂停了所有音频，恢复时可能会有短暂的爆音或者不同步。更好的做法是给音频组件设置淡入淡出，暂停时用0.2秒淡出，恢复时淡入。这样听感上更自然，也不会出现突然的静音或爆音。虚幻引擎的音频组件支持FadeIn和FadeOut，用起来很方便。

5.2 暂停菜单的响应式布局与多分辨率适配

暂停菜单的UI在不同分辨率下的表现，是很多项目上线后才暴露的问题。你在1080p下调得好好的菜单，到了4K或者带鱼屏上可能就错位了。UMG的锚点（Anchor）和DPI缩放是解决这个问题的关键。暂停菜单的根控件应该铺满屏幕，内部的按钮和文本用锚点定位，确保它们在不同宽高比下都能保持在合理位置。

我通常会把暂停菜单分成几个区域：标题区、按钮区、设置区。标题区锚定在屏幕上方居中，按钮区锚定在屏幕中央，设置区锚定在下方。每个区域内部再用垂直框或水平框排列子控件。这样无论屏幕怎么变，布局都不会乱。另外，记得在项目设置里开启DPI缩放，并根据目标平台设置合适的缩放曲线。主机游戏和PC游戏的DPI策略可能不同，需要分别测试。

还有一个细节是安全区域（Safe Zone）。主机游戏在电视上显示时，边缘可能会被裁切。虚幻引擎提供了安全区域的API，你可以在暂停菜单的根控件里获取安全区域的大小，然后把内容限制在安全区域内。这个功能在PC上不明显，但在主机上不做的话，菜单边缘的按钮可能被电视边框挡住。

5.3 暂停恢复的过渡动画与用户体验

暂停和恢复如果只是瞬间切换，体验上会很生硬。加一个短暂的过渡动画，能让整个过程舒服很多。最简单的做法是用UMG的动画序列做一个0.15到0.3秒的淡入淡出，暂停时菜单从透明渐变到不透明，恢复时反过来。如果想让效果更高级，可以加一点缩放或者模糊效果。

但要注意，过渡动画的时间不能太长。玩家按暂停是想要立刻看到菜单，如果动画要1秒才完成，会让人觉得卡顿。我的经验是暂停菜单的出现动画控制在0.2秒以内，消失动画可以稍长一点，0.3秒左右。另外，动画期间要禁用按钮的点击，防止玩家在菜单还没完全出现时就误触。

恢复游戏时的过渡也很重要。如果直接从暂停菜单跳回游戏，玩家可能会因为画面突变而失去方向感。可以在恢复时做一个短暂的画面从模糊到清晰的过渡，或者让菜单淡出的同时游戏画面淡入。虚幻引擎的后期处理体积可以配合做这种效果，但要注意暂停时后期处理是否还在运行。如果后期处理也暂停了，那过渡效果就得用UI层来实现。

6. 我踩过的那些暂停相关的坑

6.1 暂停后角色还能移动的诡异Bug

有一次我在项目里实现了暂停功能，测试时发现暂停后角色居然还能移动，只是移动速度变得极慢。排查了半天，最后发现是角色的移动组件在暂停时仍然在接收输入，只是因为时间膨胀导致移动距离极小，看起来像是“慢慢挪动”。问题的根源是我在暂停时没有禁用玩家的输入，而移动组件的逻辑虽然受DeltaTime影响，但输入事件本身是即时触发的。

解决办法是在暂停时调用DisableInput禁用玩家控制器的输入，恢复时再EnableInput。但这里有个坑：如果你在暂停菜单里需要键盘导航，禁用输入可能会影响UI的键盘响应。正确的做法是只禁用游戏世界的输入映射，保留UI的输入。虚幻引擎的输入系统支持这种区分，你可以在输入映射的上下文中设置优先级，或者用SetInputMode来切换。

这个Bug让我意识到，暂停不是单一操作，而是一组操作的集合。你需要同时处理时间、输入、UI、音频等多个子系统，任何一个遗漏都会导致奇怪的表现。后来我养成了一个习惯，把暂停相关的所有操作封装成一个PauseGame函数，里面按顺序处理时间暂停、输入切换、UI显示、音频淡出，恢复时反向操作。这样就不会漏掉任何一步。

6.2 暂停菜单按钮点击无效的排查过程

另一个让我头疼的问题是暂停菜单的按钮点不了。鼠标能看到，也能移动，但点击按钮没有任何反应。我一开始以为是UI的ZOrder问题，检查了层级发现没问题。然后又怀疑是输入模式，确认了是GameAndUI模式，鼠标也没被锁定。最后用调试工具查看点击事件，发现点击事件确实触发了，但按钮的OnClicked没有执行。

深入排查后发现，问题出在UI的焦点上。暂停菜单显示时，我没有给菜单设置键盘焦点，导致整个菜单虽然可见，但不在输入焦点链里。鼠标点击虽然能触发悬停效果，但点击事件被上层某个不可见的控件拦截了。解决办法是在菜单显示时调用SetKeyboardFocus()，把焦点给到菜单的根控件。这个操作看起来不起眼，但它是UI能正常交互的前提。

这个坑教会我一件事：UMG的交互依赖焦点链。一个控件即使可见、可点击，如果不在焦点链里，它的点击事件可能不会按预期触发。特别是当你有多个UI层叠时，焦点在哪个层决定了输入事件的分发。暂停菜单通常是最上层的UI，所以它必须主动获取焦点，否则输入事件可能被下面的游戏视口或者其他UI拦截。

6.3 恢复游戏后时间膨胀没有还原

时间膨胀没有还原这个问题，我在两个项目里都遇到过。表现是恢复游戏后，整个世界变得极慢，像是慢动作。原因是暂停时引擎把时间膨胀设成了极小值，但恢复时因为某些原因没有设回1.0。最常见的情况是：你在暂停期间手动修改了时间膨胀（比如做了一个暂停时的慢动作特效），恢复时只调用了SetGamePaused(false)，但引擎只负责恢复它自己设置的那部分，你手动改的需要你自己还原。

解决办法是在暂停时记录当前的时间膨胀值，恢复时先还原这个值，再调用SetGamePaused(false)。或者更简单粗暴：恢复时直接调用SetGlobalTimeDilation(1.0)，但这样会覆盖掉所有自定义的时间膨胀效果。如果你的游戏里有慢动作技能之类的机制，就不能这么干。我的建议是维护一个时间膨胀的栈，暂停时压入，恢复时弹出，确保不会互相覆盖。

还有一个隐蔽的坑是多个系统同时修改时间膨胀。比如你的暂停系统设了0.0001，你的慢动作系统设了0.5，两个系统打架，最后的时间膨胀是两者相乘，结果就是角色几乎不动。排查这种问题需要你打印出每一帧的时间膨胀值，看看是谁在修改它。虚幻引擎的GetWorldSettings()->TimeDilation可以随时读取当前值，调试时很有用。

6.4 暂停时音频不同步的解决方案

音频不同步的问题在暂停恢复后特别明显。如果你在暂停时直接暂停了音频，恢复时音频从暂停点继续，但游戏世界的时间已经往前走了，导致音画不同步。比如一个爆炸音效，暂停时播到一半，恢复后音效继续播，但爆炸的粒子已经因为时间膨胀恢复而瞬间播完了，看起来就是音效滞后了。

解决这个问题的思路是：暂停时不要暂停音频，而是让音频也受时间膨胀影响。虚幻引擎的音频系统默认不受时间膨胀影响，但你可以通过音频组件的SetPaused或者音频混合器的相关设置来让它跟随游戏时间。另一种做法是暂停时淡出音频，恢复时重新播放，但这会导致音效从头开始，不适合所有场景。

我最终的方案是：背景音乐在暂停时淡出，恢复时淡入，这样听感最自然；音效则在暂停时直接停止，恢复时不重新播放，因为大部分音效都是短促的，暂停后继续播反而奇怪。这个策略不是通用的，你需要根据自己游戏的音频类型来调整。关键是意识到音频和游戏世界的时间是两套系统，需要分别处理。

7. 把暂停功能做成一个可复用的模块

7.1 设计一个暂停管理器

经过多个项目的折腾，我现在的做法是把暂停功能做成一个独立的暂停管理器（PauseManager）。这个管理器负责统一处理暂停和恢复的所有逻辑：时间膨胀、输入模式、UI显示、音频淡出、状态记录。游戏里的其他系统只需要调用PauseManager->PauseGame()和PauseManager->ResumeGame()，不需要关心底层的细节。

这个管理器的核心是一个状态机，记录当前是否暂停、暂停前的时间膨胀值、暂停前的输入模式等。暂停时，它按顺序执行：记录状态、设置时间膨胀、切换输入模式、显示暂停菜单、淡出音频。恢复时反向执行。这样做的好处是逻辑集中，不会出现某个系统暂停了但另一个系统没暂停的情况。

管理器的接口设计也很重要。我通常会提供PauseGame、ResumeGame、TogglePause三个方法，以及一个OnPauseStateChanged的委托，让其他系统可以监听暂停状态的变化。比如UI系统可以监听这个委托来显示或隐藏暂停菜单，音频系统可以监听它来淡出音频。这样各个系统之间解耦，维护起来方便很多。

7.2 暂停状态的保存与恢复策略

暂停管理器还需要处理状态的保存和恢复。最简单的做法是只保存时间膨胀和输入模式，但实际项目中可能需要保存更多东西，比如玩家的输入状态、UI的焦点、音频的音量等。我的做法是定义一个FPauseState结构体，里面包含所有需要在暂停时保存、恢复时还原的数据。

struct FPauseState { float PreviousTimeDilation; FInputModeDataBase PreviousInputMode; bool bPreviousShowMouseCursor; float PreviousMasterVolume; TWeakObjectPtr<UUserWidget> PreviousFocusedWidget; };

暂停时填充这个结构体，恢复时逐项还原。这样即使暂停期间有其他系统修改了这些值，恢复时也能回到暂停前的状态。当然，这个结构体不是固定的，你可以根据自己的项目需求增减字段。关键是养成“暂停前记录，恢复时还原”的习惯，避免状态泄漏。

7.3 暂停功能的测试清单

暂停功能做完之后，一定要按照清单测试一遍。我整理了一份自己常用的测试清单，每次实现暂停功能后都会过一遍：

这份清单覆盖了大部分常见问题，但每个项目可能还有特殊场景。比如如果你的游戏有载具系统，暂停时载具的物理模拟是否停止？如果有建造系统，暂停时能否继续建造？这些都需要根据项目特点补充测试项。我的经验是，暂停功能的Bug往往不在暂停本身，而在暂停和其他系统的交互上，所以测试时要特别关注边界情况。

8. 关于暂停功能的一点个人体会

做了这么多年的虚幻引擎项目，暂停功能是我见过最容易“看起来简单做起来难”的功能之一。它不像渲染管线或者网络同步那样有很高的技术门槛，但它涉及的子系统特别多，任何一个没处理好都会导致玩家体验出问题。而且这些问题往往在开发阶段不容易发现，等到测试或者上线后才暴露出来。

我现在做暂停功能，第一件事不是写代码，而是先画一张图，把所有需要在暂停时处理的系统列出来：时间、输入、UI、音频、动画、物理、网络、存档。然后逐个确认每个系统在暂停时的预期行为，再决定怎么实现。这张图花不了多少时间，但能避免后面大量的返工。

另一个体会是，暂停功能没有标准答案。单机游戏和联机游戏的暂停策略完全不同，动作游戏和解谜游戏的暂停需求也不一样。你需要根据自己游戏的特点来决定暂停的粒度和范围。比如解谜游戏可能希望暂停时玩家还能观察场景，那就不应该完全冻结世界；而动作游戏通常需要完全暂停，避免玩家在暂停时被偷袭。理解你的游戏需要什么样的暂停，比掌握暂停的技术实现更重要。

最后分享一个小技巧：在开发阶段，给暂停功能加一个调试开关，可以单独控制时间暂停、输入暂停、UI显示等各个子功能。这样当出现问题时，你可以快速定位是哪个子系统导致的，而不是在一堆逻辑里盲目排查。这个开关在打包发布时关掉就行，开发时能省很多时间。