1. 從“卡頓”與“加速”說(shuō)起為什么需要區(qū)分兩套時(shí)間系統(tǒng)如果你剛開(kāi)始接觸游戲開(kāi)發(fā)或者嘗試自己寫一個(gè)小游戲大概率會(huì)遇到兩個(gè)讓人頭疼的“玄學(xué)”問(wèn)題一個(gè)是“為什么我的角色移動(dòng)一卡一卡的”另一個(gè)是“為什么我換了臺(tái)更快的電腦游戲里的角色反而跑得跟飛一樣”。這兩個(gè)看似不同的問(wèn)題其根源往往都指向同一個(gè)核心概念——游戲循環(huán)中對(duì)“時(shí)間”的處理方式也就是我們常說(shuō)的邏輯幀與物理幀的混淆。在游戲這個(gè)虛擬世界里一切都在運(yùn)動(dòng)、變化。角色要移動(dòng)子彈要飛行特效要播放物理物體要碰撞。為了讓這個(gè)世界“活”起來(lái)游戲程序必須不斷地更新游戲狀態(tài)并把這些更新后的狀態(tài)繪制到屏幕上。這個(gè)“不斷更新與繪制”的核心過(guò)程就是游戲循環(huán)。你可以把它想象成游戲的心臟每一次跳動(dòng)世界就向前推進(jìn)一小步。然而這顆“心臟”的跳動(dòng)節(jié)奏卻受制于一個(gè)殘酷的現(xiàn)實(shí)玩家電腦的硬件性能千差萬(wàn)別。一臺(tái)十年前的舊筆記本和一臺(tái)最新的游戲主機(jī)其計(jì)算和渲染能力可能有天壤之別。如果游戲循環(huán)的每一次“跳動(dòng)”都緊密綁定在硬件的渲染能力上會(huì)發(fā)生什么在舊機(jī)器上循環(huán)跑得慢游戲世界更新得也慢角色動(dòng)作遲緩這就是“卡頓”在新機(jī)器上循環(huán)跑得飛快游戲世界更新也飛快角色瞬間穿越地圖這就是“加速”。為了解決這個(gè)矛盾聰明的開(kāi)發(fā)者們將游戲循環(huán)中的“更新”拆解成了兩個(gè)部分一個(gè)負(fù)責(zé)處理與時(shí)間嚴(yán)格相關(guān)的游戲規(guī)則和狀態(tài)我們稱之為邏輯更新另一個(gè)負(fù)責(zé)處理與硬件性能強(qiáng)相關(guān)的畫面渲染我們稱之為渲染更新。對(duì)應(yīng)地就有了邏輯幀和物理幀或叫渲染幀這兩個(gè)核心概念。理解它們是寫出穩(wěn)定、可控、在任何設(shè)備上表現(xiàn)一致的游戲的基礎(chǔ)。這不僅僅是理論而是每一個(gè)實(shí)戰(zhàn)項(xiàng)目里都必須直面和解決的設(shè)計(jì)問(wèn)題。2. 核心概念拆解邏輯幀、物理幀與游戲循環(huán)的三位一體要徹底弄明白我們需要把游戲循環(huán)這個(gè)黑盒子打開(kāi)看看里面到底是怎么運(yùn)作的。一個(gè)經(jīng)典而健壯的游戲循環(huán)結(jié)構(gòu)通常包含以下幾個(gè)關(guān)鍵階段它們并非簡(jiǎn)單的順序執(zhí)行而是相互協(xié)作共同維持著游戲的“心跳”。2.1 物理幀被硬件綁架的視覺(jué)節(jié)奏物理幀更常被稱為渲染幀或FPS它的核心任務(wù)是將當(dāng)前游戲世界的狀態(tài)繪制到屏幕上。這個(gè)過(guò)程的頻率直接受限于顯示器的刷新率和GPU的渲染能力。驅(qū)動(dòng)者垂直同步、顯示器刷新率、GPU渲染流水線。一個(gè)常見(jiàn)的目標(biāo)是鎖定在60FPS因?yàn)檫@是大多數(shù)顯示器的標(biāo)準(zhǔn)刷新率每一幀的時(shí)間間隔約為16.67毫秒。核心工作調(diào)用圖形API執(zhí)行繪制命令。這包括提交頂點(diǎn)數(shù)據(jù)、設(shè)置著色器、處理紋理、最終將像素輸出到幀緩沖區(qū)。這個(gè)過(guò)程消耗的是GPU資源其耗時(shí)波動(dòng)很大。關(guān)鍵特性不穩(wěn)定、不可控。即便你鎖定了目標(biāo)幀率實(shí)際每一幀的渲染時(shí)間也會(huì)有微小的波動(dòng)。在復(fù)雜場(chǎng)景下掉幀更是家常便飯。如果游戲邏輯綁死在這個(gè)不穩(wěn)定的節(jié)奏上游戲體驗(yàn)就會(huì)像坐過(guò)山車。想象一下你用Unity的Update()函數(shù)或者Unreal的Tick函數(shù)來(lái)直接移動(dòng)一個(gè)物體每幀移動(dòng)固定距離。在60FPS的機(jī)器上物體每秒移動(dòng)60個(gè)單位在30FPS的機(jī)器上物體每秒只移動(dòng)30個(gè)單位。這就是將邏輯與物理幀綁定的后果——游戲速度與硬件性能掛鉤。2.2 邏輯幀游戲世界的絕對(duì)時(shí)間標(biāo)尺與物理幀的隨波逐流相反邏輯幀是游戲世界內(nèi)部的“原子鐘”它定義了游戲世界演進(jìn)的固定時(shí)間步長(zhǎng)。驅(qū)動(dòng)者一個(gè)獨(dú)立的、穩(wěn)定的定時(shí)器。例如固定每16.67毫秒模擬60Hz或33.33毫秒模擬30Hz觸發(fā)一次邏輯更新。核心工作更新所有與時(shí)間相關(guān)的游戲狀態(tài)。這包括物理模擬計(jì)算受力、速度、位置、碰撞檢測(cè)與響應(yīng)。角色AI決策樹(shù)、狀態(tài)機(jī)、尋路計(jì)算。游戲規(guī)則技能冷卻、資源增長(zhǎng)、狀態(tài)持續(xù)時(shí)間的判定。輸入處理采集并緩存玩家在這一固定時(shí)間間隔內(nèi)的輸入。關(guān)鍵特性穩(wěn)定、可控、與硬件解耦。無(wú)論外部渲染多么卡頓游戲內(nèi)部的“時(shí)間”都按照自己的節(jié)奏均勻流逝。這是實(shí)現(xiàn)游戲確定性的基石。所謂確定性就是給定相同的初始狀態(tài)和輸入序列游戲在任何機(jī)器上運(yùn)行經(jīng)過(guò)相同的時(shí)間后得到的狀態(tài)完全一致。這對(duì)于聯(lián)網(wǎng)游戲的同步、游戲錄像的回放、BUG的復(fù)現(xiàn)至關(guān)重要。2.3 游戲循環(huán)協(xié)調(diào)兩者的“總指揮”游戲循環(huán)是容納并調(diào)度邏輯幀與物理幀的框架。一個(gè)現(xiàn)代游戲循環(huán)的偽代碼清晰地揭示了三者的關(guān)系double previousTime GetCurrentTime(); double lag 0.0; // 累積的時(shí)間延遲 const double fixedDeltaTime 1.0 / 60.0; // 邏輯幀固定步長(zhǎng)如16.67ms while (gameIsRunning) { double currentTime GetCurrentTime(); double elapsedTime currentTime - previousTime; previousTime currentTime; lag elapsedTime; // 累積真實(shí)流逝的時(shí)間 // 1. 處理輸入可放在固定更新前或后但需注意順序 ProcessInput(); // 2. 固定時(shí)間步長(zhǎng)更新執(zhí)行邏輯幀 while (lag fixedDeltaTime) { UpdateGameLogic(fixedDeltaTime); // 傳入固定的時(shí)間步長(zhǎng) lag - fixedDeltaTime; } // 3. 插值計(jì)算為渲染準(zhǔn)備平滑的狀態(tài) double interpolationAlpha lag / fixedDeltaTime; // 4. 可變時(shí)間步長(zhǎng)渲染執(zhí)行物理幀 Render(interpolationAlpha); }這個(gè)結(jié)構(gòu)是理解一切的關(guān)鍵UpdateGameLogic(fixedDeltaTime)在while循環(huán)中以固定的fixedDeltaTime為步長(zhǎng)執(zhí)行一次或多次游戲邏輯更新。這確保了邏輯更新的頻率和間隔是絕對(duì)穩(wěn)定的。Render(interpolationAlpha)渲染只執(zhí)行一次但它渲染的不是某個(gè)精確邏輯幀的狀態(tài)而是兩個(gè)邏輯幀狀態(tài)之間的一個(gè)插值狀態(tài)。interpolationAlpha是一個(gè)介于0到1之間的值表示“距離上一個(gè)邏輯幀過(guò)去了多少比例的邏輯步長(zhǎng)”。通過(guò)插值即使渲染幀率波動(dòng)畫面也能保持平滑避免因邏輯幀離散更新導(dǎo)致的“卡頓”視覺(jué)感受。3. 實(shí)戰(zhàn)中的模式選擇固定更新、可變更新與混合更新理論很清晰但在實(shí)際引擎或框架中我們?nèi)绾螒?yīng)用呢主要有三種模式各有其適用場(chǎng)景和坑。3.1 固定更新模式物理與多人游戲的守護(hù)神這就是上面?zhèn)未a展示的模式。邏輯更新在一個(gè)獨(dú)立的循環(huán)中以固定時(shí)間步長(zhǎng)運(yùn)行。引擎中的體現(xiàn)Unity:FixedUpdate()函數(shù)。它的調(diào)用間隔由Time.fixedDeltaTime設(shè)置獨(dú)立于幀率。Unreal Engine: 物理線程的更新。UE的物理模擬在獨(dú)立的線程中以固定時(shí)間步長(zhǎng)運(yùn)行。Godot:_physics_process(delta)函數(shù)。參數(shù)delta是引擎配置的固定物理步長(zhǎng)。為什么物理必須用固定更新物理引擎如Box2D, PhysX的模擬穩(wěn)定性高度依賴于固定的時(shí)間步長(zhǎng)?？勺兊臅r(shí)間步長(zhǎng)會(huì)導(dǎo)致積分誤差累積使模擬變得“軟”或“爆裂”產(chǎn)生不可預(yù)測(cè)的彈跳或穿透。固定更新讓物理定律在游戲世界中穩(wěn)定生效。實(shí)戰(zhàn)心得在FixedUpdate中處理所有與物理相關(guān)的操作Rigidbody的力/速度修改、碰撞檢測(cè)后的邏輯。但要注意FixedUpdate的調(diào)用頻率可能高于或低于Update因此不適合在這里處理每幀都需要響應(yīng)的輸入如按鍵按下這類輸入最好在Update中采樣然后在FixedUpdate中使用。3.2 可變更新模式UI、動(dòng)畫與視覺(jué)特效的舞臺(tái)邏輯更新直接依賴每一幀的實(shí)際耗時(shí)。引擎中的體現(xiàn)Unity:Update()函數(shù)。參數(shù)Time.deltaTime是上一幀到這一幀的實(shí)際時(shí)間差。Unreal Engine: Actor 組件的Tick函數(shù)。參數(shù)DeltaTime是可變的時(shí)間差。Godot:_process(delta)函數(shù)。參數(shù)delta是上一幀的實(shí)際耗時(shí)。核心技巧與deltaTime相乘。這是解決“游戲速度依賴幀率”問(wèn)題的鑰匙。無(wú)論這一幀花了0.016秒還是0.1秒當(dāng)你需要讓一個(gè)物體勻速移動(dòng)時(shí)應(yīng)該這樣寫// Unity C# 示例 void Update() { // 錯(cuò)誤幀率相關(guān)移動(dòng) // transform.position Vector3.right * moveSpeed; // 正確幀率無(wú)關(guān)移動(dòng) transform.position Vector3.right * moveSpeed * Time.deltaTime; }moveSpeed * Time.deltaTime表示“這一幀應(yīng)該移動(dòng)的距離”。幀率高deltaTime小單次移動(dòng)距離小但更新次數(shù)多總距離不變幀率低則反之。適用場(chǎng)景攝像機(jī)跟隨、非物理動(dòng)畫、粒子特效更新、即時(shí)響應(yīng)的用戶界面、游戲狀態(tài)機(jī)中與絕對(duì)時(shí)間無(wú)關(guān)的部分。這些內(nèi)容對(duì)時(shí)間的連續(xù)性要求不高更追求與視覺(jué)渲染的同步。3.3 混合更新模式取長(zhǎng)補(bǔ)短的通用策略這是最常用、最健壯的架構(gòu)。游戲循環(huán)采用固定更新來(lái)處理核心邏輯物理、游戲規(guī)則同時(shí)保留可變更新來(lái)處理渲染相關(guān)和即時(shí)性要求高的邏輯。架構(gòu)優(yōu)勢(shì)穩(wěn)定性物理和核心規(guī)則在固定的時(shí)間流中運(yùn)行杜絕了因性能波動(dòng)導(dǎo)致的怪異行為。平滑性通過(guò)渲染插值即使邏輯幀率固定且低于渲染幀率畫面也能極其平滑。例如邏輯固定50Hz渲染跑在144Hz通過(guò)插值玩家依然能看到非常流暢的運(yùn)動(dòng)。性能彈性在性能吃緊時(shí)可以通過(guò)減少渲染分辨率或特效來(lái)維持邏輯幀的穩(wěn)定保證游戲“可玩性”不崩塌。邏輯卡頓比渲染卡頓更致命。一個(gè)常見(jiàn)的坑輸入處理。輸入事件鼠標(biāo)點(diǎn)擊、按鍵按下是瞬時(shí)發(fā)生的可能發(fā)生在兩個(gè)邏輯幀之間。如果只在FixedUpdate里讀取輸入可能會(huì)丟失這些事件。最佳實(shí)踐是在Update中緩存輸入狀態(tài)在FixedUpdate中使用。例如在Unity中Input.GetKeyDown這類瞬時(shí)輸入應(yīng)在Update中檢測(cè)并設(shè)置一個(gè)標(biāo)志位在FixedUpdate中消費(fèi)這個(gè)標(biāo)志位并重置。4. 進(jìn)階議題與性能調(diào)優(yōu)讓游戲循環(huán)更健壯理解了基礎(chǔ)模式我們還需要面對(duì)一些更棘手的問(wèn)題這些問(wèn)題直接關(guān)系到游戲的最終品質(zhì)。4.1 “螺旋式下降”與時(shí)間縮放當(dāng)某一幀因?yàn)榧虞d資源、復(fù)雜計(jì)算等原因耗時(shí)異常長(zhǎng)比如超過(guò)200ms會(huì)發(fā)生什么在固定更新模式下為了追上滯后時(shí)間游戲循環(huán)會(huì)連續(xù)執(zhí)行非常多次FixedUpdate直到lag被清空。在這段時(shí)間內(nèi)游戲會(huì)完全無(wú)響應(yīng)因?yàn)镃PU被邏輯更新占滿了。這就是“死亡螺旋”或“螺旋式下降”。應(yīng)對(duì)策略設(shè)置最大迭代次數(shù)在追趕循環(huán)中設(shè)置一個(gè)上限例如一幀最多執(zhí)行10次邏輯更新。超出的滯后時(shí)間直接丟棄。這會(huì)導(dǎo)致游戲輕微丟幀但避免了卡死。Unity的Time.maximumDeltaTime就起這個(gè)作用。動(dòng)態(tài)時(shí)間縮放對(duì)于非核心的、純視覺(jué)的邏輯如部分粒子系統(tǒng)、背景動(dòng)畫可以將其deltaTime與一個(gè)全局的時(shí)間縮放系數(shù)相乘。在性能緊張時(shí)調(diào)低這個(gè)系數(shù)讓這些次要效果“慢放”為核心邏輯爭(zhēng)取CPU時(shí)間。負(fù)載分離與多線程將物理、AI、音頻等計(jì)算密集型任務(wù)放到獨(dú)立的線程或作業(yè)系統(tǒng)中避免阻塞主游戲循環(huán)。4.2 渲染插值的具體實(shí)現(xiàn)插值不是魔法需要開(kāi)發(fā)者提供支持。通常你需要為每個(gè)需要平滑渲染的對(duì)象存儲(chǔ)“上一個(gè)邏輯狀態(tài)”和“當(dāng)前邏輯狀態(tài)”。// 一個(gè)簡(jiǎn)化的插值組件概念 public class InterpolatedTransform : MonoBehaviour { private Vector3 _lastPosition; private Vector3 _currentPosition; private Quaternion _lastRotation; private Quaternion _currentRotation; void FixedUpdate() { // 在邏輯更新中記錄狀態(tài) _lastPosition _currentPosition; _lastRotation _currentRotation; _currentPosition rigidbody.position; // 來(lái)自物理引擎的最新位置 _currentRotation rigidbody.rotation; } void Update() { // 在渲染更新中根據(jù)插值因子alpha計(jì)算顯示位置 float alpha Time.timeSinceLastFixedUpdate / Time.fixedDeltaTime; transform.position Vector3.Lerp(_lastPosition, _currentPosition, alpha); transform.rotation Quaternion.Slerp(_lastRotation, _currentRotation, alpha); } }這里Time.timeSinceLastFixedUpdate是Unity提供的、自上一次FixedUpdate以來(lái)的累積時(shí)間用它除以固定時(shí)間步長(zhǎng)就得到了上面?zhèn)未a中的interpolationAlpha。Lerp和Slerp是線性插值函數(shù)。這樣渲染的Transform就是邏輯位置之間的平滑過(guò)渡即使邏輯幀率只有30在60幀的屏幕上觀看也絲滑流暢。4.3 網(wǎng)絡(luò)游戲中的時(shí)間同步在網(wǎng)絡(luò)游戲中邏輯幀的概念被提升到了戰(zhàn)略高度。為了同步多個(gè)客戶端通常會(huì)采用權(quán)威服務(wù)器模型和鎖步邏輯或狀態(tài)同步。鎖步邏輯所有客戶端以完全相同的邏輯幀率運(yùn)行。每一幀各客戶端將本地玩家的操作指令發(fā)送給服務(wù)器服務(wù)器收集齊所有玩家該幀的指令后廣播各客戶端收到后才執(zhí)行該幀邏輯。這保證了絕對(duì)的確定性但延遲和掉線懲罰很大。狀態(tài)同步與客戶端預(yù)測(cè)服務(wù)器以固定頻率邏輯幀向客戶端廣播整個(gè)游戲世界的快照?？蛻舳嗽趦纱慰煺罩g根據(jù)收到的上一個(gè)狀態(tài)和本地輸入預(yù)測(cè)物體的位置并進(jìn)行渲染這就是客戶端的“邏輯幀”和“渲染幀”。當(dāng)收到服務(wù)器的新快照時(shí)如果預(yù)測(cè)有誤則需要進(jìn)行“位置修正”或“狀態(tài)回滾”。這里的挑戰(zhàn)在于如何平滑地糾正避免畫面抖動(dòng)。此時(shí)固定邏輯幀率、插值渲染和延遲補(bǔ)償算法變得無(wú)比重要。5. 不同引擎下的實(shí)戰(zhàn)配置與避坑指南理論最終要落地。我們來(lái)看看在主流引擎中如何正確配置和使用這兩套系統(tǒng)。5.1 Unity清晰區(qū)分的雙軌制Unity明確區(qū)分了Update和FixedUpdate是學(xué)習(xí)此概念的絕佳環(huán)境。關(guān)鍵設(shè)置Edit - Project Settings - TimeFixed Timestep這是邏輯幀F(xiàn)ixedUpdate的間隔。默認(rèn)0.02秒50Hz。對(duì)于需要高精度物理的游戲如賽車、平臺(tái)跳躍可以提高到0.01秒100Hz或0.005秒200Hz但這會(huì)增加CPU負(fù)擔(dān)。Maximum Allowed Timestep防止“螺旋式下降”的最大一幀F(xiàn)ixedUpdate執(zhí)行時(shí)間。默認(rèn)0.333秒。意味著如果一幀渲染耗時(shí)超過(guò)0.333秒邏輯也只追趕0.333秒的時(shí)間剩下的滯后被丟棄。Time Scale全局時(shí)間縮放系數(shù)。設(shè)置為0可以暫停游戲用于實(shí)現(xiàn)暫停菜單。避坑要點(diǎn)不要在FixedUpdate中調(diào)用Input.GetMouseButtonDown你很可能漏掉點(diǎn)擊。應(yīng)在Update中檢測(cè)。Rigidbody的操作應(yīng)放在FixedUpdate直接修改速度、施加力等。在Update中修改Rigidbody.position可能會(huì)與物理引擎的計(jì)算沖突。理解Time.deltaTime與Time.fixedDeltaTime在Update中用前者在FixedUpdate中用后者。在FixedUpdate中如果錯(cuò)誤地使用了Time.deltaTime它返回的其實(shí)是Time.fixedDeltaTime的當(dāng)前值雖然不會(huì)導(dǎo)致速度差異但會(huì)破壞代碼的清晰性。攝像跟隨如果攝像機(jī)跟隨一個(gè)由物理控制的物體簡(jiǎn)單的在Update中使用Transform.position會(huì)看到抖動(dòng)。因?yàn)槲锢砀略贔ixedUpdate而攝像機(jī)在Update讀取位置時(shí)物理可能還沒(méi)更新完這一幀。解決方案是使用LateUpdate在所有Update之后執(zhí)行或者使用上面提到的插值技術(shù)讀取Rigidbody的插值位置。5.2 Unreal Engine基于Tick的靈活配置UE的架構(gòu)更靈活任何Actor或組件都可以通過(guò)設(shè)置自己的Tick函數(shù)來(lái)參與游戲循環(huán)。關(guān)鍵配置在Actor或組件的屬性細(xì)節(jié)面板中可以找到Tick相關(guān)設(shè)置Tick Interval設(shè)置固定的Tick間隔秒。設(shè)為0則每幀都Tick可變更新設(shè)為大于0的值如0.0167則進(jìn)行固定間隔更新。Start with Tick Enabled是否開(kāi)始時(shí)就啟用Tick。Tick Group設(shè)置Tick的執(zhí)行順序組如PrePhysics, DuringPhysics, PostPhysics。這對(duì)于有依賴關(guān)系的更新順序至關(guān)重要。避坑要點(diǎn)性能意識(shí)默認(rèn)啟用Tick的Actor過(guò)多是性能殺手。不需要每幀更新的邏輯務(wù)必設(shè)置Tick Interval或直接禁用Tick。物理交互涉及物理模擬的移動(dòng)應(yīng)使用UE的物理系統(tǒng)如Projectile Movement Component或自己在物理Tick組中進(jìn)行計(jì)算避免直接修改位置導(dǎo)致與物理引擎不同步。Timers與Event對(duì)于不需要精確每幀執(zhí)行的周期性任務(wù)如每秒檢查一次使用UE的定時(shí)器系統(tǒng)FTimerManager比自己寫Tick判斷更高效、更清晰。5.3 自制游戲循環(huán)知其所以然如果你在使用SDL、SFML、GLFW等庫(kù)從零開(kāi)始寫游戲你需要親手搭建這個(gè)循環(huán)。這時(shí)上面那個(gè)經(jīng)典偽代碼就是你的藍(lán)圖。精度計(jì)時(shí)器使用std::chrono(C) 或QueryPerformanceCounter(Windows) 等高精度計(jì)時(shí)API來(lái)獲取當(dāng)前時(shí)間避免使用不精確的Sleep函數(shù)。控制渲染頻率在循環(huán)末尾如果一幀處理得太快可以計(jì)算剩余時(shí)間并Sleep一會(huì)兒以減少CPU占用。但更好的方法是使用垂直同步讓顯卡來(lái)限制幀率。處理輸入事件在循環(huán)開(kāi)始處集中處理所有累積的輸入事件如SDL_PollEvent并將它們轉(zhuǎn)換為游戲內(nèi)部可理解的命令或狀態(tài)供后續(xù)的邏輯更新使用。理解邏輯幀與物理幀掌握游戲循環(huán)的設(shè)計(jì)是游戲開(kāi)發(fā)者從“寫功能”到“做產(chǎn)品”的關(guān)鍵一步。它決定了你的游戲是只能在你的高性能開(kāi)發(fā)機(jī)上運(yùn)行還是一個(gè)能在千差萬(wàn)別的玩家設(shè)備上提供穩(wěn)定、一致體驗(yàn)的合格產(chǎn)品。下次當(dāng)你的游戲出現(xiàn)速度問(wèn)題時(shí)不要只想著優(yōu)化圖形先檢查一下你的時(shí)間管理或許問(wèn)題就迎刃而解了。