国产游戏的开放世界热潮，可以追溯至 2020 年《原神》的成功。自那时起，各厂上马开放世界项目的消息高频涌现。现在 5 年过去了，整个行业也经历了从狂热到理性的转变。
2020 年底，开放世界热潮兴起
据不完全统计，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 "。
如果你看过了上面的那些问题，就会发现，策划的问题看起来甚至更好解决——对于很多国内厂商而言，开放世界的门槛太过高大，大多数开发者在道路的前半段就已经死掉了，以至于很少有厂商能够面对设计层面的问题。而能够走到后半段的厂商，往往执行力十分强悍，内容设计反而相对比较好办。
除此之外，还有一些不值得讨论成败的项目，它们的诞生不全是为了攻向市场，而是另有其他目的。它们处于研发过程中的时候，就会给项目管理者带来薪资以外的高额收入，虽然公司规定和法律都不允许，这些人却还是会尽力让项目进度在弯路上不断徘徊。
但对于认真和踏实的项目组——我们相信这仍然是多数——来说，在历经奋斗后，往往会对开放世界产生消极理解："版本陷阱"。因为接下来等待他们的还有许多挑战。
结语
开放世界的研发门槛比大多数人想象的要高得多。它对技术、美术、项目管理都提出了空前挑战，即便是实力雄厚、经验丰富的大厂，也曾在"开放世界"的开发之路上折戟。
然而我们不妨把视角放得更高，从时间轴上宏观理解这件事：随着玩家需求的增加，游戏开发所涉及到的技术水平、设计理念、管理理念、产品素质等方面都在迅速提升。我们总会遇到类似"开放世界难题"这样的"时代挑战"。在挑战面前，项目组往往需要拿出豪赌般的资源投入、极致的高效管理、持续的敬业态度去填充技术发展上的鸿沟——而这些并不能保证必然成功，他们仍然可能面临失败，如果失败，就死掉，或者留在之前；而如果成功，就有机会见到下一关，面对新的挑战。
自电子游戏产生以来，我们的行业就是这样前进的。
配资入门网提示：文章来自网络，不代表本站观点。
