WorldCast:多人游戏画面改成“各自生成、共享一个世界”

作者:陈一帆

2026 年 10 月 8 日,港中深、SLAI、清华 SIGS、滴滴 Voyager 研究院与中科大的 12 位作者在 arXiv 发布 WorldCast:每位玩家一台客户端、一块 GPU,各自视角由自己的操作实时生成,再通过交换玩家状态与场景状态拼进同一个共享世界。论文在 Counter-Strike 2 上演示了 2 到 16 人的实时长时程游玩,代码与权重已开源。

WorldCast: Distributed Multiplayer World Models

2026 年 10 月 8 日,论文《WorldCast: Distributed Multiplayer World Models》挂上 arXiv,12 位作者分别来自香港中文大学(深圳)、SLAI、清华大学深圳国际研究生院、滴滴 Voyager 研究院和中国科学技术大学,通讯作者为李江 。它提出的做法是:不再由一台服务器算所有人的画面,而是每位玩家一台客户端、一块 GPU,各自的视角由自己的操作实时生成,客户端之间只交换“玩家状态”和“场景状态”,再拼进同一个共享世界。论文在 Counter-Strike 2 上做了 2 到 16 人的实时、长时程演示,代码和权重已经开源 。

两种旧方案,各缺一半

传统多人游戏的画面其实是本地渲染的,服务器只保存权威世界状态,客户端同步坐标和事件——世界只有一个版本,所以两个人看到的同一面墙必然一样。Genie 那类世界模型走的是另一条路:给一段提示或一帧画面,模型往下推演,画面由模型画出来,但基本是单人交互,没有持久的共享世界,也没有“另一个玩家正在这儿”这回事 。

WorldCast 想把这两半接起来:画面由模型生成,但世界得是多人共用的。它的办法是把“世界”拆成两份共享状态。

玩家状态:一个状态模型根据自己生成的视频和操作,估计出自己在地图上的位置;客户端之间交换这个位置,再投影成“相机对齐的玩家状态场”,告诉别人该把其他玩家画在哪儿、怎么画 。

场景状态:一块共享记忆库。谁生成过的区块就放进去,后来的客户端直接复用,于是同一条走廊在不同人的屏幕上长得一样 。

View 3
View 1
View 2

项目页有个对照演示很能说明问题:玩家 2 在 24.5 秒转身之前,开不开场景状态看到的是同一个地方;26.6 秒转身之后,开着场景状态,他看到的正是玩家 1 先前看过的那个位置,关掉就变成了另一个地方 。这就是“各看各的直播、共用一张地图”的差别——画面各自算,地图不能各算一份。

数字与开源

按作者给出的口径:单客户端 16+ FPS,支持 2 到 16 人,16 人时每客户端下行约 3.5 Mb/s;相机对齐的玩家状态场让其他玩家的渲染率比联合生成方法高出一个数量级以上,共享场景状态改善了整回合的视觉一致性,画质在小时级连续生成中保持稳定 。这些数字目前都还没有第三方复现。

工程侧这次放得比较全:基座是 Wan2.2-TI2V-5B,训练数据为开放数据集 OpenCS2(CC BY 4.0),分四个阶段训练,最后蒸馏成四步生成器;推理、训练、评估脚本和权重都已公开,采用 Apache-2.0 协议,另有一个联网网页 demo WorldCast Live,键鼠、手柄、手机都能操作 。一作叶子扬目前在吉林大学读本科,将在港中深读博,同时在滴滴 Voyager 研究院实习 。

边界在哪儿

验证范围目前只有 CS2 的 Ancient 和 Mirage 两张地图的 held-out 回合 。分辨率、端到端延迟,在项目页和仓库里都没给出数字;16 人以上怎么扩、共享状态只发布一次之后块内细节会不会随时间漂移,公开材料里也没有量化 。

从产品角度看,这个思路值得记一笔的地方在于:它把“一致性”从模型内部挪到了系统层面。不要求一个模型同时算清所有视角,而是让每个客户端只对自己负责,用共享状态去对齐。代价也很直接——每位玩家一块 GPU,而状态交换的频率决定了这个世界有多“同步”。现阶段它更像一个能跑起来的工程原型,还不是能替换游戏服务器的方案。

转载说明

本文根据以下公开资料整理,原文及配图出处见下方。

0
游速速·游戏观察员发布在 # game · comprehensivediscussion 圈 · 22 分钟前

评论

还没有评论,来抢沙发。

游速速 · 游戏 / 软件 / AI / 硬件一站式下载站
当前页面:帖子详情