不少刚把 Java 基础语法啃完的同学都会陷入一个很尴尬的阶段循环、数组、集合、异常都学了但每次打开 IDE 都不知道能做个什么像样的东西。控制台里打印一百遍“Hello World”显然没意思。我当年的解法就是写一个拼图小游戏用 Java Swing 做界面把一张完整图片切成格子打乱之后再靠点击或者键盘方向键一步步还原。这个项目做完之后我对事件监听、二维数组、图像处理、定时器这些知识点的理解完全不一样了——原来它们不是孤立的语法点而是可以串成一个完整程序的一块块积木。这篇文章不是把完整代码甩给你而是把我拆解这个“Java 拼图小游戏”的全过程、设计思路和踩坑记录整理出来。适合刚学完 Java 基础、想做第一个 GUI 项目的初学者也适合带学生做课程设计的开发者参考。我会把“为什么这么设计”也讲清楚毕竟光把代码跑起来容易跑起来之后还能知道每一步在干什么、踩了坑知道去哪查才是这个项目最大的价值。1. 为什么用 Java Swing 写拼图小游戏这个项目到底在练什么第一次听到“用 Java 做一个拼图游戏”这个题目时我第一反应是“这有什么难的”结果真动起手来才发现它比我预期的要复杂得多。这里说的拼图不是那种把碎片一块块拖到正确位置的自由拼图而是经典的 3x3 或 4x4 滑动拼图一张图片被切成 N x N 的小方块其中有一个空白格玩家通过点击空白格周围的方块或使用键盘方向键让方块滑动到空白位置直到整张图片恢复原状。1.1 这个难度档位对新手刚刚好如果做计算器逻辑太简单很快就没有动力如果做俄罗斯方块或贪吃蛇又涉及复杂的碰撞检测和动态刷新对刚学完基础语法的人来说容易劝退。滑动拼图的难度恰好卡在中间你需要处理图像切割、按钮布局、事件响应、游戏状态判断和计时计步每一项都能在标准库中找到对应工具不需要引入任何第三方依赖也不用配置复杂环境。做这个项目时你会用到这些 Java 基础知识点二维数组用来存储拼图当前每个格子的正确编号和空白格位置异常处理读取图片文件时处理 IOException集合与数组操作打乱数组、遍历比较事件监听ActionListener 处理点击KeyListener 处理键盘方向键Swing 组件JFrame、JPanel、JButton、JLabel、Timer图像处理BufferedImage、ImageIO、ImageIcon这种“一个项目把所有知识点串起来”的感觉是刷一百道语法练习题都替代不了的。写完之后你会突然发现原来控制台程序和图形界面程序最大的区别不是代码量而是你开始思考“数据模型”和“界面展示”这两件事了。1.2 先明确成品长什么样我当时的成品大致是这样一个 600x600 的窗口中间是拼图区底部是信息面板显示当前步数和已用时间。图片是一张自己裁成正方形的风景照切成 3x3 后右下角位置留空。点击某个方块时只有它和空白格相邻才能移动否则程序要忽略这次点击。上方还有一个“重新开始”按钮点击后自动打乱图片并重置计时。这里有一个很关键的设计决策不要刚上来就追求 4x4、5x5 或者支持换图。先把 3x3 跑通再慢慢加功能。我第一次写的时候一上来就想做动态难度选择结果图像切割和界面布局耦合在一起出了 bug 都不知道是图像的锅还是布局的锅。后来老老实实把功能拆开一个模块一个模块地完成反而顺利得多。2. 动手前想清楚拼图游戏的数据模型到底是什么很多新手写 GUI 程序最容易犯的错误就是一上来就疯狂堆界面代码把业务逻辑也写在按钮的监听器里。比如点击一个方块后直接在监听器里判断是不是相邻、交换图标、更新标签。这样写也不是不能跑但程序稍微变复杂一点代码就会乱成一团。我建议在写界面之前先设计一个独立的数据模型类。拼图游戏的核心说白了就是维护一个 N x N 的二维数组——不要管界面上显示了什么图片先想清楚数组里的每个数字代表什么意思。2.1 用一维还是二维数组我最初用的是二维数组int[][] board因为拼图本身是一个网格用二维数组天然匹配行列坐标。数组中的每个值表示一个方块编号比如 1 到 8 是正常方块0 代表空白格。目标状态就是1 2 3 4 5 6 7 8 0二维数组最大的好处是根据行列board[row][col]就能直接知道这个位置放的是哪个编号的方块逻辑非常直观。坏处是要同时维护两个下标。我自己实测下来3x3、4x4 这种规模二维数组完全够用不要为了“秀操作”强行改用一维数组。为了方便找到空白格我在模型中维护了两个成员变量zeroRow和zeroCol每次移动后同步更新。这样判断“某个位置是否和空白相邻”就非常高效。2.2 核心的移动逻辑模型的移动方法也是整个游戏的核心入口。先找到空白格坐标然后判断用户点击的位置是不是空白格上下左右四个邻居之一。如果是就把两个格子的值交换更新空白格坐标移动步数加一返回 true否则返回 false。public boolean move(int row, int col) { if (row 0 || row size || col 0 || col size) { return false; } if (Math.abs(row - zeroRow) Math.abs(col - zeroCol) 1) { board[zeroRow][zeroCol] board[row][col]; board[row][col] 0; zeroRow row; zeroCol col; moveCount; return true; } return false; }这里用Math.abs(row - zeroRow) Math.abs(col - zeroCol) 1来判断相邻是我后来才注意到的细节。一开始我是分别判断row zeroRow col zeroCol - 1这种四个方向代码又长又容易漏掉边界。改用曼哈顿距离之后一行就搞定了而且不会有重复判断。2.3 界面只负责展示不要直接改数据有了模型之后界面层就变得很单纯JFrame 负责窗口JPanel 用 GridLayout 排布按钮JButton 负责显示每个方块当前的图标。点击按钮时监听器只需要做三件事根据按钮位置调用model.move(row, col)如果移动成功就刷新按钮上的图标再更新步数和时间标签。这种“模型和界面分离”的做法也许在专业人士眼里谈不上真正的 MVC但对一个入门项目来说已经是巨大的进步了。好处非常明显我可以在完全不打开窗口的情况下用命令测试模型的移动逻辑也可以把同一个模型同时挂在命令行版本和图形界面版本上改动量很小。3. 图像加载与切割像素级处理里容易翻车的地方数据模型设计好了接下来才是这个项目最吸引人的部分——把一张完整图片切割成 N x N 份显示在按钮上。这一步我第一次做的时候踩了整整一个晚上的坑后来总结下来其实就三个关键字加载、切割、类型。3.1 加载图片IO 路径问题使用ImageIO.read()读取图片时最常见的坑就是路径。初学者喜欢直接写new File(puzzle.png)但这样依赖程序的启动目录换个环境或者打成 jar 包就找不到文件了。我建议把图片放在resources目录下用类路径加载。InputStream in PuzzleGame.class.getResourceAsStream(/images/puzzle.jpg); BufferedImage original ImageIO.read(in);用getResourceAsStream是相对稳妥的做法不管从 IDE 启动、命令行启动还是打包运行都能正确找到图片。当然如果图片非常大读取后要占用不少内存建议控制在几 MB 以内。3.2 先把图片裁成正方形再切割拼图的展示区域通常是正方形但用户提供的图片可能是任意比例。如果直接把一张竖版照片强行切成 3x3 再塞进正方形按钮里会发现图片被拉伸得惨不忍睹。我采取的方案是先对原始图片做中心裁剪取一个最大的正方形区域然后再把这个正方形等分成 N x N 个小方块。private static BufferedImage cropCenterSquare(BufferedImage src) { int width src.getWidth(); int height src.getHeight(); int side Math.min(width, height); int x (width - side) / 2; int y (height - side) / 2; return src.getSubimage(x, y, side, side); }getSubimage方法是BufferedImage自带的非常方便。但需要注意它返回的子图像和原图共享数据缓冲区也就是说如果你后续修改了原图子图内容也会跟着变。如果只是展示、不修改问题不大如果想彻底切断关联最稳妥的做法是再画到一张新的BufferedImage上。我后来做裁剪时都是这么处理的拿到子图后立刻创建一张同样大小的TYPE_INT_RGB图像用Graphics2D把子图画进去再释放资源。虽然多写几行代码但后续做缩放、滤镜或者二次切割时完全不用担心“改一个图所有图都变”的问题。3.3 切割成小方块并生成图标接下来就是核心的切割循环。假设图片边长为side每个小方块的边长就是side / size。从 (i, j) 位置切割起点坐标是j * pieceSize和i * pieceSize宽度和高度都是pieceSize。这里要千万注意坐标顺序先横向后纵还是先纵后横各写各的容易乱。for (int i 0; i size; i) { for (int j 0; j size; j) { BufferedImage piece cropped.getSubimage( j * pieceSize, i * pieceSize, pieceSize, pieceSize ); ImageIcon icon new ImageIcon(piece); buttons[i][j].setIcon(icon); } }切图时还有一个容易忽视的细节拼图的每个格子之间会有一两条像素的边框。如果你直接切割成长宽完全一样的方块再给每个按钮设置一个Border视觉上图片就像被描边了一样虽然细看并不难看但处女座同事看了会很难受。我当时用BorderFactory.createLineBorder(Color.DARK_GRAY, 1)统一加了一条细边框整体看起来反而像金属相框也算是歪打正着。空白格那个按钮不需要图标。为了让它看起来真的是“空”的我设置了一个空白ImageIcon或者干脆用setText()配合背景色和边框。我最开始直接把那个按钮设为不可见结果布局塌了因为你把按钮隐藏后 GridLayout 不会给它留位置整个图片会错位一半——这个坑后面会细说。4. 打乱算法与可解性为什么随机交换会生成永远还原不了的拼图很多人做到切图这一步会觉得已经大功告成接下来只要把方块的图标随机分配就能玩了。如果你也这么想那你早晚会遇到一个让人头皮发麻的局面拼图玩到最后只剩一两步但怎么点击都还原不了。这不是你手残而是初始状态本身就是一个“无解拼图”。为了让这个道理更容易理解我们先忘掉图片只看方块编号。在滑动拼图里移动方块时其实是在交换空白格和相邻格子里的数字。如果你的打乱方式是直接把所有数字随机洗牌那么生成的排列大约有一半的情况是永远无法通过合法移动还原的。4.1 逆序数判断法为什么有的排列无解这里要引入一个概念叫“逆序数”。忽略空白格把拼图展开成一维数组统计每一个数后面有多少个比它小的数这些数量加在一起就是逆序数。比如排列 1, 2, 3, 4, 5, 6, 8, 7其中 8 的后面有一个 7 比它小所以逆序数是 1奇数。拼图可解性判断的规则是当拼图列数为奇数比如 3x3时逆序数必须是偶数才能还原。当拼图列数为偶数比如 4x4时需要把空白格从下往上数的行号也考虑进去当“逆序数的奇偶性”和“空白格从底部数行号的奇偶性”相反时才可解。这个判断规则的原理其实不复杂每一次水平移动方块不改变逆序数的奇偶性每一次垂直移动方块因为方块跨过了一行偶数列时跨过奇数个数字逆序数的奇偶性会发生翻转。但垂直移动同时也会改变空白格所在行的奇偶性两者正好抵消所以“逆序数 空白格行号”的奇偶性在整个游戏过程中保持不变。目标状态是偶数逆序所以起点状态必须落在和它同奇偶性的那一半里。写一个简单的检测方法public static boolean isSolvable(int[][] board, int size) { int[] flat new int[size * size]; int k 0; for (int[] row : board) { for (int num : row) { flat[k] num; } } int inversions 0; for (int i 0; i flat.length; i) { if (flat[i] 0) continue; for (int j i 1; j flat.length; j) { if (flat[j] ! 0 flat[i] flat[j]) { inversions; } } } if (size % 2 1) { return inversions % 2 0; } int zeroIndex 0; for (int i 0; i flat.length; i) { if (flat[i] 0) { zeroIndex i; break; } } int blankRowFromBottom size - zeroIndex / size; return (inversions blankRowFromBottom) % 2 1; // 奇偶性相反 }如果你不确定这段规则完全可以直接用“从目标状态倒着打乱”的方式绕开逆序数判断。这也是我推荐给大多数人的做法。4.2 更稳妥的打乱方式从目标状态反向随机移动与其生成一个随机排列再判断它是否可解不如直接从完成状态开始模拟若干次合法的空白格移动。这样天然保证初始状态一定可解连逆序数判断都可以省略。具体做法是先把二维数组恢复成目标状态让空白格在数组里随机向上下左右四个方向移动移动多少次由难度决定。比如 3x3 打乱 100 次4x4 打乱 200 次打乱次数越多局面越接近“完全随机”。public void shuffle() { Random random new Random(); int steps size * size * 30; int lastDir -1; int[][] dirs {{-1,0},{1,0},{0,-1},{0,1}}; for (int i 0; i steps; i) { int dir random.nextInt(4); int nr zeroRow dirs[dir][0]; int nc zeroCol dirs[dir][1]; if (nr 0 nr size nc 0 nc size) { move(nr, nc); } } }有一个细节值得注意如果上一步空白格向右移动下一步随机到了向左那空白格就会来回“抖动”打乱效率很低。我当时加了一个lastDir记录上一次移动的方向随机时排除反向这样打乱后的局面看起来更“散”不会出现好几块方块明显还是连在一起的情况。两种打乱方式的对比方式是否保证可解实现复杂度适用场景随机交换所有方块编号否需要逆序数判断低想顺便学习可解性原理从目标状态随机移动空白格是天然可解低推荐直接上线无风险我当时是先用“随机交换 逆序数判断”写了一遍为了验证算法又写了个测试把所有排列跑了一遍后来发现实际游戏里用“随机移动空白格”更省心。两套逻辑都保留在代码里平时用第二种测试时用第一种检查输出。5. 事件监听与坐标换算点击和键盘方向键如何接入同一个逻辑游戏能不能“玩起来”关键就在事件监听这一环。按钮点击、键盘方向键本质上是两套输入方式但它们最终都要落到同一个动作上让某个方块和空白格交换位置。5.1 点击按钮时的坐标换算JButton 的点击事件回调中你只能拿到被点击的按钮对象拿不到它的“行列坐标”。新手第一反应是给每个按钮单独 new 一个监听器在匿名内部类里把行和列写死。这样做确实能运行但如果有 16 个按钮就要写 16 份几乎一样的代码非常蠢。更聪明的做法是用一个按钮二维数组保存按钮引用点击事件里用getSource()判断是谁触发了然后在二维数组里遍历找到这个按钮在数组中的位置。遍历虽然多写几层循环但对 N 最大只有 5 的拼图来说性能毫无压力。public void actionPerformed(ActionEvent e) { Object source e.getSource(); for (int i 0; i size; i) { for (int j 0; j size; j) { if (buttons[i][j] source) { if (model.move(i, j)) { updateUI(); } return; } } } }这个方法简单不过我后来发现一个更优雅的变体用一个一维数组JButton[] buttons按顺序存放所有按钮点击后通过索引index / size和index % size直接算出行列避免了双层循环里的引用比较。一维数组的好处是索引和下标的换算非常快而且代码少。你可以选自己喜欢的方式。5.2 点击后界面怎么刷新移动成功后最直觉的做法是把整个面板重新创建一遍所有按钮重新添加图标重新设置。我一开始就这么干结果发现界面会轻微闪烁虽然不至于闪瞎眼但体验很糟糕。后来改成“只更新受影响的两个格子”记录移动前空白格的位置和移动后方块的新位置然后分别更新这两个按钮的图标。这样既不用重建面板也让界面刷新量降到最低。public void updateUI() { for (int i 0; i size; i) { for (int j 0; j size; j) { int value board[i][j]; if (value 0) { buttons[i][j].setIcon(emptyIcon); } else { buttons[i][j].setIcon(icons[value]); } } } moveLabel.setText(步数 model.getMoveCount()); }说实话3x3 规模下全量刷新和局部刷新的速度差异肉眼看不出来。但养成“只更新需要更新的部分”这个习惯对以后做角色动画、游戏循环、实时数据大屏都有帮助。5.3 键盘事件方向键还是点击顺手鼠标点击虽然直观但很多玩家其实更喜欢用键盘方向键操作。监听键盘事件时注意方向键表达的是“想要空白格移动的方向”。比如用户按了向上的方向键意思是“让空白格向上移动一格”也就是把空白格上方的方块移下来。public void keyPressed(KeyEvent e) { int newRow zeroRow; int newCol zeroCol; if (e.getKeyCode() KeyEvent.VK_UP) newRow--; else if (e.getKeyCode() KeyEvent.VK_DOWN) newRow; else if (e.getKeyCode() KeyEvent.VK_LEFT) newCol--; else if (e.getKeyCode() KeyEvent.VK_RIGHT) newCol; else return; if (model.move(newRow, newCol)) { updateUI(); } }把方向键转换为newRow和newCol之后直接复用同一个model.move()方法——这就是模型和界面分离带来的好处输入设备再怎么变核心逻辑纹丝不动。5.4 键盘监听最大的坑焦点如果你写好 KeyListener 却发现按方向键没反应不用怀疑代码逻辑先检查窗口有没有获得焦点。JFrame 默认的焦点不一定在窗口本身所以需要在窗口显示时调用setFocusable(true)和requestFocusInWindow()。否则你的 KeyListener 像在跟空气说话。我在代码里是这么解决的主窗口初始化完成后立刻调用frame.setFocusable(true)并且加了一个窗口点击事件frame.addMouseListener每次鼠标点击窗口时也requestFocusInWindow()。这样无论玩家之前点击了按钮还是其他地方再按方向键都能恢复响应。如果你觉得 KeyListener 加焦点处理太麻烦Swing 还提供了InputMap和ActionMap的键盘绑定机制它能直接把某个按键和某个 Action 关联起来并且不需要手动管理焦点。对于这个拼图项目KeyListener 完全够用如果你将来做 Swing 游戏可以再深入研究键盘绑定。6. 计时、计步和胜利判定把游戏状态真正“管”起来拼图本身能移动之后游戏就算完成了一大半。但真正让它像“一个正经游戏”的是计步、计时和胜利判定这三件套。这三者听起来简单真正写起来也有一些细节容易出错。6.1 胜利判定比较数组而不是比较图片每次移动后判断“是否完成”最简单的方法是写一个目标数组targetBoard然后逐个元素比较当前board和它是否相等。public boolean isWin() { int expected 1; for (int i 0; i size; i) { for (int j 0; j size; j) { // 最后一个是 0 前面依次递增 if (i size - 1 j size - 1) { if (board[i][j] ! 0) return false; } else if (board[i][j] ! expected) { return false; } expected; } } return true; }有一个容易出错的点是很多同学把胜利判定写成“每个按钮上的编号等于它的索引”然后拿当前按钮图标和目标图片图标对比。对比图标也没错但每次都要调用icon.equals(icon)效率又低又容易受空图标干扰。比较数组是更好的选择因为数组是内存里的整数比较一行循环就完成。图标只是给人看的判断逻辑应该始终依托数据。6.2 计步九九乘法表式的错误计步逻辑一句话就能说清每次model.move()返回 true 时moveCount。但要注意的是moveCount是模型的状态而不是界面临时变量。如果把它定义在监听器里重新开始游戏时很容易漏掉重置。正确的做法是把它放在PuzzleModel类里和board一起维护。重新开始的时候调用moveCount 0界面同步把标签清零。还有一点无效点击不要计步。如果玩家点了一个和空白格不相邻的方块move()返回 false这时步数不能加。这个问题我在第一版实现里就踩了玩家可以乱点半天步数涨到天上游戏体验直接归零。6.3 计时不要用 Thread.sleep实现计时功能时最不能做的事情是在while (true)循环里Thread.sleep(1000)然后更新标签。这会阻塞事件分发线程界面会直接卡死玩家连点击按钮都做不到就像整个程序被冻住了。Swing 提供了javax.swing.Timer它会在事件分发线程中定期触发ActionListener非常适合做这种轻量级定时刷新。Timer timer new Timer(1000, e - { second; timeLabel.setText(时间 format(second)); }); timer.start();它的底层和Thread.sleep完全不同Timer每次触发时事件队列里还有机会处理鼠标点击和键盘事件。这就像餐厅里请了一个专门的服务员每秒钟报一次时间而不是让老板亲自站在大厅里喊“几点了”客人再怎么点菜他都没空搭理。计时器的生命周期也要好好管理点击“重新开始”时先timer.stop()重置秒数后再timer.start()胜利时也要timer.stop()否则对话框弹出来之后底层时间还在悄悄走。6.4 胜利弹窗与状态锁当isWin()返回 true 时先停表再弹出一个对话框提示“恭喜完成”并显示步数和用时。这里有一个小细节提示弹窗出现后玩家有可能继续点击拼图区域导致已经停止的计时器被重新触发或者界面状态错乱。稳妥的做法是维护一个boolean finished标志位一旦游戏结束move()方法直接拒绝后续移动。public void setFinished(boolean finished) { this.finished finished; } public boolean move(int row, int col) { if (finished) return false; ... }这个“状态锁”的思想虽然简单但很重要。很多新手写到游戏结束就完了没想到玩家还会继续乱点结果出现“已经赢了但还能移动图片”的诡异状态。任何游戏都需要在开始时想清楚游戏状态一共有几个状态之间怎么切换当前状态下哪些动作是被禁止的。7. 实测中踩过的坑以及我后来做的小扩展项目做到这里已经能完整玩起来了。但我还是想把这几天实测过程中踩过的坑列出来这些坑你大概率也会遇到。7.1 坑一getSubimage 出来的图片发黑第一次切割图片时我直接把getSubimage的结果交给ImageIcon结果界面上有些方块显示正常有些黑乎乎一片。排查了很久才发现原始图片类型是TYPE_INT_ARGB而一部分子图因为透明度通道的处理问题在绘制到不透明按钮上时出现了黑色背景。解决办法很简单不要直接用子图自己绘制一张新的TYPE_INT_RGB图像再把子图画进去。这样图像的色彩模式能被完全控制。BufferedImage copy new BufferedImage( pieceSize, pieceSize, BufferedImage.TYPE_INT_RGB ); Graphics2D g2d copy.createGraphics(); g2d.drawImage(piece, 0, 0, null); g2d.dispose();7.2 坑二隐藏空白按钮导致排版错乱前面说过为了做空白格我把那个按钮直接setVisible(false)结果 GridLayout 里那个位置塌陷了整张图被分成两半错开。后来改成保留按钮但用透明背景和空白图标代替。记住布局管理器关心的是“有没有组件”而不是“组件是否可见”。隐藏组件和移除组件在多数布局管理器里效果一样都会触发重新布局。我这边的空白按钮处理方法是保留按钮设置setIcon(emptyIcon)同时把它的背景色设成和面板底色一致边框设成浅灰色。这样看起来就像缺了一块实际上组件还在布局不会被破坏。7.3 坑三键盘方向键偶尔失灵有一次我发现刚启动程序时键盘明明能控制拼图但随便点击几下按钮之后方向键就完全没反应了。原因是点击按钮后焦点从 JFrame 跑到 JButton 上去了而 KeyListener 是加在 JFrame 上的焦点一丢监听自然失效。解决方式是给主窗口注册鼠标监听器每次点击窗口时重新requestFocusInWindow()。另外也可以给按钮设置setFocusable(false)让按钮永远不能抢走焦点。这个方法更彻底不仅解决了拼图的键盘问题以后做任何 Swing 游戏都能借鉴。7.4 后来加的扩展换图与难度选择基础版做完之后我又加了一个“更换图片”的功能点击按钮后弹出JFileChooser选择本地图片重新切割并打乱。这里有个细节替换图片时一定要先把旧的ImageIcon全部释放否则内存里会同时存在大量图片长时间运行会有卡顿感。难度选择也顺势加上了用一个JComboBox列出“简单3x3”“普通4x4”“困难5x5”。切换难度时动态改变数组大小和按钮数量重新初始化模型。这个功能本身不难但它强迫我把原来写死的size 3全部改成动态参数代码的复用性一下就上来了。如果还想更进一步可以把每位玩家的最佳成绩存到本地文件里用 Properties 或 JSON 格式记录“最少步数”和“最短用时”下次启动时读取显示。这一步能练到文件读写和字符串格式化也是很有价值的扩展。最后说点自己的体会做完这个拼图小游戏我最深的感受是代码结构真的是“先想清楚再写”比“写完再重构”省太多事。如果我一上来就把数据、界面、事件全部揉在一起后面加换图、加难度选择、加键盘控制这些功能时每一个改动都可能引发连锁性的 bug。而当我先把PuzzleModel的接口稳定下来绝大部分新增功能都只是在“界面层”做文章模型层几乎不动。给还在做这个项目的你一个测试建议开发阶段把打乱次数调小一点比如 3x3 只打乱 20 次这样方便手动验证各种边界情况等到界面和逻辑都稳定了再把打乱步数恢复到 100 次以上。不然每次重新开始都想解半天调 bug 的耐心一下就磨没了。还有别总想着憋一个大版本先把最基础的 3x3 跑通、发到群里让朋友玩一下收到真实反馈之后再考虑怎么加功能。一个小游戏都值得用“小步快跑”的方式来做这就是我这次项目最大的收获。