持续在线世界

Category

industry / genres 子树。节点定位：持续在线世界专题——世界持续存在带来的协同难点的类型速览。

Definition

持续在线世界的关键不只是“人多”，而是世界在玩家不在线时也要继续存在，状态要持续积累，多个系统要围绕同一份长期世界状态协同工作。典型例子包括 MMO、开放世界在线化产品、大型生存沙盒和强公会社会化游戏。

Problem

不只是人多：世界在玩家离线时继续存在，多系统要围绕同一份长期世界状态协同，这是 MMO、开放世界在线化、生存沙盒、强公会游戏的共同难点。

这类游戏真正难在哪里

一旦世界持续存在，技术问题就从“单局正确”升级为“长期稳定”。你不再只是处理一场战斗，而是在维护一个会不断膨胀的活系统：

玩家状态要长期保存
场景和对象要持续运行
不同玩家可能从不同入口同时改动同一世界
活动、版本、运维操作会持续叠加在生产环境上

所以这类游戏最怕的不是一次崩溃，而是慢性腐烂：状态脏掉、跨服耦合、脚本热修越来越重、运营操作越来越不可控。

架构重点通常放在哪

世界拆分方式决定上限：按服、按线、按场景、按 shard、按动态实例拆分，各自限制社交范围和内容表达。
状态归属必须非常清楚：角色、场景、公会、交易、邮件、活动、排行榜分别谁说了算，不能糊。
跨场景和跨服链路要谨慎：迁移、跨服战、跨服社交都会显著提高一致性和故障处理难度。
运维能力就是产品能力：扩容、迁服、回档、封禁、活动开关、灰度发布都必须制度化。

常见方案与取舍

大多数持续在线世界都会选择“局部权威、分区治理”的架构，而不是维护一个真正意义上的单一全局世界。原因很简单：统一世界太贵，也太脆。

常见取舍集中在三处：

大服社交感还是可控运维：玩家越像生活在同一个世界，迁移和扩容越难。
强交互深度还是系统稳定性：自由交易、自由建造、强公会战争都会放大对象关系和脏数据风险。
热更新灵活性还是行为可验证性：线上脚本越多，迭代越快，但故障面也越大。

常见误区

把“持续在线”理解成“所有状态都必须实时共享”。很多状态其实应该异步化、分层化，否则系统很快会失控。
过早承诺“大世界无缝”。如果玩法和商业模式并不依赖这一点，代价往往远超收益。
低估运营对系统的侵入。持续在线项目最后常常不是被战斗写死，而是被活动、补偿、跨服和历史包袱压死。

Used By

MMO 品类速览；分区组织参照。

关系链：难点 → 架构重点 → 方案取舍 → 误区。上游：models/04。下游：server 树、database 树。

Reference

本页为工程经验归纳。