feat: 实现最小正式版过水不胡规则并完善前端动作面板
- 后端实现最小正式版过水不胡规则：玩家在响应窗口选择PASS后，直到下次摸牌前不能响应胡 - 完善GameSeat状态管理，新增passedHuBlocked字段及相关方法 - 在ResponseActionWindowBuilder和GameActionProcessor中增加过水不胡校验 - 前端重构动作面板，区分回合动作和响应动作，支持多用户视角切换 - 优化公共事件处理逻辑，自动清理失效的私有动作面板 - 更新相关文档说明当前实现的规则范围和工程取舍 - 补充测试用例验证过水不胡规则的正确性
This commit is contained in:
hujun
@@ -350,12 +350,10 @@ ws WebSocket 配置与消息发布
|
||||
|
||||
### 7.5 当前尚未完成
|
||||
|
||||
- `PENG`
|
||||
- `GANG`
|
||||
- `HU`
|
||||
- `PASS`
|
||||
- 响应动作优先级裁决
|
||||
- 胡牌判定与结算
|
||||
- 自摸加番 / 加底等地方变体
|
||||
- 天胡、地胡
|
||||
- 更完整的地方化 `过水不胡`
|
||||
- 前端正式动作面板与规则联调
|
||||
- 教学开关接口
|
||||
- 局后个人复盘
|
||||
- 数据库持久化
|
||||
@@ -393,6 +391,10 @@ ws WebSocket 配置与消息发布
|
||||
- 当前支持：
|
||||
- `SELECT_LACK_SUIT`
|
||||
- `DISCARD`
|
||||
- `PENG`
|
||||
- `GANG`
|
||||
- `HU`
|
||||
- `PASS`
|
||||
|
||||
- `POST /api/games/{gameId}/lack`
|
||||
- 兼容接口
|
||||
@@ -645,7 +647,7 @@ AI 不是单一模块，而是三层能力：
|
||||
|
||||
当前状态：
|
||||
|
||||
- 进行中
|
||||
- 已基本完成
|
||||
|
||||
### M3 规则与结算
|
||||
|
||||
@@ -668,7 +670,7 @@ AI 不是单一模块，而是三层能力：
|
||||
|
||||
当前状态：
|
||||
|
||||
- 待做
|
||||
- 进行中
|
||||
|
||||
### M4 H5 正式对局体验
|
||||
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# XueZhanMaster 阶段任务看板
|
||||
|
||||
本文档把主计划拆成可以直接推进的阶段任务卡。
|
||||
本文档把主计划拆成可以直接推进的阶段任务卡。\
|
||||
当前状态快照日期：`2026-03-20`
|
||||
|
||||
---
|
||||
***
|
||||
|
||||
## 1. 使用说明
|
||||
|
||||
@@ -33,7 +33,7 @@
|
||||
- 验收标准
|
||||
- 风险提示
|
||||
|
||||
---
|
||||
***
|
||||
|
||||
## 2. 待做
|
||||
|
||||
@@ -205,7 +205,7 @@
|
||||
- 每局结束后可获得个人复盘
|
||||
- 可沉淀到错题本并二次查看
|
||||
|
||||
---
|
||||
***
|
||||
|
||||
## 3. 进行中
|
||||
|
||||
@@ -252,7 +252,7 @@
|
||||
- 验收标准：
|
||||
- 页面拆分方案可直接指导下一轮前端编码
|
||||
|
||||
---
|
||||
***
|
||||
|
||||
## 4. 已完成
|
||||
|
||||
@@ -359,3 +359,4 @@
|
||||
- `vite.config.ts` 已代理 `/api` 和 `/ws`
|
||||
- 验收结果：
|
||||
- H5 原型页面可走通当前最小链路
|
||||
|
||||
|
||||
@@ -22,19 +22,22 @@
|
||||
- AI 与真人使用同一套优先级规则
|
||||
- 同优先级冲突时，按出牌者之后的最近顺位优先
|
||||
- `PASS` 仅表示放弃当前窗口，不等于永久放弃后续所有同类机会
|
||||
- `过水不胡` 作为后续增强规则，不在当前 `V1` 强制启用
|
||||
- `一炮多响` 在项目 `V1` 中暂不实现，采用“单窗口单胜出动作”的工程裁决
|
||||
- `过水不胡` 已在项目 `V1` 中启用“最小正式版”
|
||||
- 玩家在响应窗口里本可 `HU` 但选择 `PASS` 后，直到自己下一次摸牌前，不能再做响应胡
|
||||
- 该限制只作用于响应胡，不影响 `PENG / GANG`，也不影响自摸胡
|
||||
- `一炮多响` 已在项目 `V1` 中实现，但只对 `HU` 开放多赢家同窗裁决
|
||||
- `PENG / GANG` 仍保持单赢家裁决，顺位规则不变
|
||||
|
||||
### 1.2 为什么这样定
|
||||
|
||||
- 这样能和当前后端结构最自然衔接
|
||||
- 可以先把响应窗口停顿与恢复流程做稳
|
||||
- 避免在 `HU` 判定、多人同时胡牌、结算分摊都未稳定时，提前引入高复杂度冲突逻辑
|
||||
- 可以先把响应窗口停顿、恢复和结算主链做稳
|
||||
- 即使已支持一炮多响与最小版过水不胡，也仍把复杂度限制在当前统一动作入口和统一响应窗口内
|
||||
|
||||
这符合：
|
||||
|
||||
- `KISS`：先做单窗口单胜出
|
||||
- `YAGNI`：当前不抢做一炮多响和完整过手胡体系
|
||||
- `KISS`：一炮多响只对 `HU` 放开，多赢家共用一张牌源，避免把 `PENG / GANG` 也做成多胜出分支
|
||||
- `YAGNI`：当前不抢做完整地方化 `过水不胡` 体系，也不引入可配置规则模式层
|
||||
- `SOLID`：先把规则澄清文档与裁决器边界固定
|
||||
- `DRY`：所有动作冲突统一走一套优先级裁决
|
||||
|
||||
@@ -75,11 +78,10 @@
|
||||
|
||||
- 某玩家打出一张牌后
|
||||
- 其他仍在牌局中的玩家基于这张弃牌触发响应窗口
|
||||
- 补杠声明后的抢杠胡响应窗口
|
||||
|
||||
`V1` 暂不实现：
|
||||
|
||||
- 抢杠胡窗口
|
||||
- 补杠后二次响应窗口
|
||||
- 最后一张牌必须胡的特殊强制窗口
|
||||
- 多轮连续嵌套响应窗口
|
||||
|
||||
@@ -89,14 +91,13 @@
|
||||
|
||||
- `PENG`
|
||||
- `GANG`
|
||||
- `HU`
|
||||
- `PASS`
|
||||
|
||||
`HU` 的动作入口和事件枚举虽然已预留，但真正候选生成依赖胡牌判定完成后再接入。
|
||||
其中：
|
||||
|
||||
因此要区分两个状态：
|
||||
|
||||
1. 接口和模型层：`HU` 已被保留
|
||||
2. 当前实际候选生成层：以 `PENG / GANG / PASS` 为主
|
||||
1. 弃牌响应窗口支持 `HU / PENG / GANG / PASS`
|
||||
2. 补杠抢杠胡窗口支持 `HU / PASS`
|
||||
|
||||
---
|
||||
|
||||
@@ -135,27 +136,30 @@
|
||||
- `seat 1` 和 `seat 3` 同时都能 `PENG`
|
||||
- 则 `seat 1` 获胜
|
||||
|
||||
### 4.3 为什么不在 V1 支持一炮多响
|
||||
### 4.3 为什么在 V1 只对 `HU` 支持一炮多响
|
||||
|
||||
这是一个项目级工程取舍，不是宣称外部规则世界只有这一种。
|
||||
这也是一个项目级工程取舍，不是宣称外部规则世界只有这一种。
|
||||
|
||||
原因：
|
||||
|
||||
- 一炮多响会直接放大以下复杂度：
|
||||
- 多赢家结算
|
||||
- 胡牌先后次序
|
||||
- 胡后谁退出牌局、谁继续
|
||||
- 多人同时胡后下一个行动座位怎么定
|
||||
- 当前项目还未完成：
|
||||
- `HU` 多赢家是血战到底中较常见、且用户感知较强的规则
|
||||
- 当前后端已经具备：
|
||||
- 胡牌判定
|
||||
- 基础结算
|
||||
- 胡后继续行牌完整链路
|
||||
- 胡后继续行牌主链
|
||||
- 结算历史沉淀
|
||||
- 但如果把 `PENG / GANG` 也做成多赢家分支，会明显抬高后续行牌复杂度
|
||||
|
||||
所以 `V1` 先采用：
|
||||
所以 `V1` 采用：
|
||||
|
||||
- `单窗口单胜出动作`
|
||||
- `HU` 可多赢家同窗裁决
|
||||
- `PENG / GANG` 仍然单赢家裁决
|
||||
|
||||
后续若要升级到一炮多响，应作为 `V2` 明确需求，不应在当前实现里偷偷混入。
|
||||
这样做的好处是：
|
||||
|
||||
- 保住高价值规则一致性
|
||||
- 又不破坏现有统一动作入口、统一响应窗口和统一结算出口
|
||||
- 仍符合 `KISS`
|
||||
|
||||
---
|
||||
|
||||
@@ -190,16 +194,21 @@
|
||||
|
||||
#### V1
|
||||
|
||||
- 不实现完整 `过水不胡`
|
||||
- 只保证“同一响应窗口内，PASS 后不能反悔”
|
||||
- 不实现完整地方化 `过水不胡`
|
||||
- 当前只实现“最小正式版”：
|
||||
- 玩家在响应窗口里本可 `HU` 但选择 `PASS` 时，记录一次响应禁胡状态
|
||||
- 在该玩家下一次真正摸牌前，后续弃牌胡与抢杠胡都不再给出 `HU` 候选
|
||||
- 下一次真正摸牌后解除限制
|
||||
- 不影响 `PENG / GANG`
|
||||
- 不影响自摸胡
|
||||
|
||||
#### V2
|
||||
|
||||
- 评估是否加入：
|
||||
- 玩家错过可胡后，直到自己下一次摸牌或动牌前不能再胡
|
||||
- 是否仅限制同张牌
|
||||
- 是否限制同一路听牌
|
||||
- 是否允许加番后破除限制
|
||||
- 是否需要把“解除时机”细化为摸牌、碰杠、换巡或加番后解除
|
||||
|
||||
---
|
||||
|
||||
@@ -323,20 +332,25 @@
|
||||
- 新动作基础校验
|
||||
- 新动作事件模型
|
||||
- 响应候选模型
|
||||
- 响应窗口停顿与关闭
|
||||
- 基于窗口的多人响应收集
|
||||
- `HU` 候选生成与胡牌判定
|
||||
- `HU` 的一炮多响裁决
|
||||
- 抢杠胡窗口
|
||||
- 最小正式版 `过水不胡`
|
||||
- 结构化私有动作消息
|
||||
- H5 原型页候选消息展示占位
|
||||
|
||||
当前尚未完成：
|
||||
|
||||
- 真正的响应窗口停顿
|
||||
- 基于窗口的多人响应收集
|
||||
- 优先级裁决器
|
||||
- `HU` 候选生成与胡牌判定
|
||||
- 前端正式动作面板联调
|
||||
- 更完整的地方化 `过水不胡`
|
||||
- 规则模式配置层
|
||||
|
||||
因此本文件的直接用途是：
|
||||
因此本文件当前的直接用途是：
|
||||
|
||||
- 让下一步裁决实现有明确规则依据
|
||||
- 降低“每轮新对话都重新讨论优先级”的沟通成本
|
||||
- 让后续前后端联调和规则扩展有明确规则依据
|
||||
- 降低“每轮新对话都重新讨论响应口径”的沟通成本
|
||||
|
||||
---
|
||||
|
||||
@@ -346,12 +360,12 @@
|
||||
|
||||
1. 血战到底按成都麻将大框架实现
|
||||
2. 不可吃，只处理 `碰 / 杠 / 胡 / 过`
|
||||
3. 当前第一阶段只围绕“弃牌后响应”建窗口
|
||||
3. 当前响应窗口覆盖“弃牌后响应”与“补杠后的抢杠胡响应”
|
||||
4. 优先级固定为 `HU > GANG > PENG > PASS`
|
||||
5. 同优先级按出牌者之后最近顺位优先
|
||||
5. 同优先级按出牌者之后最近顺位优先，且 `HU` 支持一炮多响
|
||||
6. `PASS` 仅放弃当前窗口
|
||||
7. 当前不实现完整 `过水不胡`
|
||||
8. 当前不实现 `一炮多响`
|
||||
7. 当前实现最小正式版 `过水不胡`，解除时机为该玩家下一次真正摸牌
|
||||
8. 当前只对 `HU` 实现一炮多响，`PENG / GANG` 仍保持单赢家裁决
|
||||
|
||||
如果后续要改这些口径，必须先更新本文件，再改代码。
|
||||
|
||||
|
||||
@@ -303,8 +303,8 @@ Sprint 目标：
|
||||
- 明确了本项目 `V1` 的同优先级裁决：
|
||||
- 按出牌者之后最近顺位优先
|
||||
- 明确了本项目 `V1` 的工程取舍：
|
||||
- 当前不实现完整 `过水不胡`
|
||||
- 当前不实现 `一炮多响`
|
||||
- 当前只实现最小正式版 `过水不胡`
|
||||
- 当前只对 `HU` 实现 `一炮多响`
|
||||
- 明确了公共消息与私有消息的职责边界
|
||||
- 明确了后续真实响应窗口接入主流程的推荐顺序
|
||||
|
||||
|
||||
Reference in New Issue
Block a user