拳頭遊戲發文正式回應2022季中冠軍賽中Ping值問題！

近幾天，《英雄聯盟》MSI可謂風波不斷，先是RNG戰隊因延遲問題被判重賽引發中國網友強烈不滿，RNG頗為給力三場重賽全勝掀起網友熱議。再是昨日T1對陣SGB的比賽中，T1上單Zeus第一視角畫面顯示其延遲僅有21ms，讓拳頭再次登上熱搜。今日（5月17日）拳頭遊戲官方發長文回應本次2022季中冠軍賽出現的一系列技術問題。

總結：

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

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

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

官方原文地址>>

概述

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

我們初次發現的問題是一個存在於我們稱之為“延遲服務工具”中的錯誤 -這個工具是用來將所有參賽選手的延遲（ping值）調整到 35ms範圍， 而該錯誤會使在釜山場館中的選手在比賽時產生額外的延遲，並使得其實際延遲高於場館現場電腦螢幕上顯示的延遲（35ms）。因此，在遠程對局中，在中國的選手是在 35ms ping值區間進行比賽的，但在釜山的選手ping值則較之更高。很不幸，我們並沒有在季中冠軍賽開始之前發現這個問題，其根本原因是一個程式碼漏洞錯誤計算了延遲，導致該數值在日誌中也是錯誤的。因此，即使我們的監控顯示一切正常，而實際上卻存在著錯誤。

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

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

本篇文章將從技術角度複盤從賽前到現在（小組賽結束）發生的整個情況。

賽前階段

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

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

問題之一就是釜山和上海之間相隔大概 850 公里（中間隔著黃海）。這意味著，網路通信需要在上海和韓國的季中冠軍賽比賽伺服器之間來回傳輸。

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

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

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

讓遠程參賽成為可能

因為電競賽事是在網路上進行的，我們希望能尋找一些遠程參賽的辦法。

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

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

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

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

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

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

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

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

方案二：將伺服器架設於韓國和中國的中間點

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

方案三：使用人工延遲

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

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

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

我們的選擇

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

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

延遲服務工具內建在《英雄聯盟》的本地客戶端/伺服器端的網路協議棧中。它會持續測量每個玩家和伺服器之間的實際網路延遲，根據需要，通過添加延遲進行調整，以達到目標延遲值。這是一種客戶端/伺服器端解決方案，目的是通過引入延遲來保證雙方的延遲均等。

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

同等競賽環境還是兩個不同的競賽環境？

想要深入了解這一話題，可能要提起我們曾經對於遠程環境和本地環境所做的一個決定。

對於電競賽事技術團隊來說，我們一直追求把現場賽事的風險降到最低。2012年洛杉磯，第二屆全球總決賽比賽因網路問題被迫中斷。這段回憶，將永遠烙刻在所有拳頭電競人心中。  

在決定2022 季中冠軍賽的網路架構設計時，我們意識到必須在兩種不同的策略之間做出決定。

策略一：所有場景下使用同等種網路架構設計

在國際比賽中，我們的競技比賽都是在使用場館內的線下伺服器上。這為我們提供了高度的可靠性，因為它允許我們直接控制網路和伺服器硬體。考慮到有一支隊伍遠程參賽，那麽就必須構築這樣一個場景：至少會有一支隊伍將通過網際網路伺服器進行比賽。那麽如果有一支隊伍需要通過網際網路伺服器參賽，一個策略就是徹底放棄我們的本地部署，轉而讓所有隊伍都通過網際網路伺服器進行比賽。

鑒於穩定性原則，我們知道如果必須架設網際網路比賽伺服器，那就要選擇十分信得過的部署方案。很顯然，韓國的比賽伺服器是值得考慮的選擇。這是一個僅供職業比賽使用的環境，和韓國公共伺服器位於同一資料中心，並常用於LCK韓國聯賽。同樣這也意味著這個伺服器有無數小時的運行資料來驗證其網路的良好連通性和架構的可信賴性。所以當至少有一支隊伍需要遠程參賽時，用這個節點是合理的。但接下來的問題是，是應該在所有比賽中使用它，還是隻針對遠程比賽使用。這便引出了策略二：最小化網路風險。

策略二：僅在必要時使用遠程參賽，最小化網路風險

在之前的策略中，考慮到某些比賽需要在網際網路環境中進行，那麽問題就變成了：“何不統統放在這個環境下呢？”這個答案很簡單：網際網路的可靠性。網際網路有時候風平浪靜，有時候則未必。如果所有季中冠軍賽比賽都在網際網路伺服器上進行，那麽任何網路問題都可能導致比賽在進行中出現問題。如果只是遠程比賽通過網際網路進行，那網路出現問題的概率就會大大降低。我們相信通過我們的計劃，能夠將風險降到最低。由於我們相信我們有能力通過使用人工延遲來實現ping值在同等競賽環境，所以這只是一個複雜性與可靠性的簡單問題。為了實現更低的風險（減少網際網路的不可靠性），我們增加了一點複雜性（兩種網路架構設計）。

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

下方的圖表就是我們所選擇的網路架構設計，展示了在不同情況下網路是如何連結運行的。

最合理方案

考慮到以上種種因素，我們決定在使用人工延遲服務並維持競賽公平性的情況下支援兩種不同的網路架構設計。兩支都在場館的隊伍比賽時，將使用架設在季中冠軍賽場地內的本地伺服器。而對上遠程參賽隊伍時，對戰雙方均在韓國資料中心的比賽伺服器上進行比賽。拳頭遊戲電競技術團隊設定了系統並進行了基礎架構測試，以確保一切運轉正常。其中包括了各種測量和監控，如 ping值、網路抖動，以及對丟包的仔細檢查。我們也讓隊伍在這個比賽伺服器上進行訓練賽，並讓他們來到現場，進行技術測試。

但在第一比賽日結束後，選手告訴我們，比賽的時候感覺很卡。部分選手表示，就算遊戲螢幕上顯示 35ms，但實際體感卻高於 35ms。當時我們所有的日誌和基礎架構監控顯示一切正確，但我們決定繼續調查，找出問題的原因。

找尋漏洞

引起這些問題的原因還是不清楚。由於架構監控工具並沒有匯報錯誤，但我們卻收到報告說比賽很卡。我們缺少特定漏洞或特定遊戲內情況來定性。於是我們又回到了基礎問題上。哪些資料是可用的？我們手裡都有哪些日誌？我們能收集到什麽訊息？

對此我們採取了兩步走的做法。首先是向參賽的職業隊伍收集問題，幫我們理解情況，到底哪裡出了岔子。你們是在哪兒發現問題的？是場館伺服器還是比賽伺服器？是場館網路環境還是訓練賽環境？是所有對局都這樣？還是只是個別情況？與此同時，因為標準報告沒有顯示任何錯誤，所以我們開始查看其他日誌和指標，尋找任何可能的差異。我們也提取了賽事客戶端和伺服器端的日誌，並開始深入研究。

舉個例子，我們曾假設問題是，也許遊戲伺服器沒有保持穩定的幀數。於是我們提取了日誌，並將資料放入一個查看工具中，把資料可視化為上面的圖表（如上示意）。它顯示了我們在每場比賽中都有非常穩定的幀數。所以這並不是職業選手報告的問題原因。

查閱日誌是一項極其細緻而艱巨的工作。資料本身看起來就像一頁又一頁看似隨機的數字流，必須通過各種工具進行編譯，將其可視化，使其有意義。每一輪的徹查，我們都沒有發現異常。

在我們查看日誌和程式碼時，我們逐漸收到了來自各方隊伍的更多反饋。大家對季中冠軍賽場地環境的抱怨比其他任何環境都多。這和我們的理解有所相背。畢竟，線下比賽和選手在同一建築裡的硬體上進行的。在擁有完美可控的網路環境下怎麽會比通過在韓國網際網路伺服器上進行比賽感覺更糟糕？

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

開發團隊隨即寫了幾段程式碼來驗證這個猜想。一般情況下，日誌是根據遊戲資料包在伺服器的網路層和客戶端的網路層之間的往返產生的。這些日誌沒有發現任何錯誤。所以我們換了一種方式用新工具來測試延遲。不再測試網路層的流量延遲，改為測試整個“端到端”的循環，從使用者點擊，再到看到該點擊響應。換句話說，測量的不再只是網路表現，只要遊戲中任何系統之間的互動會被選手接觸到，就都會去測量。

可以參考以上的圖表了解這個概念。現有的網路監控測量的是包括網路層延遲和延遲服務時延，這一點會通過綠色箭頭展示在上圖中。但是新的工具模擬了輸入層的輸入，然後測量在該輸入和伺服器響應之間發生的全棧延遲。紅色箭頭展示了新工具的監測軌跡。

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

我們做的第一件事，就是在不運行延遲服務下，設定一個基準線。因為我們有來自公共伺服器上無數小時的玩家資料，我們相信伺服器沒有任何漏洞，因此我們以它們來做參照組。  第一個設定基準線的實驗模擬了在韓國參賽的隊伍和在中國參賽的隊伍均從網際網路接入伺服器的場景。

實驗一：關閉延遲服務工具，對比韓國和中國的網路

這類實驗的資料十分複雜，這裡我們將其整理之後用圖表的形式展現出來，可以幫助大家理解我們所看到的情況。

如果你沿著橫軸（遊戲時間）看，會發現一開始（圖表左側）的延遲值很低。幾分鐘後（圖中從左到右的中間部分），我們開始模擬較高ping值的網路（例如：上海）。我們可以看到，豎軸上的延遲在上升。這和預想的完全一樣。在低ping值網路下，延遲較低；在高ping值網路下，延遲較高。

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

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

實驗二：開啟延遲服務工具，對比韓國和中國的網路

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

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

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

（2)我們自己可以在實驗室重現這個問題

（3)問題很可能就出現在人工延遲工具上

從這些訊息入手，我們就知道需要在程式碼中的何處尋找問題。 在運行各種額外的測試以了解我們更改實驗室環境的特性時發生了什麽後，我們意識到，只有在實際 ping顯著低於目標延遲的情況下才會出現計算錯誤。 在這種情況下，實際延遲將遠遠高於螢幕上顯示的延遲。

這便解釋了目前的一系列問題。為什麽日誌不顯示這些問題：因為運算錯了。為什麽場館比網路伺服器體感還差：因為環境 ping值越低，這個漏洞就越明顯。這也解釋了為什麽在釜山現場的選手覺得比賽體感延遲比螢幕上顯示的約 35ms差多了：因為實際延遲確實高於 35ms。

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

幸運的是，查閱程式碼後，我們可以很好的理解這一問題。從這裡出發，我們假設可以通過做一個配置改變，來補償這個計算錯誤。

既然我們有了辦法來模擬環境，也有了辦法來使用自研工具測試實際延遲，那麽就可以通過調節配置，得到我們想要的結果。

以下圖表顯示了與兩個實驗相同的網路環境，但這一次使用了將錯誤修正後的配置檔案。

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

和前兩次實驗一樣，先模擬一個低 ping值環境，幾分鐘後再模擬一個高 ping值環境。和之前實驗結果不同的是，在使用了更改的配置後，這次延遲服務的補償終於正確了。這張圖表顯示，就算 ping值從低切換到高，延遲都是基本相同的。

問題解決了嗎？

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

下一步措施，以及一個困難的現實

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

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

我們意識到，在場館內的選手之前都是在高於35ms範圍 的網路下進行比賽的，但在上海遠程參賽的隊伍，卻是在實際的35ms範圍內進行比賽的——35ms左右是釜山至上海的自然網路延遲 。我們沒有做到公平競爭原則下的延遲對等。

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

理解ping值的顯示數字

在我們決定重賽早期比賽之後，我們知道我們還有很多工作要做。這意味著重新制訂賽程，並與隊伍聯繫，以確保他們了解正在發生的事情和原因。 這還意味著我們準備對比賽場館的伺服器和資料中心伺服器的配置進行更改，並重新運行所有測試以驗證更改是否正確運行。 我們還邀請職業選手前往比賽現場測試新設定下的伺服器，多次檢查我們是否解決了這個問題。 我們甚至進行了盲測，讓職業選手在不知情的情況下嘗試兩種配置，並讓我們知道哪一種感覺像 35ms 延遲，哪一種感覺不止於此。

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

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

這是我們必須回應的問題。

如之前提到的，延遲服務中漏洞的解決方法是添加到配置檔案中的補償偏移值。 此偏移量對螢幕顯示的數值有副作用：

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

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

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

為了驗證這一點，我們從 30 多個進程中收集了客戶端日誌，並繪製了螢幕上顯示的 ping/延遲資料圖表（如下示意）。

上圖只顯示了RNG相關的比賽，豎軸是顯示的ping值。 與上一個部分顯示資料的圖表不同，在這種情況下，橫軸代表離散的資料集，每個遊戲都有一個資料集。 因此，每個綠色方塊都是報告的 ping值的直方圖，這些都是從客戶端日誌中讀取一個選手的一場比賽的資料。 正如這裡可以看到的，這些值存在一些波動，並且值都在 33 ms 和 39 ms 之間的範圍內。 這符合 RNG 的 35ms +/- 5ms 的已知自然延遲值。

下一個要查看的資料集是釜山選手在配置更改之前和配置更改之後的客戶端日誌（如下示意）。

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

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

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

結論

作為支援現場比賽的拳頭遊戲電競技術團隊，我們一直竭盡所能地對比賽環境進行測試、檢查、再三檢查，以確保無虞。我們一直是以為職業選手創造同等競賽環境作為最高優先級。我們的目標是讓技術讓路，將舞台留給運動和比賽本身。

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

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

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

來源：遊俠網