简介本资源是一个面向编程初学者与AI入门者的揭棋翻棋游戏开源实现聚焦策略型棋类规则建模与基础游戏AI开发。项目以Python为核心提供可运行的揭棋对弈环境及基于Minimax算法含Alpha-Beta剪枝优化的智能机器人玩家帮助学习者理解暗棋机制、状态空间搜索与人机交互逻辑。压缩包仅含2个关键文件核心逻辑代码chess.py实现棋盘管理、棋子翻动、走法校验与AI决策和结构清晰的README.md含运行说明、模式切换与规则简述整体体积仅4KB轻量易读适合代码精读与算法调试。已有328人学习下载读者可直接复现揭棋完整流程深入掌握Python面向对象设计、二维棋盘数据结构建模、递归博弈树搜索原理及命令行游戏交互实现是理论结合实践的优质小而精学习样本。1. 项目概述从传统象棋到“揭棋”的华丽转身最近在棋友圈里一个叫“揭棋”的玩法热度持续攀升它也被称为“暗棋”或“翻棋”。如果你是一位象棋爱好者同时又对传统对弈的固定开局感到有些审美疲劳那么“揭棋”绝对能给你带来全新的、充满未知和刺激的体验。简单来说揭棋是在中国象棋棋盘和棋子基础上引入了一个核心机制开局时除了将帅和士仕之外所有棋子都是背面朝上、随机摆放的。对弈双方在走第一步棋之前都不知道自己面前摆的是什么兵种也不知道对手的布局。只有当棋子被“揭开”即第一次移动它时它的真实身份才会揭晓。这个小小的规则改动瞬间将象棋从一场纯粹的计算与策略博弈变成了一场融合了记忆、概率、心理战和运气的综合较量。我最初接触揭棋是在一个线上对弈平台当时就被它那种“开盲盒”般的乐趣和瞬息万变的局势深深吸引。传统的象棋高手可以通过背诵大量开局谱和定式来建立优势但在揭棋里这一套行不通了。你精心策划的“炮二平五”开局可能移动的只是一个“兵”你以为可以“马八进七”跳出一个进攻马结果翻开发现是个“相”只能原地防守。这种不确定性极大地拉平了新手与熟手之间的差距也让每一盘棋都充满了惊喜或惊吓。更重要的是它迫使棋手跳出固有的思维定式更加注重对棋盘整体“信息”的掌控和局势的灵活判断。这个名为“chiness_chess_jieqi-master”的项目从命名上看很可能是一个旨在实现揭棋对弈的程序或引擎。“master”一词暗示了其目标可能是达到较高的AI对战水平。对于开发者、棋类AI研究者或者单纯想自己搭建一个揭棋平台来和朋友们对战的编程爱好者来说深入理解揭棋的核心规则、算法难点以及实现策略是一次非常有趣的挑战。接下来我将结合自己下揭棋和开发棋类游戏的经验彻底拆解这个项目背后的技术逻辑与实现要点。2. 揭棋的核心规则与对传统象棋的颠覆要开发一个揭棋程序首先必须吃透它的规则细节。这些规则看似简单却对游戏逻辑产生了根本性的影响是后续所有算法设计的基础。2.1 棋子初始状态与“揭开”机制这是揭棋区别于传统象棋最根本的一点。开局布子时棋盘遵循以下原则固定明子双方的将帅和两个士仕共6颗子是明着的位置与传统象棋开局完全相同。这保证了游戏有一个基本的攻防核心和底线。随机暗子剩下的所有棋子包括车、马、炮、相象、兵卒全部背面朝上即“暗子”随机摆放在各自阵营的初始位置上。这意味着在红方“兵”的位置上可能暗藏着一个“车”在黑方“炮”的位置上可能只是一个“兵”。揭开规则当一个暗子第一次被移动时它会被“揭开”并立即以其真实身份执行本次移动。这里有一个关键判定移动必须符合该棋子真实身份的走法规则。例如你试图将一个暗子像“车”一样直线移动但如果它的真实身份是“马”那么这个移动就是非法的。反之如果你像走“兵”一样只前进一步而它其实是“车”那么它也只能走这一步。因此玩家在移动暗子时实际上是在“猜测”并“声明”一种走法系统会验证该走法对于棋子揭开后的真实身份是否合法。这个机制直接导致了策略的巨变。你不再能开局就策划双车错、屏风马等套路因为你的“车”可能还在角落里当“相”用。你需要通过早期的小心试探逐步揭开棋子摸清自己的家底和对手的虚实。2.2 走子、吃子规则的变化与特殊判定揭棋的规则在传统象棋基础上增加了许多基于“明暗状态”的特殊情况暗子吃子一个暗子可以吃掉任何明子。无论这个暗子是什么身份只要它移动到的目标位置有一个对方的明子即可完成吃子。吃子后暗子被揭开以其真实身份留存在目标位置。这是一种高风险高回报的行为你可能用一个“兵”换掉了对方的“车”也可能用“马”踩掉了一个“仕”。明子吃暗子一个明子可以吃掉对方的暗子。吃子后被吃的暗子移除不揭开。这是获取信息优势的重要手段通过牺牲一个子力比如兵去揭开对方一个未知的暗子虽然损失了子但获得了宝贵的棋盘信息。暗子互吃两个暗子之间不能互相吃掉。如果移动一个暗子到一个有对方暗子的位置这一步棋是非法的。这规则避免了游戏早期因完全未知而导致的随机性过大。将帅照面与传统象棋相同但条件更为苛刻。因为只有当“将”或“帅”所在的直线或米字格取决于将的移动规则是否启用上全部是明子且无任何棋子遮挡时才算“照面”。中间的暗子会阻挡照面。注意不同平台或线下玩法在细微规则上可能有差异例如“兵卒过河前能否横走”、“象相能否吃子”等。在项目开发初期必须明确并文档化你所采用的全部规则集这是所有后续逻辑的基石。我建议优先采用最主流、接受度最广的规则版本以增加程序的通用性。2.3 信息不对称带来的策略维度这是揭棋AI设计中最有趣也最困难的部分。对局双方拥有一个共同的“信念空间”即那些尚未被揭开的暗子的所有可能分布的概率。随着棋局的进行双方通过揭开己方棋子、吃掉对方明子、观察对方走法对方选择揭开某个子暗示了他对该子身份的某种信念来不断更新这个概率模型。例如开局对手用“马”的走法揭开了他三路底线的暗子那么你就可以大概率排除他这个位置是“车”或“炮”的可能性因为车炮不会那样走。AI需要建模这种不完全信息博弈这远比完全信息的传统象棋复杂。3. 项目架构设计与关键技术选型要实现一个“jieqi-master”级别的程序我们需要一个清晰的分层架构。它不仅要处理复杂的游戏规则还要具备强大的AI对战能力。3.1 核心模块划分一个典型的揭棋程序可以划分为以下几个核心模块游戏状态管理模块这是最底层、最核心的模块。它负责维护棋盘当前的状态包括每个棋子的位置、明暗状态、真实身份。它需要提供一系列原子操作接口如“生成所有合法走法”、“执行一步走法”、“撤销一步走法”用于AI搜索回溯。这个模块的健壮性和效率直接决定了整个项目的上限。规则引擎模块封装所有揭棋特有的规则判定逻辑。它需要高效地回答诸如“从位置A到位置B对于明子X或暗子Y是否是一个合法的移动或吃子”、“执行这步走后是否形成了将军局面”、“当前局面是否结束将死、困毙、和棋”。由于暗子的存在生成合法走法会变得复杂对于暗子需要根据其所有可能的身份来生成潜在的合法走法集合。用户交互模块负责图形界面GUI或命令行界面CLI的展示与交互。需要清晰地区分明暗棋子通常用颜色或图案区分处理玩家的点击、拖拽操作并将操作转化为对游戏状态模块的调用。AI引擎模块这是“master”的精华所在。它基于当前游戏状态计算出AI认为最优的一步棋。由于是不完全信息博弈这里的算法选择至关重要。3.2 AI算法选型从蒙特卡洛到神经网络对于完全信息博弈如传统象棋、围棋Alpha-Beta剪枝配合强大的评估函数是经典解法。但对于揭棋这样的不完全信息博弈我们需要更高级的算法。蒙特卡洛树搜索MCTS这是目前处理不完全信息博弈非常主流且有效的方法尤其在棋牌类AI中如德州扑克AI “Libratus”。其核心思想是通过大量随机模拟对局来评估每一步的潜在价值。在揭棋中的具体应用AI在决策时面对的是一个信息集所有可能真实棋盘状态的概率分布。MCTS的每次模拟首先需要从当前信息集中“抽样”一个具体的、完全确定的棋盘状态例如随机为所有暗子分配一个符合初始分布的身份然后在这个抽样出来的“确定局面”下进行快速随机对弈或使用一个轻量级策略走子直到终局分出胜负。通过成千上万次这样的抽样和模拟统计从当前节点当前游戏决策点出发选择不同走法所能获得的平均胜率从而选择胜率最高的走法。优势MCTS不需要一个精确的、手工调校的局面评估函数特别适合规则复杂、分支因子大的游戏。它能自然地处理概率和信息不对称。挑战模拟效率。揭棋的搜索空间巨大需要高效的随机走子策略和良好的并行化才能保证在有限时间内给出优质决策。深度学习与神经网络可以用于增强MCTS。策略网络代替纯粹的随机走子。训练一个神经网络输入当前局面或信息集的某种表示输出选择每一步走法的概率。这能引导MCTS的模拟向更有希望的方向进行大幅提升搜索效率。价值网络代替模拟到终局。训练一个神经网络来直接评估当前局面的胜率期望减少模拟的深度加快决策速度。实现路径可以先收集大量人类高手对弈棋谱进行监督学习训练一个初版策略网络。然后让这个网络自我对弈通过强化学习如AlphaGo Zero/AlphaZero的框架不断迭代进化。基于规则的试探性算法在项目初期或对AI强度要求不高的场景可以设计一些启发式规则。例如“优先移动中路的暗子因为其可能是重要子力”、“在优势时避免用不确定的暗子去冒险吃对方明子”、“尽量用兵、相等子力去试探对方暗子”。这些规则可以作为AI的底层策略或者与MCTS的随机走子策略结合。实操心得对于个人开发者或小团队我建议采用“MCTS 轻量级启发式规则”作为起步方案。先实现一个正确、高效的规则引擎和游戏状态管理模块然后围绕其构建MCTS框架。这个组合能在相对合理的计算资源下产生一个实力不俗、且行为符合人类直觉的AI。过早引入深度学习会极大增加项目复杂度和数据、算力需求。4. 游戏状态与规则引擎的实现细节这是整个项目的地基必须设计得既正确又高效。这里我用一些伪代码和设计思路来具体说明。4.1 棋盘与棋子的数据结构设计如何表示一个“可能是任何兵种的暗子”是关键。# 棋子类型枚举 class PieceType: KING 0 # 将/帅 GUARD 1 # 士/仕 BISHOP 2 # 象/相 KNIGHT 3 # 马 ROOK 4 # 车 CANNON 5 # 炮 PAWN 6 # 兵/卒 UNKNOWN 7 # 暗子未揭开时的通用表示 # 棋子颜色 class Color: RED 0 BLACK 1 # 单个棋子的表示 class Piece: def __init__(self): self.color Color.RED self.real_type PieceType.UNKNOWN # 真实身份 self.revealed False # 是否已揭开 self.known_to_player {} # 可选针对每个玩家该棋子是否已知在部分规则或AI信息集中使用 # 棋盘状态 class BoardState: def __init__(self): # 用一个10x9的数组表示棋盘每个元素是一个Piece对象或None self.board [[None for _ in range(9)] for _ in range(10)] self.current_player Color.RED self.move_history [] # 历史着法用于悔棋和AI回溯 # 可以缓存一些信息以提高性能如双方明子列表、将军状态等 self.red_known_pieces [] self.black_known_pieces []对于暗子real_type存储其真实身份仅在内部逻辑和揭开时使用对外表现则是PieceType.UNKNOWN。revealed标志位控制其显示和交互逻辑。4.2 合法走法生成器的复杂性这是规则引擎最复杂的部分。对于明子走法生成与传统象棋类似但需考虑揭棋特有规则如能否吃暗子。对于暗子则需遍历其所有可能身份。def generate_moves_for_piece(board_state, position): piece board_state.board[position.row][position.col] moves [] if piece.revealed: # 明子按真实身份生成走法 moves generate_moves_for_known_piece(piece, position, board_state) else: # 暗子需要考虑所有可能身份 possible_types [PieceType.ROOK, PieceType.KNIGHT, PieceType.CANNON, PieceType.BISHOP, PieceType.PAWN] # 注意根据初始摆放规则暗子不可能是KING或GUARD for ptype in possible_types: # 临时假设该暗子是这个类型生成走法 pseudo_moves generate_moves_for_type(ptype, piece.color, position, board_state) for move in pseudo_moves: # 关键校验这个走法对于ptype类型是否真的合法 # 例如马走日但要检查蹩马腿象飞田检查塞象眼等。 if is_move_legal_for_type(ptype, move, board_state): # 还需要检查揭棋特殊规则暗子不能走到对方暗子位置 target_piece board_state.board[move.to_row][move.to_col] if target_piece and not target_piece.revealed and target_piece.color ! piece.color: continue # 暗子互吃非法 moves.append(move) # 去重因为不同兵种可能产生相同的目标位置比如兵进一步和车进一步位置相同 moves remove_duplicate_moves(moves) return movesgenerate_moves_for_known_piece函数需要集成所有揭棋吃子规则。例如车吃明子、吃暗子都是直接占领目标位炮吃明子需隔一子吃暗子则不允许因为炮不能吃暗子除非规则特殊规定通常炮只能吃明子。4.3 胜负判定与和棋规则除了传统的“将死”无合法应着、“困毙”虽有子但无合法走法外揭棋需要特别关注以下情况长将一方连续将军另一方无法避免通常判将军方负或不变作负。在揭棋中由于信息不对称判断“是否真正构成将军”需要精确计算。双方均无取胜可能例如双方都只剩下单将或单马/单兵对单将且无法取胜。在揭棋中可能还存在未揭开的暗子但只要这些暗子根据规则和位置判断绝对不可能构成杀棋比如被完全困住的暗子也可以判定和棋。六十回合自然限着这是防止游戏无限进行的重要规则。需要实现一个回合计数器在双方均未吃子的情况下走满60回合自动判和。在AI对弈中这个规则尤为重要。实现时需要在每次走子后调用一个is_game_over()函数检查上述条件。5. AI引擎的核心实现MCTS在揭棋中的应用让我们深入探讨如何将蒙特卡洛树搜索适配到揭棋中。MCTS包含四个步骤选择、扩展、模拟、回溯。5.1 树节点与信息集表示每个MCTS节点代表游戏的一个决策点。但在不完全信息博弈中一个节点对应的是一个“信息集”而非一个确定状态。class MCTSNode: def __init__(self, parentNone, last_moveNone, prior_prob1.0): self.parent parent self.last_move last_move # 到达此节点的着法 self.children {} # key: move, value: MCTSNode self.visit_count 0 self.total_value 0.0 # 累计价值例如红方胜率 self.prior_probability prior_prob # 先验概率来自策略网络或均匀分布 # 揭棋关键该节点对应的信念状态Belief State # 这是一个简化表示。更复杂的实现可能是一个概率分布集合。 # 例如可以存储多个抽样出的确定状态或者存储暗子身份的概率向量。 self.belief_state None # 类型可以是 BoardState 的集合或概率模型在揭棋中belief_state需要封装当前玩家所知道的所有信息棋盘上所有明子的位置以及对于每个暗子其可能身份的概率估计。在模拟开始时我们需要从这个信念状态中“抽样”出一个具体的、完全确定的棋盘状态来进行快速对弈。5.2 选择与扩展策略选择阶段从根节点开始通过树策略如UCT算法递归选择子节点直到遇到一个未完全展开的节点或叶节点。def select_child(node, exploration_weight1.414): 使用UCT公式选择子节点 total_visits node.visit_count best_score -float(inf) best_child None best_move None for move, child in node.children.items(): # UCT公式: Q c * sqrt(ln(N) / n) if child.visit_count 0: uct_score float(inf) # 优先探索未访问过的节点 else: # Q值从当前玩家视角的胜率期望。假设node是红方决策child是黑方决策后的状态。 # 那么child的价值是从红方视角看的所以Q child.total_value / child.visit_count # 但需注意在二人零和博弈中交替视角。通常存储的是从“待行动玩家”视角的价值。 # 这里简化处理假设node存储的是红方胜率。 q_value child.total_value / child.visit_count uct_score q_value exploration_weight * math.sqrt(math.log(total_visits) / child.visit_count) if uct_score best_score: best_score uct_score best_child child best_move move return best_child, best_move当选择一个访问次数为0的子节点即一个新走法时进入扩展阶段。为此走法创建一个新的子节点。关键步骤来了我们需要为这个新节点初始化其belief_state。这需要通过一个“状态转移”函数来实现该函数根据父节点的信念状态和执行的走法更新出子节点对应的新信念状态。例如如果走法揭开了一个暗子那么在新信念状态中这个棋子的身份就从概率分布坍缩为一个确定值。5.3 模拟与策略评估扩展出新节点后需要进行模拟也称为Rollout。模拟就是从该节点的信念状态出发进行一场快速随机对弈直到终局。def simulate_from_belief_state(belief_state, current_player): 从信念状态开始随机模拟一局 # 1. 抽样从信念状态中随机实例化一个确定的棋盘状态 # 这是一个简化。更精确的做法是维护一个粒子集合粒子滤波。 sampled_state sample_deterministic_state(belief_state) # 2. 快速对弈使用简单的策略如随机走子或轻量级启发式策略进行对弈 while not sampled_state.is_game_over(): # 获取当前所有合法走法 legal_moves sampled_state.get_legal_moves() if not legal_moves: break # 选择走法这里使用随机选择也可以使用一个训练好的快速策略网络 chosen_move random.choice(legal_moves) # 执行走法 sampled_state.make_move(chosen_move) # 3. 获取结果判断胜负返回奖励值例如红胜1黑胜-1和棋0 result sampled_state.get_game_result() # 将结果转换到从“模拟起始节点对应的玩家”视角的价值 if current_player Color.RED: return result # 假设result是从红方视角的得分 else: return -resultsample_deterministic_state函数是核心。它需要根据每个暗子的概率分布为其随机分配一个身份同时要保证分配结果符合游戏初始的约束例如双方暗子的兵种组合总数是固定的。一种实用的方法是在游戏开始时就为双方随机生成一个确定的暗子排列但不对玩家公开在模拟时AI使用这个“上帝视角”的真实排列来进行推演。但这样AI就拥有了额外信息。更公平的做法是AI的信念状态只包含它通过观察得到的信息在模拟时基于这些信息随机猜测暗子的身份。5.4 回溯与信息更新模拟结束后得到的结果价值需要沿着选择路径回溯更新所有祖先节点的统计信息。def backpropagate(node, simulation_value): 回溯更新节点统计信息 while node is not None: node.visit_count 1 # 注意价值的累加方向。通常累加的是从该节点玩家视角的胜率。 # 由于是零和博弈每向父节点回溯一步视角就切换一次。 node.total_value simulation_value simulation_value -simulation_value # 切换视角父节点玩家与子节点玩家相反 node node.parent经过足够多次的迭代例如10万次后根节点下访问次数最多的子节点对应的走法通常就是AI认为的最优着法。常见问题与排查技巧实录问题1AI表现过于“胆小”或“鲁莽”。这通常与模拟策略或UCT探索权重有关。如果模拟策略Rollout Policy过于保守AI会倾向于不冒险揭开棋子。可以调整探索权重exploration_weight增加它会鼓励AI尝试更多未充分探索的走法减小它则会让AI更依赖已探索的高胜率走法。也可以优化模拟策略加入一些基本的揭棋战术启发例如“在安全的情况下优先揭开中路的暗子”。问题2搜索速度太慢无法在时限内给出好棋。MCTS的性能瓶颈在于模拟速度。可以尝试以下优化1) 使用更快的、基于规则的模拟策略代替随机走子2) 实现并行MCTS同时进行多棵树的搜索或多线程模拟3) 在游戏早期由于分支极多可以设置一个最大模拟深度或时间限制4) 使用Transposition Table置换表来缓存相同的信念状态需设计高效的哈希函数。问题3信念状态表示和抽样太复杂代码难以维护。在项目初期可以采用一种简化模型假设AI知道所有暗子的真实身份但在生成走法和评估时加入一个“信息不确定性惩罚”。例如在评估函数中对于未揭开的己方大子可能为车马炮给予较低的价值因为你还不能安全地使用它。这是一种工程上的折中虽然不完美但能快速得到一个有基本策略的AI。问题4如何处理“暗子互吃非法”的规则。在生成暗子走法时必须在generate_moves_for_piece函数中严格过滤掉目标格为对方暗子的走法。在模拟过程中随机走子策略也必须遵守这一规则否则会导致模拟出非法对局影响评估准确性。6. 用户界面与交互设计要点一个友好的界面能极大提升体验。无论是图形界面还是命令行界面都需要清晰传达暗棋这一核心信息。6.1 图形界面GUI设计建议如果使用PyGame、Qt、Web前端等技术开发GUI需注意棋子绘制明子用传统象棋字体或图案显示。暗子需要用统一的、区别于明子的样式显示比如一个纯色的圆形、一个问号“”、或者一个覆盖的图案。当鼠标悬停在暗子上时可以显示提示信息如“未揭开棋子”。走子反馈玩家点击一个暗子时应高亮显示该棋子所有可能的、符合至少一种兵种走法的目标格。这能帮助玩家理解当前可以如何移动这个未知棋子。当玩家将一个暗子移动到目标格后界面应立即播放一个“翻转”动画然后显示其真实身份。信息面板显示当前回合、双方耗时、已吃掉的棋子列表。还可以考虑显示一个“可能性面板”根据当前局面和走法历史动态列出双方每个暗子可能是各种兵种的概率高级功能这能帮助玩家进行推理。悔棋与提示提供悔棋功能。可以集成一个“弱AI提示”功能在玩家思考时给出MCTS搜索到的当前最佳着法但不揭示暗子身份。6.2 命令行界面CLI的简洁实现对于专注于算法测试或网络对战的场景CLI足够用。9 8 7 6 5 4 3 2 1 a[ ][ ][ ][ ][ ][ ][ ][ ][ ] a b[ ][ ][ ][ ][ ][ ][ ][ ][ ] b c[ ][ ][ ][ ][ ][ ][ ][ ][ ] c d[ ][ ][ ][ ][ ][ ][ ][ ][ ] d e[ ][ ][ ][ ][ ][ ][ ][ ][ ] e f[ ][ ][ ][ ][ ][ ][ ][ ][ ] f g[ ][ ][ ][ ][ ][ ][ ][ ][ ] g h[ ][ ][ ][ ][ ][ ][ ][ ][ ] h i[ ][ ][ ][ ][ ][ ][ ][ ][ ] i 9 8 7 6 5 4 3 2 1 红方帅(1,5) 仕(1,4) 仕(1,6) [暗][暗][暗][暗][暗] 黑方将(10,5) 士(10,4) 士(10,6) [暗][暗][暗][暗][暗] 当前回合红方 输入着法 (如 ‘h3e3‘ 或 ‘help‘)用[暗]表示暗子。着法输入可以用坐标法如h3e3表示从h3移动到e3也可以更直观地用“前进一步”、“左平一步”等相对命令但对于暗子必须指定移动方式。执行h3e3后如果h3是暗子系统会判断这个移动对于揭开后的棋子是否合法并输出“揭开棋子红方车”。7. 性能优化与进阶方向当基础功能实现后可以追求更强的AI和更好的体验。7.1 AI强度提升策略并行化MCTS使用多线程或异步IO同时进行多场模拟。注意处理好对共享树结构的并发访问读多写少可用读写锁。集成神经网络收集数据先让随机策略的AI自我对弈生成大量棋谱状态-动作-胜负结果。训练策略网络输入棋盘状态需要设计好的特征表示包括棋子位置、明暗、历史信息等输出每个合法走法的概率。损失函数为交叉熵。训练价值网络输入棋盘状态输出当前玩家胜率的标量估计。损失函数为均方误差MSE。与MCTS结合在MCTS的选择和扩展阶段用策略网络输出的概率作为prior_probability来引导搜索在模拟阶段用价值网络直接评估叶节点代替耗时的随机模拟到底。开局库与残局库对于揭棋建立完善的开局库比较困难因为变数太多。但可以针对一些高频出现的“中残局”形态例如双方明子所剩无几仅存几个暗子建立小型残局库使用查表法快速得到最优解。7.2 网络对战与协议设计要实现联机对战需要设计一个轻量级的通信协议。状态同步服务器维护权威游戏状态。客户端只发送操作指令如“移动A子到B”服务器校验后执行并将结果状态广播给所有客户端。暗子信息隐藏这是关键。服务器知道所有棋子的真实身份但向客户端发送数据时对于对方未揭开的暗子只能发送“未知”状态而不能泄露其真实身份。协议示例JSON格式客户端-服务器{action: move, from: h3, to: e3}服务器-客户端{type: state_update, board: [...], current_player: red, last_move: {from: h3, to: e3, piece_revealed: rook, color: red}}服务器-客户端仅对移动方{type: private_info, your_hidden_pieces: {h2: knight, ...}}可选用于在客户端显示己方暗子但通常为了公平和刺激客户端也不应知道己方暗子直到揭开开发“chiness_chess_jieqi-master”的过程是一个将经典游戏规则、不完全信息博弈理论和现代AI算法相结合的绝佳实践。它不仅仅是一个编程项目更是一次对概率、决策和智能的深入探索。从构建一个正确无误的规则引擎开始到实现一个能处理信息不对称的MCTS AI每一步都充满了挑战和乐趣。当你看到自己创造的AI在棋盘上开始进行有模有样的试探、欺骗和计算时那种成就感是单纯调用一个现有引擎无法比拟的。本文还有配套的精品资源点击获取