多地方胡法场景下如何设计麻将胡法动态配置模块？

## 作用 - 支持在同一套麻将核心引擎上适配不同地区的胡牌规则，避免为各地玩法维护多套代码。 - 将花牌数量、门风轮转、番型公式、得分权重、癞子权限、胡牌术语等规则参数化、配置化。 - 通过后台下载或灰度发布更新规则，使新地区、新赛事可以快速部署，降低接入和试错成本。 - 让运营或非技术人员通过可视化管理台调整番型组合，减少对底层代码发版的依赖。 - 支持规则审计、多规则赛事并行和客户端无感更新。 ## 原理 ### 1. 用统一规则模型抽象地方差异 将胡牌条件拆成可计算的规则对象，而不是写死在业务逻辑中： - 牌池配置：牌种、张数、花牌、百搭或癞子规则。 - 流程配置：门风轮转、摸打顺序、副露规则、结算时机。 - 胡牌条件：基础胡牌结构、特殊胡型、癞子参与方式等。 - 番型配置：番型触发条件、互斥或叠加关系、倍数和权重。 - 计分配置：底分、番型得分、封顶规则、不同角色的支付关系。 - 展示配置：地方术语、UI 文案、提示文案和牌型名称映射。 这样不同地区只需要替换或组合配置，不需要改动核心牌局引擎。 ### 2. 使用 JSON Schema 描述规则 规则层采用可配置的 JSON Schema 描述，并由服务端下发： - 对字段类型、取值范围、番型依赖关系做校验，防止非法配置上线。 - 配置可版本化，支持回滚、灰度发布和按地区或房间生效。 - 客户端只负责表现层，胡牌判定和结算逻辑放在服务端，保证规则一致和结果可信。 - 同一核心程序可以同时加载多套规则，用于不同地区房间或多桌不同规则赛事。 ### 3. 胡牌判定与番型计算分离 可以把模块分成两层： - **胡牌结构判定层**：判断手牌是否满足基本胡牌条件，并处理吃、碰、杠、副露、百搭等情况。 - **番型规则计算层**：根据当前地区配置，对合法胡牌路径计算番型、倍数和得分。 胡牌判定器可使用状态压缩表示手牌集合，通过位运算和动态规划搜索合法胡牌路径；番型变化较多时，只需扩展配置和规则节点，避免传统查表法在番型变种增多后产生内存和维护问题。 ### 4. 可视化配置与发布流程 管理台提供规则编排能力： - 选择基础牌池和玩法模板。 - 配置癞子、花牌、番型、分值及互斥关系。 - 预览指定牌型的判定和结算结果。 - 提交测试环境验证。 - 通过灰度发布给部分房间或地区。 - 出现异常时按版本快速回滚。 ### 5. 审计与稳定性保障 - 关键随机事件、胡牌判定结果和配置版本应记录到存证日志，便于事后复核。 - 每局可关联使用的规则版本，避免配置更新后无法还原历史牌局。 - 服务端统一判定，客户端只展示动画和结果，防止不同端规则不一致。 - 弱网或重连时依据服务端状态快照恢复，避免重复发牌、漏牌或重复结算。 整体上，模块应采用“核心引擎稳定、地方规则配置化、判定服务端化、发布流程可审计”的设计，从而支持多地方胡法的动态扩展和快速运营。

## 作用 - 适配国标麻将、四川麻将、广东麻将等不同地区规则，避免为每种玩法硬编码一套胡牌和番型逻辑。 - 将胡牌判定、番型识别、得分计算等差异从核心流程中抽离，使规则引擎支持可配置模式。 - 降低新增地方玩法时的改动范围，提高规则复用性、可维护性和扩展能力。 ## 原理 - **分层设计**：将系统拆成规则引擎层、数据模型层、逻辑控制层、表现层和网络通信层；胡牌动态配置归入规则引擎层。 - **规则数据化**：把顺子、刻子、杠子、对子、胡牌结构、番型等规则抽象为配置或逻辑判断函数，而不是写死在牌局流程里。 - **统一基础判定**：通用胡牌结构可按“4 面子 + 1 对子”处理： 1. 统计每种牌的数量； 2. 枚举可能的对子； 3. 对剩余牌递归或回溯，判断能否拆成顺子或刻子。 - **按玩法加载配置**：不同地方玩法选择不同规则配置，由规则引擎读取后决定允许哪些胡法、番型和计分方式。 - **性能优化**：对复杂牌型计算使用记忆化搜索、缓存番型结果，避免高并发场景下重复计算。 - **保持流程独立**：牌局仍由“准备 → 洗牌 → 发牌 → 出牌 → 判定 → 结算 → 下一局”的有限状态机驱动；规则模块只负责给出合法性、胡牌和结算结果。