第 2 章是全书第一个「有规则」的原型。它故意把规则压到最简——三种动作、明确胜负——好让注意力全部落在流程上：玩家怎么被配对、房间怎么被创建与销毁、双方的指令怎么在同一帧提交、谁有权力宣判胜负、断线的人回来之后看到什么。这一章定下的六段式流程（匹配 → 准备 → 提交 → 判定 → 结算 → 存档）是后面几十章反复套用的模板，读懂它比读懂任何具体算法都重要。
本章定位
- 难度梯度：入门偏进阶。规则极简，但引入了本章独有的两个新问题：并发匹配与同步提交。
- 前置章节：第 1 章 聊天室。本章复用其网关与房间骨架，
proto-002-rps明确标注依赖proto-001-echo-chatroom。 - 能力跃迁：从「消息能到」跃迁到「消息能被公平地裁定」。玩家不再只是旁观者，而是持有待裁定意图的对手。
- 阅读时长：单篇 PRD 约 450 行，建议重点精读匹配队列的并发锁段落与判定引擎的幂等设计。
核心验证目标
- 匹配队列机制：支持多玩家排队等待配对，处理队列调度与并发锁，避免同一玩家被重复配对。
- 房间生命周期：房间的创建、进入、进行、结算、销毁全流程状态机，以及房间与匹配结果的绑定关系。
- 锁步回合（Turn-based Lockstep）：双方在时间窗内同时提交指令，超时未提交按弃权处理，服务端统一开奖。
- 服务器权威判定：胜负只能由服务端结算，客户端提交的动作需可验证、防篡改、防重放。
- 断线重连与对局恢复：重连后通过 Snapshot 恢复到正确的回合与比分，不产生「幽灵对局」。
- 日志与观战：完整记录对局过程以支持回放；第三方观战走只读通道，需要延迟广播做信息隔离。
- 积分扩展：MatchHistory 与 Leaderboard 构成的 Elo 排名雏形，为第 12 章的评分体系埋下伏笔。
技术栈建议
- 语言：Go、Node.js 或 Rust。本章逻辑量很小，语言选择主要看第 1 章的底座实现语言，保持一致最省事。
- 传输：WebSocket 双向实时通道，沿用第 1 章的 JSON 消息流。
- 存储：对局日志建议先落关系型数据库，第 4 章的题库、第 12 章的评分都会在此基础上扩展。
- 关键设计：匹配队列用带互斥锁的等待池实现即可，不必引入消息队列；回合定时器与房间状态机绑定，避免游离的全局定时器。
本章文章
| 文章标题 | 核心内容 |
|---|---|
| 在线联机原型全集：第 2 章 石头剪刀布（Rock–Paper–Scissors, RPS） | 完整 PRD：Matchmaker、Room Service、Game Logic Engine、Event Logger、Ranking Service 五模块划分，含 BO3 多局模式与超时弃权规则 |
本章只有一篇 PRD，未拆出独立的算法专题；评分系统的深入公式要到第 12 章的 Elo 与 Glicko-2 详解才展开。
与相邻章节的关系
- 上一章：第 1 章 聊天室 提供连接与房间底座，本章在其上叠加匹配与回合。
- 下一章：第 3 章 井字棋 / 四子棋 把「回合」升级为「可验证的状态空间」，开始处理棋盘这类持续演进的空间状态。