在 FPS 游戲里，一個角色被擊殺之后，往往會以敵方的視角回放本角色被定位、瞄準(zhǔn)、射擊的過程，這就是咱們常提到的死亡回放（DeathCameraReplay）。相似的，咱們在各種體育游戲外面常常須要在一次得分后展現(xiàn)精彩霎時，這種性能個別稱為精彩鏡頭。

　　上一節(jié)案例應(yīng)用的是基于本地文件存儲的回放零碎，每次播放時都須要從新加載地圖。那有沒有方法實現(xiàn)相似實況足球的實時精彩回放呢？有的，那就是基于 DuplicatedLevelCollection 和內(nèi)存數(shù)據(jù)流的回放計劃。

　　思考一下，通常射擊游戲里的擊殺鏡頭、體育競技里的精彩時刻對回放的根本需要是什么？這類回放性能往往是在某個工夫點能夠無感知地立即切換到回放鏡頭，并在回放完結(jié)后迅速再切換到失常的游戲環(huán)境。同時，思考到聯(lián)機的狀況，咱們在回放時要放棄游戲世界的失常運行，從而確保不錯過任何服務(wù)器的同步信息，不影響其余玩家。

　　為了實現(xiàn)上述的要求，咱們須要將回放的場景和實在的場景進(jìn)行拆散，在不從新加載地圖的狀況下疾速地進(jìn)行切換?？栈靡娼o出的計劃是對游戲世界 World 進(jìn)行進(jìn)一步的拆分，把所有的 Level 組織到了三個 LevelCollection 外面，別離是：

　　要留神的是，因為 LevelCollection 的引入，原來很多邏輯都變得復(fù)雜了。

　　思考到在死亡回放的時候不會影響失常較量的進(jìn)行和錄制，所以咱們通常也須要講錄制邏輯與播放邏輯齊全拆散。

　　簡略來說，就是創(chuàng)立兩個不同的 Demonetdriver，一個用于回放的錄制，另一個用于回放的播放。在游戲一開始的時候，就創(chuàng)立一個 DemonetdriverA 來開始錄制游戲，當(dāng)角色死亡觸發(fā)回放的時候，這時候創(chuàng)立一個新的 DemonetdriverB 來進(jìn)行回放數(shù)據(jù)的讀取并播放，整個過程中 DemonetdriverA 始終在處于錄制狀態(tài)，不會受到任何影響。（須要咱們手動重寫 GameInstance::PlayReplay 函數(shù)，因為默認(rèn)的邏輯每次創(chuàng)立一個新的 Demonetdriver 就會刪掉原來的那個。）

　　當(dāng)然，想要實現(xiàn)真正的疾速切換，只將回放場景與真實世界的拆散還不夠，咱們還須要保障回放數(shù)據(jù)的加載也能達(dá)到毫秒級別。所以這個時候就不能再應(yīng)用后面提到的 LocalFileNetworkReplayStreamer 把數(shù)據(jù)放到磁盤上，正確的計劃是采納基于內(nèi)存數(shù)據(jù)流的 ReplayStreamer 來放慢回放數(shù)據(jù)的讀取。上面是 InMemoryNetworkReplayStreamer 對回放數(shù)據(jù)的組織形式，每幀的數(shù)據(jù)流會依據(jù)工夫分段存儲在 StreamChunks 外面，而不同工夫點的快照則會存儲在 Checkpoints 數(shù)組外面。對于射擊游戲，咱們通常會在較量一開始就執(zhí)行錄制，錄制的數(shù)據(jù)會一直寫到上面的構(gòu)造外面并在整場較量中始終保留著，當(dāng)玩家被擊殺后就能夠立即從這里取出數(shù)據(jù)來進(jìn)行回放。

　　對于死亡回放 / 精彩鏡頭其實還有很多細(xì)節(jié)問題，這里列舉一些（最初一節(jié)會給出一些倡議）：

　　引擎編輯器外面默認(rèn)不反對 DynamicDuplicatedLevels 的創(chuàng)立，所以在不改源碼的狀況下無奈在編輯器外面實現(xiàn)死亡回放性能。

　　回放世界與真實世界都是存在的，能夠通過 SetVisible 來解決渲染，然而回放世界的物理怎么管制？

　　回放世界默認(rèn)狀況下不會復(fù)制 Controller（容易和本地的 Controller 發(fā)生沖突），所以很多相干的接口都不能應(yīng)用。

　　因為不同 Collection 的 Tick 更新機會不同，然而 Controller 只有一個，所以回放的時候要留神 Controller 的更新機會。

　　在 CSGO、Dota、堡壘之夜等游戲里，都反對玩家觀戰(zhàn)的性能，即玩家能夠通過客戶端間接進(jìn)入到某個正在進(jìn)行的較量的場景里進(jìn)行實時觀戰(zhàn)。不過個別狀況下并不是嚴(yán)格意義上的齊全實時，通常依據(jù)狀況會有肯定水平的提早。

　　實現(xiàn)該性能的一個繁難計劃就是讓觀戰(zhàn)的玩家作為一個客戶端連貫進(jìn)去，而后實時地承受服務(wù)器同步數(shù)據(jù)來進(jìn)行觀戰(zhàn)。這種形式既簡略，成果也好，然而問題也十分致命——觀戰(zhàn)的玩家可能會影響失常服務(wù)器性能，無奈很好地反對大量的玩家進(jìn)入。

　　所以大部分的游戲?qū)崿F(xiàn)的都是另一種計劃，即基于 Webserver 和回放的觀戰(zhàn)零碎。這種計劃的思路如下圖，首先咱們須要專門搭建一個用于解決回放數(shù)據(jù)的 WebServer，源源不斷地接管來自 GameServer 的回放錄制數(shù)據(jù)。而后客戶端在申請觀戰(zhàn)時不會去連貫 GameServer，而是間接通過 Http 申請以后須要播放的回放數(shù)據(jù)，從 WebServer 拿到數(shù)據(jù)后再進(jìn)行本地的解析與播放。盡管會有肯定的提早，然而現(xiàn)實狀況下成果和間接連入戰(zhàn)斗服觀戰(zhàn)是一樣的。

　　后面咱們提到過基于 Httpstream 的數(shù)據(jù)流，正是為這種計劃而實現(xiàn)的。去認(rèn)真看一下 FHttpNetworkReplayStreamer 的接口實現(xiàn)，都是通過 Http 協(xié)定對回放數(shù)據(jù)進(jìn)行封裝而后通過固定的格局來發(fā)給 WebServer 的（格局能夠依照需要批改，和 WebServer 的代碼要當(dāng)時規(guī)定對立）。

　　后面咱們花了大量的篇幅，由淺入深地解說了回放零碎的概念以及原理，而后又對兩個具體的實際案例（死亡回放、觀戰(zhàn)零碎）做了進(jìn)一步的剖析，心愿這樣能夠幫忙大家更好地了解 UE 乃至其余游戲外面回放零碎的思維思路。

　　這是侑虎科技第 1367 篇文章，感激作者 Jerish 供稿。歡送轉(zhuǎn)發(fā)分享，未經(jīng)作者受權(quán)請勿轉(zhuǎn)載。如果您有任何獨到的見解或者發(fā)現(xiàn)也歡送分割咱們，一起探討。（QQ 群：465082844）

　　【USparkle 專欄】如果你深懷絕技，愛“搞點鉆研”，樂于分享也博采眾長，咱們期待你的退出，讓智慧的火花碰撞交錯，讓常識的傳遞生生不息！

　　本站部分資源來自于網(wǎng)絡(luò)收集，若侵犯了你的隱私或版權(quán)，請及時聯(lián)系我們刪除有關(guān)信息。聯(lián)系郵箱:九游娛樂中心