企业官网建设流程全解析

1. 暂停游戏到底在暂停什么

很多人第一次在虚幻引擎里做暂停功能，脑子里想的是"让游戏停下来"，然后就去翻引擎源码，想找一个全局的"停止"按钮。这个思路从根上就偏了。虚幻引擎的暂停从来不是让引擎停止运转，而是让游戏世界的时间推进逻辑和玩家的输入响应这两件事暂时冻结，同时把渲染、UI、音频这些子系统继续保留在运行状态。你按下暂停键之后，画面还在渲染，菜单还能点击，背景音乐可能还在放，但角色不再移动、物理不再模拟、动画不再推进——这才是暂停的真实含义。

理解这一点非常关键，因为它直接决定了你后面所有实现方案的选型。如果你以为暂停是"停掉一切"，那你可能会去尝试关闭Tick、销毁Actor、甚至暂停整个World，这些做法要么会带来一堆副作用，要么根本达不到你想要的效果。而一旦你接受了"暂停是选择性冻结"这个前提，剩下的问题就变成了：我要冻结哪些东西，保留哪些东西，以及用什么机制去控制这个冻结的开关。

这篇文章面向的是已经能在虚幻引擎里跑通基本游戏逻辑、但对暂停系统还没有系统认知的开发者。不管你是做单机剧情向项目，还是做需要暂停菜单的多人联机游戏，暂停这件事都会在某个阶段成为你必须啃下来的硬骨头。我会从引擎底层的时间机制讲起，一直讲到实际项目里怎么处理暂停时的输入冲突、动画冻结、音频衰减和网络同步，尽量把每个"为什么这么做"都讲清楚。

2. 引擎底层的时间与暂停机制拆解

2.1 从Tick到时间膨胀：引擎怎么推进一帧

要搞懂暂停，先得搞懂引擎正常运行时是怎么"推进时间"的。虚幻引擎的每一帧大致经历这样一个流程：引擎心跳触发World的Tick，World再驱动里面所有Actor的Tick，Actor的Tick里更新自己的逻辑、动画、物理状态。这个链条里有一个非常核心的概念叫DeltaTime，也就是上一帧到这一帧之间经过了多少秒。所有跟时间相关的计算——角色移动速度、动画播放进度、粒子生命周期——都是拿DeltaTime去累加的。

那暂停是怎么实现的呢？引擎提供了一个叫GlobalTimeDilation的全局时间膨胀系数，以及每个Actor自己的CustomTimeDilation。当全局时间膨胀设为0的时候，DeltaTime就变成0，所有依赖DeltaTime的逻辑自然就"停"了。这就像你把水龙头拧到最小，水还在管子里，但流不出来了。这个机制的好处是它不需要你去逐个关闭Actor的Tick，引擎自动帮你处理了时间维度上的冻结。

但这里有个坑：时间膨胀为0并不等于Tick不执行。Actor的Tick函数还是会被调用的，只是传进去的DeltaTime是0。这意味着如果你在Tick里写了不依赖DeltaTime的逻辑，比如"每帧检测某个条件然后触发事件"，那这个逻辑在暂停期间依然会跑。很多新手在这里翻车，明明暂停了，结果某个计时器还在走、某个状态机还在切换，就是因为没意识到这一点。

2.2 SetPause与IsPaused：官方暂停接口的正确用法

引擎在UGameplayStatics里提供了两个直接可用的函数：SetGamePaused和IsGamePaused。调用SetGamePaused(World, true)之后，引擎会把World标记为暂停状态，同时自动把全局时间膨胀设为0，并且阻止大部分玩家输入传递到游戏逻辑。这是最省事的暂停方案，一行代码就能让整个游戏世界停下来。

但"省事"往往意味着"不够灵活"。SetGamePaused是一个全局开关，它一开，整个World里所有Actor的Tick逻辑都会受到时间膨胀的影响。如果你想让某些东西在暂停时继续运行——比如暂停菜单的动画、背景粒子的飘动、UI的过渡效果——你就需要对这些Actor单独设置CustomTimeDilation，或者把它们放到一个不受暂停影响的子系统里去驱动。

还有一个容易被忽略的点：SetGamePaused默认会同时暂停玩家的输入。这在单机游戏里是好事，但在某些场景下你可能希望暂停时玩家还能操作UI。这时候你需要检查PlayerController的SetInputMode设置，确保UI输入模式是打开的，否则你会发现暂停菜单弹出来了但点不动。

2.3 暂停与输入模式的联动关系

输入模式这件事值得单独拎出来说，因为它是暂停功能里最容易出Bug的地方。虚幻引擎的输入系统有两套模式：GameOnly和UIOnly，以及一个混合模式GameAndUI。正常游戏时你用的是GameOnly，鼠标被锁定、隐藏，所有输入都传给游戏逻辑。暂停菜单弹出来的时候，你需要切换到UIOnly或者GameAndUI，让鼠标显示出来、让UI能接收点击。

问题在于，这个切换的时机和暂停的时机如果配合不好，就会出现各种诡异现象：比如暂停了但鼠标没出来，或者鼠标出来了但游戏角色还在响应键盘移动。我踩过的坑是，在SetGamePaused之后立刻切换输入模式，结果因为暂停导致某些Tick没执行，输入模式的切换被延迟了一帧，玩家在那一帧里还能操作角色。解决办法是把输入模式切换放在暂停之前，或者用SetInputMode的强制刷新参数确保立即生效。

注意：输入模式切换和暂停操作的顺序在不同引擎版本里表现可能不一致，建议在自己的目标版本上实测确认，不要照搬网上的代码。

3. 单机项目里的暂停实现方案

3.1 最简方案：一行代码搞定基础暂停

如果你做的是单机游戏，对暂停没有特别复杂的需求，那最简单的方案就是直接在PlayerController或者某个管理类里调用SetGamePaused。按一下Esc键，游戏暂停，弹出菜单，再按一下恢复。核心代码大概长这样：

// 在PlayerController里绑定暂停输入 void AMyPlayerController::TogglePause() { bool bIsPaused = UGameplayStatics::IsGamePaused(GetWorld()); UGameplayStatics::SetGamePaused(GetWorld(), !bIsPaused); if (!bIsPaused) { // 即将暂停，显示菜单、切换输入模式 PauseMenuWidget->SetVisibility(ESlateVisibility::Visible); SetInputMode(FInputModeUIOnly()); bShowMouseCursor = true; } else { // 即将恢复，隐藏菜单、切回游戏输入 PauseMenuWidget->SetVisibility(ESlateVisibility::Collapsed); SetInputMode(FInputModeGameOnly()); bShowMouseCursor = false; } }

这段代码看起来简单，但它已经覆盖了暂停功能的核心骨架：检测当前状态、切换暂停、联动UI和输入。实测下来，对于大多数单机项目，这个方案已经够用了。但你要注意几个细节：SetGamePaused的第二个参数控制是否同时暂停输入，默认是true，如果你打算自己管理输入模式，可以把它设为false，避免引擎和你的代码打架。

3.2 暂停菜单的UI层级与焦点管理

暂停菜单弹出来之后，玩家第一件事往往是按方向键或者Tab键在按钮之间切换。这就涉及到UI的焦点管理。虚幻引擎的UMG系统里，每个可交互的控件都有一个IsFocusable属性，你需要确保菜单里的按钮都开启了这个属性，并且在菜单显示的时候主动把焦点设置到第一个按钮上，否则玩家按键盘会发现没有任何反应。

焦点管理的另一个坑是焦点逃逸。如果你的暂停菜单只覆盖了屏幕的一部分，玩家用Tab键切换焦点时可能会跑到菜单外面的控件上，甚至跑回游戏HUD。解决办法是在暂停菜单的根控件上设置FocusRecipient，或者用一个全屏的透明遮罩层把游戏区域挡住，确保焦点只在菜单内部循环。

我在一个项目里遇到过更隐蔽的问题：暂停菜单显示后，玩家用鼠标点击按钮没反应，但用键盘可以。排查了半天才发现是鼠标光标虽然显示出来了，但UI的ZOrder层级不对，菜单被一个透明的HUD控件挡住了。这种问题没有通用解法，只能靠你在项目里建立清晰的UI层级规范，暂停菜单永远放在最高的ZOrder层。

3.3 暂停时动画和音频的处理策略

暂停之后，角色的动画会冻结在当前帧，这是符合预期的。但有些项目会希望暂停时角色做一个"待机呼吸"的微动画，或者暂停菜单的背景有一个缓慢的粒子飘动效果。这时候你就需要对这些特定的Actor或组件单独处理。

对于动画，你可以给需要继续播放的SkeletalMeshComponent设置CustomTimeDilation为1，同时确保它不受全局暂停影响。但要注意，CustomTimeDilation是乘在全局时间膨胀上的，全局为0时，任何数乘以0都是0。所以更可靠的做法是把这些动画放到一个独立的、不受暂停影响的子系统里驱动，或者直接用材质动画、UI动画来实现，绕开Actor的Tick体系。

音频方面，SetGamePaused默认不会暂停音频播放。背景音乐和音效会继续播放，这在很多游戏里是期望的行为。但如果你希望暂停时音频也淡出或者暂停，就需要手动调用音频组件的AdjustVolume或者SetPaused。我一般建议暂停时把背景音乐音量降低到原来的30%左右，而不是完全静音，这样恢复时不会有突兀感。

4. 多人联机场景下的暂停难题

4.1 为什么联机游戏不能简单暂停

单机游戏的暂停是"我停我的"，联机游戏的暂停是"谁停谁的"。在一个多人共享的World里，如果某个玩家调用SetGamePaused，会发生什么？答案是：只有调用者的客户端会暂停，服务器和其他客户端不受影响。这就导致了一个尴尬的局面：你这边画面停了，但服务器上你的角色还在被其他玩家攻击，等你恢复的时候发现自己已经死了。

这就是联机游戏暂停的核心矛盾：暂停本质上是一个"全局状态"，但联机环境里没有一个所有客户端都同步的全局时钟。服务器有服务器的时钟，每个客户端有自己的本地时钟，它们之间只有近似同步。你没法让所有客户端在同一时刻暂停，因为网络延迟的存在让"同一时刻"这个概念本身就不成立。

所以绝大多数联机游戏的做法是：不提供真正的暂停功能。玩家退出游戏或者打开菜单时，角色依然留在世界里，可能被标记为"暂离"状态，但游戏世界继续运转。这不是偷懒，而是联机游戏的设计约束决定的。

4.2 单人联机与Listen Server的折中方案

如果你的联机游戏支持单人游玩，或者用的是Listen Server（其中一个玩家同时充当服务器），那暂停功能还有得商量。在Listen Server模式下，如果只有房主一个玩家在线，你可以让房主调用SetGamePaused，因为服务器和客户端在同一台机器上，暂停是同步的。但一旦有第二个玩家加入，你就必须禁用暂停功能，或者把暂停改成"菜单打开但游戏继续"的模式。

实现这个逻辑的关键是检测当前在线玩家数量。你可以在GameMode里维护一个玩家列表，当玩家数量为1且是Listen Server时允许暂停，否则禁用。这个判断要放在暂停请求的入口处，而不是等到暂停已经生效了再去补救。

bool AMyGameMode::CanPauseGame() const { // 只有Listen Server且只有一个玩家时允许暂停 if (!GetWorld()->GetNetMode() == NM_ListenServer) { return false; } return GetNumPlayers() <= 1; }

这段逻辑看起来简单，但它背后是对联机游戏本质的理解：暂停是一个需要全局一致性的操作，而全局一致性在分布式系统里是昂贵甚至不可能的。与其强行实现一个半吊子的暂停，不如在设计阶段就明确"联机模式下没有暂停"，把精力放在其他体验优化上。

4.3 网络同步中的暂停状态标记

如果你确实需要在联机环境里表达"某个玩家暂停了"这个状态，正确的做法不是暂停游戏，而是同步一个状态标记。比如给PlayerState加一个bIsAway布尔值，当玩家打开菜单时把它设为true，服务器把这个状态复制给所有客户端，其他玩家看到你的角色头顶显示一个"暂离"图标。游戏世界继续运转，但你的角色可以被设置为无敌或者自动躲避，避免在你不在的时候被偷袭。

这个方案的好处是它完全绕开了暂停的同步难题，用状态复制代替了时间冻结。而且它符合联机游戏的惯例，玩家也能理解"我打开菜单的时候游戏还在继续"这个设定。实现上你只需要在PlayerState里加一个RepNotify变量，在菜单打开和关闭时分别设置，然后在角色蓝图里根据这个变量切换表现即可。

5. 暂停功能的进阶技巧与常见问题排查

5.1 暂停时定时器和异步任务的正确处理

定时器是暂停功能里最容易出问题的地方。虚幻引擎的FTimerHandle默认是受时间膨胀影响的，全局时间膨胀为0时，定时器不会触发。这听起来很合理，但如果你有一个"暂停后3秒自动恢复"的倒计时，或者一个"暂停菜单里每0.5秒刷新一次服务器列表"的逻辑，你就会发现它们全都不动了。

解决办法是使用SetTimer的重载版本，把最后一个参数bLoop后面的bMaxOnce或者直接用FTimerManager的SetTimerForNextTick来绕开时间膨胀。更通用的做法是用GetTimerManager().SetTimer时传入一个不受暂停影响的TimerManager，或者干脆用FTSTicker这种基于真实时间的回调机制。

异步任务也是类似的情况。AsyncTask和Async节点默认在后台线程执行，不受游戏暂停影响。如果你在暂停时发起了一个异步加载请求，它会在后台继续跑，加载完成后回调到游戏线程。这个回调的时机需要你特别注意，因为暂停期间游戏线程的Tick还在跑（只是DeltaTime为0），回调可能会在你意想不到的时候触发。

5.2 暂停与存档、设置的交互陷阱

暂停菜单里通常会有"保存游戏"和"设置"两个选项。这两个功能跟暂停状态交互时都有坑。保存游戏时，你需要确保保存的数据是暂停那一刻的准确快照，而不是被暂停影响后的中间状态。比如某个Actor的位置在暂停时被冻结了，但它的物理模拟可能还有残留的速度值，保存的时候要把这些值也一并处理干净。

设置菜单的坑更隐蔽。玩家在暂停菜单里调整了画质设置，很多设置需要重新加载关卡或者重建渲染资源才能生效。如果你在暂停状态下直接应用这些设置，可能会导致渲染线程和游戏线程的状态不一致，轻则画面闪烁，重则崩溃。稳妥的做法是在设置菜单里提示玩家"部分设置将在恢复游戏后生效"，把需要重建的操作延迟到恢复之后执行。

5.3 常见问题速查表

这张表里的每一行都是我或者身边同行实际踩过的坑。你会发现大部分问题的根源都在于"以为暂停是全局的，实际上它是选择性的"。只要你记住这个核心原则，遇到问题时先问自己"这个东西是受时间膨胀影响的，还是不受影响的"，排查方向就清晰了。

5.4 暂停功能的性能考量

暂停本身对性能的影响微乎其微，因为大部分计算都停了。但暂停菜单的渲染开销不能忽视。如果你的暂停菜单是一个复杂的3D场景，或者有大量的粒子特效，那暂停时的GPU开销可能比游戏运行时还高。我见过一个项目，暂停菜单里放了一个实时渲染的角色模型展示，结果暂停时帧率反而下降了。

优化思路很简单：暂停菜单尽量用2D UI实现，避免在暂停时渲染复杂的3D内容。如果确实需要展示3D模型，可以用SceneCaptureComponent2D把模型渲染到一张RenderTarget上，然后当作图片显示，这样开销远低于实时渲染整个场景。另外，暂停时可以把游戏世界的渲染分辨率降低，或者直接冻结最后一帧的画面当作背景，进一步减少GPU负担。

6. 从暂停延伸出去的设计思考

暂停这个功能看似简单，但它其实是一个窗口，透过它能看到游戏架构里的很多深层问题。比如你的游戏逻辑是不是过度依赖Tick？如果所有东西都写在Tick里，那暂停时你就很难精细控制哪些该停哪些该继续。再比如你的UI和游戏逻辑耦合得紧不紧？如果暂停菜单直接引用了游戏里的Actor，那暂停时的状态管理就会变得很混乱。

我在实际项目里的体会是，暂停功能最好在项目早期就设计进去，而不是等到后期再补。早期设计的时候，你可以把"可暂停"和"不可暂停"的逻辑分层，把需要独立于游戏时间运行的系统（UI、音频、网络）单独抽出来，这样后期加暂停功能就是水到渠成的事。反过来，如果项目已经写了一堆紧耦合的Tick逻辑，再想加暂停就得大动干戈。

还有一个值得思考的点是：暂停到底应该由谁触发？很多项目把暂停逻辑写在PlayerController里，这没问题，但如果你的游戏有多个玩家或者多种输入设备，暂停的触发源就会变得复杂。更优雅的做法是定义一个PauseManager或者GameState里的暂停接口，所有触发源都通过这个接口来请求暂停，由它统一管理暂停状态和相关的UI、输入、音频联动。这样你的暂停逻辑就是可测试、可扩展的，不会因为加了一个新的输入设备就到处改代码。

最后分享一个小技巧：在开发阶段，你可以给暂停功能加一个调试开关，允许在暂停状态下用特定的组合键单步执行一帧。这对于调试那些"暂停时状态不对"的问题非常有用，你可以一帧一帧地看暂停和恢复的瞬间到底发生了什么。这个功能实现起来不难，就是在暂停状态下临时把时间膨胀设为一个极小值而不是0，然后手动触发一次Tick。试过之后你会发现，很多之前想不通的暂停Bug，在单步调试下都一目了然。