排隊與掉線,線上遊戲的「人口災難」
根據以往的經驗,只要一款線上遊戲還有些名號,那麼初期上線的過程往往伴隨著一場“人口災難”,玩家們蜂擁而至,超過伺服器負載的使用者連線,就像是持續不斷的合法 DDOS 攻擊,瞬間擊垮那些以規模著稱的公司和作品。《魔獸世界》如此,《命運2》如此,《最終幻想14》也是如此。
2004 年,暴雪配備了 40 臺伺服器迎接《魔獸世界》開服,但他們完全低估了使用者的數量級,遊戲幾近崩潰。後來發展到擴充頻寬也於事無補,不得不中斷零售商的盒裝遊戲供應,以免情況進一步惡化。
再就是不久前《命運2》的資料片“暗影要塞”上線,同樣因伺服器當機而進行了一次緊急維護,期間還鬧出了“Steam 好友超過 300 就會閃退”的笑話。有人在社交媒體上調侃到:工作辭了,婚也離了,孩子放學沒去接,就為了履行“守護者”的職責,現在你居然不讓我打遊戲?
上述這些問題,對很多人來說可能早已習以為常,但當自己不止一次的遭遇時,還是會感到疑惑。那麼多資源殷實的大公司,那麼多富有才華的遊戲製作者,為何總是一錯再錯?
搞不定的引擎
早期的線上遊戲很少會有排隊系統,因為玩家數量有限,開發商和中介軟體的製作者也不太關心使用者分流 —— 一個 MMO 內容比較泛用的引擎,Big World 就有類似的缺陷。
打造該產品的 Micro Forté 公司很有意思,他們在上世紀 80 年代給 EA 開發了幾部作品後,就佈局其它業務去了。直到 1994 年時重返遊戲行業,從澳大利亞政府那弄了筆撥款,籌劃著製作 MMOFPS 的內容、開發引擎和工具,後來又順利被微軟看中,作為推廣 Xbox live 服務的一部分,運氣可以說相當不錯。
但財大氣粗的微軟,當時其實投資了好幾家涉足 FPS 聯機遊戲的團隊,他們最後選擇了 Bungie 做的《光環》,Micro Forté 只不過是個保底。於是在專案被終止後,這家公司因經營困難被迫裁員 70%。幸好開發引擎在資金鍊斷裂前做完了,他們為了填補家用就直接打包拿出來賣,沒想到銷路不錯。
用 Big World 創造小鎮
這套 MMO 工具最終商業化,並得名 Big World 是在 2002 年,有很多我們熟悉的企業都購買了授權,比如網易用來開發《天下2》和《天下3》,Wargaming 拿來支援《坦克世界》的服務,臺灣的宇峻奧汀也是使用者之一。
還有一個比較流行的說法,有人認為《魔獸世界》的一部分功能也是通過“自研 + Big World”引擎來實現的。理由很簡單,當時暴雪的母公司維旺迪想要收購 Micro Forté,最後遭到拒絕,退而求其次獲得了引擎的使用權,而 Micro Forté 的公司介紹中又有這麼一段耐人尋味的話:
2001 年底,在技術完工的最後階段,我們收到了全球領先的跨國互動娛樂公司的收購邀約。作為交易的一部分,這家跨國公司提出會將一個重要的 IP,奇幻 MMOG 專案交由我方打造,但由於董事會認為出價太低,所以交易未能完成。
不難發現,在很長一段時間內,Big World 引擎都是線上遊戲的一套設計正規化。但正因為推出得太早,它在排隊系統、以及使用者分流方面是有所缺陷的。
就拿角色建模來說,由於最初定位於 FPS 遊戲,相當一部分頻寬和處理器資源都用在了 3D 空間的位置同步上。比如《坦克世界》裡一炮打過去,履帶、車頭、車尾都有不同判定,對於絕大多數型別的 MMO 遊戲而言,這套機制有些過於浪費效能了。
坦克世界
在排隊系統的設計上,通常情況下可以單拿一組伺服器出來當“連線伺服器”,作為使用者的入口。它們把彙集起的資訊送到“心跳伺服器”,由此轉發到處理內容的“邏輯伺服器”。當然有些小公司沒錢、沒條件,那也可以考慮利用多程式設計,把排隊系統獨立到一個程式裡,負擔過高時再分配到另一臺物理機器上運轉。
但因為 Micro Forté 最早根本沒考慮這些,導致其它公司的程式設計師在給 Big World 新增程式碼時,只能把排隊系統放到引擎框架內,結果就是沒法提高優先順序,很難和伺服器的其它資源做隔離。
再就是排隊本身的邏輯,要求伺服器短時間內接納連線,並將這些連線進行分流和保持,以免玩家“重連”而增加伺服器的負擔。但 Big World 全部採取了不穩定的 UDP 通訊協議,導致連線很難保持(雖然遊戲內使用 UDP 是一種合適的方式,參考《無盡的任務》)。
如果觀察最近幾年推出的線上遊戲,會發現很多廠商都拋棄了老舊的 Big World 引擎,也有人在此基礎上進行了二次優化。但有些古老的排隊系統早已定型,重構需要耗費很多資源,有些設計思路也沒有革新,一時半會還來不及做轉型。
不過,之所以 Big World 引擎能被線上遊戲廣泛應用,證明它還是有兩把刷子。祕訣是它並不以地圖的形式來分擔負載,而是哪裡聚集的玩家多,就給哪裡分配伺服器資源,比較靈活,因此理論上可以最大限度的容納角色數量。2011 年時,《坦克世界》就創造了併發線上人數 25 萬的成績 。
相比之下,有人猜測《最終幻想14》的單區容量撐死 10 萬人,肯定是架構方面有所不同。比如 1.0 版本用的是 Square Enix 自研“Crystal tools”引擎,當時的設計非常愚蠢,幾乎所有的頁面互動都要過一道伺服器,無法在本地進行,玩家們關個物品欄都要幾秒鐘,很容易導致伺服器過載。
歸根究底,這些網路工程的技術,和製作遊戲內容領域有別,也難怪那些知名的單機遊戲開發團隊頻繁踩坑。反倒是現在比較流行的手遊,伺服器單區容量都是以幾百萬註冊使用者、幾十萬線上玩家為基準的。
料不到的問題
當然,無論使用什麼樣的技術,還是不計成本的優化,使用者連線數在物理意義上都是有限制的。較為常見的一套排隊系統是,客戶端登入時等同於向醫院櫃檯掛號,叫到你的號時,連線伺服器把號給收回來,同時送出一張通行券。但這其中又有很多變化,比如競技匹配的排隊機制,就要求將水平相近的玩家一批批放行。看似無縫的邏輯,也很容易在外力的影響下崩潰。
《廢土之王》的製作人拉米(Rami Ismail)舉了個有趣的例子,他認為,如果是程式碼本身減慢了玩家資料的處理速度,可以比喻成“一個車站有足夠多的火車和軌道,但每個乘客都必須下車填一張表”。若是硬體限制,那相當於“軌道的數量不夠,一大批進站的火車堵住了”。要是算到網路問題的頭上,就如同“發車班次太少,人們都被困在了車站”:
也許從 A 站到 D 站的火車只比你想象中慢了 2%,但久而久之 D 站就會擠滿等待的人,直到最終發生故障。
其實站在消費者的角度來看,線上遊戲的冗長排隊和頻繁掉線,無疑是運營商“風控”的結果。他們本可以掏錢買伺服器解決問題,但又擔心玩家流失後,針對基礎設施的投資打了水漂,因此才過於保守。但置身其中的一部分開發者又會認為,問題的根源通常不是缺少機器,而是軟體引發的崩潰和故障。
一組常規的伺服器,每個黑櫃子中都包含硬碟、交換機、伺服器集線器等元件
前頑皮狗工作室的德魯(Drew Thaler)對此深有體會,他之前負責維護《神祕海域》和《最後生還者》的多人伺服器。由於索尼提供了一項尚未大規模使用的技術,《最後生還者》在重製到 PS4 上時,伺服器的程式碼出現了問題,這導致玩家的匹配時間過長,有時還會直接掉線。
開發團隊當時提出了一個臨時方案,幾個月後才發現,那個問題只是由一小段關於“SSL 實現”的 Java 程式碼引發的。換而言之,可能是配置加密傳輸時,手動處理埠、約定協議給搞錯了。雖然這算是一個比較低階的失誤,很容易就能解決,但相當難以定位,德魯表示:
就像是手機上的谷歌地圖給你指了條錯路……最後原因可以追溯到你家有根電線出了故障……網路服務不僅僅是一臺伺服器,它們是複雜的系統。這臺伺服器處理匹配和排隊,那臺要去接收日誌,這個得拿來做 NAT 隧道,還有裝置用於處理排行榜和身份驗證,又比如應對虛擬貨幣,需要對交易進行特別保護……
《神祕海域4》的多人模式也需要連線匹配
故障可能由任何細小的東西引起,《網路創世紀》的設計師拉菲(Raph Koster)同樣分享了一則糗事。有次在給《網路創世紀》的活動製作聖誕樹時,由於缺少美術,他突發奇想的做了個看起來很酷的功能:
我在一棵普通的松樹上附加指令碼,做出了彩色寶石的效果。每棵樹都帶有周期性的回撥指令碼,這些指令碼可以(使寶石)出現和消失,所以它們會閃爍。然後我們給每個登陸的玩家送了棵聖誕樹,成千上萬棵樹使得每秒會產生 20 個回撥,每臺伺服器上的訊息佇列都超載了,最終導致整個伺服器崩潰。
《網路創世紀》中的聖誕樹
實際上,《全境封鎖2》中也有過相似的問題,玩家們的炮塔和無人機有時不起作用,最後查明原來是技能的狀態效果太過複雜,一旦有很多人同時使用,訊息就會堆積起來阻塞伺服器。這意味著,不少程式碼上的缺陷,只有在使用者數量激增的情況下才會體現,德魯補充到:
這就是問題所在,遊戲在測試或是千人模擬時遠轉良好,但如果 1 個小時內,突然有 10 萬人登陸會怎樣……3A 遊戲免費後,使用者會呈指數增加,付費情況下你可能不會完全預料到這一點。我們推出過《神祕海域》的免費週末活動,它帶來了 10~20 倍於正常負載(的使用者數),擊垮了我們的伺服器。
如何保證線上遊戲穩定的執行,以及如何減少排隊和掉線的情況,全方位牽扯到引擎、遊戲設計和網路工程等相關知識,由此來看它是一項非常精細的技術。但有時這些理不清的關係,會導致某些麻煩無法單靠開發者、運營商,乃至投資人任何一方解決,於是他們本應付諸的成本,順理成章的轉嫁到了玩家身上。
十年前還有人相信,遵循摩爾定律的發展,線上遊戲的一些網路制約最終會弱化。但隨著積體電路走向瓶頸,以及使用者需求的不斷提升,時至如今,它仍然是一個懸而未決的問題。
--------------------------------------------------------------------------------
參考資料:
What is a login-queue?
MMO 的排隊系統
Why Online Game Launches Are Often A Mess
作者:箱子
來源:VGtime
地址:https://www.vgtime.com/topic/1067969.jhtml
相關文章
- 暫停,掉線,遊戲工作室的現實難題遊戲
- 突破還是災難? 淺談遊戲中的身份轉換與敘事遊戲
- 致命Bug:軟體缺陷的災難與啟示
- 遊戲背後的文化:心流理論與遊戲難度曲線遊戲
- 機器學習中的維度災難機器學習
- 雲災備、雲容災、雲備份、資料庫上雲、線下線上雲災備、災備有云等資料庫
- win10遊戲掉線怎麼解決_win10玩遊戲老是掉線修復方法Win10遊戲
- 《致命Bug:軟體缺陷的災難與啟示》讀後感受
- SQL Server災難恢復SQLServer
- zookeeper重啟,線上微服務全部掉線,怎麼回事?微服務
- XYD 排隊
- 由SUN公司為太平洋災難中心提供災難預警系統的技術支援想到的
- 在一款硬核模擬經營遊戲中“養人口”有多難?遊戲
- VR對於應對災難的意義 不要僅把VR用於遊戲!VR遊戲
- 架構與思維:一次快取雪崩的災難覆盤架構快取
- 昨日Oracle災難現場的經歷薦Oracle
- Oralce 資料庫的災難恢復(轉)資料庫
- Not Pr0n 號稱最難的線上解謎遊戲遊戲
- PostgreSQL資料檔案災難恢復-解析與資料dumpSQL
- 北京“721災難”風險管控分析
- IT系統災難恢復基本指南
- 遊戲到底難不難,是誰說了算? 關於遊戲難度與玩家技巧的那些事遊戲
- 在氣候災難的時代,這些遊戲正在用自己的方式去重新審視自然遊戲
- 對union集合操作理解不足造成的巨大的災難
- zookeeper恢復了,線上微服務卻全部掉線了,怎麼回事?微服務
- MySQL資料災難挽救之truncate tableMySql
- MySQL資料災難挽救之drop tableMySql
- MySQL資料災難挽救之Delete\UpdateMySqldelete
- 歐盟統計局:2023年30%的歐盟人口參與過線上學習
- 我在微服務世界中看到的災難 - joaoqalves微服務
- 「生產事故」MongoDB複合索引引發的災難MongoDB索引
- 上線6年翻紅的SLG遊戲《Evony》與其背後國內團隊的故事遊戲
- 使用RMAN實現災難恢復測試
- 離線查詢與線上查詢
- 要避免的七個災難性的雲端計算錯誤
- 蘋果AirPods線下鋪貨 果粉排隊購買很快售罄蘋果AI
- 百度掉隊BAT 5年後阿里與騰訊的勝負已揭曉BAT阿里
- win10 一會一掉線怎麼解決_win10 玩遊戲一直掉線怎麼辦Win10遊戲