来源与版本策略
当前版本
| 项目 | 值 |
|---|---|
| HTTP 与 WebSocket API | v0.1 |
| 游戏规则 | v0.14 |
| 服务器仓库 | arena-hero/arena-hero |
| 已审查服务器提交 | b24cfcd22b82c0af0f3993397d2696629762e7e5 |
| Python SDK | arena-hero/arena-hero-python，PyPI v0.2.9 |
| 已审查 SDK 提交 | 423d252adcca439669adb3e7b04252e53b4430bd |
| 服务端审查日期 | 2026 年 8 月 6 日 |
| SDK 审查日期 | 2026 年 8 月 6 日 |
| 文档仓库 | arena-hero/arena-hero-doc |
| 语言 | 英文、简体中文 |
按五个项目仓库整理的版本变化见更新日志。
文档和服务端不一致时
这些页面描述的是公开的游戏规则和 API，但运行时到底怎么表现，由服务端代码、数据库 约束和测试说了算。
所以当已发布的文字和已发布的实现对不上时：
- 别把这个差异当成隐含规则去利用；
- 记下确切的服务端版本，以及你实际观察到的行为；
- 到文档仓库或服务端仓库提一个 Issue；
- 等预期行为定下来之后，两个仓库一起更新。
哪些修改会影响兼容性
下面这些只要一动，就可能弄坏现有客户端，因此每一条都需要明确的协议版本决定：
- 15 秒全局命令窗口，以及以
state作为动作触发器； - 确定性结算阶段和原子提交；
- 完整来源计划替换，以及 Manual 的优先级；
- 动作字段规则与幂等；
- WebSocket 消息类型和重连快照；
- 战争迷雾的隐私边界；
- 地图生成器契约；
- 有限资源的区块配额、Cargo 掉落、消耗、刷新与竞争规则；
max(10, population × 5)的严格 Core 容量与超额销毁；- 精确的随人口变化的 Unit 价格、战后人口结算和权威生产结果价格；
- 战斗摧毁 Core 时的资源获胜者、同 Tick 双方 Core 死亡和容量外销毁规则；
- 战斗后无条件 Core 自毁，包括迁移中行为、全军移除、掉落、归属和立即重生；
- 战斗后 Unit 与 Core 恢复 HP、Unit 优先使用资源，以及 Core 恢复、修盾和生产位于 战斗之后的结算顺序；
- Ranger 八方向射线几何，以及只有射线中间格障碍物阻挡射击的规则；
- Ranger 无需目标的按格射击，以及移动后按最低 HP、UUID 原始字节序确定目标的规则；
- Core 在被摧毁的同一个 Tick 尝试重生，以及仅用于重试的
RESPAWNING状态； - 决定重放结果的核心平衡规则。
其余的东西——文字、排版、图表、示例、讲解顺序——可以随意改进，因为它们都不改变游戏 契约。
为什么现在还没有版本选择器
公开 API 仍是 v0.1，当前游戏规则是 v0.14，所以站点只发布一个当前版本，提供英文和简体 中文两种语言。等有了第一个稳定的兼容版本，旧协议就可以作为 Docusaurus 版本保留下来。
修改协议时要更新什么
任何玩法或游戏 API 的改动，都得把下面这些一并带上：
- 服务端仓库里的实现和测试；
- 官方 Python SDK 中对应的模型、行为和测试；
- 本仓库里同步更新的英文和简体中文页面；
- 涉及到的话，更新 OpenAPI 或 AsyncAPI Schema；
- 通过验证的双语生产构建；
- 只要现有客户端可能被弄坏，就给出明确的兼容性说明。