广场上的一百人
我们同时让一百个玩家进入城镇,每人有账号、两个角色和一支队伍,随意走动,偶尔发一句 “oi”。整整两分钟没有一个人掉线。至此第 1 阶段结束。
为什么做
路线图里有一个结束第 1 阶段的条件:城镇要能承受一百人。我们宁愿这样提前找到极限,也不想等真人在聊天里抱怨时才发现。
怎么实现的
在一台机器上开一百份游戏是不行的,所以这一百个 bot 都跑在同一个程序里,每个都有自己的连接、账号和路线。对服务器来说,这就是一百个不同的人。
第一次的结果是,处理能力还行,网络不行。服务器每个 tick 大约花 7 毫秒,预算是 50 毫秒,但每个玩家每秒收到接近 16 KB。所有人都在同一个地方出生,所以每个人能看到大约三十个其他人,而位置是用一种通用格式发送的,里面全是文本。
我们换成了二进制包:每个玩家用一个短编号,位置用整数像素,朝向用两个字节。每看到一个人是八个字节。带宽降到每个玩家每秒 2.6 KB,少了六倍,手机连接也绰绰有余。
| 指标(100 个玩家) | 之前 | 之后 |
|---|---|---|
| 服务器平均 tick | ~7 ms | ~7 ms |
| 最差 tick | ~40 ms | ~40 ms |
| 每个玩家的发送量 | ~15,8 KB/s | ~2,6 KB/s |
这是在开发机上测的,服务器和 bot 共用同一个处理器,所以在真正的服务器上应该会更宽裕。40 ms 的最差 tick 出现在峰值时,等城镇变大,我们要盯的就是它。
下一步
第 2 阶段:其余的系统,从真正的背包和农场开始。
变更
- perf(city): 8-byte binary city snapshots; 100-bot load test passes
CityCodec packs each visible player as u16 id, u16 x, u16 y, s8 dir x/y; static info carries the short id once. Load tool runs many bots in one process with a SceneMultiplayer per bot; server prints tick and bandwidth stats with --stats. 100 of 100 bots stayed in the city for 2 minutes: ~7 ms average tick, bandwidth per player down from ~15.8 to ~2.6 KB/s. Closes fase 1; roadmap moves to fase 2. Protocol 6.