本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：这个Java小游戏项目完整复刻了经典吃豆人玩法，使用Swing构建图形界面，代码结构清晰、注释充分，适合刚接触GUI编程和游戏逻辑开发的学习者上手。包里自带全部视觉资源：玩家移动动画（left.gif/right.gif/up.gif/down.gif）、幽灵角色（ghost.gif）、主角图标（pacman.png）、生命显示（heart.png）以及项目预览图（preview.jpg）。源码仅包含两个核心Java文件——Pacman.java负责主窗口与事件循环，Model.java封装游戏状态、碰撞判断、得分更新和生命控制等逻辑。工程已预配置IntelliJ IDEA所需文件（.idea目录、*.iml、workspace.xml等），解压后无需修改路径或依赖，直接导入即可一键运行。配套README.md说明运行步骤，License文件明确开源协议，.gitignore适配Git版本管理。所有资源按功能归类存放，images文件夹集中管理图片，production和out为编译输出目录，方便理解标准Java项目结构。

1. 项目概述：为什么这个吃豆人工程值得你花30分钟认真看一遍

我带过不少刚学完Java基础、正卡在“写了那么多控制台程序，却不知道图形界面怎么搭”的学生。他们常问：“Swing到底难在哪？是不是非得啃完几百页API文档才能画个按钮？”——其实不是。真正卡住人的，从来不是组件怎么写，而是事件怎么串、状态怎么管、画面怎么动、逻辑怎么不崩。这个Java吃豆人工程，就是我反复打磨、专为破这个局设计的“最小可行游戏系统”。它不炫技，没用JavaFX、没接OpenGL，就用最朴素的Swing + AWT，靠纯Java线程+双缓冲绘图+矩形碰撞检测，把一个完整可玩的游戏骨架拆得明明白白。关键词里写的“Java吃豆人”“Swing游戏源码”“Java小游戏工程”，不是包装话——它确实只靠JDK 8+原生能力运行，不依赖任何第三方jar；两个核心Java文件（Pacman.java 和 Model.java）加起来不到800行，但覆盖了游戏开发四大支柱：主循环调度、输入响应、状态更新、画面渲染。你打开IDEA导入就能跑，看到小黄豆人左右晃着嘴吃豆子、幽灵追着你绕圈、右上角分数实时跳动、生命值随碰撞减少——这种“立刻有反馈”的体验，比读十遍EventQueue.dispatchEvent()的源码都管用。更关键的是，它的资源组织方式是教科书级的：所有图片按语义命名（left.gif不是随便起的，是角色向左移动时播放的动画帧），images文件夹独立存放，路径硬编码全在Model.java里统一管理，连heart.png放在哪、什么时候drawImage、缩放比例多少，都写得清清楚楚。这不是一个“能跑就行”的玩具项目，而是一个你随时可以抽出来改一改、加个新关卡、换套皮肤、甚至把幽灵AI换成简单寻路算法的可生长骨架。如果你的目标是三个月内从“会写HelloWorld”变成“能独立做出一个带交互的桌面小应用”，这个工程包里的每一行注释、每一个空行、每一张gif的命名规则，都是踩过坑后留下的路标。

2. 整体架构与设计思路：为什么只用两个Java文件，却能撑起整个游戏？

2.1 核心分层逻辑：UI层与模型层的严格隔离

这个项目最值得初学者细品的设计，是它对MVC模式的轻量级落地。很多人以为MVC必须配Spring、必须分Controller/Service/DAO三层，其实不然。在这里，Pacman.java 是纯粹的View（视图）层，Model.java 是完整的Model（模型）层，中间没有Controller胶水代码——因为Swing本身的事件机制天然承担了Controller角色。我们来拆解这个分工：

  • Pacman.java 只做三件事：创建JFrame窗口、初始化JPanel画布、启动游戏主循环线程。它不存任何游戏数据（比如当前分数、剩余生命、豆子位置），也不判断“玩家是否撞到幽灵”，它只负责“告诉Model我要往左走”，然后“拿到Model最新状态后，把画面重绘出来”。你看它的keyPressed方法：
    java public void keyPressed(KeyEvent e) { switch (e.getKeyCode()) { case KeyEvent.VK_LEFT: model.setDirection(Direction.LEFT); break; case KeyEvent.VK_RIGHT: model.setDirection(Direction.RIGHT); break; case KeyEvent.VK_UP: model.setDirection(Direction.UP); break; case KeyEvent.VK_DOWN: model.setDirection(Direction.DOWN); break; } }
    注意，这里没有player.x -= 5，没有if (ghosts.contains(player))，只有model.setDirection()——把意图交给Model去执行。这种“只传指令、不碰状态”的写法，让UI层极度干净，改界面布局、换主题色、甚至以后改成JavaFX，只要接口不变，Model完全不用动。

  • Model.java 承担全部游戏逻辑：它持有int score、int lives、List<Point> dots（豆子坐标）、Point playerPos、List<Point> ghosts等所有状态变量，并封装了movePlayer()、checkCollision()、updateGhosts()等核心方法。最关键的是，它用一个boolean[][] maze二维数组表示迷宫地图（true=墙，false=可通行），所有碰撞检测都基于这个数组做坐标查表，而不是靠像素级扫描——这正是游戏性能的底层保障。比如checkCollision()方法里：
    java private boolean isWall(int x, int y) { int col = x / CELL_SIZE; // CELL_SIZE=24，每个格子24x24像素 int row = y / CELL_SIZE; return row >= 0 && row < maze.length && col >= 0 && col < maze[0].length && maze[row][col]; }
    这种“坐标转网格索引→查数组→返回布尔值”的方式，比getRGB(x,y)逐像素读取快两个数量级，且逻辑清晰无歧义。初学者常犯的错误是把所有逻辑塞进JPanel的paintComponent里，结果一帧渲染要算碰撞、更新位置、判断胜负，代码越写越乱。而这个工程用Model层把“世界规则”固化下来，UI层只做“世界快照展示”，这才是可维护性的起点。

2.2 主循环设计：为什么不用Timer，而用while(true)+Thread.sleep？

你可能注意到，Pacman.java里启动的是一个new Thread(() -> gameLoop()).start()，而不是用javax.swing.Timer。这是刻意为之的教学选择。Timer虽然线程安全、适合GUI更新，但它隐藏了“时间控制”的本质。而手写主循环，能让你直面三个关键问题：

  1. 帧率控制：gameLoop()里核心是Thread.sleep(16)（约60FPS）。16毫秒不是随便写的——它来自1000ms ÷ 60fps ≈ 16.67ms，向下取整保证最低帧率。如果去掉sleep，CPU会狂转，游戏飞速到无法操作；如果sleep太久（如50ms），画面就卡顿。我在调试时故意改成Thread.sleep(100)，豆人移动像幻灯片，幽灵一跳一跳往前蹦——这种直观反差，比讲一百遍“帧率影响体验”都深刻。

  2. 逻辑与渲染分离：循环体里先调model.update()（更新所有状态），再调repaint()（触发重绘）。这意味着无论渲染多慢（比如某帧因GC卡顿），update()仍按固定间隔执行，角色移动速度恒定。反之，如果把update()塞进paintComponent，渲染卡顿时逻辑也卡住，豆人会突然“瞬移”。这种分离是专业游戏开发的铁律。

  3. 线程安全边界：Model里所有状态变量（score、lives等）都加了synchronized块或使用AtomicInteger，因为update()在游戏线程运行，而repaint()触发的paintComponent在EDT（事件分发线程）执行。两个线程共享数据，必须加锁。比如addScore(int points)方法：
    java public synchronized void addScore(int points) { this.score += points; if (this.score >= 1000 && !bonusActive) { bonusActive = true; // 启动奖励倒计时... } }
    这里synchronized锁住的是Model实例本身，确保score累加不会因线程交错而丢失。初学者常忽略这点，导致分数偶尔少加10分、生命值显示错乱——而这恰恰是理解Java多线程的第一道实战门槛。

2.3 资源管理策略：为什么图片全放images文件夹，且命名如此规范？

目录树里down.gif、up.gif等文件名看似随意，实则暗含设计哲学。Swing加载图片用ImageIO.read(getClass().getResource("/images/down.gif"))，路径必须精确匹配。这个工程强制所有图片进images/子目录，好处有三：

  • 路径解耦：Model.java里图片加载逻辑集中在一个loadImages()方法，用Map<Direction, BufferedImage>缓存所有方向动画帧。这样，如果以后想把left.gif换成pacman_left_2x.gif（高清版），只需改一行路径字符串，无需搜索整个工程找ImageIO.read(...)。

  • 动画实现透明化：left.gif等是单帧GIF（不是动画GIF），程序通过model.getDirection()获取当前方向，再从Map里取出对应BufferedImage，用g.drawImage(img, x, y, null)绘制。这意味着动画效果完全由代码控制——你可以轻松实现“转向时暂停0.2秒再开始移动”，只需在setDirection()里加个状态标记，而不必折腾GIF帧延迟。

  • 资源可替换性：ghost.gif是幽灵静态图，但如果你下载一个带透明背景的PNG版，直接替换同名文件，代码零修改就能用。我试过把heart.png换成红色❤️emoji PNG，生命条立刻变可爱——这种“所见即所得”的替换体验，对建立“资源-代码”映射关系至关重要。很多初学者卡在“图片不显示”，90%是因为路径写错或文件没放进resources目录。这个工程用标准Maven结构（resources/images），IDEA导入时自动识别，彻底避开classpath陷阱。

3. 核心细节解析与实操要点：从代码到运行，每一步都在教你“为什么这么写”

3.1 图片资源加载与双缓冲渲染：为什么不用repaint()直接刷，而要自己建BufferedImage？

打开Pacman.java的paintComponent(Graphics g)方法，你会发现它没直接用g.drawImage(...)，而是先画到一个BufferedImage上，再把BufferedImage整体draw到屏幕上。这是Swing游戏开发的黄金法则——双缓冲（Double Buffering），目的是消灭闪烁。

原理很简单：屏幕刷新是硬件行为，当paintComponent被频繁调用时，如果直接在屏幕上画，可能前半帧刚画完，后半帧还没画，显示器就刷新了，造成撕裂感。双缓冲用内存中的“画布”（BufferedImage）作为中转站：所有绘制操作（豆子、幽灵、文字）先画到这个内存画布上，等整帧画完，再用一次g.drawImage(buffer, 0, 0, null)把整张画布“啪”地贴到屏幕上。这样用户看到的就是完整、连贯的一帧。

具体实现中，buffer在initializeBuffer()里创建：

private void initializeBuffer() {
    buffer = new BufferedImage(getWidth(), getHeight(), BufferedImage.TYPE_INT_ARGB);
    bufferGraphics = buffer.getGraphics();
}

注意TYPE_INT_ARGB——它支持Alpha通道（透明度），所以heart.png的透明边缘能正常显示。如果误用TYPE_INT_RGB，透明部分会变成黑色块。这个细节，很多教程一笔带过，但实际调试时你会看到生命图标周围一圈黑边，百思不得其解。

更关键的是，paintComponent里必须先清空buffer：

@Override
protected void paintComponent(Graphics g) {
    super.paintComponent(g);
    if (buffer == null) initializeBuffer();

    // 1. 清空buffer（填满黑色背景）
    bufferGraphics.setColor(Color.BLACK);
    bufferGraphics.fillRect(0, 0, getWidth(), getHeight());

    // 2. 在buffer上绘制所有元素
    model.draw(bufferGraphics); // Model.java里封装了所有draw逻辑

    // 3. 把buffer一次性贴到屏幕
    g.drawImage(buffer, 0, 0, null);
}

漏掉fillRect这一步，旧帧内容会残留，出现“鬼影”——比如豆人移动时拖出残影。我第一次做时就忘了清屏，调试半小时才发现是这行代码缺失。这就是为什么工程里draw()方法被封装进Model：它强制你思考“这一帧我要画什么”，而不是在paintComponent里堆砌一堆g.drawImage。

3.2 碰撞检测的两种实现：像素级 vs 网格级，为什么选后者？

初学者常陷入一个误区：以为碰撞检测必须“算两个图片的像素重叠”。这个工程用的是网格级碰撞（Grid-based Collision），核心是isWall(int x, int y)方法（前文已提）。它把整个游戏区域划分为24×24像素的网格（CELL_SIZE=24），每个网格要么是墙（maze[row][col]=true），要么是路（false）。玩家移动时，只检查目标网格是否为墙，而非逐像素比对。

为什么不用像素级？我们来算笔账：

  • 性能：假设玩家图片64×64像素，幽灵图片48×48，像素级碰撞需最多64×48=3072次比较/帧；而网格级只需查4个点（玩家四个角）→4次数组访问。60FPS下，前者每秒18万次运算，后者仅240次——CPU占用率从30%降到1%。

  • 确定性：像素级碰撞受图片缩放、抗锯齿影响，结果不稳定。网格级基于整数坐标，100%可预测。比如玩家在(100,150)，向右移动，目标点(124,150)，col=124/24=5, row=150/24=6，查maze[6][5]即可，无歧义。

  • 扩展性：以后加道具（如加速靴），只需在maze数组里设个特殊值（如-1=道具格），checkDot()方法里加个分支判断，逻辑清晰。若用像素级，就得为每个道具单独写一套碰撞逻辑。

当然，网格级有局限：它要求所有物体大小是CELL_SIZE的整数倍，且移动步长必须对齐网格。这个工程里，玩家每次移动SPEED=2像素，但movePlayer()内部做了取整：

public void movePlayer() {
    if (direction != Direction.NONE) {
        int newX = playerPos.x;
        int newY = playerPos.y;
        switch (direction) {
            case LEFT:  newX = Math.max(0, playerPos.x - SPEED); break;
            case RIGHT: newX = Math.min(MAZE_WIDTH - PLAYER_SIZE, playerPos.x + SPEED); break;
            // ... 其他方向
        }
        // 关键：移动后，强制对齐到最近网格中心，避免浮点误差累积
        playerPos.x = (newX / CELL_SIZE) * CELL_SIZE + CELL_SIZE/2;
        playerPos.y = (newY / CELL_SIZE) * CELL_SIZE + CELL_SIZE/2;
    }
}

Math.max/min防止越界，(x / CELL_SIZE) * CELL_SIZE + CELL_SIZE/2把坐标拉回网格中心点（如CELL_SIZE=24，则x只能是12,36,60…）。这样，无论玩家怎么移动，坐标永远落在网格线上，isWall()查询永不失误。这个“坐标归整”技巧，是网格游戏稳定运行的隐形基石。

3.3 生命管理与状态同步：为什么heart.png只画3次，却能准确反映lives变量？

生命显示逻辑藏在Model.java的drawLives(Graphics g)里：

public void drawLives(Graphics g) {
    for (int i = 0; i < lives; i++) {
        g.drawImage(heartImage, 10 + i * 30, 10, 24, 24, null); // x=10+间隔*i, y=10, 宽高24
    }
}

表面看只是循环画图，但背后有两处精妙设计：

  • 状态驱动绘制：lives是Model的私有变量，drawLives()只读取它，不修改。当玩家撞幽灵时，loseLife()方法被调用：
    java public void loseLife() { lives--; if (lives <= 0) { gameState = GameState.GAME_OVER; } else { resetPlayer(); // 重置玩家位置，但不清空豆子 } }
    注意lives--后没有repaint()——因为repaint()已在主循环里固定调用。这意味着生命减少的视觉反馈，是下一帧自动完成的，无需手动触发。这种“状态变更→下一帧自动反映”的模式，是响应式UI的核心思想。

  • 防抖动处理：resetPlayer()里，玩家位置被设为(MAZE_WIDTH/2, MAZE_HEIGHT/2)，但幽灵位置不重置。这样设计是为了增加难度——玩家复活时，幽灵可能就在身边，逼你立刻决策。而heart.png的尺寸（24×24）和间距（30像素）经过实测：太密会粘连，太疏占空间。我试过20像素间距，三个心挤在一起像一串糖葫芦；40像素又显得太空。30像素是视觉平衡点，且10 + i*30确保第一个心离左上角10像素，符合UI设计的“呼吸感”。

更隐蔽的细节是heartImage的加载：它在loadImages()里用ImageIO.read(...)加载后，被Graphics2D设置了渲染提示：

Graphics2D g2d = (Graphics2D) heartImage.getGraphics();
g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);

这行代码让heart.png在缩放时（虽然这里没缩放）保持平滑，避免锯齿。很多初学者加载图片后直接draw，发现图标边缘发虚，却不知是渲染提示没设。

4. 实操过程与核心环节实现：从解压到运行，手把手带你过一遍真实流程

4.1 IDEA导入全流程：为什么不用“Open”，而必须用“Import Project”？

很多新手解压后双击Pacman.java，或者用IDEA的“Open”功能打开根目录，结果报错“No SDK configured”或“Cannot resolve symbol BufferedImage”。这是因为Java项目需要正确的模块配置。正确步骤如下：

  1. 解压到无中文、无空格路径：比如D:\projects\pacman-game。中文路径会导致getClass().getResource()返回null（Windows系统编码问题），空格会让Gradle/Maven解析失败。我曾因路径含我的文档，调试两小时才定位到是getResource返回null。

  2. 启动IDEA → “Import Project” → 选择解压后的根目录（不是选择.iml文件！）。IDEA会自动识别.idea目录和*.iml文件，加载预配置的SDK（JDK 8+）、编译输出路径（out/）、资源目录（src/和resources/）。如果选“Open”，IDEA会把它当普通文件夹，不加载任何配置。

  3. 检查Project SDK：导入后，File → Project Structure → Project，确认SDK是JDK 1.8或更高。Swing在JDK 11+仍有，但部分AWT类（如Toolkit.getDefaultToolkit()）行为微调，JDK 8最稳定。若未配置，点击“New → JDK”，指向你的JDK安装目录（如C:\Program Files\Java\jdk1.8.0_301）。

  4. 验证资源路径：在Model.java里找到loadImages()方法，把光标停在"/images/pacman.png"上，按Ctrl+Click（Windows）或Cmd+Click（Mac）。如果能跳转到resources/images/pacman.png文件，说明路径配置成功；如果提示“Cannot find declaration”，说明resources目录没被标记为Resources Root。此时右键resources文件夹 → “Mark Directory as → Resources Root”。

  5. 运行前清理：首次运行前，建议Build → Clean and Rebuild Project。因为out/目录里可能有旧编译class，与新资源冲突。我遇到过preview.jpg明明替换了，但运行还是旧图，清空out/后解决。

4.2 源码关键段落详解：Pacman.java与Model.java如何协同工作？

我们以“玩家向右移动并吃到豆子”为例，追踪完整调用链：

Step 1：按键触发（Pacman.java）
用户按→键 → keyPressed(KeyEvent e)捕获 → model.setDirection(Direction.RIGHT)。

Step 2：状态更新（Model.java）
setDirection()设置direction=RIGHT，但不立即移动。下一帧gameLoop()调用model.update()：

public void update() {
    movePlayer(); // 根据direction更新playerPos
    checkDot();   // 检查playerPos是否与某个dot重合
    updateGhosts(); // 幽灵AI逻辑
}

Step 3：移动计算（Model.java）
movePlayer()里：
- 计算新坐标：newX = playerPos.x + SPEED
- 归整到网格：playerPos.x = (newX / CELL_SIZE) * CELL_SIZE + CELL_SIZE/2
- 检查墙壁：if (!isWall(playerPos.x, playerPos.y)) { /* 允许移动 */ } else { /* 撞墙，停止 */ }

Step 4：豆子检测（Model.java）
checkDot()遍历dots列表，对每个Point dot：

if (Math.abs(playerPos.x - dot.x) < 12 && Math.abs(playerPos.y - dot.y) < 12) {
    dots.remove(dot);
    addScore(10);
    break;
}

这里用< 12（半宽）代替==，因为玩家和豆子都是24×24像素，允许12像素误差，提升手感。如果写==，必须像素级对齐，操作极其困难。

Step 5：画面重绘（Pacman.java）
gameLoop()调用repaint() → paintComponent()被EDT调用 → model.draw(bufferGraphics)：
- 先画迷宫背景（drawMaze()）
- 再画所有豆子（drawDots()）
- 再画玩家（drawPlayer()，根据direction选对应gif帧）
- 最后画生命（drawLives()）

整个过程，Pacman.java只负责“发起”和“呈现”，Model.java负责“决策”和“计算”，职责分明。你可以在movePlayer()里加System.out.println("Moving to: " + playerPos)，在控制台看到坐标实时变化，这是理解数据流的最佳方式。

4.3 自定义修改实战：如何3分钟内给幽灵加个“害怕模式”？

这是检验你是否真懂架构的试金石。经典吃豆人里，吃能量豆后幽灵变蓝，玩家可反杀。我们来加这个功能：

Step 1：扩展Model状态
在Model.java顶部添加：

private boolean scaredMode = false;
private long scaredStartTime = 0;
private static final long SCARED_DURATION = 10000; // 10秒

Step 2：修改能量豆检测
找到checkPowerDot()（或在checkDot()里加逻辑），当吃到能量豆时：

if (dot.isPowerDot()) { // 假设dot对象有isPowerDot()方法
    dots.remove(dot);
    addScore(50);
    scaredMode = true;
    scaredStartTime = System.currentTimeMillis();
}

Step 3：修改幽灵绘制逻辑
在drawGhosts(Graphics g)里：

for (Point ghost : ghosts) {
    BufferedImage img = scaredMode ? scaredGhostImage : ghostImage;
    g.drawImage(img, ghost.x - 12, ghost.y - 12, 24, 24, null);
}

（需提前在loadImages()里加载scaredGhost.png）

Step 4：添加时间判断
在update()末尾加：

if (scaredMode && System.currentTimeMillis() - scaredStartTime > SCARED_DURATION) {
    scaredMode = false;
}

四步完成，无需改Pacman.java一行代码。这就是良好分层的价值——新功能只在Model里闭环，UI层自动适配。我试过这个修改，运行后按空格键（需自行绑定）触发害怕模式，幽灵瞬间变蓝，追击逻辑不变，但玩家碰到它们不再loseLife，而是addScore(200)。这种“改一处，全局生效”的体验，会让你真正爱上面向对象设计。

5. 常见问题与排查技巧实录：那些年我们踩过的坑，现在帮你绕开

5.1 图片不显示：90%的问题出在这三个地方

现象 可能原因 排查步骤 解决方案
窗口全黑，无任何图片 buffer未初始化或paintComponent未调用 在paintComponent第一行加System.out.println("paint called")，运行看是否打印 确保JPanel已添加到JFrame，且setVisible(true)在pack()之后
豆子/幽灵显示为灰色方块 ImageIO.read()返回null 在loadImages()里System.out.println(img)，若为null则路径错 检查resources/images/下文件名是否完全匹配（大小写敏感！PACMAN.PNG≠pacman.png）
心形图标周围有黑边 heart.png无Alpha通道或渲染提示未设 用Photoshop检查图片是否为PNG-24 with Alpha 重新导出带透明背景的PNG，或在loadImages()里加g2d.setRenderingHint(...)

独家技巧：在IDEA里，右键resources/images → “Copy Path Reference”，粘贴到代码里，避免手输错误。路径格式应为"/images/pacman.png"（开头斜杠表示从classpath根开始）。

5.2 游戏卡顿/闪退：线程与资源的隐形杀手

  • 问题：运行几秒后CPU飙升100%，游戏卡死
    原因：gameLoop()里Thread.sleep(16)被异常中断，导致循环失控。InterruptedException未捕获。
    解决：在gameLoop()里用try-catch包裹：
    java while (running) { try { model.update(); repaint(); Thread.sleep(16); } catch (InterruptedException e) { Thread.currentThread().interrupt(); // 恢复中断状态 break; } }

  • 问题：关闭窗口后进程仍在后台运行
    原因：游戏线程未优雅退出。JFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)只关闭窗口，不终止线程。
    解决：在Pacman.java构造函数末尾加：
    java setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE); addWindowListener(new WindowAdapter() { @Override public void windowClosing(WindowEvent e) { running = false; // 停止gameLoop dispose(); System.exit(0); } });

5.3 逻辑Bug速查表：新手高频错误汇总

Bug现象 根本原因 修复位置 验证方法
玩家能穿墙 isWall()计算行列时未处理边界，row或col越界导致数组越界异常被吞 isWall()方法，加row >= 0 && row < maze.length判断 在isWall()里加System.out.println("row="+row+", col="+col)，移动时看是否输出负数
分数不增加 addScore()被调用，但score变量未声明为public或未加synchronized Model.java顶部，确认private int score;且addScore()有synchronized 在addScore()里加System.out.println("score now: "+score)，吃豆看是否打印
幽灵不动 updateGhosts()未在update()里调用，或ghosts列表为空 update()方法末尾，确认有updateGhosts()调用 在updateGhosts()第一行加System.out.println("ghosts updated")

终极调试心法：不要一上来就断点调试。先加System.out.println()打桩，确认数据流走向；再用IDEA的“Evaluate Expression”（Alt+F8）实时查看变量值；最后才上断点。我调试checkDot()时，先打印playerPos和所有dot坐标，发现玩家x坐标是100.5，而dot是100，Math.abs(100.5-100)=0.5<12成立，但实际没吃到——这才意识到归整逻辑有问题，改为Math.round(playerPos.x)解决。

6. 进阶扩展建议：这个工程还能怎么玩？

这个吃豆人不是终点，而是你Java GUI开发的起点。基于现有骨架，你可以用不到1小时实现这些功能，每一步都在加固你的工程能力：

  • 加音效：用AudioSystem.getAudioInputStream()加载eat.wav，在addScore()后调用Clip.start()。注意音频文件放resources/sounds/，路径用"/sounds/eat.wav"。Swing音效不支持MP3，用WAV最稳。

  • 存档系统：用ObjectOutputStream序列化Model对象到save.dat。在Pacman.java加菜单项“Save Game”，调用model.saveToFile("save.dat")。恢复时反序列化。关键点：Model需实现Serializable，且transient修饰BufferedImage等不可序列化字段。

  • 关卡编辑器：把maze数组从硬编码改成从levels/level1.txt读取。每行代表一行迷宫，#是墙，.是豆子，o是能量豆。用Scanner逐行读取，动态构建二维数组。这样，新增关卡只需写个文本文件。

  • 网络对战雏形：用ServerSocket和Socket实现简易联机。一台机器运行服务端（托管Model状态），另一台运行客户端（只负责输入和显示）。Model.update()改为从Socket接收指令，repaint()改为接收服务端推送的状态包。虽简陋，但已涵盖网络编程核心概念。

我个人在实际教学中发现，学生完成这些扩展后，对Java的理解会从“语法层面”跃升到“系统层面”——他们开始思考“这个功能该放在哪一层”“数据如何安全传递”“资源何时释放”。这正是工程师思维的萌芽。这个工程包的价值，不在于它多完美，而在于它足够小、足够真、足够开放——小到你能一眼看穿所有逻辑，真到每个bug都源于你自己的理解偏差，开放到你随时可以撕掉重写某一部分。当你某天自己写出一个比它更复杂的GUI应用时，回看这段代码，会发现那些曾经困扰你的Thread.sleep、repaint、getResource，早已成为肌肉记忆。而这就是成长最踏实的脚印。

本文还有配套的精品资源，点击获取 menu-r.4af5f7ec.gif

简介：这个Java小游戏项目完整复刻了经典吃豆人玩法，使用Swing构建图形界面，代码结构清晰、注释充分，适合刚接触GUI编程和游戏逻辑开发的学习者上手。包里自带全部视觉资源：玩家移动动画（left.gif/right.gif/up.gif/down.gif）、幽灵角色（ghost.gif）、主角图标（pacman.png）、生命显示（heart.png）以及项目预览图（preview.jpg）。源码仅包含两个核心Java文件——Pacman.java负责主窗口与事件循环，Model.java封装游戏状态、碰撞判断、得分更新和生命控制等逻辑。工程已预配置IntelliJ IDEA所需文件（.idea目录、*.iml、workspace.xml等），解压后无需修改路径或依赖，直接导入即可一键运行。配套README.md说明运行步骤，License文件明确开源协议，.gitignore适配Git版本管理。所有资源按功能归类存放，images文件夹集中管理图片，production和out为编译输出目录，方便理解标准Java项目结构。


本文还有配套的精品资源，点击获取
menu-r.4af5f7ec.gif

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

WRB1205S-1WR2 与钡特电源 VB1-12S05S 参数规格解析｜ 1W 宽压输入隔离 DC-DC 工业电源模块性能拆解

avatar 亚马逊云科技技术品牌专区
cover

人工智能如何改变学习方式

avatar 亚马逊云科技技术品牌专区
cover

FPGA 人工智能开发新手入门指南

avatar 亚马逊云科技技术品牌专区