posts
在线联机原型第 39 章导航：跨平台对战
本章要验证的是「一个玩家用手机、另一个用手柄，两人能公平地打同一局」这件事。跨平台对战的难点从来不在网络，而在输入：不同终端的操作精度、帧率、延迟、屏幕尺寸都不一样，把它们塞进同一套判定规则里，公平性就会立刻失衡。本页给出第 39 章跨平台对战（Cross-Platform Battle）的定位、六个核心验证目标（输入映射、协议统一、公平性补偿、状态同步降级、账号与数据互通、网络质量分级）、推荐技术栈与真实文章入口。
第 39 章处理的是一个「商业上必须做、技术上处处是坑」的需求：跨平台对战。移动端玩家和主机玩家同场竞技，听起来只是把两拨人连到同一台服务器，实际要解决的是输入抽象、帧率对齐、延迟补偿、账号互通、以及最棘手的公平性——手柄的瞄准精度天然高于触屏，直接把两者放进同一个匹配池，等于给一半玩家判了刑。这一章适合准备做多端同服的产品与架构，也适合想系统理解输入抽象与延迟补偿的实现者。
本章定位
| 项目 | 内容 |
|---|
| 全集层数 | 第 4 层（概念原型层） |
| 难度梯度 | 进阶。协议统一属中等难度，公平性补偿与多端降级属高阶，建议先完成第 15 章微型赛车与第 16 章简版 MOBA |
| 前置章节 | 第 6 章 Pong 对战、第 15 章微型赛车、第 16 章简版 MOBA、第 38 章动态地形与世界生成 |
| 后续章节 | 第 40 章元宇宙市场与创作经济、第 47 章多语言实时语音协作、第 55 章多宇宙桥接 |
| 原型代号 | proto-39-跨平台对战 |
| 形态 | 平台兼容型，单篇文章的完整 PRD，覆盖架构、状态机、接口与验证清单 |
这一章的关键抽象是「逻辑输入」：所有终端都必须把自己的物理操作翻译成一组统一的语义动作（前进、瞄准、释放），服务端只认这组语义，不认设备。有了这层抽象，公平性补偿才有可挂载的位置。
核心验证目标
| 验证点 | 要回答的问题 | 判定标准 |
|---|
| 输入映射 | 触屏、键鼠、手柄如何映射到同一套逻辑动作 | 每个动作在所有终端都有等价输入方式 |
| 协议统一 | 不同终端如何共用同一套网络协议 | 一份协议定义覆盖全部平台，无分支实现 |
| 公平性补偿 | 输入精度差异如何被平衡 | 可配置补偿策略，匹配池可按输入类型隔离 |
| 状态同步降级 | 低端机帧率不足时如何保证体验 | 降级后判定仍与服务端一致 |
| 账号与数据互通 | 多端账号、进度、购买如何统一 | 一份身份与数据，多端可登录可续玩 |
| 网络质量分级 | 不同网络条件的玩家如何被公平对待 | 可按延迟与丢包分级匹配或补偿 |
技术栈建议
- 语言：Go、Rust、Python 三者任选，网关与同步服务建议用 Go 或 Rust。
- 协议：WebSocket over HTTPS 作为统一传输层，必要时用 QUIC 改善移动网络下的弱网表现，gRPC 承载服务间调用。
- 存储：Redis 保存在线状态与匹配队列；PostgreSQL 保存统一账号、进度与跨端购买记录。
- 客户端：各终端各自实现输入适配层，但共享同一份逻辑动作定义与协议生成代码。
- 可观测：分平台延迟分布、输入到判定的时延、降级触发率、跨端登录成功率。
本章文章
这篇文章内部按八个部分展开，阅读时可以直接跳到关心的那一段：
| PRD 小节 | 内容 |
|---|
| 一、概述 | 平台兼容的一句话定义与本章要验证的能力 |
| 二、核心玩法与系统目标 | 产品体验、功能目标与四类验证重点 |
| 三、系统架构设计 | Gateway、对战 Service、State Manager、Event Bus、Persistence 五层划分 |
| 四、功能模块详解 | 基础通信、状态同步、输入校验、日志与监控 |
| 五、状态机与流程图 | 对局状态机与输入广播时序图 |
| 六、事件与接口定义 | WebSocket 消息类型与 REST 会话接口 |
| 七、性能指标与优化 | 延迟、并发、吞吐、内存四项目标值 |
| 八、验证清单 | 可直接当作验收用例的五条清单 |
与相邻章节的关系
相关专题