國產游戲的開放世界熱潮，可以追溯至 2020 年《原神》的成功。自那時起，各廠上馬開放世界項目的消息高頻涌現。現在 5 年過去了，整個行業也經歷了從狂熱到理性的轉變。

據不完全統計，2024 年以來，已有超過 37 家開放世界游戲開發團隊解散，超半數項目陷入停滯或終止。在那個狂熱時期堅持下來的部分項目，如《鳴潮》《燕云十六聲》等游戲成功走到了市場前列，后繼的《白銀之城》與《異環》等作品憑借差異化創新嶄露頭角。而在它們身后，是各式各樣的尸體。

開放世界項目同時具備 " 極高風險 " 與 " 極大成功 " 的屬性。我們嘗試從市場趨勢和研發模式等角度進行分析，希望發現背后具體且復雜的成因。

為什么要做開放世界？

中國游戲行業一直在迅猛發展。龐大的玩家群體導致市場在 10 年內形成了從休閑游戲到重度游戲的轉變，玩家們呼喚更復雜、更龐大和更有代入感的游戲。MMO 和卡牌游戲在 2020 年已經成為一片紅海，買量成本不斷增加，玩法結構趨同，行業發展近乎停滯。市場亟待全新品類的爆款來打開新出路。2020 年底，《原神》登上市場中心舞臺，從玩法角度上，它預示著 " 開放世界 " 可能成為下一個時代的主旋律。

開放世界需要大量積累、長期投入，但在國內又有一些特殊情況。從相當多老板、制作人、主策的角度上，" 開放世界 " 等同于 " 可以用來低價買量 "。在這個系列變成紅海之前，" 開放世界 " 能大幅度降低買量成本，項目盈利就可以輕松實現。問題的關鍵是，" 便宜買量 " 的窗口期很短，項目組必須搶在 " 開放世界 " 買量的價格上來之前，把項目完成并推向市場——剩余時間取決于友商的開發速度。

所以不但要做，更要迅速做。

先把壓力給到程序

經典 MMO 類別產品高度成熟的特征之一，就是核心內容趨同。到了現在這個時間段，新立的項目不會再選擇從零開始，非新入行的從業者都有自己的儲備：美術資源、策劃文檔……還有項目工程。

如果你是老板，現在想做一個 MMO 項目，你只需要找到 2 個可靠的程序負責人，讓他們分別負責客戶端和服務器端（這兩個程序員最好此前一直在這樣配合），再找到交易、App 購置，以及若干套美術資源，然后找到 1 個老練的策劃負責配置調整和換皮——恭喜，你得到了一款 " 經典 " 的 MMORPG。先不要管它是否好玩，是否存在法律風險，它至少是一個五臟俱全、能正常運行的游戲。接下來就看市場的了。

從程序角度，這種極致的研發效率依賴于開發工程師在此前多個項目中積累的工程資源，這些資源中包含了一款 MMO 類游戲絕大多數基礎功能對應的程序需求，它們可能來自此前項目的傳承，而 " 此前 " 的范圍相當大，甚至包括一些非常久遠的項目。

這條傳承鏈路不是同一個工作室、甚至不是同一個公司內部的合法迭代，而是漫長時間里跨越不同公司高墻和保密協議的大膽聯合。人員在行業里流動，帶著他們的情感、經驗、記憶和工程資源。

對于游戲開發而言，有時候設計會讓位于效率，移動游戲尤其如此。在經歷了足夠長時間的發展后，國內的主流 MMO 呈現了 " 核心內容趨同 " 的大勢——這不全是因為從業者在游戲設計層面達成了共識，也有相當一部分原因在于，各項目組的程序工程共有一張連接彼此的混亂族譜。

對于 " 開放世界 " 來說，事情就不一樣了。

北京某中廠的關卡策劃告訴觸樂，他有一位前同事跳槽去了米哈游，對方在米哈游供職期間，對公司和項目的一切均閉口不談，原因是米哈游的 " 高壓線條例 "。

時代變了，大廠開始從意識和流程上極度重視保密。以米哈游為例，它對內部項目信息采取嚴格的保密措施。這一定程度限制了員工與外界同行的交流，也讓核心工程代碼不會向外流傳。其他游戲開發公司也有類似、甚至更嚴格的保密制度。

因此，對于絕大多數中小項目組而言，做開放世界項目沒有直接的工程可參考了。" 抄作業 " 這條路很難走通，產品之間轉變成了純粹的技術實力比拼。

程序問題是最單純、也最復雜的問題。北方某小廠的策劃老李曾負責一個 MMOARPG 項目，2020 年底，公司 CEO 目睹《原神》爆火之后，決定對老李的的項目進行大改，" 我們必須把它做成開放世界 "。

項目已經研發 2 年有余，最根本的東西是傳統 MMO 的底子。按場景加載的邏輯，游戲內 1000m × 1000m 大小的面積是單一場景的極限。開發組基于這一規范產出了所有美術資源，開發了后續所有的功能和玩法。如果改成開放世界，所有資源要重做一遍。然而，公司此時并沒有能做開放世界的程序人員。

最后，這位 CEO 放棄了貫徹 " 開放世界 " 之路。面對事實，他發現技術上要填的 " 坑 " 太多。但作為折衷方法，老李的項目做了許多 " 帶有開放世界色彩 " 的東西，例如互動探索點，算是強行蹭上了 " 開放世界 " 這個噱頭。

真心想做開放世界的項目組，只能在技術方向上全力拓展。

從技術角度而言，從 " 讀條加載切換場景 " 到 " 開放世界 "，主要區別在于場景加載方式。前者是經典方案，角色進入一個場景前就加載全部資源，切換場景時卸載舊場景資源，然后加載新場景（即 " 讀地圖 "）。這套邏輯無法滿足開放世界，因為開放世界一定會很大，如果一股腦全加載到內存，沒有多少玩家的設備硬件條件能支持。

所以有了采用動態加載方案：編輯器會把開放世界場景切成幾十個地塊，依據玩家所在坐標，程序會自動加載玩家腳下和周身 8 個方向、共 9 個地塊。隨著玩家位移，不斷加載新靠近的地塊，卸載遠離的地塊。

這就是開放世界地圖加載的基本原理，隨著人物移動，內存加載和卸載工作始終在進行，這是程序的工作重點之一。這一基本邏輯會帶來一系列關聯問題，模型密度、燈光、場景顯示距離、模型 LOD、蘋果和安卓的內存配給區別等等，都會產生影響。開發工程師要不斷深入優化，如果優化不好，高配設備會出現卡頓、發熱等問題，中低端設備干脆沒法玩。

" 技術 " 在這個過程中代表了最剛性的支出和最無法繞開的困難。但好在它們是純邏輯的問題，可以通過不斷努力嘗試去解決，在進展過程中，決策者可以清晰認清前進的方向和前方的阻礙——雖然很費勁，但僅僅只是費勁而已，相比起其他困擾來說，還不至于迷失。

權力結構的混亂

一般來說，做好某件事有兩種方向。第一種是系統學習相關專業知識并加以正確訓練，然后循規蹈矩地完成；第二種則是大量踩坑反復試錯，通過總結經驗教訓，找到可行之路。

面對 " 開放世界 " 這個新命題，絕大多數團隊都是倉促迎戰，它們不約而同地在第二條道路上前進。許多需要一開始確立的規范，以及貫穿項目始終的常用基建，都必須讓路于緊湊的工期和匱乏的人力。

老練的團隊都有豐富的項目中前期經驗，之所以是 " 中前期 "，是因為比起 " 活到上線 " 的游戲，" 曾經活過 " 的項目要多得多。多數情況下，項目立項的第一推動者是公司老板，團隊成員很多時候只是順勢前進。所以，大部分在研的開放世界項目會順利通過前期——老板的意志是項目最大的保障——順利抵達中期，也就是 Demo 通過，開始大量召集人手進行鋪量的階段。

對于 MMO 項目而言，100 人的研發團隊已經是較大的規模。而現在—— 2025 年——如《鳴潮》這種頂尖的開放世界二游研發團隊規模是 800 人以上。以中等水平，也就是假定老板為某個開放世界項目的鋪量安排了 500 人的團隊預算來計算，那么接下來，在人力資源部門的配合努力下，研發團隊得到了大約 5 倍于 MMO 時代的人員。這個體量意味著，一名制作人無法直接掌控團隊全員。

為了應對這種局面，領導者需要把所有工作內容分類。工作內容通常會分成兩類：" 復雜尖端的核心重點 " 和 " 簡單量大的常規內容 "。核心成員（往往同時是管理者）會依靠一套管理系統，讓開發中的常規內容按照已知標準自然推進，讓自己的時間和精力聚焦在項目的攻堅部分。所以，核心領導者會把管理工作拆分，之后將自己專注范圍之外的內容交給其他領導把控。

這會導致，一個開放世界項目有多個核心成員共管，他們可能在開始也曾有過分工，但隨著項目推進，更多難以界定的問題和工作涌現，管理層面原始的分工安排逐漸讓位于核心成員之間的隱形默契。

某科幻題材大世界項目的開發人員 " 云教授 " 向觸樂舉了個例子。他所在的策劃組內有 4 個核心領導，權力最大的制作人管理項目全部內容，游戲的一切都要按照他心中的藍圖來實現；第 2 位核心成員把控進度，敦促所有人按時交差的同時驗收所有工作成果；第 3 位核心成員負責日常管理，如工作周報、培訓等等，但也會在項目當前進行的工作中挑自己感興趣的介入指導；第 4 位核心成員比較謙遜，只在特定時候為陷入困難的人提供支持。

隨著項目推進，大家和第 4 位核心成員關系還行，矛盾就聚焦在前 3 位，偶爾會有某幾個功能負責人想找上這 3 人 " 同歸于盡 " ——人們發現，一個需求文檔從開始起草，到評審通過，會收到多重指示。3 位領導的側重點和性格不同，每個人都可能對內容給出不同意見，再加上 "3 人意見相同 "" 其中 2 人意見相同但與另 1 人矛盾 " 的情況，落在執行人員頭上就是 7 種潛在的可能性。隨著時間推移，每位領導的觀點還可能產生變化，更令人無所適從。作為身處基層的策劃，云教授需要拿出一個融合所有領導想法的方案，并收獲所有領導的嫌棄。

某中廠前策劃祥同學也告訴觸樂，公司 2 年前重啟大世界項目后，基層策劃要面對頂層的多個領導。公司以民主的思路，讓每個策劃方案都經歷 5 到 6 個管理者的漫長拉鋸。提出方案的人要綜合每個領導的要求完善文檔，但要求總會包含 2 個及以上互斥的立場，不少員工因此感覺無路可走，最終選擇離職。祥同學對此感嘆：" 也許很多東西進步了，但草臺班子定律永遠不會過時。"

工作流的混亂

沿海地區某中廠版本 PM 小趙曾想親手把項目組的場景負責人 " 從公司大樓扔出去 "。

原因很簡單，這位負責人不愿意自己的工作內容僅僅在策劃需求的范圍內發揮——小趙傳來的文檔要求兩個地區之間有可行走區域連接，而場景負責人在實際落地內容時，為地區交界處設計了河流和渡船，并表示這是出于審美考慮做的加工。

小趙嘗試數輪交涉，但對方堅持自己的設計，直到更多的同事找到他——因為多了河流和渡船，任務規劃需要修改；因為渡船為新增機制，程序需要做新的邏輯，動作組需要設計主角的劃船動作和船體的運動動畫；因為這段屬于前期流程，需要動畫組去設計渡船行進中的運鏡；因為領導不曾批準過這個改動，需要場景負責人去和領導 " 單挑 " ……出于種種原因，最終，這位負責人做出了讓步。

看似結局圓滿，但相關人員為此消耗了幾個小時的精力，原本要推進的內容都為此放下。一條線路上，許多人半天的工作產出都是零，但工期不會為此延后。小趙一邊加班痛苦地調整排期，一邊通過聊天窗口向我吐槽這些。

這就是工業化的代價——當游戲越來越大，開發越來越復雜，團隊的規模就越大，內部互動關系也就越復雜，從而越來越呈現出對初始條件敏感、非線性、難以長期精確預測等特征。在這個前提下，" 某個成員的靈光一閃 " 已經不是好事了。隨著團隊規模的提升，" 靈光一閃 " 會導致團隊內矛盾數量呈幾何級數增加，即便微不足道的摩擦也容易導向嚴重的后果。

在工程管理層面，小趙遇到的問題算是比較好解決的，進行針對性培訓或換人即可。更大的問題是基建工具的缺失。傳統移動 MMO 項目的從業者往往認為一套工作行為規范就足夠應付開發——對于規模較小的游戲而言，這沒錯。但當某個項目的開發人員超過 500 名，管理者就不可能關注到每一個成員。

所以，基建工具必不可少。基建工具一般由專門的工具組維護，能夠協助研發人員規避基本的錯誤操作，自動完成那些重復但必要的操作。尤其在版本管理工作上，基建工具可以協助開發者完成 " 自動合并主干 "" 特定版本內容篩選 " 等便捷操作。它提供的便捷和限制從宏觀上把工作限定在了有效和安穩的范圍內，使開發者可以更多關注工作內容本身。

具體到開放世界產品，舉例來說，因為內容龐大，開發人員極多，所以主干版本不但包含了所有的功能、資源和配置、更包含了所有的 Bug。這導致在多數時間里，主干版本都無法穩定運行。

因此，項目需要給不同模塊的負責成員分發版本，進行多線并行開發。但模塊之間互有影響，異步版本之間又有兼容障礙，這些問題直接關系到多版本開發的拆分或合并操作。這就需要有基建工具用于理清版本并自動化拆分合并。

云教授曾在某中廠的在研開放世界項目供職，出于一些原因，項目歷經了核心成員的整體換血。在過去，MMO 和卡牌時代，項目組人少，內容也不多，無需拆分多個開發版本，僅憑純人力手動就能搞定多版本問題。但此時，開放世界產品的體量已讓工作陣線極大鋪開，由于項目起步時的準備工作不完善，基建缺失，加上人員換血導致的項目部分知識失傳，且執行層長時間逃避多版本合并的問題，導致各版本的兼容性愈發糟糕。后來傳聞，這個項目組已經 " 幾十天沒打出完整的包 " 了。

這只是一個相對典型的例子。因為開放世界游戲工程規模更大，所以對開發流程和管理要求就更高。然而許多中小廠開發團隊此前的規模只有幾十人，根本沒有基建工具和工作流的概念，也沒有力量去設計開發并維護它們。項目人數達到 300、甚至 500 人，原有的管理方法全部失效，只能靠蠻力和緣分要求項目穩定前進，隨著規模擴大，最終必然會陷入混亂。

不過，仍然有一些優秀的開發組能夠邁過這個檻。接下來，他們面對的問題其實好辦很多。

內容設計中的缺陷

能活到這一步的項目組其實很厲害了，他們至少在技術上跨過了 " 開放世界 " 的門檻，在管理問題上沒讓項目組散架，甚至確立了可行穩定的工作流。從這個角度，遇到內容設計問題甚至可以算是一種幸福。

所以到了這一步，反而沒什么可說的——開放世界不但考驗技術和管理，也在考驗策劃對于內容的設計能力，傳統 MMO 對場景的規劃一般就是列 Todo List：這個區域下放多少寶箱、放多少怪、放多少解謎、種哪些 NPC、配多長時間的任務。

面對開放世界，許多策劃也如法炮制，最終給玩家呈現一個 " 技術上運用了開放世界的 MMO"。

如果你看過了上面的那些問題，就會發現，策劃的問題看起來甚至更好解決——對于很多國內廠商而言，開放世界的門檻太過高大，大多數開發者在道路的前半段就已經死掉了，以至于很少有廠商能夠面對設計層面的問題。而能夠走到后半段的廠商，往往執行力十分強悍，內容設計反而相對比較好辦。

除此之外，還有一些不值得討論成敗的項目，它們的誕生不全是為了攻向市場，而是另有其他目的。它們處于研發過程中的時候，就會給項目管理者帶來薪資以外的高額收入，雖然公司規定和法律都不允許，這些人卻還是會盡力讓項目進度在彎路上不斷徘徊。

但對于認真和踏實的項目組——我們相信這仍然是多數——來說，在歷經奮斗后，往往會對開放世界產生消極理解：" 版本陷阱 "。因為接下來等待他們的還有許多挑戰。

結語

開放世界的研發門檻比大多數人想象的要高得多。它對技術、美術、項目管理都提出了空前挑戰，即便是實力雄厚、經驗豐富的大廠，也曾在 " 開放世界 " 的開發之路上折戟。

然而我們不妨把視角放得更高，從時間軸上宏觀理解這件事：隨著玩家需求的增加，游戲開發所涉及到的技術水平、設計理念、管理理念、產品素質等方面都在迅速提升。我們總會遇到類似 " 開放世界難題 " 這樣的 " 時代挑戰 "。在挑戰面前，項目組往往需要拿出豪賭般的資源投入、極致的高效管理、持續的敬業態度去填充技術發展上的鴻溝——而這些并不能保證必然成功，他們仍然可能面臨失敗，如果失敗，就死掉，或者留在之前；而如果成功，就有機會見到下一關，面對新的挑戰。

自電子游戲產生以來，我們的行業就是這樣前進的。