拳頭游戲官方發(fā)長文回應(yīng)本次2022季中冠軍賽出現(xiàn)的一系列技術(shù)問題。

長文總結(jié)：

1.在上海的選手屏幕顯示的 ping值是正確的

2.在釜山的選手屏幕顯示的 ping值不正確，并且比實際延遲低約13ms

3.未能及時發(fā)現(xiàn)的漏洞影響了比賽，對ping值顯示錯誤問題的溝通也不夠及時透明。再次對此造成的問題和困擾致以深深的歉意。

概述

在過去的幾天，拳頭游戲電競技術(shù)團隊在努力解決圍繞著2022季中冠軍賽的一系列技術(shù)問題，尤其在我們用來為線下選手和遠程參賽選手平衡ping值的工具上。

我們初次發(fā)現(xiàn)的問題是一個存在于我們稱之為“延遲服務(wù)工具”中的錯誤 -這個工具是用來將所有參賽選手的延遲(ping值)調(diào)整到 35ms范圍， 而該錯誤會使在釜山場館中的選手在比賽時產(chǎn)生額外的延遲，并使得其實際延遲高于場館現(xiàn)場電腦屏幕上顯示的延遲(35ms)。因此，在遠程對局中，在中國的選手是在 35ms ping值區(qū)間進行比賽的，但在釜山的選手ping值則較之更高。很不幸，我們并沒有在季中冠軍賽開始之前發(fā)現(xiàn)這個問題，其根本原因是一個代碼漏洞錯誤計算了延遲，導(dǎo)致該數(shù)值在日志中也是錯誤的。因此，即使我們的監(jiān)控顯示一切正常，而實際上卻存在著錯誤。

我們在5月13日對該延遲服務(wù)工具進行了配置修改，以解決這個漏洞。考慮到之前實際網(wǎng)絡(luò)延遲增加對釜山場館中的比賽造成的影響，我們做出了艱難但是必要的決定：對B組對局ping值不相同的三場比賽進行重賽。

然而，5月13日這一配置修改帶來的另一個問題是，現(xiàn)在在釜山選手電腦屏幕上顯示的是錯誤的、低于實際 ping值的數(shù)字 ——盡管實際ping值現(xiàn)在已被修正并確保對等。 其后果是，當我們播放選手屏幕畫面時，屏幕上會呈現(xiàn)一個錯誤的較低的 ping值。同時，由于我們團隊沒能及時將這個外顯誤差進行有效溝通，故而觀眾會認為在場館里的選手正在以低于他們實際延遲的ping值進行比賽。

本篇文章將從技術(shù)角度復(fù)盤從賽前到現(xiàn)在(小組賽結(jié)束)發(fā)生的整個情況。

賽前階段

當我們開始計劃今年季中冠軍賽最后階段的技術(shù)設(shè)置時，新冠疫情帶來的持續(xù)挑戰(zhàn)擺在了我們面前。LPL賽區(qū)代表隊，Royal Never Give Up (RNG) 不會從上海前往釜山，而會遠程參賽。

表面上看，簡單的解決方案是讓遠程參賽的隊伍連到季中冠軍賽比賽服務(wù)器就行，其他隊伍在線下進行比賽。然而這樣的解決方案也并不理想，存在諸多問題。

問題之一就是釜山和上海之間相隔大概 850 公里(中間隔著黃海)。這意味著，網(wǎng)絡(luò)通信需要在上海和韓國的季中冠軍賽比賽服務(wù)器之間來回傳輸。

數(shù)據(jù)在客戶端和服務(wù)器間往返傳輸所需的時間就是我們常說的“ping值”(又稱為延遲)。從 RNG 俱樂部所在地到季中冠軍賽的比賽服務(wù)器，大約自然延遲是 35毫秒(ms) 。 而且其他十支參賽隊伍會在釜山的比賽場館里參賽，他們的延遲會低很多，大約在 15ms左右。請注意，我們本文里的ping值通常都指一個范圍，因為ping值常會在+/-5ms的極小范圍內(nèi)波動。

如果是一名普通《英雄聯(lián)盟》玩家，35ms 到 15ms 之間的差異或許是很難察覺到的。但對職業(yè)選手來說，這足以改變比賽手感，產(chǎn)生細微但仍能察覺到的差異。拳頭游戲電競賽事核心原則中的一條，就是保證競賽公平性。我們希望讓所有參賽的隊伍，能夠在平等競技條件下競賽。

既然說到平等競賽環(huán)境，那我們說明一下ping值差異問題。

讓遠程參賽成為可能

因為電競賽事是在網(wǎng)絡(luò)上進行的，我們希望能尋找一些遠程參賽的辦法。

但隨之而來的兩個問題是：

1)上海和釜山之間 35ms 的延遲是否能夠保證最高水準的競技發(fā)揮?

2)我們是否能提供同等競賽環(huán)境，讓所有選手都有相同的延遲?

對于第一個問題的回答是：“是”。對于英雄聯(lián)盟電競賽事來說，在最高級別的比賽中，我們認為最高可忍受的延遲極限為 40ms(上下浮動5ms)。 通過與內(nèi)部和外部合作伙伴，包括我們內(nèi)部的游戲分析和設(shè)計團隊的深入討論和分析，我們在2020年中確認了這個范圍。當ping值超過40ms范圍時，大部分職業(yè)選手會開始注意到延遲，它也開始影響諸如英雄選擇、技能釋放以及對對手的操作做出快速反應(yīng)的能力。

對于第二個問題的回答，我們考慮了以下幾個方案：

方案一：每支隊伍都在自然延遲下進行比賽

該方案建議，遠程參賽隊可自行選擇所擁有的最快速網(wǎng)絡(luò)，直連到季中冠軍賽比賽服務(wù)器。這意味著現(xiàn)場參賽隊伍會在低 ping值(~15ms)下比賽，而遠程參賽隊伍(以RNG為例)則要在其自然延遲下比賽。從中國連接到釜山的自然延遲約為 35ms。

我們考慮過，但還是否決了這個方案。因為基于競賽公平性的原則，我們希望保證對每個參賽隊伍的公平。

方案二：將服務(wù)器架設(shè)于韓國和中國的中間點

還有一種解決方案是，如果中韓兩國之間的ping值是 35ms，直接把服務(wù)器放在兩地中心點，延遲均分，不就各自只有 17.5ms 了嗎?實際上這個方案的實施仍然具有諸多挑戰(zhàn)…其中一個最大的問題是，要在汪洋大海中間架設(shè)服務(wù)器。

方案三：使用人工延遲

所以如果在韓國參賽的隊伍ping值很低，而在中國參賽的隊伍ping值又相對較高，那給韓國那邊加上一些延遲使兩邊對等，這可行嗎?我們能做到嗎?

事實證明，《英雄聯(lián)盟》的開發(fā)團隊已經(jīng)有了一種引入人工延遲的方法，即延遲服務(wù)(Latency Service)。也有人叫它：“假ping”。這是一種客戶端/服務(wù)器功能，旨在解決疫情下，遠程競賽需要公平競賽環(huán)境的需求。延遲服務(wù)允許我們設(shè)置一個目標值(如 35ms)，它會在客戶端和服務(wù)器上為每個玩家加入延遲，使大家保持基本相同的延遲水平。

我們曾成功地在過去一些英雄聯(lián)盟電競賽事里運用了該工具，當時的比賽都是遠程進行的。但這次是首次在全球性賽事上使用這一工具，并且其中部分選手還在釜山本地場館進行對局。雖然我們之前使用過，但環(huán)境中的部分細微差異總有可能造成我們無法預(yù)見的錯誤。在訓練賽服務(wù)器上的人工延遲應(yīng)用效果比較理想，再加上我們長期使用的可靠網(wǎng)絡(luò)基礎(chǔ)設(shè)施和測試方法，我們當時認為已經(jīng)有足夠多的應(yīng)用實例，能在小組賽階段之前發(fā)現(xiàn)所有的重大問題。

我們的選擇

再三衡量各種方案后，我們認為最重要的是保證競賽公平性，那么使用方案三 - 人工延遲便是最好的解決方案。

了解人工延遲：它的工作原理

延遲服務(wù)工具內(nèi)置在《英雄聯(lián)盟》的本地客戶端/服務(wù)器端的網(wǎng)絡(luò)協(xié)議棧中。它會持續(xù)測量每個玩家和服務(wù)器之間的實際網(wǎng)絡(luò)延遲，根據(jù)需要，通過添加延遲進行調(diào)整，以達到目標延遲值。這是一種客戶端/服務(wù)器端解決方案，目的是通過引入延遲來保證雙方的延遲均等。

上圖顯示了系統(tǒng)的各個組件。圖片頂部是游戲服務(wù)器組件，底部是游戲客戶端(選手的電腦)。在目前這種情況下，延遲服務(wù)的目標延遲值為 35ms。圖中的紅色箭頭表示存在的實際網(wǎng)絡(luò)延遲。正如所看到的，釜山的選手 1 和選手 2 顯示為 15ms 的“真實”ping值，而上海的選手 10 顯示為 35ms的ping值。黃色框表示在客戶端和服務(wù)器端人為添加了多少延遲。在這種情況下，選手 1 和選手 2 分別向客戶端和服務(wù)器端添加了 10ms 的延遲，達到了目標延遲 35 ms。選手 10 已經(jīng)具有等于目標延遲 35 ms 的實際延遲，因此沒有添加延遲(0ms)。

同等競賽環(huán)境還是兩個不同的競賽環(huán)境?

想要深入了解這一話題，可能要提起我們曾經(jīng)對于遠程環(huán)境和本地環(huán)境所做的一個決定。

對于電競賽事技術(shù)團隊來說，我們一直追求把現(xiàn)場賽事的風險降到最低。2012年洛杉磯，第二屆全球總決賽比賽因網(wǎng)絡(luò)問題被迫中斷。這段回憶，將永遠烙刻在所有拳頭電競?cè)诵闹小?/p>

在決定2022 季中冠軍賽的網(wǎng)絡(luò)架構(gòu)設(shè)計時，我們意識到必須在兩種不同的策略之間做出決定。

策略一：所有場景下使用同等種網(wǎng)絡(luò)架構(gòu)設(shè)計

在國際比賽中，我們的競技比賽都是在使用場館內(nèi)的線下服務(wù)器上。這為我們提供了高度的可靠性，因為它允許我們直接控制網(wǎng)絡(luò)和服務(wù)器硬件。考慮到有一支隊伍遠程參賽，那么就必須構(gòu)筑這樣一個場景：至少會有一支隊伍將通過互聯(lián)網(wǎng)服務(wù)器進行比賽。那么如果有一支隊伍需要通過互聯(lián)網(wǎng)服務(wù)器參賽，一個策略就是徹底放棄我們的本地部署，轉(zhuǎn)而讓所有隊伍都通過互聯(lián)網(wǎng)服務(wù)器進行比賽。

鑒于穩(wěn)定性原則，我們知道如果必須架設(shè)互聯(lián)網(wǎng)比賽服務(wù)器，那就要選擇十分信得過的部署方案。很顯然，韓國的比賽服務(wù)器是值得考慮的選擇。這是一個僅供職業(yè)比賽使用的環(huán)境，和韓國公共服務(wù)器位于同一數(shù)據(jù)中心，并常用于LCK韓國聯(lián)賽。同樣這也意味著這個服務(wù)器有無數(shù)小時的運行數(shù)據(jù)來驗證其網(wǎng)絡(luò)的良好連通性和架構(gòu)的可信賴性。所以當至少有一支隊伍需要遠程參賽時，用這個節(jié)點是合理的。但接下來的問題是，是應(yīng)該在所有比賽中使用它，還是只針對遠程比賽使用。這便引出了策略二：最小化網(wǎng)絡(luò)風險。

策略二：僅在必要時使用遠程參賽，最小化網(wǎng)絡(luò)風險

在之前的策略中，考慮到某些比賽需要在互聯(lián)網(wǎng)環(huán)境中進行，那么問題就變成了：“何不統(tǒng)統(tǒng)放在這個環(huán)境下呢?”這個答案很簡單：互聯(lián)網(wǎng)的可靠性。互聯(lián)網(wǎng)有時候風平浪靜，有時候則未必。如果所有季中冠軍賽比賽都在互聯(lián)網(wǎng)服務(wù)器上進行，那么任何網(wǎng)絡(luò)問題都可能導(dǎo)致比賽在進行中出現(xiàn)問題。如果只是遠程比賽通過互聯(lián)網(wǎng)進行，那網(wǎng)絡(luò)出現(xiàn)問題的概率就會大大降低。我們相信通過我們的計劃，能夠?qū)L險降到最低。由于我們相信我們有能力通過使用人工延遲來實現(xiàn)ping值在同等競賽環(huán)境，所以這只是一個復(fù)雜性與可靠性的簡單問題。為了實現(xiàn)更低的風險(減少互聯(lián)網(wǎng)的不可靠性)，我們增加了一點復(fù)雜性(兩種網(wǎng)絡(luò)架構(gòu)設(shè)計)。

考慮到這兩種選項，并基于我們的評估，我們決定采用策略二，它能夠為賽事的可靠性和競賽公平性帶來最低的風險。

下方的圖表就是我們所選擇的網(wǎng)絡(luò)架構(gòu)設(shè)計，展示了在不同情況下網(wǎng)絡(luò)是如何鏈接運行的。

最合理方案

考慮到以上種種因素，我們決定在使用人工延遲服務(wù)并維持競賽公平性的情況下支持兩種不同的網(wǎng)絡(luò)架構(gòu)設(shè)計。兩支都在場館的隊伍比賽時，將使用架設(shè)在季中冠軍賽場地內(nèi)的本地服務(wù)器。而對上遠程參賽隊伍時，對戰(zhàn)雙方均在韓國數(shù)據(jù)中心的比賽服務(wù)器上進行比賽。拳頭游戲電競技術(shù)團隊設(shè)置了系統(tǒng)并進行了基礎(chǔ)架構(gòu)測試，以確保一切運轉(zhuǎn)正常。其中包括了各種測量和監(jiān)控，如 ping值、網(wǎng)絡(luò)抖動，以及對丟包的仔細檢查。我們也讓隊伍在這個比賽服務(wù)器上進行訓練賽，并讓他們來到現(xiàn)場，進行技術(shù)測試。

但在第一比賽日結(jié)束后，選手告訴我們，比賽的時候感覺很卡。部分選手表示，即便游戲屏幕上顯示 35ms，但實際體感卻高于 35ms。當時我們所有的日志和基礎(chǔ)架構(gòu)監(jiān)控顯示一切正確，但我們決定繼續(xù)調(diào)查，找出問題的原因。

找尋漏洞

引起這些問題的原因還是不清楚。由于架構(gòu)監(jiān)控工具并沒有匯報錯誤，但我們卻收到報告說比賽很卡。我們?nèi)鄙偬囟┒椿蛱囟ㄓ螒騼?nèi)情況來定性。于是我們又回到了基礎(chǔ)問題上。哪些數(shù)據(jù)是可用的?我們手里都有哪些日志?我們能收集到什么信息?

對此我們采取了兩步走的做法。首先是向參賽的職業(yè)隊伍收集問題，幫我們理解情況，到底哪里出了岔子。你們是在哪兒發(fā)現(xiàn)問題的?是場館服務(wù)器還是比賽服務(wù)器?是場館網(wǎng)絡(luò)環(huán)境還是訓練賽環(huán)境?是所有對局都這樣?還是只是個別情況?與此同時，因為標準報告沒有顯示任何錯誤，所以我們開始查看其他日志和指標，尋找任何可能的差異。我們也提取了賽事客戶端和服務(wù)器端的日志，并開始深入研究。

舉個例子，我們曾假設(shè)問題是，也許游戲服務(wù)器沒有保持穩(wěn)定的幀率。于是我們提取了日志，并將數(shù)據(jù)放入一個查看工具中，把數(shù)據(jù)可視化為上面的圖表(如上示意)。它顯示了我們在每場比賽中都有非常穩(wěn)定的幀率。所以這并不是職業(yè)選手報告的問題原因。

查閱日志是一項極其細致而艱巨的工作。數(shù)據(jù)本身看起來就像一頁又一頁看似隨機的數(shù)字流，必須通過各種工具進行編譯，將其可視化，使其有意義。每一輪的徹查，我們都沒有發(fā)現(xiàn)異常。

在我們查看日志和代碼時，我們逐漸收到了來自各方隊伍的更多反饋。大家對季中冠軍賽場地環(huán)境的抱怨比其他任何環(huán)境都多。這和我們的理解有所相背。畢竟，線下比賽和選手在同一建筑里的硬件上進行的。在擁有完美可控的網(wǎng)絡(luò)環(huán)境下怎么會比通過在韓國互聯(lián)網(wǎng)服務(wù)器上進行比賽感覺更糟糕?

這引發(fā)了另一個設(shè)想…如果日志的延遲測量顯示良好，但體驗相反，那會不會是日志出了問題?會不會是我們測量延遲的方式有問題?

開發(fā)團隊隨即寫了幾段代碼來驗證這個猜想。一般情況下，日志是根據(jù)游戲數(shù)據(jù)包在服務(wù)器的網(wǎng)絡(luò)層和客戶端的網(wǎng)絡(luò)層之間的往返產(chǎn)生的。這些日志沒有發(fā)現(xiàn)任何錯誤。所以我們換了一種方式用新工具來測試延遲。不再測試網(wǎng)絡(luò)層的流量延遲，改為測試整個“端到端”的循環(huán)，從用戶點擊，再到看到該點擊響應(yīng)。換句話說，測量的不再只是網(wǎng)絡(luò)表現(xiàn)，只要游戲中任何系統(tǒng)之間的互動會被選手接觸到，就都會去測量。

可以參考以上的圖表了解這個概念。現(xiàn)有的網(wǎng)絡(luò)監(jiān)控測量的是包括網(wǎng)絡(luò)層延遲和延遲服務(wù)時延，這一點會通過綠色箭頭展示在上圖中。但是新的工具模擬了輸入層的輸入，然后測量在該輸入和服務(wù)器響應(yīng)之間發(fā)生的全棧延遲。紅色箭頭展示了新工具的監(jiān)測軌跡。

有了這個新工具，我們就能在實驗室中進行測試，看看能不能重現(xiàn)選手們的問題。

我們做的第一件事，就是在不運行延遲服務(wù)下，設(shè)置一個基準線。因為我們有來自公共服務(wù)器上無數(shù)小時的玩家數(shù)據(jù)，我們相信服務(wù)器沒有任何漏洞，因此我們以它們來做參照組。 第一個設(shè)置基準線的實驗?zāi)M了在韓國參賽的隊伍和在中國參賽的隊伍均從互聯(lián)網(wǎng)接入服務(wù)器的場景。

實驗一：關(guān)閉延遲服務(wù)工具，對比韓國和中國的網(wǎng)絡(luò)

這類實驗的數(shù)據(jù)十分復(fù)雜，這里我們將其整理之后用圖表的形式展現(xiàn)出來，可以幫助大家理解我們所看到的情況。

如果你沿著橫軸(游戲時間)看，會發(fā)現(xiàn)一開始(圖表左側(cè))的延遲值很低。幾分鐘后(圖中從左到右的中間部分)，我們開始模擬較高ping值的網(wǎng)絡(luò)(例如：上海)。我們可以看到，豎軸上的延遲在上升。這和預(yù)想的完全一樣。在低ping值網(wǎng)絡(luò)下，延遲較低;在高ping值網(wǎng)絡(luò)下，延遲較高。

第一個實驗，作為參照組，說明用新工具測量的結(jié)果是符合我們預(yù)期的。這是個好的開始。

下一個實驗，我們會用相同的步驟進行檢測，但這次我們開啟延遲服務(wù)工具。

實驗二：開啟延遲服務(wù)工具，對比韓國和中國的網(wǎng)絡(luò)

我們需要記住的是，人工延遲服務(wù)的目的就是無條件平衡網(wǎng)絡(luò) ping值。所以如果我們更改了實驗室中的網(wǎng)絡(luò)ping值特性，那么我們的預(yù)期就是延遲服務(wù)將加入延遲，使得測量值保持相同。然而，數(shù)據(jù)卻表明不是這樣的。正如所看到的，上海的模擬網(wǎng)絡(luò)所顯示的延遲比韓國模擬網(wǎng)絡(luò)所顯示的延遲要低。這是在我們意料之外的，這也展示了延遲服務(wù)為韓國網(wǎng)絡(luò)環(huán)境帶來了比上海網(wǎng)絡(luò)環(huán)境更高的延遲。

從這份報告我們可以確定三件事：

1)問題是真實存在的，且確實與選手們報告的情況相符

2)我們自己可以在實驗室重現(xiàn)這個問題

3)問題很可能就出現(xiàn)在人工延遲工具上

從這些信息入手，我們就知道需要在代碼中的何處尋找問題。 在運行各種額外的測試以了解我們更改實驗室環(huán)境的特性時發(fā)生了什么后，我們意識到，只有在實際 ping顯著低于目標延遲的情況下才會出現(xiàn)計算錯誤。 在這種情況下，實際延遲將遠遠高于屏幕上顯示的延遲。

這便解釋了目前的一系列問題。為什么日志不顯示這些問題：因為運算錯了。為什么場館比網(wǎng)絡(luò)服務(wù)器體感還差：因為環(huán)境 ping值越低，這個漏洞就越明顯。這也解釋了為什么在釜山現(xiàn)場的選手覺得比賽體感延遲比屏幕上顯示的約 35ms差多了：因為實際延遲確實高于 35ms。

既然找到了問題，那下一步就是盡快解決它。

幸運的是，查閱代碼后，我們可以很好的理解這一問題。從這里出發(fā)，我們假設(shè)可以通過做一個配置改變，來補償這個計算錯誤。

既然我們有了辦法來模擬環(huán)境，也有了辦法來使用自研工具測試實際延遲，那么就可以通過調(diào)節(jié)配置，得到我們想要的結(jié)果。

以下圖表顯示了與兩個實驗相同的網(wǎng)絡(luò)環(huán)境，但這一次使用了將錯誤修正后的配置文件。

實驗三：在正確的配置下啟用延遲服務(wù)工具

和前兩次實驗一樣，先模擬一個低 ping值環(huán)境，幾分鐘后再模擬一個高 ping值環(huán)境。和之前實驗結(jié)果不同的是，在使用了更改的配置后，這次延遲服務(wù)的補償終于正確了。這張圖表顯示，即便 ping值從低切換到高，延遲都是基本相同的。

問題解決了嗎?

這個配置修正了一個游戲中 ping值計算的錯誤，卻也產(chǎn)生了一個副作用，即釜山場館內(nèi)選手屏幕上的幀數(shù)和 ping值顯示(Ctl-V)會出現(xiàn)錯誤。顯示的 ping值會比實際 ping值低大約 13ms。這是因為，我們上述對延遲服務(wù)所做的配置更改，本質(zhì)上是在目標值上直接添加了一個偏移量，以補償計算錯誤。這會對客戶端中記錄和顯示的 ping值應(yīng)用偏移量產(chǎn)生下游效應(yīng)(稍后我們會詳細分析這點)。其結(jié)果是外部客戶端顯示的數(shù)字將比實際 ping 低 13 ms左右。雖然這個結(jié)果不是完美的，但當時我們認為確保同等競賽環(huán)境里的對等延遲是一件更重要的事情，即便這意味著釜山場館外顯屏幕會顯示錯誤的數(shù)值。

下一步措施，以及一個困難的現(xiàn)實

既然我們已經(jīng)知道如何準確測量真正的延遲，并找到了一個通過更改配置能夠補償這個計算錯誤的解決方法，我們馬上準備了一個計劃進行修正部署，并準備向選手和粉絲溝通，說明之前出現(xiàn)的問題。

但當我們明白了問題所在，我們卻面臨著一個困難的現(xiàn)實。

我們意識到，在場館內(nèi)的選手之前都是在高于35ms范圍 的網(wǎng)絡(luò)下進行比賽的，但在上海遠程參賽的隊伍，卻是在實際的35ms范圍內(nèi)進行比賽的——35ms左右是釜山至上海的自然網(wǎng)絡(luò)延遲 。我們沒有做到公平競爭原則下的延遲對等。

我們需要立即告知隊伍。唯一的問題是，這個差異是否大到足以需要重賽。這是一個賽事運營的決定。經(jīng)過估算，由于計算錯誤，前三個比賽日中釜山和上海的真實延遲差值大約在15 - 20ms 之間。這也讓我們最終做出一個艱難的決定，即使用更新后的配置，將三場受影響的比賽進行重賽，以確保競賽公平性。

理解ping值的顯示數(shù)字

在我們決定重賽早期比賽之后，我們知道我們還有很多工作要做。這意味著重新制定賽程，并與隊伍聯(lián)系，以確保他們了解正在發(fā)生的事情和原因。 這還意味著我們準備對比賽場館的服務(wù)器和數(shù)據(jù)中心服務(wù)器的配置進行更改，并重新運行所有測試以驗證更改是否正確運行。 我們還邀請職業(yè)選手前往比賽現(xiàn)場測試新設(shè)置下的服務(wù)器，多次檢查我們是否解決了這個問題。 我們甚至進行了盲測，讓職業(yè)選手在不知情的情況下嘗試兩種配置，并讓我們知道哪一種感覺像 35ms 延遲，哪一種感覺不止于此。

很不幸的是，我們并沒有及時且清晰地將這個外顯誤差向各位玩家以及轉(zhuǎn)播團隊溝通。

不久之后，我們的粉絲就指出了對韓國隊伍來說似乎是不公平的優(yōu)勢。 我們開始看到粉絲發(fā)布一張顯示 22ms 延遲的屏幕截圖，而不是預(yù)期的約 35ms 的延遲。

這是我們必須回應(yīng)的問題。

如之前提到的，延遲服務(wù)中漏洞的解決方法是添加到配置文件中的補償偏移值。 此偏移量對屏幕顯示的數(shù)值有副作用：

在上海的選手屏幕顯示的 ping值是正確的

在釜山的選手屏幕顯示的 ping值不正確，并且比實際延遲低約 13ms

這里重申一下原因，上海的屏幕顯示的ping值是正確的，因為當他們使用延遲工具時，他們已經(jīng)達到了35 ms左右的延遲目標，因此延遲工具并不會為他們的體驗添加補償。而釜山的屏幕數(shù)字顯示不正確的原因是，在引擎中引入了延遲配置偏移量，它糾正了引擎中的延遲錯誤計算，讓實際延遲能夠達到35ms這個目標。但這將產(chǎn)生讓日志和ping值顯示偏移約 13 ms 的下游效應(yīng)。

為了驗證這一點，我們從 30 多個進程中收集了客戶端日志，并繪制了屏幕上顯示的 ping/延遲數(shù)據(jù)圖表(如下示意)。

上圖只顯示了RNG相關(guān)的比賽，豎軸是顯示的ping值。 與上一個部分顯示數(shù)據(jù)的圖表不同，在這種情況下，橫軸代表離散的數(shù)據(jù)集，每個游戲都有一個數(shù)據(jù)集。 因此，每個綠色方塊都是報告的 ping值的直方圖，這些都是從客戶端日志中讀取一個選手的一場比賽的數(shù)據(jù)。 正如這里可以看到的，這些值存在一些波動，并且值都在 33 ms 和 39 ms 之間的范圍內(nèi)。 這符合 RNG 的 35ms +/- 5ms 的已知自然延遲值。

下一個要查看的數(shù)據(jù)集是釜山選手在配置更改之前和配置更改之后的客戶端日志(如下示意)。

在上圖中，我們過濾了數(shù)據(jù)，僅顯示在釜山比賽場館進行的比賽。左側(cè)顯示的游戲是配置更改之前進行的比賽。正如這里可以看到的，顯示數(shù)值在 33 到 39ms 之間，范圍為 35ms +/- 5。我們也知道，通過更新“端到端”的監(jiān)測工具進行檢驗以及結(jié)合選手報告，真正的延遲和所顯示的不同。

在圖表的右側(cè)，我們看到在使用能夠提供相同真正延遲的新配置后，顯示延遲數(shù)值介于 19 ms和25 ms之間-通常在22 ms +/- 5 ms的波動范圍以內(nèi)。將這兩個值相減可以看出，顯示ping值中的偏移誤差是一致的，大約為13ms (35ms - 22ms = 13ms)。因此，在配置更改并解決實際延遲問題后，當釜山屏幕顯示ping值顯示 22 ms左右時，實際上真實延遲是 35 ms左右。

回到顯示 T1 與 SGB 比賽的屏幕截圖，這解釋了當時 Zeus 的屏幕顯示ping值為 22 ms左右，而在添加我們從實驗中得到的校正偏移值后，真正的延遲則是在 35ms左右。

結(jié)論

作為支持現(xiàn)場比賽的拳頭游戲電競技術(shù)團隊，我們一直竭盡所能地對比賽環(huán)境進行測試、檢查、再三檢查，以確保無虞。我們一直是以為職業(yè)選手創(chuàng)造同等競賽環(huán)境作為最高優(yōu)先級。我們的目標是讓技術(shù)讓路，將舞臺留給運動和比賽本身。

我們也希望盡一切努力堅持競賽公平性，并為全世界的粉絲創(chuàng)造更好的觀賽體驗。任何計劃的修改，都可能帶來風險。但我們希望做到最好，來規(guī)避風險，并為選手和粉絲創(chuàng)造最好的體驗。

但在這次整件事情中，我們未能及時發(fā)現(xiàn)的漏洞影響了比賽，我們對ping值顯示錯誤問題的溝通也不夠及時透明。我們再次對此造成的問題和困擾致以深深的歉意。

我們深知這幾天對大家并不容易，因此我們正在進行額外的測試和驗證，以確保后面的對抗賽和淘汰賽階段順利無虞。我們還要感謝隊伍和選手們在此期間表現(xiàn)出的堅韌，盡管有諸多障礙，他們?nèi)詾槲覀兘鉀Q這些問題提供了寶貴的反饋。雖然我們不敢妄言以后永遠不會再出現(xiàn)任何可能影響比賽的程序問題，但我們承諾一定從這次事件中吸取教訓，更及時地與隊伍和粉絲進行溝通，并持續(xù)地為良好的賽場環(huán)境做出不懈的自我監(jiān)督和自我改進。

標簽：