简介这是一份面向Java初学者与Swing桌面开发爱好者的实战项目源码用Java SE标准库中的Swing工具包完整复刻了《植物大战僵尸》的核心玩法适合想通过完整项目理解GUI编程、事件驱动与多线程动画的开发者练手。压缩包共155个文件约19.15MB包含20个java源文件、39个class编译文件以及44个png、24个gif、22个jpg等图片素材和2个wav音效另附1份docx文档与工程配置文件资源齐全可直接导入运行。代码配有全量注释并额外提供文档解释逐行说明JFrame主窗口、JPanel绘制、JButton交互、ActionListener事件监听、Graphics2D图形渲染、多线程刷新以及MVC分层等关键知识点帮助读者理清游戏循环与资源加载逻辑。目前已有437人学习下载适合作为课程设计、毕业设计参考或Swing进阶练习便于快速掌握桌面游戏开发思路并二次改造。1. 从一份 Java Swing 课程设计说起植物大战僵尸到底能拆出多少东西很多人第一次看到「Java Swing 做的植物大战僵尸」第一反应是这不就是个课程设计吗能有什么技术含量。但真正动手做过的人会知道这个标题背后藏着一条完整的桌面应用开发链路——Swing 事件分发线程、定时器驱动的游戏主循环、基于网格的碰撞检测、面向对象继承体系、资源加载与双缓冲绘图甚至还有一份能讲清楚设计思路的文档。它解决的不是「怎么玩」而是「怎么用纯 Java 标准库不依赖任何游戏引擎把一个可运行的塔防游戏从零搭出来」。适合谁看正在找 Java 课程设计案例源码的学生、想用一个小项目把面向对象编程 Java 落地的初学者、以及需要一份带全注释和文档解释的参考实现来对照自己代码的开发者。热搜里「java课程设计案例源码」「面向对象编程java」「java基础」这几个词恰好对应了这个项目的三个价值点可复现、可学习、可扩展。接下来我会按「架构怎么拆 → 代码怎么写 → 坑在哪 → 怎么验证」的顺序把这份 Swing 植物大战僵尸的落地路径讲透。2. 用 Swing 搭一个能跑的游戏骨架从 JFrame 到游戏主循环2.1 为什么选 Swing 而不是 JavaFX 或游戏引擎先说选型理由。Swing 是 JDK 自带的老牌 GUI 工具包零额外依赖javac编译完直接java就能跑这对课程设计场景极其友好——老师拿到你的压缩包不需要装 Maven、不需要配 Gradle、不需要联网下引擎。JavaFX 从 JDK 11 开始被移出标准库要单独引依赖多一层环境变量配置的麻烦。至于 LibGDX 这类游戏框架功能强但学习曲线陡一个课程设计犯不上。Swing 的绘图模型是「被动重绘」组件状态变了调repaint()系统在合适时机回调paintComponent(Graphics g)。游戏需要每秒刷新几十次所以必须自己驱动一个主循环。常见做法是用javax.swing.Timer它的事件回调跑在事件分发线程EDT上天然避免了多线程操作 Swing 组件的线程安全问题。这一点很关键——如果你用Thread.sleep自己写循环再直接改组件大概率会遇到界面卡死或者偶发的绘制错乱这就是典型的玄学 bug。游戏主循环的职责就三件事更新逻辑僵尸移动、子弹飞行、阳光下落、检测碰撞、触发重绘。把这三件事拆成独立方法主循环只负责按固定间隔调用代码结构会非常清晰。2.2 最小可运行骨架JFrame JPanel Timer下面这段代码是整个游戏的骨架去掉所有业务逻辑只保留窗口、画布和主循环。你可以直接复制运行看到的效果是一个每 16 毫秒重绘一次的空白窗口。import javax.swing.*; import java.awt.*; public class GameMain extends JFrame { public GameMain() { setTitle(植物大战僵尸 - Swing版); setSize(900, 600); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); setResizable(false); setLocationRelativeTo(null); // 窗口居中 add(new GamePanel()); // 加入自定义画布 } public static void main(String[] args) { // Swing 组件必须在 EDT 上创建这是铁律 SwingUtilities.invokeLater(() - new GameMain().setVisible(true)); } } class GamePanel extends JPanel { private int frameCount 0; // 帧计数器用于验证主循环 public GamePanel() { setBackground(new Color(30, 30, 30)); // 16ms 约等于 60FPS游戏循环的核心 Timer timer new Timer(16, e - { update(); // 1. 更新逻辑 repaint(); // 2. 触发重绘 }); timer.start(); } private void update() { frameCount; // 后续所有实体移动、碰撞检测都写在这里 } Override protected void paintComponent(Graphics g) { super.paintComponent(g); // 必须调用否则背景擦除异常 g.setColor(Color.WHITE); g.drawString(Frame: frameCount, 20, 30); } }逻辑说明SwingUtilities.invokeLater保证窗口在 EDT 上创建这是 Swing 的硬性要求绕过它可能在部分系统上出现组件初始化异常。Timer的 16 毫秒间隔对应约 60 帧每秒是人眼流畅感知的常用值。paintComponent里第一行super.paintComponent(g)不能省它负责清空上一帧内容省掉的话画面会拖影。参数说明setSize(900, 600)是窗口尺寸后面网格布局要按这个尺寸反推格子大小。setResizable(false)固定窗口避免玩家拉伸导致坐标错位。Timer的间隔参数如果你调成 33帧率降到 30僵尸移动会明显卡顿调成 8 则可能在某些低配机器上 CPU 占用飙升。16 是经验值。提示所有对 Swing 组件的读写都放在 EDT 上不要另起线程直接操作组件。如果确实需要后台计算用SwingWorker它的done()方法会回到 EDT。2.3 网格坐标系设计把 900×600 切成可计算的格子植物大战僵尸的核心是「草坪网格」——植物种在格子里僵尸沿行前进。所以第一步是把像素坐标和网格坐标建立映射。常见做法是定义格子宽高然后写两个转换方法。public class GridConfig { public static final int CELL_WIDTH 80; // 每格宽 public static final int CELL_HEIGHT 100; // 每格高 public static final int ROWS 5; // 草坪 5 行 public static final int COLS 9; // 草坪 9 列 public static final int OFFSET_X 100; // 草坪左上角 X 偏移 public static final int OFFSET_Y 80; // 草坪左上角 Y 偏移 // 网格坐标 - 像素坐标格子左上角 public static int toPixelX(int col) { return OFFSET_X col * CELL_WIDTH; } public static int toPixelY(int row) { return OFFSET_Y row * CELL_HEIGHT; } // 像素坐标 - 网格列用于判断点击了哪一格 public static int toCol(int pixelX) { return (pixelX - OFFSET_X) / CELL_WIDTH; } public static int toRow(int pixelY) { return (pixelY - OFFSET_Y) / CELL_HEIGHT; } }逻辑说明toPixelX/Y用于绘制时把逻辑格子转成屏幕位置toCol/toRow用于鼠标点击时反查格子。这套双向映射是整个游戏坐标系统的基础植物种植、僵尸定位、子弹碰撞都依赖它。参数说明CELL_WIDTH80、CELL_HEIGHT100是根据 900×600 窗口和 9×5 网格反推的留出了顶部状态栏和左侧偏移。OFFSET_X100给左侧留出植物选择栏的空间。这些值一旦确定所有素材图片的尺寸也要按这个比例缩放否则会出现植物画到格子外面去的翻车现场。注意整数除法在toCol里会向下取整如果点击位置在草坪左侧pixelX OFFSET_X结果会是负数。使用前必须判断col 0 col COLS否则数组越界直接崩。3. 面向对象拆实体植物、僵尸、子弹的继承体系怎么设计3.1 抽象基类 GameObject把共性抽干净游戏里所有会动、会画的东西——向日葵、豌豆射手、普通僵尸、豌豆子弹——都有共同属性位置、宽高、是否存活、每帧行为。把这些抽成一个抽象基类子类只关注自己的特殊逻辑。这是面向对象编程 Java 里「继承 多态」最典型的落地场景。import java.awt.*; public abstract class GameObject { protected int x, y; // 像素坐标 protected int width, height; // 碰撞体积 protected boolean alive true; public GameObject(int x, int y, int width, int height) { this.x x; this.y y; this.width width; this.height height; } // 每帧更新自己的状态子类必须实现 public abstract void update(); // 每帧绘制自己子类必须实现 public abstract void draw(Graphics g); // 矩形碰撞检测所有实体通用 public boolean collidesWith(GameObject other) { return this.x other.x other.width this.x this.width other.x this.y other.y other.height this.y this.height other.y; } public boolean isAlive() { return alive; } public void setAlive(boolean alive) { this.alive alive; } public int getX() { return x; } public int getY() { return y; } }逻辑说明update()和draw()声明为抽象方法强制每个子类实现自己的行为——豌豆射手 update 里判断冷却时间到了就生成子弹僵尸 update 里往左移动。collidesWith用轴对齐矩形碰撞AABB这是 2D 游戏最常用的碰撞算法够用且快。参数说明width/height是碰撞体积不一定等于图片尺寸。比如僵尸图片可能 70×100但碰撞体积设成 50×90 会让手感更好避免「明明没碰到却判定命中」的挫败感。这个值需要反复调属于手感参数。3.2 植物与僵尸的具体实现状态机与冷却机制以豌豆射手为例它有两个核心状态冷却中、可射击。用一个cooldown计数器实现每帧减一减到 0 就能发射并重置。public class Peashooter extends GameObject { private int cooldown 0; private static final int FIRE_INTERVAL 90; // 约 1.5 秒一发60FPS private GamePanel panel; public Peashooter(int x, int y, GamePanel panel) { super(x, y, 70, 90); this.panel panel; } Override public void update() { if (cooldown 0) { cooldown--; return; } // 检查本行是否有僵尸有才发射避免浪费子弹 if (panel.hasZombieInRow(GridConfig.toRow(y))) { panel.addBullet(new Bullet(x width, y 20, GridConfig.toRow(y))); cooldown FIRE_INTERVAL; } } Override public void draw(Graphics g) { g.setColor(new Color(0, 180, 0)); g.fillRect(x, y, width, height); // 占位实际用图片替换 } }逻辑说明cooldown是典型的「计时器状态机」每帧递减归零后执行动作并重置。hasZombieInRow让豌豆射手只在有敌人的行开火这是原版游戏的行为也是性能优化——避免满屏无意义子弹。参数说明FIRE_INTERVAL90是在 60FPS 下约 1.5 秒一发这个值直接决定游戏难度。调成 60 会明显变简单调成 120 则可能打不过第一波。Bullet构造时传入行号是为了让子弹只和同一行的僵尸碰撞避免跨行误伤。僵尸的实现思路类似但移动逻辑是每帧x - speed速度值决定难度。普通僵尸 speed 设 0.3 像素每帧走完 9 格大约需要 20 多秒给玩家留出种植时间。3.3 实体管理器用 List 统一驱动所有对象有了各种实体还需要一个统一的地方管理它们的生命周期——添加、更新、绘制、清理死亡对象。常见做法是在 GamePanel 里维护几个 List。// GamePanel 内部 private ListGameObject plants new ArrayList(); private ListGameObject zombies new ArrayList(); private ListGameObject bullets new ArrayList(); private void update() { // 更新所有实体 plants.forEach(GameObject::update); zombies.forEach(GameObject::update); bullets.forEach(GameObject::update); // 碰撞检测子弹 vs 僵尸 for (GameObject bullet : bullets) { for (GameObject zombie : zombies) { if (bullet.isAlive() zombie.isAlive() bullet.collidesWith(zombie)) { bullet.setAlive(false); ((Zombie) zombie).takeDamage(20); } } } // 统一清理死亡对象避免遍历时删除导致 ConcurrentModificationException plants.removeIf(o - !o.isAlive()); zombies.removeIf(o - !o.isAlive()); bullets.removeIf(o - !o.isAlive()); }逻辑说明先统一 update再统一做碰撞检测最后统一清理。这个顺序很重要——如果在 update 过程中删除元素会抛ConcurrentModificationException这是新手最常见的翻车点之一。removeIf配合isAlive标志位把「标记死亡」和「真正移除」分开是安全的做法。参数说明子弹伤害 20、僵尸血量 100意味着 5 发子弹打死一个普通僵尸。这些数值集中定义成常量方便统一调整平衡性不要散落在各处硬编码。4. 全注释与文档解释怎么让代码自己会说话4.1 注释的三个层次类注释、方法注释、行内注释「全注释」不是每行都写废话而是分层次。类注释说清楚这个类在整个游戏里扮演什么角色方法注释说清楚输入输出和副作用行内注释只解释「为什么这么写」而不是「这行在做什么」。/** * 豌豆射手种植后每隔固定帧数向本行发射子弹。 * 依赖 GamePanel 提供的 hasZombieInRow 和 addBullet 接口。 * 生命周期由 GamePanel.plants 管理血量归零后移除。 */ public class Peashooter extends GameObject { /** * 每帧调用处理冷却递减与发射判定。 * 副作用冷却归零且本行有僵尸时会向 panel 添加一个 Bullet。 */ Override public void update() { // 冷却未结束时直接返回避免每帧都做僵尸检测省性能 if (cooldown 0) { cooldown--; return; } // ... } }逻辑说明类注释回答「这是什么、和谁协作、生命周期」方法注释回答「做什么、有什么副作用」行内注释回答「为什么」。这样一份代码交给别人他不用问你就知道每个类的定位。参数说明Javadoc 的param、return、throws在公开方法上要写全IDE 能直接生成文档。课程设计答辩时老师翻到注释规范的代码印象分直接拉满。4.2 文档解释该写什么设计文档的四个必备章节配套文档不是把代码翻译一遍而是讲清楚代码里看不出来的决策。一份合格的文档至少包含四部分需求描述、模块划分、关键算法说明、运行方式。下面用表格给出每部分的核心内容。章节必须写清楚的内容常见缺失需求描述游戏目标、操作方式、胜负条件只写「做个植物大战僵尸」没定义胜利条件模块划分每个类的职责、类之间的关系只列类名不说谁调用谁关键算法碰撞检测方式、主循环帧率、坐标映射完全不提读者看不懂坐标怎么算的运行方式JDK 版本、编译命令、启动类只给源码不给启动入口逻辑说明文档的价值在于「代码里没有的信息」。比如为什么选 16 毫秒而不是 20 毫秒为什么碰撞体积比图片小这些决策过程写进文档才是真正的「文档解释」。参数说明运行方式里要明确 JDK 版本。Swing 在 JDK 8 到 JDK 17 之间行为基本一致但如果用了var或新 API就要标注最低版本。热搜里「java: 警告: 源发行版 17 需要目标发行版 17」就是版本不匹配的典型报错文档里写清楚能帮读者省掉这个坑。4.3 用注释标记待办和已知问题全注释还有一个实用价值把「已知但没修」的问题标出来。用统一的TODO和FIXME标记答辩时主动说明比被老师问出来强。// TODO: 目前僵尸只支持直线行走后续可加绕路逻辑 // FIXME: 窗口最小化再恢复时Timer 可能出现短暂跳帧暂未定位逻辑说明TODO表示计划内的功能FIXME表示已知缺陷。这两个标记在主流 IDE 里都能一键检索方便集中管理。参数说明不要滥用。满屏 TODO 会显得代码没写完控制在个位数且每条都要能说清楚「为什么现在不做」。5. 避坑与排查Swing 游戏开发最容易翻车的五个地方5.1 画面闪烁现象是移动的僵尸拖出残影现象僵尸移动时身后留下一串残影或者整个画面一闪一闪。原因没有正确调用super.paintComponent(g)或者直接在paint而不是paintComponent里绘制。解决确保重写的是paintComponent且第一行调用父类方法。如果还有闪烁给 GamePanel 设置双缓冲——Swing 默认开启双缓冲但如果手动创建了 Graphics 就要注意。另一个常见原因是把绘制逻辑写在了paint里paint会先调用paintComponent再调用paintBorder和paintChildren顺序不对就会闪。5.2 界面卡死现象是点击按钮没反应窗口拖不动现象游戏运行几秒后整个窗口无响应。原因在 EDT 上执行了耗时操作比如用Thread.sleep做延时或者在大循环里做重计算。解决所有耗时逻辑拆出去用SwingWorker或Timer分帧处理。游戏主循环本身就是分帧的每帧只做一点点不要在一帧里遍历上万个对象。如果确实需要加载大图片放到后台线程加载完再回 EDT 更新。5.3 数组越界现象是点击草坪边缘直接崩溃现象鼠标点在草坪最左边或最上边程序抛ArrayIndexOutOfBoundsException。原因toCol/toRow返回了负数或超出范围的值没有做边界检查就拿来索引数组。解决所有从像素坐标转网格坐标的地方统一加边界判断。public static boolean isValidCell(int row, int col) { return row 0 row ROWS col 0 col COLS; }逻辑说明把边界检查抽成一个方法所有调用点复用避免漏判。参数说明ROWS和COLS来自 GridConfig改网格大小时只需改一处。5.4 资源加载失败现象是图片显示成空白或抛 NullPointerException现象ImageIO.read返回 null或者getResource找不到文件。原因图片路径写成了绝对路径换台机器就失效或者图片放在源码目录但没被复制到 classpath。解决统一用getClass().getResource(/images/peashooter.png)从 classpath 加载图片放在src/main/resources/images/下。如果返回 null先打印getClass().getResource()看 classpath 根在哪再对照路径。5.5 计时器叠加现象是游戏越玩越快现象重新开始游戏后僵尸移动速度翻倍。原因每次开始游戏都new Timer()并start()但旧的 Timer 没有stop()多个 Timer 同时在跑。解决把 Timer 作为成员变量开始新游戏前先timer.stop()或者全局只创建一个 Timer用状态标志控制是否更新逻辑。private Timer gameTimer; // 成员变量全局唯一 private void restartGame() { if (gameTimer ! null) { gameTimer.stop(); // 先停旧的 } // 重置游戏状态... gameTimer new Timer(16, e - { update(); repaint(); }); gameTimer.start(); }逻辑说明Timer 是资源创建了就要负责停止。参数说明stop()后 Timer 对象还可以重新start()不必每次 new但为了状态干净重启时重建也可以关键是旧的必须停。6. 进阶技巧用状态模式重构关卡切换与胜负判定玩到后面你会发现游戏其实有多个状态准备种植、战斗进行中、胜利、失败。如果全用if-else判断代码会迅速膨胀成一团。我一般会用状态模式把每个状态的行为独立出来这也是把课程设计拔高到「有设计模式」层次的关键一步。先定义一个状态接口每个状态负责处理输入和更新。public interface GameState { void onEnter(GamePanel panel); // 进入状态时初始化 void update(GamePanel panel); // 每帧更新 void onMouseClick(int row, int col, GamePanel panel); // 处理点击 String getName(); } // 战斗状态正常更新所有实体 class PlayingState implements GameState { public void onEnter(GamePanel panel) { /* 重置波次 */ } public void update(GamePanel panel) { panel.updateEntities(); if (panel.allZombiesDead()) { panel.setState(new WinState()); } else if (panel.zombieReachedHouse()) { panel.setState(new LoseState()); } } public void onMouseClick(int row, int col, GamePanel panel) { panel.tryPlant(row, col); // 只有战斗状态能种植物 } public String getName() { return PLAYING; } }逻辑说明GamePanel持有一个GameState引用每帧委托给当前状态处理。切换状态只需setState(new WinState())所有if-else消失。onEnter负责状态初始化比如进入胜利状态时播放音效、停止僵尸生成。参数说明状态切换的判定条件放在update里每帧检查一次。allZombiesDead要排除还没生成的波次否则第一波没出就判胜利。zombieReachedHouse判断僵尸 x 坐标小于房屋边界。验证状态机是否正确有个简单办法在setState里打印状态切换日志跑一局看日志顺序是否符合预期。public void setState(GameState newState) { System.out.println([STATE] currentState.getName() - newState.getName()); currentState newState; currentState.onEnter(this); }逻辑说明日志能帮你快速定位「为什么游戏卡在某个状态不动」。参数说明正式发布时把打印去掉或改成日志框架避免控制台刷屏。我自己的习惯是每加一个新状态先画一张状态转移图贴在显示器边上确认所有可能的转移路径都覆盖到了再写代码。这个习惯帮我省掉了无数次「赢了之后还能继续种植物」的尴尬 bug。状态模式不是银弹但对于关卡切换、暂停恢复、胜负判定这类场景它比一堆布尔标志位清晰太多。希望帮到你。本文还有配套的精品资源点击获取