無(wú)論如何，我們就這樣湊合了好一陣子，直到死亡回放(Killcam)需求的出現(xiàn)。

          為了實(shí)現(xiàn)Killcam，我們會(huì)有兩個(gè)不同的、并行的游戲環(huán)境，一個(gè)用來(lái)進(jìn)行實(shí)時(shí)游戲過(guò)程渲染，一個(gè)用來(lái)專門做Killcam。我接下來(lái)會(huì)展示它們是如何實(shí)現(xiàn)的。

首先，也很直接，我會(huì)添加第二個(gè)全新的ECS World，現(xiàn)在就有兩個(gè)World了，一個(gè)是liveGame(正常游戲)，一個(gè)是replayGame用來(lái)實(shí)現(xiàn)回放（Replay）。

回放(Replay)的工作方式是這樣的，服務(wù)器會(huì)下發(fā)大概8到12秒左右的網(wǎng)絡(luò)游戲數(shù)據(jù)，接著客戶端翻轉(zhuǎn)World，開始渲染replayAdmin這個(gè)World的信息到玩家屏幕上。然后轉(zhuǎn)發(fā)網(wǎng)絡(luò)游戲數(shù)據(jù)給replayAdmin，假裝這些數(shù)據(jù)真的是來(lái)自網(wǎng)絡(luò)的。此時(shí)，所有的System，所有的組件，所有的行為都不知道它們并沒(méi)有被預(yù)測(cè)(predict，譯注：后面才講到的同步技術(shù))，它們以為客戶端就是實(shí)時(shí)運(yùn)行在網(wǎng)絡(luò)上的，像正常游戲過(guò)程一樣。

聽起來(lái)很酷吧？如果有人想要了解更多關(guān)于回放的技術(shù)，我建議你們明天去聽一下Phil Orwig的分享，也是在這個(gè)房間，上午11點(diǎn)整。

無(wú)論如何，到現(xiàn)在我們已經(jīng)知道的是：首先，所有需要全局訪問(wèn)System的調(diào)用點(diǎn)（call sites）會(huì)突然出錯(cuò)(譯注：Tim思維太跳躍了，突然話鋒一轉(zhuǎn)，完全跟不上)；另外，不再只有唯一一個(gè)全局EntityAdmin了，現(xiàn)在有兩個(gè)；System A無(wú)法直接訪問(wèn)全局System B，不知怎地，只能通過(guò)共享的EntityAdmin來(lái)訪問(wèn)了，這樣很繞。

在Killcam之后，我們花了很長(zhǎng)時(shí)間來(lái)回顧我們的編程模式的缺陷，包括：怪異的訪問(wèn)模式；編譯周期太長(zhǎng)；最危險(xiǎn)的是內(nèi)部系統(tǒng)的耦合?？雌饋?lái)我們有大麻煩了。

針對(duì)這些問(wèn)題的最終解決方案，依賴于這樣一個(gè)事實(shí)：開發(fā)一個(gè)只有唯一實(shí)例的組件其實(shí)沒(méi)什么不對(duì)！根據(jù)這個(gè)原則，我們實(shí)現(xiàn)了一個(gè)單例（Singleton）組件。

          這些組件屬于單一的匿名實(shí)體，可以通過(guò)EntityAdmin直接訪問(wèn)。我們把System中的大部分狀態(tài)都移到了單例中。

          這里我要提一句，只需要被一個(gè)System訪問(wèn)的狀態(tài)其實(shí)是很罕見(jiàn)的。后來(lái)在開發(fā)一個(gè)新System的過(guò)程中我們保持了這個(gè)習(xí)慣，如果發(fā)現(xiàn)這個(gè)系統(tǒng)需要依賴一些狀態(tài)。就做一個(gè)單例來(lái)存儲(chǔ)，幾乎每一次都會(huì)發(fā)現(xiàn)其他一些System也同樣需要這些狀態(tài)，所以這里其實(shí)已經(jīng)提前解決了前面架構(gòu)里的耦合問(wèn)題。

下面是一個(gè)單例輸入的例子。

全部按鍵信息都存在一個(gè)單例里面，只是我們把它從InputSystem中移出來(lái)了。任何System如果想知道按鍵是否按下，只需要隨便拿一個(gè)組件來(lái)詢問(wèn)（那個(gè)單例）就行了。這樣做以后，一些很麻煩的耦合問(wèn)題消失了，我們也更加遵循ECS的架構(gòu)哲學(xué)了：System沒(méi)有狀態(tài)；組件不帶行為。

按鍵并不是行為，掌管本地玩家移動(dòng)的Movement System里有一個(gè)行為，用這個(gè)單例來(lái)預(yù)測(cè)本地玩家的移動(dòng)。而MovementStateSystem里有個(gè)行為是把這些按鍵信息打包發(fā)到服務(wù)器（譯注：按鍵對(duì)于不同的System就不是不同的主體）。

結(jié)果發(fā)現(xiàn)，單例模式的使用非常普遍，我們整個(gè)游戲里的40%組件都是單例的。

一旦我們把某些System狀態(tài)移到單例中，會(huì)把共享的System函數(shù)分解成Utility（實(shí)用）函數(shù)，這些函數(shù)需要在那些單例上運(yùn)行，這又有點(diǎn)耦合了，我們接下來(lái)會(huì)詳細(xì)討論。

改造后如圖22，InputSystem依然存在（譯注：然而并沒(méi)有看到InputSystem在哪里），它負(fù)責(zé)從操作系統(tǒng)讀取輸入操作，填充SingletonInput的值，然后下游的其他System就可以得到同樣的Input去做它們想做的。

像按鍵映射之類的事情就可以在單例里實(shí)現(xiàn)，就與CommandSystem解耦了。

我們把PostBuildPlayerCommand函數(shù)也挪到了CommandSysem里，本應(yīng)如此，現(xiàn)在可以保證所有對(duì)玩家輸入的命令（PlayerCommand）的修改都能且僅能在此處進(jìn)行了。這些玩家命令是很重要的數(shù)據(jù)結(jié)構(gòu)，將來(lái)會(huì)在網(wǎng)絡(luò)上同步并用來(lái)模擬游戲過(guò)程。

在引入單例組件時(shí)，我們還不知道，我們其實(shí)正在打造的是一個(gè)解耦合、降低復(fù)雜度的開發(fā)模式。在這個(gè)例子中，CommandSystem是唯一一處能夠產(chǎn)生與玩家輸入命令相關(guān)副作用的地方（譯注：sideeffect，指當(dāng)調(diào)用函數(shù)時(shí)，除了返回函數(shù)值之外，還對(duì)主調(diào)用函數(shù)產(chǎn)生附加影響，例如修改全局變量了）。

每個(gè)程序員都能輕易地了解玩家命令的變化，因?yàn)樵谝淮?span>System更新的同一時(shí)刻，只有這一處代碼有可能產(chǎn)生變化。如果想添加針對(duì)玩家命令的修改代碼，那也很明朗，只能在這個(gè)源文件中改，所有的模棱兩可都消失了。

          現(xiàn)在討論另外一個(gè)問(wèn)題，與共享行為(sharedbehavior)有關(guān)。

          共享行為一般出現(xiàn)在同一行為被多個(gè)System用到的時(shí)候。

有時(shí)，同一個(gè)主體的兩個(gè)觀察者，會(huì)對(duì)同一個(gè)行為感興趣?；氐角懊鏅鸦涞睦樱愕男^(qū)業(yè)委會(huì)主席和園丁，可能都想知道這棵樹會(huì)在春天到來(lái)的時(shí)候，掉落多少葉子。

根據(jù)這個(gè)輸出可以做不同的處理，至少主席可能會(huì)沖你大喊大叫，園丁會(huì)老老實(shí)實(shí)回去干活，但是這里的行為是相同的。

舉個(gè)例子，大量代碼都會(huì)關(guān)心“敵對(duì)關(guān)系”，例如，實(shí)體A與實(shí)體B互相敵對(duì)嗎？敵對(duì)關(guān)系是由3個(gè)可選組件共同決定的：filter bits，pet master和pet。filter bits存儲(chǔ)隊(duì)伍編號(hào)（team index）；pet master存儲(chǔ)了它所擁有全部pet的唯一鍵；pet一般用于像托比昂的炮臺(tái)之類。

如果2個(gè)實(shí)體都沒(méi)有filter bits，那么它們就不是敵對(duì)的。所以對(duì)于兩扇門來(lái)說(shuō)，它們就不是敵對(duì)的，因?yàn)樗鼈兊?span>filter bits組件沒(méi)有隊(duì)伍編號(hào)。

如果它們(譯注：2個(gè)實(shí)體)都在同一個(gè)隊(duì)伍，那自然就不是敵對(duì)的，這很容易理解。

如果它們分別屬于永遠(yuǎn)敵對(duì)的2個(gè)隊(duì)伍，它們會(huì)同時(shí)檢查自己身上和對(duì)方身上的pet master組件，確保每個(gè)pet都和對(duì)方是敵對(duì)關(guān)系。這也解決了一個(gè)問(wèn)題：如果你跟每個(gè)人都是敵對(duì)的，那么當(dāng)你建造一個(gè)炮臺(tái)時(shí)，炮臺(tái)會(huì)立馬攻擊你（譯注：完全沒(méi)理解為什么會(huì)這樣）。確實(shí)會(huì)的，這是個(gè)bug，我們修復(fù)了。（眾笑）

如果你想檢查一枚飛行中的炮彈的敵對(duì)關(guān)系，只需要回溯檢查射出這枚炮彈的開火者就行了，很簡(jiǎn)單。

這個(gè)例子的實(shí)現(xiàn)，其實(shí)就是個(gè)函數(shù)調(diào)用，函數(shù)名是CombatUtilityIsHostile，它接受2個(gè)實(shí)體作為參數(shù)，并返回true或者false來(lái)代表它們是否敵對(duì)。無(wú)數(shù)System都調(diào)用了這個(gè)函數(shù)。

圖25中就是調(diào)用了這個(gè)函數(shù)的System，但是如你所見(jiàn)，只用到了3個(gè)組件，少得可憐，而且這3個(gè)組件對(duì)它們都是只讀的。更重要的是，它們是純數(shù)據(jù)，而且這些System絕不會(huì)修改里面的數(shù)據(jù)，僅僅是讀。

再舉一個(gè)用到這個(gè)函數(shù)的例子。

作為一個(gè)例子，當(dāng)用到共享行為的Utility函數(shù)時(shí)我們采用了不同的規(guī)則。

如果你想在多處調(diào)用一個(gè)Utility函數(shù)，那么這個(gè)函數(shù)就應(yīng)該依賴很少的組件，而且不應(yīng)該帶副作用或者很少的副作用。如果你的Utility函數(shù)依賴很多組件，那就試著限制調(diào)用點(diǎn)的數(shù)量。

我們這里的例子叫做CharacterMoveUtil，這個(gè)函數(shù)用來(lái)在游戲模擬過(guò)程中的每個(gè)tick里移動(dòng)玩家位置。有兩處調(diào)用點(diǎn),一處是在服務(wù)器上模擬執(zhí)行玩家的輸入命令，另一處是在客戶端上預(yù)測(cè)玩家的輸入。

          我們繼續(xù)用Utility函數(shù)替換 System間的函數(shù)調(diào)用，并把狀態(tài)從System移到單例組件中。

如果你打算用一個(gè)共享的Utility函數(shù)替換System間的函數(shù)調(diào)用，是不可能自動(dòng)地(magically)避免復(fù)雜性的，幾乎都得做語(yǔ)句級(jí)的調(diào)整。

正如你可以把副作用都隱藏在那些公開訪問(wèn)的System函數(shù)后面一樣，你也可以在Utility函數(shù)后面做同樣的事。

如果你需要從好幾處調(diào)用那些Utility函數(shù)，就會(huì)在整個(gè)游戲循環(huán)中引入很多嚴(yán)重的副作用。雖然是在函數(shù)調(diào)用后面發(fā)生的，看起來(lái)沒(méi)那么明顯，但這也是相當(dāng)可怕的耦合。

如果本次分享只讓你學(xué)到一點(diǎn)的話，那最好是：如果只有一個(gè)調(diào)用點(diǎn)，那么行為的復(fù)雜性就會(huì)很低，因?yàn)樗械母弊饔枚枷薅ǖ胶瘮?shù)調(diào)用發(fā)生的地方了。

          下面瀏覽一下我們用來(lái)減少這類耦合的技術(shù)。

當(dāng)你發(fā)現(xiàn)有些行為可能產(chǎn)生嚴(yán)重的副作用，又必須執(zhí)行時(shí)，先問(wèn)問(wèn)你自己：這些代碼，是必須現(xiàn)在就執(zhí)行嗎？

好的單例組件可以通過(guò)“推遲”（Deferment）來(lái)解決System間耦合的問(wèn)題。“推遲”存儲(chǔ)了行為所需狀態(tài)，然后把副作用延后到當(dāng)前幀里更好的時(shí)機(jī)再執(zhí)行。

例如，代碼里有好多調(diào)用點(diǎn)都要生成一個(gè)碰撞特效(impact effects)。

包括hitscan(譯注：直射，沒(méi)有飛行時(shí)間)子彈；帶飛行時(shí)間的可爆炸拋射物；查里婭的粒子光束，光束長(zhǎng)得就像墻壁裂縫，而且在開火時(shí)需要保持接觸目標(biāo)；另外還有噴涂。

創(chuàng)建碰撞特效的副作用很大，因?yàn)槟阈枰谄聊簧蟿?chuàng)建一個(gè)新的實(shí)體，這個(gè)實(shí)體可能間接地影響到生命周期、線程、場(chǎng)景管理和資源管理。

碰撞特效的生命周期，需要在屏幕渲染之前就開始，這意味著它們不需要在游戲模擬的中途顯現(xiàn)，在不同的調(diào)用點(diǎn)都是如此。

下圖30是用來(lái)創(chuàng)建碰撞特效的一小部分代碼。基于Transform（譯注：變形，包括位移旋轉(zhuǎn)和縮放）、碰撞類型、材質(zhì)結(jié)構(gòu)數(shù)據(jù)來(lái)做碰撞計(jì)算，而且還調(diào)用了LOD、場(chǎng)景管理、優(yōu)先級(jí)管理等，最終生成了所需的特效。

      這些代碼確保了像彈孔、焦痕持久特效不會(huì)很奇怪的疊在一起。例如，你用獵空的槍去射擊一面墻，留下了一堆麻點(diǎn)，然后法老之鷹發(fā)出一枚火箭彈，在麻點(diǎn)上面造成了一個(gè)大面積焦痕。你肯定想刪了那些麻點(diǎn)，要不然看起來(lái)會(huì)很丑，像是那種深度沖突（Z-Fighting）引起的閃爍。我可不想在到處去執(zhí)行那個(gè)刪除操作，最好能在一處搞定。

          我得修改代碼了，但是看上去好多啊，調(diào)用點(diǎn)一大堆，改完了以后每一處都需要測(cè)試。而且以后英雄越來(lái)越多，每個(gè)人都需要新的特效。然后我就到處復(fù)制粘貼這個(gè)函數(shù)的調(diào)用，沒(méi)什么大不了的，不就是個(gè)函數(shù)調(diào)用嘛，又不是什么噩夢(mèng)。（眾笑）

          其實(shí)這樣做以后，會(huì)在每個(gè)調(diào)用點(diǎn)都產(chǎn)生副作用的。程序員就得花費(fèi)更多腦力來(lái)記住這段代碼是如何運(yùn)作的，這就是代碼復(fù)雜度所在，肯定是應(yīng)該避免的。

          于是我們有了Contact單例。

          它包含了一個(gè)未決的碰撞記錄的數(shù)組，每個(gè)記錄都有足夠的信息，來(lái)在本幀的晚些時(shí)候創(chuàng)建那個(gè)特效。如果你想要生成一個(gè)特效的時(shí)候，只需要添加一條新記錄并填充數(shù)據(jù)就可以了。等運(yùn)行到幀的后期，進(jìn)行場(chǎng)景更新和準(zhǔn)備渲染的時(shí)候，ResolveContactSystem會(huì)遍歷數(shù)組，根據(jù)LOD規(guī)則生成特效并互相疊加。這樣的話，即使有嚴(yán)重的副作用，在每一幀也只是發(fā)生在一個(gè)調(diào)用點(diǎn)而已。

          除了降低復(fù)雜度以外，“推遲”方案還有很多其他優(yōu)點(diǎn)。數(shù)據(jù)和指令都緩存在本地，可以帶來(lái)性能提升；你可以針對(duì)特效做性能預(yù)算了，例如你有12個(gè)D.VA同時(shí)在射墻，她們會(huì)帶來(lái)數(shù)百個(gè)特效，你不用立即創(chuàng)建全部這些特效，你可以僅僅創(chuàng)建自己操縱的D.VA的特效就可以了，其他特效可以在后面的運(yùn)算過(guò)程中分?jǐn)傞_來(lái)，平滑性能毛刺。這樣做有很多好處，真的，你現(xiàn)在可以實(shí)現(xiàn)一些復(fù)雜的邏輯了。即使ResolveContactSystem需要執(zhí)行多線程協(xié)作，來(lái)確定單個(gè)粒子效果的朝向， 現(xiàn)在也很容易做。“推遲”技術(shù)真的很酷。

Utility函數(shù)，單例，推遲，這些都只是我們過(guò)去3年時(shí)間建立ECS架構(gòu)的一小部分模式。除了限制System中不能有狀態(tài)，組件里不能有行為以外，這些技術(shù)也規(guī)定了我們?cè)?span>Overwatch中如何解決問(wèn)題。

遵守這些限制意味著你要用很多奇技淫巧來(lái)解決問(wèn)題。不過(guò)，這些技術(shù)最終造就了一個(gè)可持續(xù)維護(hù)的、解耦合的、簡(jiǎn)潔的代碼系統(tǒng)。它限制了你，它把你帶到坑里，但這是個(gè)“成功之坑”。

學(xué)習(xí)了這些之后呢，咱們來(lái)聊聊真正的難題之一，以及ECS是如何簡(jiǎn)化它的。

作為gameplay(游戲玩法，機(jī)制)工程師，我們解決過(guò)的最重要的問(wèn)題就是網(wǎng)絡(luò)同步（netcode）。

這里先說(shuō)下目標(biāo)，是要開發(fā)一款快速響應(yīng)（responsive）的網(wǎng)絡(luò)對(duì)戰(zhàn)動(dòng)作游戲。為了實(shí)現(xiàn)快速響應(yīng)，就必須針對(duì)玩家的操作做預(yù)測(cè)（predict，也可以說(shuō)是預(yù)表現(xiàn)）。如果每個(gè)操作都要等服務(wù)器回包的話，就不可能有高響應(yīng)性了。盡管因?yàn)橐恍┗斓巴婕易鞅姿圆荒苄湃慰蛻舳耍且呀?jīng)20年了，這條FPS游戲真理沒(méi)變過(guò)。

          游戲中有快速響應(yīng)需求的操作包括：移動(dòng)，技能，就我們而言還有帶技能的武器，以及命中判定（hit registration）。

這里所有的操作都有統(tǒng)一的原則：玩家按下按鍵后必須立即能夠看到響應(yīng)。即使網(wǎng)絡(luò)延遲很高時(shí)也必須是如此。

像我這頁(yè)PPT中演示的那樣，ping值已經(jīng)250ms了，我所有的操作也都是立即得到反饋的，“看上去”很完美，一點(diǎn)延遲都沒(méi)有。

然而呢，帶預(yù)測(cè)的客戶端，服務(wù)器的驗(yàn)證和網(wǎng)絡(luò)延遲就會(huì)帶來(lái)副作用：預(yù)測(cè)錯(cuò)誤（misprediction，或者說(shuō)預(yù)測(cè)失?。┝恕ｎA(yù)測(cè)錯(cuò)誤的主要癥狀就一點(diǎn)，會(huì)使得你沒(méi)能成功執(zhí)行“你認(rèn)為你已經(jīng)做出的”操作。

雖然服務(wù)器需要糾正你的操作，但代價(jià)并不會(huì)是操作延遲。我們會(huì)用”確定性”（Determinism）來(lái)減少預(yù)測(cè)錯(cuò)誤發(fā)生的概率，下面是具體的做法。

          前提條件不變，PING值還是250毫秒。我認(rèn)為我跳起來(lái)了，但是服務(wù)器不這么看，我被猛拉回原地，而且被凍住了（冰凍是英雄Mei的技能之一）。這里（PPT中視頻演示）你甚至可以看到整個(gè)預(yù)測(cè)的工作過(guò)程。預(yù)測(cè)過(guò)程開始時(shí)，試圖把我們移到空中，甚至大猩猩跳躍技能的CD都已經(jīng)進(jìn)入冷卻了，這是對(duì)的，我們不希望預(yù)測(cè)準(zhǔn)確率僅僅是十之八九。所以我們希望盡可能的快速響應(yīng)，

如果你碰巧在斯里蘭卡玩這個(gè)游戲，而且又被Mei凍住了，那么就有可能會(huì)預(yù)測(cè)錯(cuò)誤。

下面我會(huì)首先給出一些準(zhǔn)則，然后討論一下這個(gè)嶄新的技術(shù)是如何利用ECS來(lái)減少?gòu)?fù)雜度的。

          這里不會(huì)涉及到通用的數(shù)據(jù)復(fù)制技術(shù)、遠(yuǎn)端實(shí)體插值（remote entity interpolation）或者是向后緩和（backwardsreconciliation）技術(shù)細(xì)節(jié)。

我們完全是站在巨人的肩膀上，使用了一些其他文獻(xiàn)中提過(guò)的技術(shù)而已。后面的幻燈片會(huì)假定大家對(duì)那些技術(shù)都已經(jīng)很熟悉了。

確定性(Determinism)

          確定性模擬技術(shù)依賴于時(shí)鐘的同步，固定的更新周期和量化。服務(wù)器和客戶端都運(yùn)行在這個(gè)保持同步的時(shí)鐘和量化值之上。時(shí)間被量化成command frame，我們稱之為“命令幀”。每個(gè)命令幀都是固定的16毫秒，不過(guò)在電競(jìng)比賽時(shí)是7毫秒。

          模擬過(guò)程的頻率是固定的，所以需要把計(jì)算機(jī)時(shí)鐘循環(huán)轉(zhuǎn)換為固定的命令幀序號(hào)。我們使用了一個(gè)循環(huán)累加器來(lái)處理幀號(hào)的增長(zhǎng)。

在我們的ECS框架內(nèi)，任何需要進(jìn)行預(yù)表現(xiàn)、或者基于玩家的輸入模擬結(jié)果的System，都不會(huì)使用Update，而是用UpdateFixed。UpdateFixed會(huì)在每個(gè)固定的命令幀調(diào)用。

          假定輸出流是穩(wěn)定的，那么客戶端的始終總是會(huì)超前于服務(wù)器的，超前了大概半個(gè)RTT加上一個(gè)緩存幀的時(shí)長(zhǎng)。這里的RTT是PING值加上邏輯處理的時(shí)間。上圖39的例子中，我們的RTT是160毫秒，一半就是80毫秒，再加上1幀，我們每幀是16毫秒，全加起來(lái)就是客戶端相對(duì)于服務(wù)器的提前量。

          圖中的垂直線代表每一個(gè)處理中的幀?？蛻舳碎_始模擬并把第19幀的輸入上報(bào)給服務(wù)器，過(guò)一段時(shí)間（基本上是半個(gè)RTT加上緩沖時(shí)間）以后，服務(wù)器才開始模擬這一幀。這就是我為什么要說(shuō)客戶端永遠(yuǎn)是領(lǐng)先于服務(wù)器的。

          正因?yàn)榭蛻舳耸且还赡X的盡快接受玩家輸入，盡可能地貼近現(xiàn)在時(shí)刻，如果還需要等待服務(wù)器回包才能響應(yīng)的話，那看起來(lái)就太慢了，會(huì)讓游戲變得卡頓。圖39中的緩沖區(qū)，你肯定希望盡可能的?。ㄗg注：緩沖越小，模擬時(shí)就越接近當(dāng)前時(shí)刻），順便說(shuō)一句，游戲運(yùn)行的頻率是60赫茲，我這里播放動(dòng)畫的速度是正常速度的百分之一（譯注：這也是為了讓觀眾看得更清晰、明白）。

客戶端的預(yù)測(cè)System讀取當(dāng)前輸入，然后模擬獵空的移動(dòng)過(guò)程。我這里是用游戲搖桿來(lái)表示獵空的輸入操作并上報(bào)的。這里的（第14幀）獵空是我當(dāng)前時(shí)刻模擬出來(lái)的運(yùn)動(dòng)狀態(tài)，經(jīng)過(guò)完整的RTT加上緩沖事件，最終獵空會(huì)從服務(wù)器上回到客戶端（譯注：這里最好結(jié)合演講視頻，靜態(tài)的文章無(wú)法表達(dá)到位）。這里回來(lái)的是經(jīng)過(guò)服務(wù)器驗(yàn)證的運(yùn)動(dòng)狀態(tài)快照。服務(wù)器模擬權(quán)威帶來(lái)的副作用就是驗(yàn)證需要額外的半個(gè)RTT時(shí)間才能回到客戶端。

那么這里客戶端為什么要用一個(gè)環(huán)形緩沖（ring buffer）來(lái)記錄歷史運(yùn)動(dòng)軌跡呢？這是為了方便與服務(wù)器返回的結(jié)果進(jìn)行對(duì)比。經(jīng)過(guò)比較，如果與服務(wù)器模擬結(jié)果相同，那么客戶端會(huì)開開心心地繼續(xù)處理下一個(gè)輸入。如果結(jié)果不一致，那就是一個(gè)“預(yù)測(cè)錯(cuò)誤”，這時(shí)就需要“和解”（reconcile）了。

如果想簡(jiǎn)單，那就直接用服務(wù)器下發(fā)的結(jié)果覆蓋客戶端就行了，但是這個(gè)結(jié)果已經(jīng)是“舊”（相對(duì)于當(dāng)前時(shí)刻的輸入來(lái)講）的了，因?yàn)榉?wù)器的回包一般都是幾百毫秒之前的了。

除了上面那個(gè)環(huán)形緩沖以外，我們還有另一個(gè)環(huán)形緩沖用來(lái)存儲(chǔ)玩家的輸入操作。因?yàn)樘幚硪苿?dòng)的代碼是確定性的，一旦玩家開始進(jìn)入他想要進(jìn)入到移動(dòng)狀態(tài)，想要重現(xiàn)這個(gè)過(guò)程也是很容易的。所以這里我們的處理方式就是，一旦從服務(wù)器回包發(fā)現(xiàn)預(yù)測(cè)失敗，我們把你的全部輸入都重播一遍直至追上當(dāng)前時(shí)刻。如下圖41中的第17幀所示，客戶端認(rèn)為獵空正在跑路，而服務(wù)器指出，你已經(jīng)被暈住了，有可能是受到了麥克雷的閃光彈的攻擊。

接下來(lái)的流程是，當(dāng)客戶端收到描述角色狀態(tài)的數(shù)據(jù)包時(shí)，我們基本上就得把移動(dòng)狀態(tài)及時(shí)恢復(fù)到最近一次經(jīng)過(guò)服務(wù)器驗(yàn)證過(guò)狀態(tài)上去，而且必須重新計(jì)算之后所有的輸入操作，直至追上當(dāng)前時(shí)刻（第25幀）。

          現(xiàn)在客戶端進(jìn)行到第27幀（上圖）了，這時(shí)我們收到了服務(wù)器上第17幀的回包。一旦重新同步（譯注：注意下圖41中客戶端獵空的狀態(tài)全都更正為“暈”了）以后，就相當(dāng)于回退到了“幀同步”（lockstep）算法了。

我們肯定知道我們到底被暈了多久。

      到了下圖第33幀以后，客戶端就知道已經(jīng)不再是暈住的狀態(tài)了，而服務(wù)器上也正在模擬相同的情況。不再有奇怪的同步追趕問(wèn)題了。一旦進(jìn)入這個(gè)移動(dòng)狀態(tài)，就可以重發(fā)玩家當(dāng)前時(shí)刻的操作輸入了。

          然而，客戶端網(wǎng)絡(luò)并不保證如此穩(wěn)定，時(shí)有丟包發(fā)生。我們游戲里的輸入都是通過(guò)定制化的可靠UDP實(shí)現(xiàn)。所以客戶端的輸入包常常無(wú)法到達(dá)服務(wù)器，也就是丟包。服務(wù)器又試圖保持了一個(gè)小小的、保存未模擬輸入的緩沖區(qū)，但是讓它盡量的小，以保證游戲操作的流暢。

          一旦這個(gè)緩沖區(qū)是空的，服務(wù)器只能根據(jù)你最后一次輸入去“猜測(cè)”。等到真正的輸入到達(dá)時(shí)，它會(huì)試著“緩和”，確保不會(huì)弄丟你的任何操作，但是也會(huì)有預(yù)測(cè)錯(cuò)誤。

          下面是見(jiàn)證奇跡的時(shí)刻。

          上圖可以看到，已經(jīng)丟了一些來(lái)自客戶端的包，服務(wù)器意識(shí)到以后，就會(huì)復(fù)制先前的輸入操作來(lái)就行預(yù)測(cè)，一邊祈禱希望預(yù)測(cè)正確，一邊發(fā)包告訴客戶端：“嘿哥們，丟包了，不太對(duì)勁哦”。接下來(lái)發(fā)生的就更奇怪的了，客戶端會(huì)進(jìn)行時(shí)間膨脹，比約定的幀率更快地進(jìn)行模擬。