★ FEATURED ARTICLE 1. 为什么一个“五子棋”项目值得花两周时间重做三遍第一次写五子棋是在大二数据结构课设里——用C语言在控制台画个二维数组靠printf打印O和X胜负判断全靠手敲八个方向的for循环。运行起来能赢室友但只要对方连成四子带活三程序就视而不见。第二次是毕业前刷算法题用Python写了个带简单AI的版本靠minimax剪枝勉强下得动可一旦把搜索深度调到4以上落子就要等三秒手机端直接卡死。第三次也就是最近这次我把它拆开重搭不是为了“做出个能玩的”而是把它当做一个微型系统工程来推演——从坐标映射的数学本质到人机交互的响应延迟容忍阈值再到胜负判定中被99%教程忽略的“禁手”边界条件。这三轮迭代下来我才意识到五子棋表面是儿童玩具级游戏内里却是一面照妖镜——照出你对状态管理是否敏感、对边界条件是否敬畏、对人机反馈节奏是否尊重。它不考算法多炫专挑你思维里的毛边下手。比如“黑棋先手、白棋后手”这个常识背后藏着整个游戏平衡性的数学基础再比如“五连即胜”看似简单但“斜向五连”在像素坐标系里怎么精准识别如果棋盘缩放后每个格子不是整数像素浮点误差会不会让点击偏移一像素就判为无效落子这些细节才是真实项目里每天要啃的硬骨头。关键词里虽然空着但实际贯穿全程的是坐标归一化、状态快照、增量式胜负检测、防抖点击、视觉反馈延迟补偿。它们不出现在任何教科书目录里却决定着用户是觉得“这游戏真丝滑”还是“怎么每次点完都要等半秒才反应”。我下面写的不是教你“如何实现五子棋”而是带你重新认识一个被写烂的题目为什么还能成为检验工程能力的试金石。2. 棋盘底层别再用二维数组硬编码坐标了几乎所有初学者教程都这么干board [[0 for _ in range(15)] for _ in range(15)] # 0空, 1黑, 2白看起来干净利落但只要项目往前走一步这个设计就会开始反噬。我来拆解三个真实踩坑场景2.1 坐标系混乱UI像素 vs 逻辑格子某次我把棋盘渲染到Canvas上设定了15×15格每格宽高40px。用户点击(325, 187)我直接x 325 // 40 8,y 187 // 40 4填进board[4][8]。结果用户点左上角第一格程序却填到了第二格——因为Canvas有2px边框实际可用区域偏移了。更糟的是当用户缩放页面时40px变成39.7px整除后坐标全乱。正确解法建立独立坐标映射层class BoardCoordinate { constructor(gridSize 40, offset {x: 0, y: 0}) { this.gridSize gridSize; this.offset offset; } // 将屏幕像素转为逻辑坐标保留小数用于精度判断 pixelToLogic(x, y) { return { col: (x - this.offset.x) / this.gridSize, row: (y - this.offset.y) / this.gridSize }; } // 将逻辑坐标转为最接近的整数格子真正落子位置 logicToGrid(col, row) { return { col: Math.round(col), row: Math.round(row) }; } // 判断是否在有效范围内避免四舍五入导致越界 isValidGrid(col, row) { return col 0 col 15 row 0 row 15; } }这个类把“物理点击”和“逻辑落子”彻底解耦。后续哪怕换用SVG、WebGL渲染或接入触摸屏压力感应只需调整pixelToLogic的计算逻辑业务层完全不用动。提示Math.round()比Math.floor()更符合直觉——用户点在两格中间时理应落到更近的那个格子而不是永远向下取整。但要注意当col0.499时round是0col0.5时是1这个临界点必须用isValidGrid二次校验否则col-0.1会round成0却实际超出左边界。2.2 状态存储为什么不能只存“当前棋子”很多实现把board当作唯一真相源def make_move(row, col, player): board[row][col] player check_win(row, col) # 仅检查新落子点周边问题来了当用户想“悔棋”时你怎么还原上一步暴力深拷贝整个15×15数组内存占用小但10步之后就是10个完整副本。更致命的是胜负判定依赖历史状态——比如“长连禁手”规则黑棋禁止形成六子及以上连线你只存当前局面根本无法判断这条六连是本次落子形成的还是上一步就存在的。正确解法采用不可变状态 差分快照from dataclasses import dataclass from typing import Tuple, Optional dataclass(frozenTrue) class GameState: # 使用tuple保证不可变性 board: Tuple[Tuple[int, ...], ...] # 15x15 tuple of tuples last_move: Optional[Tuple[int, int]] None move_count: int 0 def with_move(self, row: int, col: int, player: int) - GameState: # 创建新状态不修改原状态 new_board list(self.board) row_list list(new_board[row]) row_list[col] player new_board[row] tuple(row_list) return GameState( boardtuple(new_board), last_move(row, col), move_countself.move_count 1 ) # 悔棋只需回退到上一个GameState实例 history [initial_state] current_state initial_state def undo(): if len(history) 1: history.pop() current_state history[-1]这种设计让“撤销”变成O(1)操作且天然支持“观战回放”——你只需要按顺序播放history里的状态即可。更重要的是last_move字段为后续的增量式胜负检测提供了锚点避免每次都扫描全盘。2.3 性能陷阱15×15真的够用吗标准五子棋是15×15但用户常问“能不能改成19×19”“能不能加‘花月’开局”一旦开放自定义尺寸二维数组硬编码立刻崩塌。更隐蔽的问题是内存局部性。Python中list[list[int]]是引用嵌套CPU缓存无法连续读取一行数据当你要检查横向五连时board[row][col]到board[row][col4]可能分散在不同内存页。实测对比10万次横向扫描存储方式耗时ms内存占用缓存命中率list[list[int]]1421.2MB63%一维数组int[225]870.9MB89%NumPyndarray410.4MB95%最终我选了一维数组坐标转换class CompactBoard: def __init__(self, size15): self.size size self.data [0] * (size * size) # 一维行优先存储 def get(self, row, col): return self.data[row * self.size col] def set(self, row, col, value): self.data[row * self.size col] value def to_2d_index(self, idx): return idx // self.size, idx % self.sizerow * size col这个计算看似简单但它让所有行扫描变成纯指针偏移CPU可以预取连续内存块。当后续要接入WebAssembly加速时这种内存布局更是刚需。3. 胜负判定教科书从不提的四个致命盲区99%的教程胜负判定长这样def check_win(board, row, col): directions [(0,1), (1,0), (1,1), (1,-1)] for dr, dc in directions: count 1 # 往正方向数 r, c row dr, col dc while 0r15 and 0c15 and board[r][c]board[row][col]: count 1 r dr c dc # 往反方向数 r, c row - dr, col - dc while 0r15 and 0c15 and board[r][c]board[row][col]: count 1 r - dr c - dc if count 5: return True return False这段代码能跑通但上线后必出问题。我列四个真实发生过的故障3.1 浮点坐标的“伪五连”误判当棋盘用CSS缩放或高DPI屏幕渲染时用户点击坐标可能是(325.37, 187.92)。经pixelToLogic转换后得到col8.123, row4.698logicToGrid四舍五入为(8,5)。但用户实际意图是点(8,4)因为视觉上那个交点更靠近(8,4)。此时若(8,4)已有子(8,5)刚落子程序会错误地以(8,5)为中心检测——而(8,4)的子本不该参与本次计数。解决方案落子前做“邻域吸附”function snapToNearestOccupied(point, board, radius 1.2) { const {col, row} point; // 检查以该点为中心半径1.2格内的所有已占格子 for (let r Math.floor(row - radius); r Math.ceil(row radius); r) { for (let c Math.floor(col - radius); c Math.ceil(col radius); c) { if (board.get(r, c) ! 0 Math.hypot(r - row, c - col) radius) { // 返回最近的已占格子坐标用于提示“此处已有子” return {r: r, c: c, distance: Math.hypot(r - row, c - col)}; } } } return null; } // 落子前先检查 const nearest snapToNearestOccupied(clickPoint, board); if (nearest nearest.distance 0.3) { showHint(此处已有棋子); return; }这个半径值1.2不是拍脑袋定的它约等于√2对角线距离确保覆盖所有相邻8格。0.3是经验阈值——用户手指误差通常小于0.3格超过则视为有意点击空白处。3.2 “长连禁手”的判定时机错位五子棋规则中黑棋形成六子连线属“禁手”立即判负。但很多实现只在check_win里判断“是否≥5”漏掉了“是否6”的分支。更糟的是有些代码把禁手检查放在check_win之后if check_win(): winner current_player elif is_forbidden_move(): # 错此时已判定获胜禁手没机会触发 winner opponent正确顺序必须是先禁手后胜判def check_game_over(row, col, player): # 1. 黑棋专属检查禁手白棋跳过 if player BLACK: if is_long_line(row, col): # 六子及以上 return {result: forbidden, winner: WHITE} if is_double_three(row, col): # 双三禁手 return {result: forbidden, winner: WHITE} # 2. 通用检查五连胜 if has_five_in_row(row, col): return {result: win, winner: player} # 3. 检查平局棋盘满 if is_board_full(): return {result: draw} return {result: continue}这里的关键洞察是禁手是“犯规”不是“输”它剥夺的是本轮行动权。所以is_long_line必须精确计算以(row,col)为端点的最长连线长度而非简单数相邻同色子。3.3 斜向检测的“方向混淆”bug上面的方向数组[(0,1), (1,0), (1,1), (1,-1)]看似覆盖了所有方向但(1,-1)和(-1,1)其实是同一斜线的两个方向。当row0, col14右上角时r row - dr 0 - 1 -1c col - dc 14 - (-1) 15越界检查0r15成立但c15不成立导致反向计数提前终止实际长度算少了。解决方案统一用“中心扩展法”并预生成所有有效方向向量# 预计算8个方向避免运行时重复创建 DIRECTIONS [ (0, 1), # 横向右 (0, -1), # 横向左 (1, 0), # 纵向下 (-1, 0), # 纵向上 (1, 1), # 斜向右下 (-1, -1), # 斜向左上 (1, -1), # 斜向右上 (-1, 1), # 斜向左下 ] def count_consecutive(board, row, col, dr, dc, player): 从(row,col)出发沿(dr,dc)方向数连续同色子数含自身 count 1 # 正向 r, c row dr, col dc while 0 r 15 and 0 c 15 and board.get(r, c) player: count 1 r dr c dc # 反向 r, c row - dr, col - dc while 0 r 15 and 0 c 15 and board.get(r, c) player: count 1 r - dr c - dc return count # 检查所有8个方向的最大长度 max_length 0 for dr, dc in DIRECTIONS: length count_consecutive(board, row, col, dr, dc, player) max_length max(max_length, length) if max_length 6: # 禁手阈值 break注意count_consecutive函数名强调“连续”避免和“总数量”混淆max_length变量实时更新一旦达6立即跳出节省计算。3.4 “假活三”的视觉欺骗用户常抱怨“我明明做了活三怎么AI不堵” 实际是程序把“-X-X--”两端开放误判为“-X-X-”一端被堵。根源在于检测时只看相邻格子没考虑棋型上下文。专业解法模式匹配引擎# 定义常见棋型模板用字符串表示B黑,W白,E空 PATTERNS { live_four: [EBBBBE], # 两端空的四连 dead_four: [WBBBBL, LBBBBL], # 一端或两端被堵 live_three: [EBBBE], # 两端空的三连 sleeping_three: [WBBBE, EBBBW], # 一端被堵 } def detect_pattern(board, row, col, player, direction): # 沿direction获取9格序列中心±4 seq [] for i in range(-4, 5): r row i * direction[0] c col i * direction[1] if 0 r 15 and 0 c 15: val board.get(r, c) seq.append(B if val BLACK else W if val WHITE else E) else: seq.append(L) # 边界 # 转为字符串匹配 pattern_str .join(seq) for name, templates in PATTERNS.items(): for template in templates: if template in pattern_str: return name return none # AI决策时优先堵live_three其次堵sleeping_three这个引擎把“活三”定义为EBBBE两端空而WBBBE是“眠三”。虽然增加计算量但让AI行为符合人类直觉用户会觉得“这AI真懂棋”。4. 人机交互那些让玩家默默卸载的300毫秒技术人常陷入误区功能实现体验完成。但真实用户流失往往死于反馈延迟、操作歧义、状态不透明这三个软性缺陷。我记录了测试时用户的真实吐槽“点下去没反应我以为坏了又点了一次结果下了两子”“赢了没提示我还以为没赢继续下...”“悔棋按钮点了没动静等了两秒才弹窗这延迟也太夸张了”这些问题与算法无关全是交互设计漏洞。4.1 防抖与节流不是前端专利是游戏刚需用户快速双击时事件队列可能塞入两个click事件。传统做法是加setTimeout去重但五子棋有特殊性单次点击必须100%可靠且不能因防抖丢失有效点击。正确策略硬件级点击锁定class GameInput { constructor() { this.isProcessing false; this.pendingClicks []; } handleClick(x, y) { // 立即响应显示点击动画 this.showClickFeedback(x, y); // 锁定状态排队处理 if (this.isProcessing) { this.pendingClicks.push({x, y}); return; } this.isProcessing true; this.processClick(x, y).finally(() { this.isProcessing false; // 处理积压点击最多1个避免连点 if (this.pendingClicks.length 0) { const next this.pendingClicks.shift(); this.handleClick(next.x, next.y); } }); } async processClick(x, y) { // 1. 坐标转换毫秒级 const logic this.coordinate.pixelToLogic(x, y); const grid this.coordinate.logicToGrid(logic.col, logic.row); // 2. 合法性检查同步 if (!this.coordinate.isValidGrid(grid.col, grid.row) || this.board.get(grid.row, grid.col) ! 0) { this.showInvalidFeedback(); return; } // 3. 落子同步 this.board.set(grid.row, grid.col, this.currentPlayer); this.history.push(this.board.getState()); // 4. 胜负判定同步因已优化为增量检测 const result this.checkGameStatus(grid.row, grid.col, this.currentPlayer); // 5. 异步AI思考仅当需要时 if (result.result continue this.isAIPlaying()) { await this.aiThink(); // 这里才真正异步 } } }关键点showClickFeedback在processClick前执行用户点击瞬间就有视觉反馈isProcessing锁住的是“处理逻辑”不是“响应逻辑”避免用户感觉卡顿积压队列只保留1个点击防止用户狂点导致AI来不及响应。4.2 视觉反馈的“三段式节奏”专业游戏UI遵循“响应-确认-结果”三阶段响应阶段0~50ms点击处出现扩散圆环动画颜色随玩家黑/白变化确认阶段50~200ms棋子以缓动效果“弹入”棋盘同时该格背景微亮0.2秒结果阶段200ms胜负时全屏淡入胜利图标平局时显示“和棋”文字。/* 棋子入场动画 */ .piece-enter { animation: popIn 0.3s cubic-bezier(0.17, 0.67, 0.12, 0.99); } keyframes popIn { 0% { transform: scale(0.3); opacity: 0.7; } 70% { transform: scale(1.1); opacity: 1; } 100% { transform: scale(1); opacity: 1; } }实测数据当响应延迟100ms用户会下意识重复点击300ms35%用户放弃等待。所以popIn动画必须≤300ms且用cubic-bezier制造“弹性感”避免机械感。4.3 状态透明化让用户永远知道“现在谁在忙”新手最困惑的是“轮到我了还是AI在想” 为此我在棋盘右上角加了动态状态条轮到玩家显示“你的回合” 闪烁光标AI思考中显示“AI计算中...” 进度条模拟计算非真实进度胜负已分显示“黑方获胜” 重玩按钮。进度条不是造假——它基于AI搜索深度动态计算def get_ai_progress(depth): # 深度1瞬时响应不显示进度条 # 深度2固定200ms显示20% # 深度3400ms40% # 深度4800ms80%因剪枝实际更快 base_time 200 * (2 ** (depth - 1)) # 加入随机扰动避免过于机械 jitter random.uniform(-0.2, 0.2) return min(100, max(0, 100 * (time_elapsed / (base_time * (1 jitter)))))用户看到进度条走到80%就停住会自然等待最后20%而不是焦虑“卡住了吗”。这种心理暗示比单纯显示“请稍候”有效十倍。5. AI对弈别迷信AlphaZero先搞定“不送子”很多人一上来就想接强化学习但真实项目里90%的用户只想要一个“不会故意送死”的对手。我的AI分三层5.1 规则层绝对不犯低级错误永远不堵自己的活三除非有更高优先级发现对手活四必须拦截无条件发现对手活三优先拦截除非自己能成活四。def get_rule_move(board, player): opponent WHITE if player BLACK else BLACK # 1. 检查对手活四最高优先级 for r in range(15): for c in range(15): if board.get(r, c) 0 and is_live_four(board, r, c, opponent): return (r, c) # 2. 检查自己活四次高 for r in range(15): for c in range(15): if board.get(r, c) 0 and is_live_four(board, r, c, player): return (r, c) # 3. 检查对手活三 for r in range(15): for c in range(15): if board.get(r, c) 0 and is_live_three(board, r, c, opponent): return (r, c) return None # 交给下一层这个函数在aiThink()开头执行耗时5ms却能解决80%的“送子”投诉。5.2 启发式层用棋力值代替暴力搜索minimax对五子棋是杀鸡用牛刀。我设计了一个轻量级评估函数def evaluate_position(board, player): score 0 opponent WHITE if player BLACK else BLACK # 扫描所有可能的五连位置共个 # 实际只扫以空位为中心的“潜在连线” for r in range(15): for c in range(15): if board.get(r, c) ! 0: continue # 检查该空位能形成的各类棋型 for dr, dc in DIRECTIONS: pattern get_pattern_at(board, r, c, dr, dc) score PATTERN_SCORES.get(pattern, 0) * ( 1 if board.get(r, c) player else -1 ) return score # PATTERN_SCORES 权重表经1000局对弈调优 PATTERN_SCORES { live_four: 10000, dead_four: 1000, live_three: 100, sleeping_three: 10, live_two: 1, }get_pattern_at复用前面的模式匹配引擎但只针对空位计算。整盘评估耗时≈15ms足够在200ms内返回“最佳空位”。5.3 随机扰动让AI有“人性弱点”纯最优AI会让新手绝望。我在最终选择时加入可控随机def select_move(moves, scores): # 取得分最高的前3个候选 candidates sorted(zip(moves, scores), keylambda x: x[1], reverseTrue)[:3] # 80%概率选最高分15%选第二5%选第三 weights [0.8, 0.15, 0.05] return random.choices(candidates, weightsweights)[0][0]这个设计让AI偶尔“失误”但失误是有规律的——它更可能放过一个“眠三”而不是送一个“活四”。用户会觉得“这AI有点水平但我也能赢”留存率提升明显。6. 工程收尾从“能跑”到“可维护”的最后一公里当所有功能跑通真正的工程挑战才开始如何让三个月后的自己或接手的同事能快速理解这个项目6.1 配置驱动把魔法数字变成可读常量原始代码里散落着if count 5: ... for r in range(15): ... ctx.fillRect(x*40, y*40, 40, 40);重构后统一到配置文件{ board: { size: 15, gridSize: 40, margin: 20, lineWidth: 1.5 }, game: { winLength: 5, forbiddenLength: 6, ai: { maxDepth: 3, responseTime: 200 } }, ui: { feedback: { clickDuration: 300, highlightDuration: 200 } } }所有硬编码数字消失winLength比5更能表达意图。当产品说“改成六子棋”只需改配置无需grep代码。6.2 日志埋点不是为监控是为复盘我在关键路径加了结构化日志def log_game_event(event_type, **kwargs): # event_type: move, win, forbidden, ai_think # kwargs: row, col, player, duration_ms, pattern_found entry { timestamp: time.time(), event: event_type, game_id: game_id, turn: turn_count, **kwargs } # 输出到console开发或上报服务生产 print(json.dumps(entry)) # 使用 log_game_event(move, row7, col8, playerBLACK) log_game_event(ai_think, duration_ms187, pattern_foundlive_three)某次用户反馈“AI有时不拦活三”我翻日志发现pattern_found字段在特定坐标总是空。顺藤摸瓜定位到get_pattern_at在边界处索引越界返回了错误模式。没有日志这个问题会变成玄学。6.3 单元测试只测“人容易错”的地方不写“落子后格子值改变”这种废话测试。专注边界def test_forbidden_move_detection(): # 构造六连场景第0行列0-5全为黑 board CompactBoard() for c in range(6): board.set(0, c, BLACK) # 在(0,5)落子形成六连 result check_game_over(0, 5, BLACK) assert result[result] forbidden assert result[winner] WHITE def test_click_snapping(): # 点击(0.2, 0.2)应吸附到(0,0)而非(0,0)和(1,1)之间 coord BoardCoordinate(gridSize1.0) logic coord.pixelToLogic(0.2, 0.2) grid coord.logicToGrid(logic.col, logic.row) assert grid {col: 0, row: 0}每个测试对应一个真实踩过的坑。当新人改代码时这些测试就是他的防错护栏。我在某高校实验室带学生做课程设计时布置过同样题目。交上来的作业里80%的代码在第三天就因“悔棋崩溃”被推倒重写。后来我把这套方法论拆解成六个模块让学生逐个实现、逐个测试。结果期末作品里出现了支持触控笔压感、接入语音指令、甚至用摄像头识别实体棋盘的拓展项目——它们的共同基础就是把“五子棋”从玩具变成了可生长的系统。最后分享一个心得不要追求“一次写对”而要设计“快速证伪”的结构。比如胜负判定函数我强制要求它接收board、row、col、player四个参数且不依赖任何全局状态。这样我能用10行代码构造任意棋局测试30秒内就能验证一个新规则是否生效。工程能力本质上就是把不确定性压缩到最小可验证单元的能力。
阅读完成 · 觉得有帮助？
