魔獸世界懷舊服,官網藍貼總結安其拉開門,全球玩傢共4000隻黑甲蟲
本月初,《魔獸世界懷舊服》中最令人期待的事件之一上線瞭-安其拉戰爭。
整個懷舊服-部落和聯盟的強強聯合-聚集在一起,為打開大門和解鎖安其拉貢獻瞭資源。
當“流沙之戰”於2006年首次(也是唯一一次)發生時,來自每個服務器的成千上萬的玩傢再希利蘇斯參與瞭這次壯舉。人數超出瞭開發團隊的想象,簡單地說,我們還沒有做好準備。服務器很快變得超載,許多玩傢陷入瞭登錄,斷開連接並試圖在12小時內重新上線的循環中,而我們的工程師則忙於解決修補程序問題並使玩傢重新連接。
在活動期間我們確實設法穩定瞭服務器,並吸取瞭很多教訓,但我們看到瞭做得更好的機會。WoW Classic通過專註於服務器優化以消除延遲和消除服務器崩潰,同時在希利蘇斯的玩傢數量是2006年活動首次亮相時的兩倍。
在本文中,我們將介紹如何使用自動調節和壓力測試來確定斷點和手工優化解決方案,以及如何在軟件中提出解決方案,從而重新創建這個備受期待的事件,解決硬件無法解決的問題,以及我們如何在服務器崩潰次數有限的情況下策劃全球性事件,同時保留瞭《魔獸世界》的經典遊戲體驗。
再現第二次戰爭
在如何設計此事件的方式時,我們牢記三個具體目標:防止服務器崩潰,增加預期的區域玩傢限制,並確定在將玩傢移植到希利蘇斯之外之前可以容忍多少延遲。在深入瞭解如何最大限度地提高服務器性能之前,必須瞭解我們正在處理的約束:懷舊服代碼庫的局限性,人群管理解決方案的工作方式以及它們如何影響遊戲玩法。
超越邊界
現代版本的《魔獸世界》建立在15年前發佈的原始代碼庫的基礎上。自遊戲發佈以來,我們已經開發出瞭更現代的方式來處理《艾澤拉斯戰役》中的大量玩傢,尤其是分層。分層使魔獸世界服務器可以容納比2006年更多的遊戲玩傢。在為艾澤拉斯戰役中,我們使用它們通過在玩傢人數達到一定閾值後復制區域(例如Zuldazar)來管理服務器的玩傢負載。這可以通過在區域的不同版本中分散玩傢來消除延遲問題,因為玩傢不斷地向服務器發送大量數據包以準確確定其動作,因此玩傢互動是CPU占用最大的時間。此外,分層可緩解過渡到玩傢人數超過閾值的新區域時可能遇到的潛在滯後問題。聽起來很簡單,除瞭有個吸引人的地方- 魔獸經典經過精心設計,可以忠實地重現原始的1.12遊戲數據,其中包括保留其遊戲玩法。在極少數情況下,分層會在進入新區域時使您的怪物(例如敵方玩傢或NPC)消失。保持仇恨將意味著失去一些懷舊的遊戲性時光,它們會跨越區域邊界追逐玩傢和NPC。因此,現在我們需要提出一種不幹擾原始遊戲玩法的解決方案,同時還允許我們將更多玩傢加入服務器,而不會迫使玩傢遭受無法玩的延遲。
為瞭解決這個問題,我們選擇使用分層(整個區域(例如東部王國)的副本)來管理玩傢人數和滯後問題,同時保持原始發行版的令人難忘的魅力,以便玩傢可以再次跨區域放風箏並追逐世界首領跨越區域內的敵方玩傢,無需將他們重新分配到其他分層的風險。但是,將圖層設計為非永久解決方案。由於原始的1.12版本既沒有使用分層技術,因此許諾我們隻會在《魔獸世界經典》發佈時使用分層並隨著時間的推移逐步淘汰它們,因為它們在世界各地分佈更均勻。在某些情況下,由於大量活躍玩傢(例如,北美的Faerlina),我們仍然使用分層,但是自遊戲發佈以來,我們減少瞭在這些領域中活躍的層數。經過15年的積累,《 AQL戰爭》是《魔獸世界》經典遊戲中備受期待的事件之一,我們希望《 AQL戰爭》能夠在一個區域(遊戲發行版起始區域之外)中擁有最多的玩傢,而無需進行分層管理。沒有分層或分散人口技術,我們就必須迅速地發揮創造力。
手工打造難忘的經歷
我們通過尋找(自動化的玩傢)並指示他們模仿真實玩傢可能會做的事情(例如施放法術,與NPC戰鬥以及在該地區四處移動)來尋找非分層碎片解決方案。這使我們可以快照成千上萬的玩傢在一個區域中進行交互時的表現。在運行瞭這些模擬之後,我們與志願者組織瞭壓力測試,以便我們可以捕獲現實的玩傢行為並觀察他們的比較。這給瞭我們一些斷點的指示,以及服務器數量最多的服務器代碼中遇到最多問題的部分。對服務器幀時間的測量進行瞭嚴格審查,以查看它們與導致服務器無響應(也稱為死鎖)的距離有多近。
下一步是分析影響服務器性能的因素,以便我們可以將這一艱巨的任務分解為可理解的目標。我們面臨的是一個多項式問題,這意味著我們無法通過向它扔更快的硬件來解決它,因為硬件的性能不是指數級的。取而代之的是,我們必須通過有選擇地將哪些數據傳達給玩傢以及每隔多長時間來手工進行優化。
為瞭說明這個難題,我們假設有20位玩傢圍成一圈跳躍。服務器通過數據包(數據可交付物)將每個玩傢的動作中繼到其他19個玩傢。在這20人的小組中,服務器處理380個數據包(總共20個玩傢* 19個接收者= 380個數據包)。當更多玩傢在區域中執行相同操作時,此問題會加重。如果我們將示例增加到500個,則將從服務器發送249,500個數據包。如果我們將示例再增加到1,500個,則將2,248,500個數據包發送到服務器。根據玩傢的動作,每秒發送多個數據包- 請記住,以上示例僅說明一個動作。發送給服務器的數據包越多,服務器在處理其他玩傢的動作時必須承擔的處理時間越多。當此問題加劇時,服務器將開始陷入僵局。在《魔獸世界經典》中,每個領域的玩傢數量比2006年的數量要多得多,因此我們期望與以往相比,我們能夠容納更多的玩傢。
優化服務器性能
我們的服務器經過精心設計,可以在遇到死鎖時崩潰並重新啟動,因此我們知道,盡一切力量來幫助最大程度地縮短處理時間是至關重要的。經過一些測試,很明顯,移動是對服務器施加巨大壓力的第一道處理能力。我們首先刪除面對的更新(顯示角色模型面對的方向),並且僅在玩傢開始,停止或使用鍵盤移動時才發送玩傢更新。由於過多的播放器的延遲已經受到影響,因此花費CPU時間發送次要的面對更新會使保真度變差。因此,最好停止發送它們。我們決定取消發送運動更新的頻率,以支持在區域中擁有更多玩傢。請記住,我們正在嘗試在服務器崩潰之前找到突破點,同時允許盡可能多的玩傢進入希利蘇斯。畢竟,最好錯過一些動作更新,而不是根本無法登錄到角色。我們還開始限制標記為優先級較低的數據。做某事被認為是“不太重要”的動作,其發送速度不應與“更重要”的動作相同。我們看到許多消息都是一次發送的,而不管它們有多重要,並且優化瞭代碼以僅向您批量發送不太重要的信息,並減少瞭發送頻率。
BUFF和減益效果對我們的表現又有很大的影響。在全世界,尤其是在與BOSS戰鬥時,buff和debuff一直應用於單位。盡管這似乎沒什麼大不瞭,但由於周圍都是高度集中的玩傢,因此需要傳遞這些信息。類似於限制低優先級數據,我們現在對buff和debuff進行批處理,以避免連續向玩傢發送多個數據包。
管理玩傢人數
除瞭優化服務器以在每個區域中容納更多玩傢之外,我們也無法逃避不可能在希利蘇斯中容納整個服務器的人口(超過原始1.12 WOW的兩倍)。必須做出艱難的決定,通過控制允許誰進入和允許多少玩傢來限制進入該區域。我們決定隻允許希利蘇斯內允許60級角色,如果已滿則停止允許符合條件的角色進入。制定此限制是正確的選擇,因為眾所周知,希利蘇斯事件是遊戲的終極內容,並且較低級別的角色仍可以參與其他地區的戰爭,例如殺死在貧瘠之地中遊蕩的小怪。適用於20級到30級的玩傢。第二個關鍵點是,我們知道在不使服務器崩潰的情況下可以處理的區域中有多少玩傢的上限。然後,問題就變成瞭該數字應減少到多少,以達到最佳的演奏者比率。經過測試,我們發現這個數字大約是1,500,如果他們疊放在一起的話。但是,由於偶數占據瞭整個區域,因此一旦玩傢分散,我們看到的性能問題很小。
該活動計劃在所有地區舉行,因此我們必須確保該活動可以跨多個層進行。這意味著在一層上敲鑼的持權者應該在與該服務器相關的所有其他層上開始活動。由於事件的觸發是基於玩傢互動的,所以我們希望確保權杖持有者在多層中可見,以便同一服務器中的所有玩傢都能看到它們。這就產生瞭一個有趣的問題,因為服務器現在必須中繼此信息,而這些信息通常不需要相互通信。當我們編譯並通過服務器發送更新以確保我們跨多個層鏡像數據時,可能會給成千上萬的玩傢帶來很多麻煩。
我們從引入荊棘谷釣魚比賽開始開發這項技術,然後將其應用到瞭奧妮克希亞,奈法利安,祖格和世界BUFF。一旦我們認為它能夠按預期工作,我們就可以與其他技術一起對AQL開門事件進行測試。
試驗解決方案
既然我們已經解決瞭主要的技術難題,並采用瞭幾種方法來優化服務器性能,那麼現在該是測試我們所做的一切的時候瞭。我們創建瞭10小時戰爭的簡化版本,縮小為僅運行一個小時。
在第一次壓力測試期間,我們幾乎讓所有玩傢進入該區域,看看會發生什麼。在某一時刻,我們幾乎是整個1.12服務器容量的150%。這是我們看到測試服務器崩潰的時候。我們知道我們對要限制區域的人數有非常高的數字,而且我們看到的數字大大超過瞭這個數字。我們調查瞭這個問題,並意識到允許玩傢同時進入一個區域和一個區域之外的代碼是一個隊列,無法立即處理許多玩傢。這就是為什麼玩傢沒有被移走,以及玩傢長時間停留在飛行路線上的原因。我們恢復瞭服務器並繼續進行壓力測試,並隨即進行瞭調整。我們將數字慢慢降低到感覺仍然很落後,可以玩的程度,並且留住瞭比以前任何區域都多的玩傢。該事件原本隻需要一個半小時,但由於崩潰而導致最多需要四個小時才能完成。
一周後進行瞭第二次壓力測試。這使我們能夠查看優化是否有效。在進行壓力測試後,我們立即註意到瞭改進-玩傢不再被困在通往希利蘇斯的飛行路線上!我們能夠獲得足夠的數據,以證明我們可以輕松地在希利蘇斯中擁有多少玩傢。在兩次測試之後,我們提出瞭一些認為可以在管理延遲和服務器穩定性之間取得最佳平衡的數字。這些測試使我們能夠查看優化是否有效,並認為這兩項測試均成功,因為它們使我們能夠識別區域上限並對其進行迭代。
在艾澤拉斯各地傳播服務器解決方案
最初,這些優化計劃僅在開門戰期間對希利蘇斯有效。在確定它們可以安全地在全球范圍內推廣之後,我們在1.13.5中將它們應用於瞭整個世界。一旦戰爭努力開始,玩傢便開始上交補給品並大批收拾蟲皮屍體。我們不僅在希利蘇斯(Silithus),而且在我們的首都和外圍地區都看到大量的玩傢湧入。這些優化有助於使這些體驗更加出色,從而使艾澤拉斯各地可以進行大規模的PvP戰鬥。甚至有一些玩傢甚至催生瞭使用BOSS風王子桑德蘭來幫助清除。
即使尚未發生開門事件,一些服務器仍面臨著一些奇怪的問題,即它們的收集沒有進展。一些服務器完成戰爭工作的速度如此之快,以至於在每個上交的服務器中都會導致出現競爭狀況,這可能會導致5天計時器無法啟動。由於發生這種極端情況的機會很小,因此我們能夠手動修復這些服務器,然後解決此問題,以供將來的服務器完成他們的工作。
戰爭工作完成之後,已經過去瞭五天,打開瞭大門,我們開始監視世界上第一個開放的中國服務器。在中國,第一個能開門的服務器是奧羅。當我們監視每個層人口時,我們看到每一層上的大多數玩傢都在希利蘇斯。該事件一次跨數千個玩傢的多個最大化層進行,這是我們從未做過的事情。盡管存在明顯的滯後,但是我們的服務器在第一個中國服務器開放期間沒有遇到任何崩潰。
敲第一個鑼!
值得註意的是,8月4日,服務器重置後不久,北美將有多個服務器準備迎戰。我們一步一腳印地主動監視Game Master帳戶上的這些服務器,並通過觀察工具來監視和解決可能遇到的任何問題。每個領域都打開並開始活動,沒有任何問題。持權杖的人收到瞭久負盛名的黑色奇拉坐騎,玩傢不得不與更大的蟲子作戰,我們對穩定性感到滿意。當我們等待第一臺重置後的服務器完成其五天的等待時間時,我們註意到瞭一個重要的問題:服務器重啟後事件沒有持續存在。這意味著,如果服務器崩潰或重啟,我們將失去所有進展。盡管自從《魔獸世界》開發之初就存在此問題,但並沒有很多應用程序在服務器重啟後持續使用事件。我們的團隊能夠迅速解決該問題,但是我們需要確保不會再發生任何重啟,直到我們能夠部署一個修復程序並將所有現有的戰爭努力狀態正確地編入我們的數據庫中,而不會幹擾玩傢。
有人可能會爭辯說,讓服務器崩潰是造成原始AQL戰爭混亂的原因,這反過來又使之令人難忘。相反,我們努力通過策劃更穩定的體驗來培養同樣的熱情,每臺服務器上可以同時與大約1,500名玩傢共享這些體驗。我們希望讓經典AQ戰爭的記憶能夠在10小時的比賽中吸引盡可能多的玩傢,而不會中斷。雖然我們確實遇到過一些崩潰的境地,但我們能夠使它們迅速恢復在線狀態。這些領域已完全恢復,並在幾分鐘之內恢復瞭在線,隨後沒有發生崩潰。
全球已有超過4,000名玩傢成為黑蟲子的擁有者(Scarab Lords),並且隨著每臺服務器進行的努力,這一數字還在繼續攀升。自從AQL戰爭開始以來,對魔獸世界懷舊服的興奮和參與令人難以置信,我們感謝所有加入我們參加第二次“流沙之戰”的人們!