从“想练手”到“真正能玩”迷宫游戏Python实现复盘最近有个朋友问我想写个小游戏练手选什么项目合适。我给的答案是迷宫生成与解谜游戏。原因很简单迷宫这个项目看起来小实际把数据结构、随机算法、坐标换算、图形渲染、碰撞检测全串起来了而且做完之后非常有成就感——“这是我亲手生成的一面迷宫”。这篇文章就把我用Python实现迷宫游戏的完整过程拆开来讲包含算法选型、核心代码、pygame接入、以及我实际踩过的几个坑。如果你也想写一个能跑起来玩的迷宫小游戏照着这篇做至少能少走两晚弯路。1. 开始之前坐标体系与格子模型是你所有代码的地基很多新手一上来就想着怎么画迷宫结果写到一半发现墙的位置对不上、玩家穿墙、越界报错根本原因是没提前把迷宫的地基——数据模型和坐标体系——想清楚。迷宫本质上是一张二维网格每个格子就是迷宫的最小单元后面所有算法和渲染都围绕这张网格展开所以第一步不是装pygame而是先定义格子。1.1 用什么数据结构表示一个格子一个格子需要记住两件事它在哪里、它四周哪几面墙还在。前者用行号和列号表示后者用四个布尔值记录上、下、左、右的墙状态。我建议用一个简单的类来封装class Cell: def __init__(self, row, col): self.row row self.col col self.walls {top: True, right: True, bottom: True, left: True} self.visited False这里的visited是给迷宫生成算法用的标记是否被遍历过。为什么用字典而不是四个单独的属性因为后面写“拆墙”逻辑时可以通过字符串键名直接操作对称的两面墙代码更简洁。当然如果你追求极致性能用四个独立布尔属性也可以但对一个游戏项目来说字典的可读性优势更明显。整个迷宫就是这样一个二维列表maze[row][col]比如maze[2][3]就是第3行第4列的格子。注意这里有个新手容易拧巴的地方先写row还是先写col我建议全项目统一先row后col也就是“行在前”。习惯之后就不容易把二维数组的下标搞反。1.2 面板尺寸与像素坐标之间的换算网格坐标和屏幕像素坐标是两套系统。网格坐标是逻辑上的(row, col)像素坐标是pygame画图时用的(x, y)。它们之间的换算关系并不复杂就是乘一个格子边长GRID_ROWS 15 # 迷宫行数 GRID_COLS 17 # 迷宫列数 CELL_SIZE 30 # 每个格子的像素边长 WALL_WIDTH 2 # 墙的厚度 # 窗口尺寸 格子数 x 格子边长 墙预留宽度防止画出边界外 WIN_WIDTH GRID_COLS * CELL_SIZE WALL_WIDTH WIN_HEIGHT GRID_ROWS * CELL_SIZE WALL_WIDTH这里有一个非常容易忽略的点墙本身是有厚度的。很多教程把墙厚当成0格子边长等于像素边长结果画出来总是差几像素或者边界被截断。我的做法是给整个画布四周多预留一个墙厚。换算公式也很直观第row行第col列格子的左上角像素坐标是(col * CELL_SIZE WALL_WIDTH, row * CELL_SIZE WALL_WIDTH)。你用这个坐标画格子底色、定位玩家、判断点击全都统一用这一套公式就不会东错一处西错一处。2. 迷宫生成算法选型三种主流方案的真实差异迷宫生成看起来是个“随机打通”的过程但实际逻辑比想象中严谨。常见生成算法有那么几种递归回溯、随机Prim、Kruskal。它们生成的迷宫风格差异很大选错算法后面改代码的成本很高。2.1 递归回溯死胡同就是它最好的朋友递归回溯是最经典的深度优先算法。它的核心逻辑是从一个格子出发随机挑一个没走过的邻居打通墙走过去如果当前格子没有未访问的邻居就往回退到上一个格子继续。这个过程用一句话概括走到底没路就回头回头之后再往别的方向走。用栈来模拟回溯过程非常自然stack [start] start.visited True while stack: current stack[-1] neighbors get_unvisited_neighbors(current, grid) if not neighbors: stack.pop() else: nxt random.choice(neighbors) remove_walls_between(current, nxt) nxt.visited True stack.append(nxt)这段代码生成的迷宫有一个很鲜明的特点它会尽量往深处探索所以迷宫里有很多狭长的通道和长死路视觉上像是有“一意孤行”的感觉。这种迷宫对玩家来说比较有压迫感通关路线也往往藏在深处。实现上只要一个列表就能完成回溯不需要额外的图结构是最容易入门的方案。2.2 随机Prim与Kruskal两种“随机感”更强的方案随机Prim算法是从一个格子开始把它的所有邻居加入候选列表然后从候选列表中随机选一个格子打通再把新格子的未访问邻居也加入候选列表循环往复。Kruskal则是把每个格子看成一个独立集合随机挑选一面墙如果墙两边的格子分属不同集合就拆掉墙并合并集合否则忽略。这两种算法的实现都比递归回溯绕一些Kruskal需要用到并查集代码量明显上升。用一张表来对比它们生成的迷宫风格算法实现难度迷宫风格特性递归回溯低长走廊、死路深通路单一步数偏长随机Prim中分支丰富岔路多死路短Kruskal偏高非常均匀连通性最均匀偶有环形这里的“风格差异”不是玄学而是算法本质造成的。递归回溯总是沿着一条路深挖容易形成长巷Prim每次都从边界扩展分支自然更散Kruskal完全随机地合并区域所以整体最均匀。2.3 为什么我选递归回溯我最终选择递归回溯作为主实现理由有三个第一它最直观新手看代码就能顺着逻辑走一遍不需要并查集的概念铺垫第二生成的迷宫用在游戏上“感觉对”那种狭窄深巷带来的探索感比均匀迷宫更有迷宫味第三它的性能足够应对实际游戏规模我用它生成50×50的迷宫也就一瞬间的事而游戏里一般15×15到25×25就够玩了。如果你做的不是传统迷宫游戏而是偏解谜或开放探索的迷宫那随机Prim会是更好的选择它的岔路多、死路短玩家不会在一个死胡同里卡太久。这是我做完这版之后的一个总结先放在这里方便你按自己的游戏类型选。3. 核心生成代码逐段拆解从空网格到完整迷宫算法思想搞明白之后就要把它变成能跑的代码。这一节我把生成迷宫的关键函数逐个拆开讲包括每段代码为什么要那样写以及我最初写错的地方。3.1 邻居判断与拆墙细节决定迷宫是否越界先看获取未访问邻居的函数。这里最大的坑就是边界最上边一行没有上方邻居最右边一列没有右侧邻居索引越界会让整个程序直接崩掉。def get_unvisited_neighbors(cell, grid): rows, cols len(grid), len(grid[0]) neighbors [] r, c cell.row, cell.col if r 0 and not grid[r - 1][c].visited: neighbors.append(grid[r - 1][c]) if r rows - 1 and not grid[r 1][c].visited: neighbors.append(grid[r 1][c]) if c 0 and not grid[r][c - 1].visited: neighbors.append(grid[r][c - 1].visited) if c cols - 1 and not grid[r][c 1].visited: neighbors.append(grid[r][c 1]) return neighbors判断条件里的r 0、r rows - 1这些是对坐标范围做守卫not ...visited确保这个邻居还没被探索过。这两个条件少一个都不行少了边界判断会越界少了访问判断会走回已经遍历过的格子导致迷宫生成逻辑死循环。拆墙函数要同时拆掉当前格子和目标格子之间的那面墙。比如当前格子在左边、目标格子在右边那就把当前格子的right墙和目标格子的left墙都置为False否则迷宫画出来就是一面“单向墙”——从这边看墙没了从那边看墙还在非常诡异。def remove_walls_between(cell1, cell2): dr cell2.row - cell1.row dc cell2.col - cell1.col if dr -1: # 目标在上方 cell1.walls[top] False cell2.walls[bottom] False elif dr 1: # 目标在下方 cell1.walls[bottom] False cell2.walls[top] False elif dc -1: # 目标在左边 cell1.walls[left] False cell2.walls[right] False elif dc 1: # 目标在右边 cell1.walls[right] False cell2.walls[left] False这段代码用方向的差值来判断相对位置逻辑清晰而且拆墙和加墙都是成对出现的不容易出现“只拆了一半”的bug。3.2 回溯主循环里的一个关键细节何时标记visited回到主循环代码注意我在把邻居压入栈之前就已经把它的visited标记为True了。这个细节很重要如果等到弹出栈时再标记同一个格子可能被多个邻居同时加入候选导致生成出来的迷宫出现大量重复访问甚至会影响最终形态。为了更直观我用一个小例子解释A格子有两个邻居B和CB和C都还没有被访问。如果“入栈时才标记”你从A分别把B和C加入栈随后其实B和C都会把对方当未访问邻居一路重复处理逻辑混乱而“入栈前标记”就能确保一个格子只会被加入一次因为第二次检查它时已经visited了。整个while循环直到栈为空才结束这个条件保证了迷宫所有格子都被访问到一个都不会漏。如果有格子没被访问它迟早会被某个已访问格子的邻居发现并压入栈所以最终生成的迷宫必定是连通的。3.3 一个能跑的控制台验证版本先别急着上pygame我强烈建议先做一个控制台验证版把迷宫先用字符打印出来。这样做有两个好处一是验证生成算法是否正确二是调试时不需要反复开关游戏窗口。打印逻辑很简单输出三行字符模拟一格子的上下墙如果格子之间有左墙则打印竖线没有左墙就打印空格。def print_maze_text(grid): rows, cols len(grid), len(grid[0]) for r in range(rows): # 上墙行 line1 for c in range(cols): line1 --- if grid[r][c].walls[top] else print(line1 ) # 中间行 line2 for c in range(cols): line2 | if grid[r][c].walls[left] else print(line2 |) # 最后一行下墙 print(--- * cols )这种基于文本的验证方式看起来简陋但真的能救你一命。比如你发现输出里迷宫有些格子之间没有墙、有些格子之间双墙一眼就能定位到拆墙逻辑的问题比在图形窗口里靠眼睛猜快太多了。4. 从控制台到游戏窗口pygame交互实现的关键步骤迷宫数据生成好之后接下来就是把它渲染到游戏窗口里并让玩家能通过键盘控制移动。这一节讲pygame接入的核心环节包含初始化、绘制、键盘事件和胜利判定。4.1 渲染墙与格子画右墙和下墙的隐藏规则pygame的绘制思路是遍历每个格子先用浅色填充格子底色再根据墙状态绘制四条边。但这里有一个细节如果每个格子都把自己四条完整的墙画一遍相邻格子的公共墙会被画两次不仅浪费还会因为坐标偏差产生重叠的暗影。我的做法是每个格子只画“左边”和“上边”的墙以及“右边”和“下边”当且仅当它是最右列或最后一行时才画。听起来有点绕换个说法一堵墙的归属权属于“左边那个格子”或“上边那个格子”这样每个墙只被画一次。最后一行和最后一列的外框由最后一个方向的格子补画。def draw_maze(screen, grid): screen.fill((245, 245, 220)) # 底色 rows, cols len(grid), len(grid[0]) for r in range(rows): for c in range(cols): cell grid[r][c] x c * CELL_SIZE WALL_WIDTH y r * CELL_SIZE WALL_WIDTH pygame.draw.rect(screen, (255, 255, 255), (x, y, CELL_SIZE, CELL_SIZE)) if cell.walls[top]: pygame.draw.line(screen, (0, 0, 0), (x, y), (x CELL_SIZE, y), WALL_WIDTH) if cell.walls[left]: pygame.draw.line(screen, (0, 0, 0), (x, y), (x, y CELL_SIZE), WALL_WIDTH) if c cols - 1 and cell.walls[right]: pygame.draw.line(screen, (0, 0, 0), (x CELL_SIZE, y), (x CELL_SIZE, y CELL_SIZE), WALL_WIDTH) if r rows - 1 and cell.walls[bottom]: pygame.draw.line(screen, (0, 0, 0), (x, y CELL_SIZE), (x CELL_SIZE, y CELL_SIZE), WALL_WIDTH)按这个逻辑画出来的迷宫墙线不会重复也不会出现某个格子边缘颜色特别深的情况。如果你看到迷宫图里的墙有的粗有的细多半就是重复绘制导致的。4.2 键盘移动与碰撞检测一次一个格子的节奏感玩家移动我建议采用“按一次方向键移动一个格子”的交互模式而不是长按连续跑动。这样一来节奏更接近传统小游戏二来碰撞检测逻辑非常简单。核心思路先算出目标格子坐标检查当前格子和目标格子之间那面墙是否还在墙还在就说明不能走墙拆了就更新玩家的格子坐标。def try_move(player_row, player_col, direction, grid): r, c player_row, player_col if direction up: if r 0 and not grid[r][c].walls[top]: return r - 1, c elif direction down: if r len(grid) - 1 and not grid[r][c].walls[bottom]: return r 1, c elif direction left: if c 0 and not grid[r][c].walls[left]: return r, c - 1 elif direction right: if c len(grid[0]) - 1 and not grid[r][c].walls[right]: return r, c 1 return r, c # 无法移动就留在原地如果你希望玩家按住方向键可以连续移动那就要结合pygame.key.get_pressed()加上一个移动冷却计时器。比如每0.15秒允许移动一次这样既保持连贯性又不会快到穿墙。两种方案对应不同的游戏手感没有绝对优劣我后来做的是“单按一次走一格”因为玩家能更清晰地感知迷宫布局。4.3 胜利判定与流程控制终点标记和重新开局在迷宫对角的终点放一个不同颜色的方块玩家格子坐标等于终点坐标时触发胜利画面。在这里我建议把“生成迷宫”和“游戏循环”拆开成独立函数这样重新开局时只需要重新生成一次数据不需要重启程序。draw_start(screen, 0, 0) draw_end(screen, GRID_ROWS - 1, GRID_COLS - 1)利用pygame.KEYDOWN事件里的K_r键做重新开始按一下重新生成一个随机迷宫这对体验帮助非常大。玩家玩完一局不需要关掉窗口重开也是一个小游戏“完成度”的体现。除此之外还可以在窗口标题上显示当前状态比如pygame.display.set_caption(迷宫游戏 - 已通关)通用性很强。5. 实测中的坑我踩过的那些迷宫相关的坑再完美的计划也有翻车的时候下面列几个我实际开发中遇到的坑每一个都卡了半小时甚至更久。把问题现象和根因放在一起说希望你能跳过这些。5.1 迷宫多画了一圈外框第一次跑起来满心欢喜打开窗口结果迷宫的四条边出现了一圈重复的粗黑框。排查了很久发现问题出在绘制循环里每个格子都画了四条完整的墙。想象一下第一行格子的下墙被自己画一遍同时第二行格子的上墙又画一遍外面一圈因为没有邻居格子最后左右上下各多出半条墙线。解决办法就是我前面说的“每面墙只归属于一个格子”只画左边和上边右墙和下墙仅在边界时画。这个逻辑理清之后画面干净很多。5.2 玩家能穿墙穿墙问题有两类常见原因。第一类是碰撞检测写反了检查了目标格子那面墙而不是当前格子的墙。比如向右移动应该检查当前格子的walls[right]结果写成了目标格子的walls[left]虽然通常这两面墙是同步拆掉的但如果算法里拆墙时出了偏差就会出现能穿墙的bug。第二类原因是像素坐标取整问题玩家位置是float类型渲染时四舍五入后可能与实际格子对不上。我的解决办法是让玩家只存在于格子坐标系中不直接使用像素坐标做移动判断移动后重新根据格子坐标计算像素位置从根本上避免了误差累积。5.3 移动速度“飘”或者“卡”用事件循环监听按键时如果玩家快速按两下方向键pygame事件队列里会同时出现两个KEYDOWN玩家会瞬间移动两格看起来就是“飘”。反过来如果检测不到按键事件又会觉得“卡”。这个问题的本质是帧率和操作频率没有做好节奏控制。我建议加入一个简单的冷却机制用pygame.time.get_ticks()记录上一次移动的时间距离上次移动不足150毫秒时忽略新的移动指令。这样既能保证响应速度又不会因为操作过快产生穿模感。6. 不满足于能玩这些方向值得继续做迷宫能跑之后下一步就看你想扩展到什么程度。这里分享三个我自己觉得有价值的方向每个都不会太复杂但能让项目从“实现游戏”升级到“玩起来更像样”。6.1 BFS自动求解给迷宫加一双“眼睛”广度优先搜索BFS是解迷宫最简单有效的算法。从一个格子按层次向外扩散每次把能走到的相邻格子加入队列并记录前驱直到到达终点然后从终点回溯路径。思路极其直白一路横扫扫到终点就赢了。from collections import deque def bfs_solve(grid, start, end): queue deque([start]) prev {start: None} while queue: cur queue.popleft() if cur end: break for direction in [up, down, left, right]: nxt try_move(cur[0], cur[1], direction, grid) if nxt ! cur and nxt not in prev: prev[nxt] cur queue.append(nxt) # 回溯路径 path [] cur end while cur is not None: path.append(cur) cur prev[cur] path.reverse() return path把这个路径渲染成一条彩色线段按一下B键就显示通关路线。这个功能特别适合用来测试迷宫生成质量路径太长说明死路太多路径太短则会让人一眼看穿谜底。做成可开关的提示游戏的可玩性反而更好。6.2 难度阶梯同样的代码换个参数就是新关卡迷宫难度并不需要设计复杂逻辑改动GRID_ROWS和GRID_COLS就能获得完全不同的体验。8×8能快速通关适合新手30×30基本是挑战级迷宫里走一分钟还没过半程也正常。更自然的方式是做一个关卡配置表把行数、列数、窗口尺寸都放在配置字典里通关后按Enter进入下一关这样玩家感受到的是递进式的难度曲线而不是我直接改源码重新运行。LEVELS [ {rows: 7, cols: 7, cell: 40}, {rows: 11, cols: 13, cell: 36}, {rows: 15, cols: 17, cell: 30}, {rows: 21, cols: 25, cell: 26}, ]这里还有一个小细节格子变多以后建议把每步移动的冷却时间略微调短一点否则大迷宫走到终点耗时太久容易让玩家失去耐心。6.3 存档与计时让每一局都有“被记住”的价值加一个计时器模块从进入关卡开始用get_ticks()统计通关耗时再用一个JSON文件保存每个关卡的最佳成绩通关时如果比历史最快还快就更新记录。这些功能单独看都很小合在一起却让一个“练手小游戏”变成了一个会让人反复挑战的小作品。我在自己的版本里加了通关时间显示和简单的最短步数记录朋友试玩之后明显多了一份争强好胜的劲头。迷宫游戏写到现在我最大的体会是这个项目的门槛不在某一个单独知识点而在于把生成算法、数据表示、渲染、交互四条线拧在一起。你如果从头跟下来至少已经跨过了这个门槛——先跑通控制台版再接pygame最后按你的喜好加功能。这套路径对任何小游戏项目都适用希望我的踩坑记录能帮你省下那几个小时的debug时间。
从“想练手”到“真正能玩”迷宫游戏Python实现复盘最近有个朋友问我想写个小游戏练手选什么项目合适。我给的答案是迷宫生成与解谜游戏。原因很简单迷宫这个项目看起来小实际把数据结构、随机算法、坐标换算、图形渲染、碰撞检测全串起来了而且做完之后非常有成就感——“这是我亲手生成的一面迷宫”。这篇文章就把我用Python实现迷宫游戏的完整过程拆开来讲包含算法选型、核心代码、pygame接入、以及我实际踩过的几个坑。如果你也想写一个能跑起来玩的迷宫小游戏照着这篇做至少能少走两晚弯路。1. 开始之前坐标体系与格子模型是你所有代码的地基很多新手一上来就想着怎么画迷宫结果写到一半发现墙的位置对不上、玩家穿墙、越界报错根本原因是没提前把迷宫的地基——数据模型和坐标体系——想清楚。迷宫本质上是一张二维网格每个格子就是迷宫的最小单元后面所有算法和渲染都围绕这张网格展开所以第一步不是装pygame而是先定义格子。1.1 用什么数据结构表示一个格子一个格子需要记住两件事它在哪里、它四周哪几面墙还在。前者用行号和列号表示后者用四个布尔值记录上、下、左、右的墙状态。我建议用一个简单的类来封装class Cell: def __init__(self, row, col): self.row row self.col col self.walls {top: True, right: True, bottom: True, left: True} self.visited False这里的visited是给迷宫生成算法用的标记是否被遍历过。为什么用字典而不是四个单独的属性因为后面写“拆墙”逻辑时可以通过字符串键名直接操作对称的两面墙代码更简洁。当然如果你追求极致性能用四个独立布尔属性也可以但对一个游戏项目来说字典的可读性优势更明显。整个迷宫就是这样一个二维列表maze[row][col]比如maze[2][3]就是第3行第4列的格子。注意这里有个新手容易拧巴的地方先写row还是先写col我建议全项目统一先row后col也就是“行在前”。习惯之后就不容易把二维数组的下标搞反。1.2 面板尺寸与像素坐标之间的换算网格坐标和屏幕像素坐标是两套系统。网格坐标是逻辑上的(row, col)像素坐标是pygame画图时用的(x, y)。它们之间的换算关系并不复杂就是乘一个格子边长GRID_ROWS 15 # 迷宫行数 GRID_COLS 17 # 迷宫列数 CELL_SIZE 30 # 每个格子的像素边长 WALL_WIDTH 2 # 墙的厚度 # 窗口尺寸 格子数 x 格子边长 墙预留宽度防止画出边界外 WIN_WIDTH GRID_COLS * CELL_SIZE WALL_WIDTH WIN_HEIGHT GRID_ROWS * CELL_SIZE WALL_WIDTH这里有一个非常容易忽略的点墙本身是有厚度的。很多教程把墙厚当成0格子边长等于像素边长结果画出来总是差几像素或者边界被截断。我的做法是给整个画布四周多预留一个墙厚。换算公式也很直观第row行第col列格子的左上角像素坐标是(col * CELL_SIZE WALL_WIDTH, row * CELL_SIZE WALL_WIDTH)。你用这个坐标画格子底色、定位玩家、判断点击全都统一用这一套公式就不会东错一处西错一处。2. 迷宫生成算法选型三种主流方案的真实差异迷宫生成看起来是个“随机打通”的过程但实际逻辑比想象中严谨。常见生成算法有那么几种递归回溯、随机Prim、Kruskal。它们生成的迷宫风格差异很大选错算法后面改代码的成本很高。2.1 递归回溯死胡同就是它最好的朋友递归回溯是最经典的深度优先算法。它的核心逻辑是从一个格子出发随机挑一个没走过的邻居打通墙走过去如果当前格子没有未访问的邻居就往回退到上一个格子继续。这个过程用一句话概括走到底没路就回头回头之后再往别的方向走。用栈来模拟回溯过程非常自然stack [start] start.visited True while stack: current stack[-1] neighbors get_unvisited_neighbors(current, grid) if not neighbors: stack.pop() else: nxt random.choice(neighbors) remove_walls_between(current, nxt) nxt.visited True stack.append(nxt)这段代码生成的迷宫有一个很鲜明的特点它会尽量往深处探索所以迷宫里有很多狭长的通道和长死路视觉上像是有“一意孤行”的感觉。这种迷宫对玩家来说比较有压迫感通关路线也往往藏在深处。实现上只要一个列表就能完成回溯不需要额外的图结构是最容易入门的方案。2.2 随机Prim与Kruskal两种“随机感”更强的方案随机Prim算法是从一个格子开始把它的所有邻居加入候选列表然后从候选列表中随机选一个格子打通再把新格子的未访问邻居也加入候选列表循环往复。Kruskal则是把每个格子看成一个独立集合随机挑选一面墙如果墙两边的格子分属不同集合就拆掉墙并合并集合否则忽略。这两种算法的实现都比递归回溯绕一些Kruskal需要用到并查集代码量明显上升。用一张表来对比它们生成的迷宫风格算法实现难度迷宫风格特性递归回溯低长走廊、死路深通路单一步数偏长随机Prim中分支丰富岔路多死路短Kruskal偏高非常均匀连通性最均匀偶有环形这里的“风格差异”不是玄学而是算法本质造成的。递归回溯总是沿着一条路深挖容易形成长巷Prim每次都从边界扩展分支自然更散Kruskal完全随机地合并区域所以整体最均匀。2.3 为什么我选递归回溯我最终选择递归回溯作为主实现理由有三个第一它最直观新手看代码就能顺着逻辑走一遍不需要并查集的概念铺垫第二生成的迷宫用在游戏上“感觉对”那种狭窄深巷带来的探索感比均匀迷宫更有迷宫味第三它的性能足够应对实际游戏规模我用它生成50×50的迷宫也就一瞬间的事而游戏里一般15×15到25×25就够玩了。如果你做的不是传统迷宫游戏而是偏解谜或开放探索的迷宫那随机Prim会是更好的选择它的岔路多、死路短玩家不会在一个死胡同里卡太久。这是我做完这版之后的一个总结先放在这里方便你按自己的游戏类型选。3. 核心生成代码逐段拆解从空网格到完整迷宫算法思想搞明白之后就要把它变成能跑的代码。这一节我把生成迷宫的关键函数逐个拆开讲包括每段代码为什么要那样写以及我最初写错的地方。3.1 邻居判断与拆墙细节决定迷宫是否越界先看获取未访问邻居的函数。这里最大的坑就是边界最上边一行没有上方邻居最右边一列没有右侧邻居索引越界会让整个程序直接崩掉。def get_unvisited_neighbors(cell, grid): rows, cols len(grid), len(grid[0]) neighbors [] r, c cell.row, cell.col if r 0 and not grid[r - 1][c].visited: neighbors.append(grid[r - 1][c]) if r rows - 1 and not grid[r 1][c].visited: neighbors.append(grid[r 1][c]) if c 0 and not grid[r][c - 1].visited: neighbors.append(grid[r][c - 1].visited) if c cols - 1 and not grid[r][c 1].visited: neighbors.append(grid[r][c 1]) return neighbors判断条件里的r 0、r rows - 1这些是对坐标范围做守卫not ...visited确保这个邻居还没被探索过。这两个条件少一个都不行少了边界判断会越界少了访问判断会走回已经遍历过的格子导致迷宫生成逻辑死循环。拆墙函数要同时拆掉当前格子和目标格子之间的那面墙。比如当前格子在左边、目标格子在右边那就把当前格子的right墙和目标格子的left墙都置为False否则迷宫画出来就是一面“单向墙”——从这边看墙没了从那边看墙还在非常诡异。def remove_walls_between(cell1, cell2): dr cell2.row - cell1.row dc cell2.col - cell1.col if dr -1: # 目标在上方 cell1.walls[top] False cell2.walls[bottom] False elif dr 1: # 目标在下方 cell1.walls[bottom] False cell2.walls[top] False elif dc -1: # 目标在左边 cell1.walls[left] False cell2.walls[right] False elif dc 1: # 目标在右边 cell1.walls[right] False cell2.walls[left] False这段代码用方向的差值来判断相对位置逻辑清晰而且拆墙和加墙都是成对出现的不容易出现“只拆了一半”的bug。3.2 回溯主循环里的一个关键细节何时标记visited回到主循环代码注意我在把邻居压入栈之前就已经把它的visited标记为True了。这个细节很重要如果等到弹出栈时再标记同一个格子可能被多个邻居同时加入候选导致生成出来的迷宫出现大量重复访问甚至会影响最终形态。为了更直观我用一个小例子解释A格子有两个邻居B和CB和C都还没有被访问。如果“入栈时才标记”你从A分别把B和C加入栈随后其实B和C都会把对方当未访问邻居一路重复处理逻辑混乱而“入栈前标记”就能确保一个格子只会被加入一次因为第二次检查它时已经visited了。整个while循环直到栈为空才结束这个条件保证了迷宫所有格子都被访问到一个都不会漏。如果有格子没被访问它迟早会被某个已访问格子的邻居发现并压入栈所以最终生成的迷宫必定是连通的。3.3 一个能跑的控制台验证版本先别急着上pygame我强烈建议先做一个控制台验证版把迷宫先用字符打印出来。这样做有两个好处一是验证生成算法是否正确二是调试时不需要反复开关游戏窗口。打印逻辑很简单输出三行字符模拟一格子的上下墙如果格子之间有左墙则打印竖线没有左墙就打印空格。def print_maze_text(grid): rows, cols len(grid), len(grid[0]) for r in range(rows): # 上墙行 line1 for c in range(cols): line1 --- if grid[r][c].walls[top] else print(line1 ) # 中间行 line2 for c in range(cols): line2 | if grid[r][c].walls[left] else print(line2 |) # 最后一行下墙 print(--- * cols )这种基于文本的验证方式看起来简陋但真的能救你一命。比如你发现输出里迷宫有些格子之间没有墙、有些格子之间双墙一眼就能定位到拆墙逻辑的问题比在图形窗口里靠眼睛猜快太多了。4. 从控制台到游戏窗口pygame交互实现的关键步骤迷宫数据生成好之后接下来就是把它渲染到游戏窗口里并让玩家能通过键盘控制移动。这一节讲pygame接入的核心环节包含初始化、绘制、键盘事件和胜利判定。4.1 渲染墙与格子画右墙和下墙的隐藏规则pygame的绘制思路是遍历每个格子先用浅色填充格子底色再根据墙状态绘制四条边。但这里有一个细节如果每个格子都把自己四条完整的墙画一遍相邻格子的公共墙会被画两次不仅浪费还会因为坐标偏差产生重叠的暗影。我的做法是每个格子只画“左边”和“上边”的墙以及“右边”和“下边”当且仅当它是最右列或最后一行时才画。听起来有点绕换个说法一堵墙的归属权属于“左边那个格子”或“上边那个格子”这样每个墙只被画一次。最后一行和最后一列的外框由最后一个方向的格子补画。def draw_maze(screen, grid): screen.fill((245, 245, 220)) # 底色 rows, cols len(grid), len(grid[0]) for r in range(rows): for c in range(cols): cell grid[r][c] x c * CELL_SIZE WALL_WIDTH y r * CELL_SIZE WALL_WIDTH pygame.draw.rect(screen, (255, 255, 255), (x, y, CELL_SIZE, CELL_SIZE)) if cell.walls[top]: pygame.draw.line(screen, (0, 0, 0), (x, y), (x CELL_SIZE, y), WALL_WIDTH) if cell.walls[left]: pygame.draw.line(screen, (0, 0, 0), (x, y), (x, y CELL_SIZE), WALL_WIDTH) if c cols - 1 and cell.walls[right]: pygame.draw.line(screen, (0, 0, 0), (x CELL_SIZE, y), (x CELL_SIZE, y CELL_SIZE), WALL_WIDTH) if r rows - 1 and cell.walls[bottom]: pygame.draw.line(screen, (0, 0, 0), (x, y CELL_SIZE), (x CELL_SIZE, y CELL_SIZE), WALL_WIDTH)按这个逻辑画出来的迷宫墙线不会重复也不会出现某个格子边缘颜色特别深的情况。如果你看到迷宫图里的墙有的粗有的细多半就是重复绘制导致的。4.2 键盘移动与碰撞检测一次一个格子的节奏感玩家移动我建议采用“按一次方向键移动一个格子”的交互模式而不是长按连续跑动。这样一来节奏更接近传统小游戏二来碰撞检测逻辑非常简单。核心思路先算出目标格子坐标检查当前格子和目标格子之间那面墙是否还在墙还在就说明不能走墙拆了就更新玩家的格子坐标。def try_move(player_row, player_col, direction, grid): r, c player_row, player_col if direction up: if r 0 and not grid[r][c].walls[top]: return r - 1, c elif direction down: if r len(grid) - 1 and not grid[r][c].walls[bottom]: return r 1, c elif direction left: if c 0 and not grid[r][c].walls[left]: return r, c - 1 elif direction right: if c len(grid[0]) - 1 and not grid[r][c].walls[right]: return r, c 1 return r, c # 无法移动就留在原地如果你希望玩家按住方向键可以连续移动那就要结合pygame.key.get_pressed()加上一个移动冷却计时器。比如每0.15秒允许移动一次这样既保持连贯性又不会快到穿墙。两种方案对应不同的游戏手感没有绝对优劣我后来做的是“单按一次走一格”因为玩家能更清晰地感知迷宫布局。4.3 胜利判定与流程控制终点标记和重新开局在迷宫对角的终点放一个不同颜色的方块玩家格子坐标等于终点坐标时触发胜利画面。在这里我建议把“生成迷宫”和“游戏循环”拆开成独立函数这样重新开局时只需要重新生成一次数据不需要重启程序。draw_start(screen, 0, 0) draw_end(screen, GRID_ROWS - 1, GRID_COLS - 1)利用pygame.KEYDOWN事件里的K_r键做重新开始按一下重新生成一个随机迷宫这对体验帮助非常大。玩家玩完一局不需要关掉窗口重开也是一个小游戏“完成度”的体现。除此之外还可以在窗口标题上显示当前状态比如pygame.display.set_caption(迷宫游戏 - 已通关)通用性很强。5. 实测中的坑我踩过的那些迷宫相关的坑再完美的计划也有翻车的时候下面列几个我实际开发中遇到的坑每一个都卡了半小时甚至更久。把问题现象和根因放在一起说希望你能跳过这些。5.1 迷宫多画了一圈外框第一次跑起来满心欢喜打开窗口结果迷宫的四条边出现了一圈重复的粗黑框。排查了很久发现问题出在绘制循环里每个格子都画了四条完整的墙。想象一下第一行格子的下墙被自己画一遍同时第二行格子的上墙又画一遍外面一圈因为没有邻居格子最后左右上下各多出半条墙线。解决办法就是我前面说的“每面墙只归属于一个格子”只画左边和上边右墙和下墙仅在边界时画。这个逻辑理清之后画面干净很多。5.2 玩家能穿墙穿墙问题有两类常见原因。第一类是碰撞检测写反了检查了目标格子那面墙而不是当前格子的墙。比如向右移动应该检查当前格子的walls[right]结果写成了目标格子的walls[left]虽然通常这两面墙是同步拆掉的但如果算法里拆墙时出了偏差就会出现能穿墙的bug。第二类原因是像素坐标取整问题玩家位置是float类型渲染时四舍五入后可能与实际格子对不上。我的解决办法是让玩家只存在于格子坐标系中不直接使用像素坐标做移动判断移动后重新根据格子坐标计算像素位置从根本上避免了误差累积。5.3 移动速度“飘”或者“卡”用事件循环监听按键时如果玩家快速按两下方向键pygame事件队列里会同时出现两个KEYDOWN玩家会瞬间移动两格看起来就是“飘”。反过来如果检测不到按键事件又会觉得“卡”。这个问题的本质是帧率和操作频率没有做好节奏控制。我建议加入一个简单的冷却机制用pygame.time.get_ticks()记录上一次移动的时间距离上次移动不足150毫秒时忽略新的移动指令。这样既能保证响应速度又不会因为操作过快产生穿模感。6. 不满足于能玩这些方向值得继续做迷宫能跑之后下一步就看你想扩展到什么程度。这里分享三个我自己觉得有价值的方向每个都不会太复杂但能让项目从“实现游戏”升级到“玩起来更像样”。6.1 BFS自动求解给迷宫加一双“眼睛”广度优先搜索BFS是解迷宫最简单有效的算法。从一个格子按层次向外扩散每次把能走到的相邻格子加入队列并记录前驱直到到达终点然后从终点回溯路径。思路极其直白一路横扫扫到终点就赢了。from collections import deque def bfs_solve(grid, start, end): queue deque([start]) prev {start: None} while queue: cur queue.popleft() if cur end: break for direction in [up, down, left, right]: nxt try_move(cur[0], cur[1], direction, grid) if nxt ! cur and nxt not in prev: prev[nxt] cur queue.append(nxt) # 回溯路径 path [] cur end while cur is not None: path.append(cur) cur prev[cur] path.reverse() return path把这个路径渲染成一条彩色线段按一下B键就显示通关路线。这个功能特别适合用来测试迷宫生成质量路径太长说明死路太多路径太短则会让人一眼看穿谜底。做成可开关的提示游戏的可玩性反而更好。6.2 难度阶梯同样的代码换个参数就是新关卡迷宫难度并不需要设计复杂逻辑改动GRID_ROWS和GRID_COLS就能获得完全不同的体验。8×8能快速通关适合新手30×30基本是挑战级迷宫里走一分钟还没过半程也正常。更自然的方式是做一个关卡配置表把行数、列数、窗口尺寸都放在配置字典里通关后按Enter进入下一关这样玩家感受到的是递进式的难度曲线而不是我直接改源码重新运行。LEVELS [ {rows: 7, cols: 7, cell: 40}, {rows: 11, cols: 13, cell: 36}, {rows: 15, cols: 17, cell: 30}, {rows: 21, cols: 25, cell: 26}, ]这里还有一个小细节格子变多以后建议把每步移动的冷却时间略微调短一点否则大迷宫走到终点耗时太久容易让玩家失去耐心。6.3 存档与计时让每一局都有“被记住”的价值加一个计时器模块从进入关卡开始用get_ticks()统计通关耗时再用一个JSON文件保存每个关卡的最佳成绩通关时如果比历史最快还快就更新记录。这些功能单独看都很小合在一起却让一个“练手小游戏”变成了一个会让人反复挑战的小作品。我在自己的版本里加了通关时间显示和简单的最短步数记录朋友试玩之后明显多了一份争强好胜的劲头。迷宫游戏写到现在我最大的体会是这个项目的门槛不在某一个单独知识点而在于把生成算法、数据表示、渲染、交互四条线拧在一起。你如果从头跟下来至少已经跨过了这个门槛——先跑通控制台版再接pygame最后按你的喜好加功能。这套路径对任何小游戏项目都适用希望我的踩坑记录能帮你省下那几个小时的debug时间。
