JAVA石头迷阵这个项目说起来有点意思。它最开始只是我随手写的一个迷宫生成算法Demo——一个二维数组、一个栈、十来行递归跑出个黑白格路径就完事了。结果玩了两天觉得干巴巴的就动手给迷宫铺上石头纹理、加了角色、加了推石头解谜最后硬是整成一个小而完整的Swing游戏石头迷阵。所谓“迷阵”不只是普通的迷宫寻路它在经典迷宫的基础上叠加了推箱子式的方块解谜路上会有可推动的石头你需要把它们推到指定位置或者借助它们垫脚才能打开下一段路的开关。整个项目用Java开发依赖纯JDK的Swing和2D图形接口不接任何第三方库能跑Java的地方就能跑非常适合拿来当Java课程设计、面试作品或者纯粹想练练算法和图形界面手感的人。下面我把这个项目的玩法、算法、渲染、寻路以及踩过的坑一次说清楚。1. 为什么叫“石头迷阵”项目定位与功能拆解1.1 从迷宫游戏到“石头”主题大多数迷宫游戏的地图是抽象的矩形通道玩家看到的是一堆灰格子玩起来没有沉浸感。我做这个项目时想要一个视觉上“有重量感”的迷宫墙体是石块堆砌的质感地面是压实的石板出口立着一面旗子角色是一个简单的小人。这样迷宫看起来像一座远古遗迹走在里面才有一点探险的味道。主题定下来后我把玩法也做了统一不仅墙是石头迷宫里还散落着可推动的石头方块。这些石头不是普通障碍物——靠近它时按方向键可以推动如果石头后面是空地它会往前滑一格如果后面是墙、另一个石头或者机关你就推不动。这样一来“石头”从单纯的美术素材变成了玩法核心项目名称“石头迷阵”也就名副其实了。1.2 最终功能清单我整理了一下最终交付的版本包括以下功能模块具体功能地图生成递归回溯法随机生成迷宫每次开局地形不同地图渲染Swing双缓冲绘制石块墙、石板路、出口旗、角色动画帧角色控制键盘方向键移动支持长按连续移动碰撞检测判定推石头解谜可推动的石头方块推入凹陷标记点计分全部推到位触发出口解锁寻路提示BFS计算最短路径按F键显示白色脚印提示路线步数统计记录移动步数、推动石头次数通关后结算评价关卡配置通过文本文件配置地图支持新增关卡无需改代码重置重开R键重置当前关卡Esc退出到选关界面功能看着多但核心代码量其实不大主程序加算法加渲染大约一千行上下。我现在回头看这个项目最值得讲的部分有两个一个是迷宫怎么“长”出来另一个是推石头碰撞怎么判定得干净利落。下面分开说。2. 迷宫怎么“长”出来生成算法的选型与实现2.1 三种迷宫生成算法我为什么选了递归回溯市面上迷宫生成的主流算法有这么几种递归回溯DFS、Prim、Kruskal。网上随便一搜都是代码但实际用起来差别不小。递归回溯的生成过程很直观从起点开始沿着当前格子随机找一个没访问过的邻居打通墙壁走过去如果周围没有走过的路了就原路返回继续找直到所有格子都被访问过。它生成的迷宫有一条很明显的主干道分支相对少整体视觉上比较“爽”走到终点路径感强适合玩家探索。Prim算法生成的是均质迷宫通道特别密分支多而碎走起来像绕迷宫解谜感强但视觉上显得太密集。Kruskal生成的迷宫偏向“横平竖直”对玩家来说有点太规整趣味性弱。结合游戏体验来说石头迷阵的主要玩法是探索和推石头不是极限解谜所以我选了递归回溯。它生成速度快几百毫秒搞定地图样式也符合“远古遗迹”的审美——主干道能一眼看出把石头推到目标位的操作空间也更足。2.2 递归回溯生成器的关键实现迷宫用二维数组表示我习惯用一个int[][] map每个格子的值代表类型0是地面1是石块墙2是可推动的石头3是目标凹陷4是出口。生成阶段只处理墙和地面。核心挖墙逻辑用栈模拟递归避免深递归导致栈溢出// 迷宫坐标按“偶数格”处理map[row][col]行列都是偶数时为可通行格 int[][] map new int[height][width]; boolean[][] visited new boolean[height][width]; Dequeint[] stack new ArrayDeque(); int startRow 1, startCol 1; visited[startRow][startCol] true; stack.push(new int[]{startRow, startCol}); int[][] dirs {{-2,0},{2,0},{0,-2},{0,2}}; while (!stack.isEmpty()) { int[] current stack.peek(); int row current[0], col current[1]; // 收集所有未访问的、坐标合法的邻居 Listint[] neighbors new ArrayList(); for (int[] dir : dirs) { int nr row dir[0], nc col dir[1]; if (nr 0 nr height - 1 nc 0 nc width - 1 !visited[nr][nc]) { neighbors.add(new int[]{nr, nc}); } } if (!neighbors.isEmpty()) { // 随机选一个邻居打通中间的墙 int[] next neighbors.get(rng.nextInt(neighbors.size())); map[(row next[0]) / 2][(col next[1]) / 2] 0; visited[next[0]][next[1]] true; stack.push(next); } else { stack.pop(); } }这里有个细节值得说一下为什么用栈而不是递归函数因为地图大一点、数据量上来之后递归深度可能达到几千层JVM默认栈大小扛不住。用ArrayDeque模拟栈后进先出在逻辑上和递归完全等价还避开了栈溢出的风险。我在做这个项目时一开始用的就是递归本地跑20x20的图还没事改成60x60后直接StackOverflowError果断换成了显式栈之后就没再出过问题。2.3 随机种子的取舍可复现和可玩性的平衡迷宫生成一定要用随机但调试时随机就很折磨人——有时候你定位到一个渲染Bug重开一局地图变了不知道是Bug还是地图本身的问题。所以我加了一个Random构造器生成算法接收一个可以设置的Random实例默认是系统时间seed但调试时用固定seed比如new Random(42)这样每次生成的地图都一致方便排查逻辑问题。后来我又在固定seed的同时做了地图哈希值显示每次开局把当前地图的哈希值打印在控制台如果玩家说“我这边卡关了”我让他把哈希值发过来我这边用同一个seed可以还原出一模一样的地图排查效率直接拉满。3. 从算法到画面Swing渲染层的地图数据通路3.1 JFrame、JPanel和双缓冲别在这上面省事Swing的渲染层次其实不复杂JFrame是窗口JPanel是画布。核心是把所有绘制逻辑塞到JPanel的paintComponent(Graphics g)方法里然后在JFrame里setContentPane(new GamePanel(...))。双缓冲这个点务必注意如果直接在你的JPanel上裸画快速移动时画面会闪得很厉害。Swing的JPanel默认就是双缓冲的但如果你重写了paintComponent又去手动调super.paintComponent(g)什么都不干只是清空背景闪屏会少很多。如果你用了JLabel、JButton这些组件堆叠来做游戏画面我劝你趁早换回纯paint组件一多性能急转直下移动时残影严重。我的做法是JPanel保持默认双缓冲paintComponent里第一步调super.paintComponent(g)清屏然后按地图数组逐格绘制。绘制之前预加载好所有BufferedImage严禁在paint方法里读图片——那是一次读取解码颜色转换的完整体力活多做几次游戏就像PPT翻页。3.2 地图数据模型二维数组和屏幕坐标的换算地图数据是二维数组屏幕坐标是以像素为单位的坐标系中间需要一个换算函数。我用的这种private void drawMap(Graphics2D g2d, int[][] map) { int tileSize 40; // 每格40x40像素 for (int row 0; row map.length; row) { for (int col 0; col map[0].length; col) { int value map[row][col]; int x col * tileSize; int y row * tileSize; BufferedImage img getImageForValue(value); if (img ! null) { g2d.drawImage(img, x, y, tileSize, tileSize, null); } } } }这里tileSize的单位是“格子的像素宽”。我踩过一个坑一开始我把地图行列和屏幕坐标混在一起角色移动时把屏幕坐标当成数组下标去取格子结果角色走到地图边缘就直接数组越界。后来我强制自己把数据层和渲染层隔离开——角色在地图数据里存的是[row, col]坐标渲染时才乘tileSize得到像素坐标。这样碰撞检测只查数组不碰像素天然避免越界问题。另外还有一点关于图片资源的处理。石头墙壁的纹理我是自己用程序画的没有外部的图片文件。因为外部图片一旦放到别的目录路径就变成运行时踩坑的重灾区。程序化生成纹理的好处是和代码打包在这里一个jar跑遍所有环境不依赖外部资源路径。如果你坚持要用外部图片我建议放到classpath资源目录下用getClass().getResource(/images/wall.png)读取而不是用new File(images/wall.png)——后者换个当前工作目录就崩。3.3 键盘监听和连续移动的手感角色移动的经典坑就是按键一下动一步长按不连续或者长按倒是连续了但按得很急时鬼畜抖动。根源在于你把移动逻辑直接写在keyPressed事件里。键盘事件不是高频轮询它只在键被按下和松开时触发keyPressed触发一次等于动一步长按反而要靠系统的按键重复机制而这个机制的速度和延迟你是控制不了的。正确做法是把按键状态记录在一个Set里keyPressed时把按下的键加进去keyReleased时移除。同时游戏循环里每隔一段时间比如每帧查这个Set看哪些方向键还按着持续移动。我用的主循环是Swing Timer每16毫秒触发一次大约60FPS移动速度也按这个节奏来。private final SetInteger pressedKeys new HashSet(); Override public void keyPressed(KeyEvent e) { pressedKeys.add(e.getKeyCode()); } Override public void keyReleased(KeyEvent e) { pressedKeys.remove(e.getKeyCode()); } Override public void actionPerformed(ActionEvent e) { if (pressedKeys.contains(KeyEvent.VK_UP)) tryMove(-1, 0); if (pressedKeys.contains(KeyEvent.VK_DOWN)) tryMove(1, 0); if (pressedKeys.contains(KeyEvent.VK_LEFT)) tryMove(0, -1); if (pressedKeys.contains(KeyEvent.VK_RIGHT)) tryMove(0, 1); repaint(); }这样改完长按连续移动、斜方向同时按两个键抢同一帧行为都是可控的。还有一个细节keyPressed里如果对事件调用了e.consume()可以防止某些平台上方向键同时触发焦点转移这个也可以加上。4. 推石头和碰撞判定看着简单细节全是坑4.1 为什么“下一格坐标”这种判定会出Bug角色移动的碰撞检测很多人直觉上会写先算角色下一步要走到的坐标然后看那个坐标是不是墙是墙就不动不是墙就走过去。这在纯寻路迷宫里完全没问题但加了推石头功能就出事了。因为可推动的石头也是一个格子。角色走到石头格子上得先判断石头能不能被推走石头能不能推走又要看石头后面那一格是不是空地。如果你把碰撞检测只写一层“看目标格子是不是墙”就会出现两种情况一是角色直接“踩”到石头上穿模二是石头明明是空心的但因为你只顾着查角色目标格没查石头后面一格导致推不动。正确的思路是把移动判定拆成三层目标位置是墙什么都不做。目标位置是空地或出口角色移过去。目标位置是可推动石头检查石头前方的格子如果前方是空地则角色和石头同时移动一格如果前方是墙、石头、目标凹陷或边界则整个动作取消。4.2 推石头碰撞的完整实现实现方式如下tryMove方法接收方向参数返回boolean表示是否发生移动private boolean tryMove(int dRow, int dCol) { int newRow playerRow dRow; int newCol playerCol dCol; if (newRow 0 || newRow map.length || newCol 0 || newCol map[0].length) { return false; } int targetValue map[newRow][newCol]; // 目标位置是不可通行的墙 if (targetValue WALL) { return false; } // 目标位置是可推动的石头 if (targetValue PUSHABLE_STONE) { int beyondRow newRow dRow; int beyondCol newCol dCol; if (beyondRow 0 || beyondRow map.length || beyondCol 0 || beyondCol map[0].length) { return false; } int beyondValue map[beyondRow][beyondCol]; if (beyondValue WALL || beyondValue PUSHABLE_STONE || beyondValue OUTLET_FLAG) { return false; } // 推动石头角色和石头各前移一格 map[beyondRow][beyondCol] tentativelyTreat(beyondValue, PUSHABLE_STONE); map[newRow][newCol] PLAYER; map[playerRow][playerCol] GROUND; playerRow newRow; playerCol newCol; pushCount; return true; } // 目标位置是空地或出口时正常移动 map[playerRow][playerCol] GROUND; map[newRow][newCol] PLAYER; playerRow newRow; playerCol newCol; return true; }这里有一个很容易被忽略的细节石头推走之后原来的位置要变成玩家位置玩家原来的位置要变回地面而石头原来的位置如果是目标凹陷3推完之后不能直接覆盖成地面否则石头就“消失”了凹陷目标也失效了。实际中我把“目标凹陷”和“石头停留”分成两个状态石头进入凹陷后格子类型变成“已占位的石头”它仍然占着这一格、不能继续被推走同时通关判定时统计所有凹陷是否都被占位。如果你省掉这个状态推石头和关卡判定很容易拧巴成一团。4.3 推石头的“死角”设计为什么需要重置键推箱子玩法看似简单一个致命问题是石头一旦推到边界角落就永远推不出来了。纯推箱子游戏会把玩家推进无解局面只能重开。石头迷阵里我干脆把这个“无解感”做成了惊喜要素部分关卡故意让某块石头卡在一个看似死路的位置但只要你从另一个方向靠近会发现石头后面还有一个隐藏凹陷石头可以继续推过去。这种设计让玩家“卡关”后瞬间想通比简单的无脑路径要耐玩。但无论如何操作失误还是会发生。所以R键重置、Esc键退出这两个快捷键必须有。我当时在第一版连重置键都没加玩着玩着自己把自己关进死角只能杀进程重开体验极差。加完重置键游戏才算真正能好好玩。5. 一键寻路提示BFS在迷宫里为什么够用5.1 BFS与A*的取舍寻路提示功能要实现的是玩家按F键显示从当前位置到出口的最短路径。迷宫里所有走的步数权重都是1没有沼泽、陷阱这种消耗差异这就是一个无权图上的最短路径问题。BFS天然就是O(VE)的最优解法不需要启发式函数辅助。A*在无权图上虽然也能用但h(n)如果直接取曼哈顿距离和BFS的实际搜索范围没有本质区别还多了一堆open list、closed list和排序的开销纯属给自己加戏。如果未来给地图加上消耗差异比如某些石头地面移动要算3步某些石板路算1步那BFS就不够了得换成Dijkstra或者A*。我当时的实现是BFS逻辑简单、调试省心孤立的迷宫节点全都能覆盖。5.2 BFS寻路的实现细节BFS寻路核心是维护一个队列和一张前驱表private Listint[] bfsPath(int startRow, int startCol, int targetRow, int targetCol, int[][] map) { int rows map.length, cols map[0].length; boolean[][] visited new boolean[rows][cols]; int[][] prevRow new int[rows][cols]; int[][] prevCol new int[rows][cols]; Queueint[] queue new ArrayDeque(); Arrays.fill(prevRow[0], -1); queue.offer(new int[]{startRow, startCol}); visited[startRow][startCol] true; int[][] dirs {{-1,0},{1,0},{0,-1},{0,1}}; while (!queue.isEmpty()) { int[] cur queue.poll(); if (cur[0] targetRow cur[1] targetCol) { break; } for (int[] d : dirs) { int nr cur[0] d[0], nc cur[1] d[1]; if (nr 0 || nr rows || nc 0 || nc cols) continue; if (visited[nr][nc]) continue; if (map[nr][nc] WALL || map[nr][nc] PUSHABLE_STONE) continue; visited[nr][nc] true; prevRow[nr][nc] cur[0]; prevCol[nr][nc] cur[1]; queue.offer(new int[]{nr, nc}); } } // 从出口倒推路径 Listint[] path new ArrayList(); int r targetRow, c targetCol; while (!(r startRow c startCol)) { if (r -1) return List.of(); // 无路径 path.add(new int[]{r, c}); int pr prevRow[r][c]; int pc prevCol[r][c]; r pr; c pc; } Collections.reverse(path); return path; }这里有两点需要注意。第一前驱表一定要用两个int数组来存前驱的row和col而不是用一个int存“移动方向编码”。方向编码在回溯时容易出错而且调试很不直观。用两个数组存前驱坐标回溯时一步一行非常清晰。第二出口本身在地图里的值可能是出口旗所在格如果要显示“到终点”的路径目标格允许玩家到达BFS遍历时不能把出口排除掉。5.3 在Swing线程里跑寻路别阻塞UI线程寻路和渲染不能混在同一个线程里直接跑。如果地图特别大比如80x80BFS本身计算量不小如果直接在按键事件里执行并且立刻调用repaint界面会卡顿一两秒体验非常糟糕。我的做法是用SwingWorker在后台线程执行BFS完成后把路径结果传回UI线程再重绘。这个细节在调画面时很容易被忽略但作为棋牌类小游戏按一个键卡半秒和按一个键立刻出结果玩家对游戏品质的感知差距是巨大的。6. 测试与调优从能跑到玩得上手差的不是一点6.1 手动测试用例表纯游戏的逻辑不像业务系统那么好写自动化单测手动测试占了绝大部分。我整理了下面这张表每次改完逻辑按顺序过一遍测试项操作预期结果基本移动按上下左右角色按方向移动一格长按连动按住右键不放角色持续向右移动撞墙角色紧贴墙面向墙移动角色不移动、画面无异常推石头前方空位角色靠近石头并将石头推向空地角色和石头同时前移一格推石头前方墙角把石头推到这个墙角角色不移动石头不动步数不增推石头进凹陷把石头推到目标凹陷位置石头停留在凹陷中目标计数1出口解锁条件所有目标凹陷都被占位出口可通行走到出口出现结算画面重置玩到一半按R地图恢复初始布局步数清零寻路提示按F白色脚印从角色位置连到出口快速连按高频交替按上下左右无卡顿、无数组越界窗口缩放拖拽窗口大小画面和逻辑正常地图不扭曲这张表帮我抓了不少莫名其妙的Bug。最大一个出口解锁后如果角色站在出口格上再按R重置会出现角色和新地图的地形重叠。原因是重置逻辑里没把角色坐标恢复只重生成地图数组。这个只能在手动测试里发现因为单测时不太会去模拟这种交互顺序。6.2 渲染性能优化只画看得见的格子最初版本的drawMap是整个地图全量绘制。20x20的地图没感觉但到了50x502500格每帧绘制压力就上来了尤其是后面加了石头的阴影和角色动画帧帧率肉眼可见地掉。优化方案是“视口裁剪”只绘制当前窗口可见范围内的格子区间。int visibleColStart Math.max(0, (cameraX - 50) / tileSize); int visibleColEnd Math.min(map[0].length - 1, (cameraX viewportWidth) / tileSize 1); int visibleRowStart Math.max(0, (cameraY - 50) / tileSize); int visibleRowEnd Math.min(map.length - 1, (cameraY viewportHeight) / tileSize 1);配合一个简单的cameraX、cameraY跟随角色移动角色走在大型迷宫中时画面只渲染视野内的格子帧率根本不会随着地图规模变大而崩。这个裁剪逻辑不复杂但收益极大大尺寸迷宫配上它才算真正能玩。6.3 一个必须说的小技巧地图哈希与关卡配置分离我把关卡配置做成了文本文件格式每行表示一格字符映射到不同地形#是墙、空格是地面、P是玩家、S是可推动石头、T是目标凹陷、E是出口。新加一关只需要改文本文件不用改Java代码。这里劝一句如果你要把做好的项目当作业交上去关卡配置用外部文本文件是加分项但要注意交付时一并打包配置文件否则换台电脑运行直接报错说找不到关卡文件。我一般建议文本内嵌成resource这样不会丢。7. 扩展方向与个人复盘石头迷阵做完之后回头审视自己写的代码有几个地方是我觉得如果重做一遍会更完善的一是角色和推石头逻辑目前全部写在主类的tryMove里代码行数虽然不多但和渲染、生成逻辑耦合度偏高如果想要更多玩法扩展需要拆成独立的GameState类二是目前没有独立的音效模块推石头成功、通关这两个关键反馈点没有音效感官体验少了半口气三是石头和出口的联动还比较死目前是所有凹陷占位后出口才解锁如果做成“石头进入指定凹陷才会触发对应出口”关卡设计的可能性会更大。对于想在这个项目基础上接着做点什么的朋友我觉得有三个方向值得考虑。第一个是做成关卡编辑器玩家可以在图形界面里自己画地图、摆石头、定目标然后保存成关卡文件继续玩这比写死地图有意思得多第二个是加一个游戏内计时和步数排行榜配上简单的序列化存档能让游戏有反复挑战的欲望第三个是把渲染层换成JavaFX或者封装一个简单的API接口让核心的迷宫生成和推石头逻辑可以被Web前端或者移动端复用——这也是很多人在改编游戏时的经典做法。最后说一点我的真实体会。这种小游戏项目最锻炼人的地方不是算法本身而是“从能跑到玩得上手”的那段路。迷宫生成算法网上到处都有拷贝下来跑通不算本事难的是让玩家在49步的时候推那块石头时不觉得卡手、按快捷键时有即时反馈、踩进死角时有重置的出口。石头迷阵玩到今天每一次改动的成就感都来自这些看不见的小细节。希望这篇分享也能让你的石头迷阵走得更远。 
长河君 · 2026/10/15 17:11:48 · 阅读 1.2k Java Swing开发石头迷阵：递归回溯迷宫生成与BFS寻路全解析
JAVA石头迷阵这个项目说起来有点意思。它最开始只是我随手写的一个迷宫生成算法Demo——一个二维数组、一个栈、十来行递归跑出个黑白格路径就完事了。结果玩了两天觉得干巴巴的就动手给迷宫铺上石头纹理、加了角色、加了推石头解谜最后硬是整成一个小而完整的Swing游戏石头迷阵。所谓“迷阵”不只是普通的迷宫寻路它在经典迷宫的基础上叠加了推箱子式的方块解谜路上会有可推动的石头你需要把它们推到指定位置或者借助它们垫脚才能打开下一段路的开关。整个项目用Java开发依赖纯JDK的Swing和2D图形接口不接任何第三方库能跑Java的地方就能跑非常适合拿来当Java课程设计、面试作品或者纯粹想练练算法和图形界面手感的人。下面我把这个项目的玩法、算法、渲染、寻路以及踩过的坑一次说清楚。1. 为什么叫“石头迷阵”项目定位与功能拆解1.1 从迷宫游戏到“石头”主题大多数迷宫游戏的地图是抽象的矩形通道玩家看到的是一堆灰格子玩起来没有沉浸感。我做这个项目时想要一个视觉上“有重量感”的迷宫墙体是石块堆砌的质感地面是压实的石板出口立着一面旗子角色是一个简单的小人。这样迷宫看起来像一座远古遗迹走在里面才有一点探险的味道。主题定下来后我把玩法也做了统一不仅墙是石头迷宫里还散落着可推动的石头方块。这些石头不是普通障碍物——靠近它时按方向键可以推动如果石头后面是空地它会往前滑一格如果后面是墙、另一个石头或者机关你就推不动。这样一来“石头”从单纯的美术素材变成了玩法核心项目名称“石头迷阵”也就名副其实了。1.2 最终功能清单我整理了一下最终交付的版本包括以下功能模块具体功能地图生成递归回溯法随机生成迷宫每次开局地形不同地图渲染Swing双缓冲绘制石块墙、石板路、出口旗、角色动画帧角色控制键盘方向键移动支持长按连续移动碰撞检测判定推石头解谜可推动的石头方块推入凹陷标记点计分全部推到位触发出口解锁寻路提示BFS计算最短路径按F键显示白色脚印提示路线步数统计记录移动步数、推动石头次数通关后结算评价关卡配置通过文本文件配置地图支持新增关卡无需改代码重置重开R键重置当前关卡Esc退出到选关界面功能看着多但核心代码量其实不大主程序加算法加渲染大约一千行上下。我现在回头看这个项目最值得讲的部分有两个一个是迷宫怎么“长”出来另一个是推石头碰撞怎么判定得干净利落。下面分开说。2. 迷宫怎么“长”出来生成算法的选型与实现2.1 三种迷宫生成算法我为什么选了递归回溯市面上迷宫生成的主流算法有这么几种递归回溯DFS、Prim、Kruskal。网上随便一搜都是代码但实际用起来差别不小。递归回溯的生成过程很直观从起点开始沿着当前格子随机找一个没访问过的邻居打通墙壁走过去如果周围没有走过的路了就原路返回继续找直到所有格子都被访问过。它生成的迷宫有一条很明显的主干道分支相对少整体视觉上比较“爽”走到终点路径感强适合玩家探索。Prim算法生成的是均质迷宫通道特别密分支多而碎走起来像绕迷宫解谜感强但视觉上显得太密集。Kruskal生成的迷宫偏向“横平竖直”对玩家来说有点太规整趣味性弱。结合游戏体验来说石头迷阵的主要玩法是探索和推石头不是极限解谜所以我选了递归回溯。它生成速度快几百毫秒搞定地图样式也符合“远古遗迹”的审美——主干道能一眼看出把石头推到目标位的操作空间也更足。2.2 递归回溯生成器的关键实现迷宫用二维数组表示我习惯用一个int[][] map每个格子的值代表类型0是地面1是石块墙2是可推动的石头3是目标凹陷4是出口。生成阶段只处理墙和地面。核心挖墙逻辑用栈模拟递归避免深递归导致栈溢出// 迷宫坐标按“偶数格”处理map[row][col]行列都是偶数时为可通行格 int[][] map new int[height][width]; boolean[][] visited new boolean[height][width]; Dequeint[] stack new ArrayDeque(); int startRow 1, startCol 1; visited[startRow][startCol] true; stack.push(new int[]{startRow, startCol}); int[][] dirs {{-2,0},{2,0},{0,-2},{0,2}}; while (!stack.isEmpty()) { int[] current stack.peek(); int row current[0], col current[1]; // 收集所有未访问的、坐标合法的邻居 Listint[] neighbors new ArrayList(); for (int[] dir : dirs) { int nr row dir[0], nc col dir[1]; if (nr 0 nr height - 1 nc 0 nc width - 1 !visited[nr][nc]) { neighbors.add(new int[]{nr, nc}); } } if (!neighbors.isEmpty()) { // 随机选一个邻居打通中间的墙 int[] next neighbors.get(rng.nextInt(neighbors.size())); map[(row next[0]) / 2][(col next[1]) / 2] 0; visited[next[0]][next[1]] true; stack.push(next); } else { stack.pop(); } }这里有个细节值得说一下为什么用栈而不是递归函数因为地图大一点、数据量上来之后递归深度可能达到几千层JVM默认栈大小扛不住。用ArrayDeque模拟栈后进先出在逻辑上和递归完全等价还避开了栈溢出的风险。我在做这个项目时一开始用的就是递归本地跑20x20的图还没事改成60x60后直接StackOverflowError果断换成了显式栈之后就没再出过问题。2.3 随机种子的取舍可复现和可玩性的平衡迷宫生成一定要用随机但调试时随机就很折磨人——有时候你定位到一个渲染Bug重开一局地图变了不知道是Bug还是地图本身的问题。所以我加了一个Random构造器生成算法接收一个可以设置的Random实例默认是系统时间seed但调试时用固定seed比如new Random(42)这样每次生成的地图都一致方便排查逻辑问题。后来我又在固定seed的同时做了地图哈希值显示每次开局把当前地图的哈希值打印在控制台如果玩家说“我这边卡关了”我让他把哈希值发过来我这边用同一个seed可以还原出一模一样的地图排查效率直接拉满。3. 从算法到画面Swing渲染层的地图数据通路3.1 JFrame、JPanel和双缓冲别在这上面省事Swing的渲染层次其实不复杂JFrame是窗口JPanel是画布。核心是把所有绘制逻辑塞到JPanel的paintComponent(Graphics g)方法里然后在JFrame里setContentPane(new GamePanel(...))。双缓冲这个点务必注意如果直接在你的JPanel上裸画快速移动时画面会闪得很厉害。Swing的JPanel默认就是双缓冲的但如果你重写了paintComponent又去手动调super.paintComponent(g)什么都不干只是清空背景闪屏会少很多。如果你用了JLabel、JButton这些组件堆叠来做游戏画面我劝你趁早换回纯paint组件一多性能急转直下移动时残影严重。我的做法是JPanel保持默认双缓冲paintComponent里第一步调super.paintComponent(g)清屏然后按地图数组逐格绘制。绘制之前预加载好所有BufferedImage严禁在paint方法里读图片——那是一次读取解码颜色转换的完整体力活多做几次游戏就像PPT翻页。3.2 地图数据模型二维数组和屏幕坐标的换算地图数据是二维数组屏幕坐标是以像素为单位的坐标系中间需要一个换算函数。我用的这种private void drawMap(Graphics2D g2d, int[][] map) { int tileSize 40; // 每格40x40像素 for (int row 0; row map.length; row) { for (int col 0; col map[0].length; col) { int value map[row][col]; int x col * tileSize; int y row * tileSize; BufferedImage img getImageForValue(value); if (img ! null) { g2d.drawImage(img, x, y, tileSize, tileSize, null); } } } }这里tileSize的单位是“格子的像素宽”。我踩过一个坑一开始我把地图行列和屏幕坐标混在一起角色移动时把屏幕坐标当成数组下标去取格子结果角色走到地图边缘就直接数组越界。后来我强制自己把数据层和渲染层隔离开——角色在地图数据里存的是[row, col]坐标渲染时才乘tileSize得到像素坐标。这样碰撞检测只查数组不碰像素天然避免越界问题。另外还有一点关于图片资源的处理。石头墙壁的纹理我是自己用程序画的没有外部的图片文件。因为外部图片一旦放到别的目录路径就变成运行时踩坑的重灾区。程序化生成纹理的好处是和代码打包在这里一个jar跑遍所有环境不依赖外部资源路径。如果你坚持要用外部图片我建议放到classpath资源目录下用getClass().getResource(/images/wall.png)读取而不是用new File(images/wall.png)——后者换个当前工作目录就崩。3.3 键盘监听和连续移动的手感角色移动的经典坑就是按键一下动一步长按不连续或者长按倒是连续了但按得很急时鬼畜抖动。根源在于你把移动逻辑直接写在keyPressed事件里。键盘事件不是高频轮询它只在键被按下和松开时触发keyPressed触发一次等于动一步长按反而要靠系统的按键重复机制而这个机制的速度和延迟你是控制不了的。正确做法是把按键状态记录在一个Set里keyPressed时把按下的键加进去keyReleased时移除。同时游戏循环里每隔一段时间比如每帧查这个Set看哪些方向键还按着持续移动。我用的主循环是Swing Timer每16毫秒触发一次大约60FPS移动速度也按这个节奏来。private final SetInteger pressedKeys new HashSet(); Override public void keyPressed(KeyEvent e) { pressedKeys.add(e.getKeyCode()); } Override public void keyReleased(KeyEvent e) { pressedKeys.remove(e.getKeyCode()); } Override public void actionPerformed(ActionEvent e) { if (pressedKeys.contains(KeyEvent.VK_UP)) tryMove(-1, 0); if (pressedKeys.contains(KeyEvent.VK_DOWN)) tryMove(1, 0); if (pressedKeys.contains(KeyEvent.VK_LEFT)) tryMove(0, -1); if (pressedKeys.contains(KeyEvent.VK_RIGHT)) tryMove(0, 1); repaint(); }这样改完长按连续移动、斜方向同时按两个键抢同一帧行为都是可控的。还有一个细节keyPressed里如果对事件调用了e.consume()可以防止某些平台上方向键同时触发焦点转移这个也可以加上。4. 推石头和碰撞判定看着简单细节全是坑4.1 为什么“下一格坐标”这种判定会出Bug角色移动的碰撞检测很多人直觉上会写先算角色下一步要走到的坐标然后看那个坐标是不是墙是墙就不动不是墙就走过去。这在纯寻路迷宫里完全没问题但加了推石头功能就出事了。因为可推动的石头也是一个格子。角色走到石头格子上得先判断石头能不能被推走石头能不能推走又要看石头后面那一格是不是空地。如果你把碰撞检测只写一层“看目标格子是不是墙”就会出现两种情况一是角色直接“踩”到石头上穿模二是石头明明是空心的但因为你只顾着查角色目标格没查石头后面一格导致推不动。正确的思路是把移动判定拆成三层目标位置是墙什么都不做。目标位置是空地或出口角色移过去。目标位置是可推动石头检查石头前方的格子如果前方是空地则角色和石头同时移动一格如果前方是墙、石头、目标凹陷或边界则整个动作取消。4.2 推石头碰撞的完整实现实现方式如下tryMove方法接收方向参数返回boolean表示是否发生移动private boolean tryMove(int dRow, int dCol) { int newRow playerRow dRow; int newCol playerCol dCol; if (newRow 0 || newRow map.length || newCol 0 || newCol map[0].length) { return false; } int targetValue map[newRow][newCol]; // 目标位置是不可通行的墙 if (targetValue WALL) { return false; } // 目标位置是可推动的石头 if (targetValue PUSHABLE_STONE) { int beyondRow newRow dRow; int beyondCol newCol dCol; if (beyondRow 0 || beyondRow map.length || beyondCol 0 || beyondCol map[0].length) { return false; } int beyondValue map[beyondRow][beyondCol]; if (beyondValue WALL || beyondValue PUSHABLE_STONE || beyondValue OUTLET_FLAG) { return false; } // 推动石头角色和石头各前移一格 map[beyondRow][beyondCol] tentativelyTreat(beyondValue, PUSHABLE_STONE); map[newRow][newCol] PLAYER; map[playerRow][playerCol] GROUND; playerRow newRow; playerCol newCol; pushCount; return true; } // 目标位置是空地或出口时正常移动 map[playerRow][playerCol] GROUND; map[newRow][newCol] PLAYER; playerRow newRow; playerCol newCol; return true; }这里有一个很容易被忽略的细节石头推走之后原来的位置要变成玩家位置玩家原来的位置要变回地面而石头原来的位置如果是目标凹陷3推完之后不能直接覆盖成地面否则石头就“消失”了凹陷目标也失效了。实际中我把“目标凹陷”和“石头停留”分成两个状态石头进入凹陷后格子类型变成“已占位的石头”它仍然占着这一格、不能继续被推走同时通关判定时统计所有凹陷是否都被占位。如果你省掉这个状态推石头和关卡判定很容易拧巴成一团。4.3 推石头的“死角”设计为什么需要重置键推箱子玩法看似简单一个致命问题是石头一旦推到边界角落就永远推不出来了。纯推箱子游戏会把玩家推进无解局面只能重开。石头迷阵里我干脆把这个“无解感”做成了惊喜要素部分关卡故意让某块石头卡在一个看似死路的位置但只要你从另一个方向靠近会发现石头后面还有一个隐藏凹陷石头可以继续推过去。这种设计让玩家“卡关”后瞬间想通比简单的无脑路径要耐玩。但无论如何操作失误还是会发生。所以R键重置、Esc键退出这两个快捷键必须有。我当时在第一版连重置键都没加玩着玩着自己把自己关进死角只能杀进程重开体验极差。加完重置键游戏才算真正能好好玩。5. 一键寻路提示BFS在迷宫里为什么够用5.1 BFS与A*的取舍寻路提示功能要实现的是玩家按F键显示从当前位置到出口的最短路径。迷宫里所有走的步数权重都是1没有沼泽、陷阱这种消耗差异这就是一个无权图上的最短路径问题。BFS天然就是O(VE)的最优解法不需要启发式函数辅助。A*在无权图上虽然也能用但h(n)如果直接取曼哈顿距离和BFS的实际搜索范围没有本质区别还多了一堆open list、closed list和排序的开销纯属给自己加戏。如果未来给地图加上消耗差异比如某些石头地面移动要算3步某些石板路算1步那BFS就不够了得换成Dijkstra或者A*。我当时的实现是BFS逻辑简单、调试省心孤立的迷宫节点全都能覆盖。5.2 BFS寻路的实现细节BFS寻路核心是维护一个队列和一张前驱表private Listint[] bfsPath(int startRow, int startCol, int targetRow, int targetCol, int[][] map) { int rows map.length, cols map[0].length; boolean[][] visited new boolean[rows][cols]; int[][] prevRow new int[rows][cols]; int[][] prevCol new int[rows][cols]; Queueint[] queue new ArrayDeque(); Arrays.fill(prevRow[0], -1); queue.offer(new int[]{startRow, startCol}); visited[startRow][startCol] true; int[][] dirs {{-1,0},{1,0},{0,-1},{0,1}}; while (!queue.isEmpty()) { int[] cur queue.poll(); if (cur[0] targetRow cur[1] targetCol) { break; } for (int[] d : dirs) { int nr cur[0] d[0], nc cur[1] d[1]; if (nr 0 || nr rows || nc 0 || nc cols) continue; if (visited[nr][nc]) continue; if (map[nr][nc] WALL || map[nr][nc] PUSHABLE_STONE) continue; visited[nr][nc] true; prevRow[nr][nc] cur[0]; prevCol[nr][nc] cur[1]; queue.offer(new int[]{nr, nc}); } } // 从出口倒推路径 Listint[] path new ArrayList(); int r targetRow, c targetCol; while (!(r startRow c startCol)) { if (r -1) return List.of(); // 无路径 path.add(new int[]{r, c}); int pr prevRow[r][c]; int pc prevCol[r][c]; r pr; c pc; } Collections.reverse(path); return path; }这里有两点需要注意。第一前驱表一定要用两个int数组来存前驱的row和col而不是用一个int存“移动方向编码”。方向编码在回溯时容易出错而且调试很不直观。用两个数组存前驱坐标回溯时一步一行非常清晰。第二出口本身在地图里的值可能是出口旗所在格如果要显示“到终点”的路径目标格允许玩家到达BFS遍历时不能把出口排除掉。5.3 在Swing线程里跑寻路别阻塞UI线程寻路和渲染不能混在同一个线程里直接跑。如果地图特别大比如80x80BFS本身计算量不小如果直接在按键事件里执行并且立刻调用repaint界面会卡顿一两秒体验非常糟糕。我的做法是用SwingWorker在后台线程执行BFS完成后把路径结果传回UI线程再重绘。这个细节在调画面时很容易被忽略但作为棋牌类小游戏按一个键卡半秒和按一个键立刻出结果玩家对游戏品质的感知差距是巨大的。6. 测试与调优从能跑到玩得上手差的不是一点6.1 手动测试用例表纯游戏的逻辑不像业务系统那么好写自动化单测手动测试占了绝大部分。我整理了下面这张表每次改完逻辑按顺序过一遍测试项操作预期结果基本移动按上下左右角色按方向移动一格长按连动按住右键不放角色持续向右移动撞墙角色紧贴墙面向墙移动角色不移动、画面无异常推石头前方空位角色靠近石头并将石头推向空地角色和石头同时前移一格推石头前方墙角把石头推到这个墙角角色不移动石头不动步数不增推石头进凹陷把石头推到目标凹陷位置石头停留在凹陷中目标计数1出口解锁条件所有目标凹陷都被占位出口可通行走到出口出现结算画面重置玩到一半按R地图恢复初始布局步数清零寻路提示按F白色脚印从角色位置连到出口快速连按高频交替按上下左右无卡顿、无数组越界窗口缩放拖拽窗口大小画面和逻辑正常地图不扭曲这张表帮我抓了不少莫名其妙的Bug。最大一个出口解锁后如果角色站在出口格上再按R重置会出现角色和新地图的地形重叠。原因是重置逻辑里没把角色坐标恢复只重生成地图数组。这个只能在手动测试里发现因为单测时不太会去模拟这种交互顺序。6.2 渲染性能优化只画看得见的格子最初版本的drawMap是整个地图全量绘制。20x20的地图没感觉但到了50x502500格每帧绘制压力就上来了尤其是后面加了石头的阴影和角色动画帧帧率肉眼可见地掉。优化方案是“视口裁剪”只绘制当前窗口可见范围内的格子区间。int visibleColStart Math.max(0, (cameraX - 50) / tileSize); int visibleColEnd Math.min(map[0].length - 1, (cameraX viewportWidth) / tileSize 1); int visibleRowStart Math.max(0, (cameraY - 50) / tileSize); int visibleRowEnd Math.min(map.length - 1, (cameraY viewportHeight) / tileSize 1);配合一个简单的cameraX、cameraY跟随角色移动角色走在大型迷宫中时画面只渲染视野内的格子帧率根本不会随着地图规模变大而崩。这个裁剪逻辑不复杂但收益极大大尺寸迷宫配上它才算真正能玩。6.3 一个必须说的小技巧地图哈希与关卡配置分离我把关卡配置做成了文本文件格式每行表示一格字符映射到不同地形#是墙、空格是地面、P是玩家、S是可推动石头、T是目标凹陷、E是出口。新加一关只需要改文本文件不用改Java代码。这里劝一句如果你要把做好的项目当作业交上去关卡配置用外部文本文件是加分项但要注意交付时一并打包配置文件否则换台电脑运行直接报错说找不到关卡文件。我一般建议文本内嵌成resource这样不会丢。7. 扩展方向与个人复盘石头迷阵做完之后回头审视自己写的代码有几个地方是我觉得如果重做一遍会更完善的一是角色和推石头逻辑目前全部写在主类的tryMove里代码行数虽然不多但和渲染、生成逻辑耦合度偏高如果想要更多玩法扩展需要拆成独立的GameState类二是目前没有独立的音效模块推石头成功、通关这两个关键反馈点没有音效感官体验少了半口气三是石头和出口的联动还比较死目前是所有凹陷占位后出口才解锁如果做成“石头进入指定凹陷才会触发对应出口”关卡设计的可能性会更大。对于想在这个项目基础上接着做点什么的朋友我觉得有三个方向值得考虑。第一个是做成关卡编辑器玩家可以在图形界面里自己画地图、摆石头、定目标然后保存成关卡文件继续玩这比写死地图有意思得多第二个是加一个游戏内计时和步数排行榜配上简单的序列化存档能让游戏有反复挑战的欲望第三个是把渲染层换成JavaFX或者封装一个简单的API接口让核心的迷宫生成和推石头逻辑可以被Web前端或者移动端复用——这也是很多人在改编游戏时的经典做法。最后说一点我的真实体会。这种小游戏项目最锻炼人的地方不是算法本身而是“从能跑到玩得上手”的那段路。迷宫生成算法网上到处都有拷贝下来跑通不算本事难的是让玩家在49步的时候推那块石头时不觉得卡手、按快捷键时有即时反馈、踩进死角时有重置的出口。石头迷阵玩到今天每一次改动的成就感都来自这些看不见的小细节。希望这篇分享也能让你的石头迷阵走得更远。