北京
一款多人在线游戏，服务器上同时挂着500多名玩家、数万个实体在世界里互相交互，CPU占用率却只到48线程的50%。这不是什么大厂旗舰项目的成绩单，而是一个开源游戏 Veloren 的日常表现。
Veloren 的一位核心开发者最近写下了这个项目在开发过程中做过的一些"不太一样"的选择。他坦言自己现在能投入项目的时间不多——如果你也是父母，大概能理解原因。但这些选择本身，对做游戏的人来说可能有点意思。
从2018年就开始押注ECS
Veloren 没有采用传统的面向对象类继承结构，而是建立在 ECS（实体组件系统）之上。如今这在 Rust 生态里已经相当常见，但项目在2018年起步时，ECS 除了做演示程序之外几乎没人认真用，团队不得不自己发明了大量内部概念来满足需求。
这个决定带来的回报很直接：Veloren 的扩展性比大多数多人在线游戏好得多。开发者给出的数字是，48线程服务器上连接500多名玩家、游戏世界里数万个实体同时交互，核心利用率能轻松跑到50%。
而大多数同类游戏想达到这个量级，只有两条路：要么砍掉玩法范围，减少实体之间的交叉交互；要么把玩家激进地切分到不同的世界空间里去。
当多态变成默认选项
ECS 也带来了一些意想不到的怪毛病。传统游戏引擎里，不同类型的实体会在类型层面做编译期分叉，类之间的多态是需要专门开启的选项。而在 ECS 里，多态是默认状态，实体的分类体系反而需要主动去建立。
这种反转造成过一些相当有趣的副作用：
- 曾经有个 bug，玩家会根据身上携带的物品被分配一个 ItemDrop 组件。由于掉落物实现方式的切换出了点岔子，结果是玩家可以"捡起"附近的其他玩家——被捡起的一方实体会被丢弃，人直接被踢出游戏服务器。
- 刚实现坐骑功能时，防止互相骑乘的循环检测逻辑和控制权传递逻辑都有缺陷。玩家因此能堆出巨大的实体塔，一个骑一个；甚至能造出坐骑循环，物理引擎拼命想解开互相矛盾的骑乘约束，场面像极了 Bethesda 游戏里那种翻滚的混乱车轮。
玩家和NPC，尽量当成同一种东西
在尽可能大的范围内，Veloren 把玩家角色和 NPC 当作同一种存在。举两个例子：
两者与物理引擎的交互方式完全一致。NPC 不能瞬移，不能穿墙，也不能人为控制自己的物理属性。如果 NPC 的行为代码不够聪明，没把自身的动量和摩擦力算进去，走到悬崖边它就是会掉下去。
两者也拥有完全相同的移动控制选项。所有移动和控制指令都经过 Controller 这个 ECS 组件，它相当于一个虚拟手柄。
把玩家和 NPC 拉到同一套规则下，代价是 NPC 的智能必须真的过关，好处则是整个世界的物理表现不会出现两套标准。对一款开源多人游戏来说，这种一致性本身就是设计的一部分。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
