示例一:极简对局¶

本示例规则简单到只有两个玩家、各发一张牌、谁的点数大谁赢。对应平台仓库中的 test2.json,内置规则名 Tiny Demo。该规则当前作为最小可跑示例,推荐初学者照着搭一遍,熟悉规则构建器的操作。

设计¶

玩家类增加一个 score 属性(整数,默认 0),用来记录输赢。

牌类增加一个 point 属性,类型为枚举,取值 A=1、2=2、3=3。

牌桌类不需要额外属性,使用平台默认即可。

只需要一个牌型,命名为「单张」。

属性:weight(整数),表示这张牌的权重,即点数本身。

build_flow:

牌型开始
   → 条件转移(传入牌组数量 == 1?)
       是 → 匹配返回(result=匹配, weight=第一张牌.point)
       否 → 匹配返回(result=不匹配)

compare_flow(单张 vs 单张):

比较开始
   → 条件转移(A.weight > B.weight?)
       是 → 比较返回(A 胜)
       否 → 比较返回(B 胜)

只有一个牌型,无需配置压制关系。

对局开始
   → 洗牌
   → 发牌(每人 1 张, point ∈ [1, 3])
   → 出牌(玩家 1)
   → 出牌(玩家 2)
   → 结束对局

结算开始
   → 条件转移(当前玩家.score > 另一玩家.score?)
       是 → 结算结束(result=胜)
       否 → 结算结束(result=负)

发牌组件需要指定属性范围与张数。这里 prop_pair=[{point: 1..3}],count=1。

出牌组件不需要内容,平台会自动把「当前出牌者」切到下一个玩家。

条件转移的 condition 槽需要接一个比较组件。比较组件的左值是「当前玩家.score」,右值是「另一玩家.score」,运算符为大于。

第一次操作时,建议在规则构建器中点击「导入 JSON」,粘贴 WildCard_BackEnd/test2.json 的内容,观察平台如何把 JSON 还原为图形界面,再尝试微调。

熟悉后再自己从零拖一遍同样的结构,验证对每个组件插槽位置的理解。

把发牌组件的 count 改为 3 即可实现「每人 3 张」。

引入动作选择组件可以让玩家在出牌前选择「出牌」或「重发」,根据选择跳转到不同分支。

把规则元信息中的人数改为 3,主流程再加一个出牌组件,就实现了三人对局。

下一章引入更复杂的牌型识别:示例二:斗地主炸弹。