拓冰网站定制 
简介这份Java潜艇大战游戏源码面向具备Java基础、希望借完整项目理解游戏开发流程的学习者与开发者可用于课程设计、毕业设计参考或自学练手。源码围绕面向对象建模展开将潜艇、鱼雷、战舰等元素抽象为独立对象并涉及Swing图形界面搭建、键盘与鼠标事件监听、多线程刷新游戏逻辑与渲染、矩形与AABB碰撞检测、得分与命中判定等核心机制同时包含音效图像资源加载和文件读写持久化玩家记录等实用环节。压缩包共78个文件约401KB以20个java源文件与36个class字节码为主体另含12个png游戏素材、4个xml配置及Eclipse工程相关文件目录结构清晰便于直接导入运行与逐模块研读。目前已有953人学习下载适合通过阅读与调试源码提升Java编程与游戏开发能力。1. 潜艇大战游戏源码一个 Java 桌面项目能带你走多远很多人第一次搜「Java实现潜艇大战游戏源码」心里想的其实是两件事一是想找一个能直接跑起来的 Java 小游戏练手二是想知道这类源码到底值不值得花时间读。潜艇大战属于典型的二维射击/躲避类玩法核心逻辑不复杂玩家潜艇在网格或像素坐标里移动敌方舰船或深水炸弹按规则下落碰撞判定触发扣血或结束。它不像 MOBA 游戏源码那样牵扯帧同步和状态回滚也不像拉霸游戏源码那样重随机数校验但麻雀虽小五脏俱全——游戏循环、事件监听、碰撞检测、资源加载、状态管理一个不少。如果你正在啃 Java 基础、准备 Java 面试题里的面向对象设计题或者想找一个能塞进简历的小项目这类源码是性价比很高的切入点。下面我按自己带人做过的路径把从看懂到跑通再到改出花样的全过程拆开讲。2. 先拆骨架潜艇大战源码里到底有哪些类2.1 从游戏循环倒推需要的对象拿到一份潜艇大战源码别急着从 main 方法一行行往下读那样很容易陷进细节里出不来。我一般先找游戏循环——通常是while(running)或者 Swing 的Timer驱动看它每一帧调用了哪些方法。一个最小可运行的潜艇大战循环里至少要做四件事处理输入、更新位置、检测碰撞、重绘画面。把这四件事对应的类名记下来你就得到了整个项目的骨架。常见的类划分是这样的GamePanel继承JPanel并实现Runnable或ActionListener负责循环和绘制Submarine或Player表示玩家潜艇持有坐标、速度、生命值Enemy或Bomb表示敌方单位通常有一个update()方法让 y 坐标递增GameObject作为父类抽出公共的 x、y、width、height 和getBounds()。如果源码里没有GameObject这层抽象说明作者是新手写法每个类各写各的碰撞矩形这种代码读起来累但改起来反而直观。提示先画一张类关系草图再读代码比直接翻源码快三倍。草图不用漂亮能看出谁持有谁、谁调用谁就够了。2.2 用一张表锁定关键字段和参数读源码时最怕的就是变量名起得随意a、b、temp满天飞。这时候别硬记直接做一张字段对照表把每个类里影响手感和难度的数值挑出来。下面是我从多份潜艇大战源码里总结出的高频参数你对照自己手上的版本填一遍基本就摸清作者的设计意图了。参数名常见写法所在类作用典型取值调整后的手感变化speed/moveSpeedPlayer玩家每帧移动像素3~6调大更灵活调太大容易穿模enemySpeedEnemy敌方下落速度1~4决定整体难度曲线spawnIntervalGamePanel生成敌方的帧间隔30~90越小敌人越密playerHP/lifePlayer初始生命值3~5直接改容错率width/height各对象碰撞矩形尺寸20~60影响判定松紧delayTimer每帧毫秒数16~3316 约 60FPS33 约 30FPS这张表的价值在于当你觉得游戏「太难」或「太无聊」时不用改逻辑只动这几个数就能验证。比如把spawnInterval从 60 改成 30敌人密度翻倍立刻能感受到压力变化。这也是为什么我建议新手先跑通再读逻辑——参数是理解设计最快的入口。2.3 碰撞检测为什么是这类源码的分水岭潜艇大战的碰撞检测通常有两种写法矩形相交和圆形距离。矩形相交用Rectangle.intersects()一行搞定适合方块贴图圆形距离要算Math.sqrt(dx*dxdy*dy) r1r2适合圆形潜艇。源码里用哪种直接反映了作者对精度的要求。我见过不少版本为了省事把所有对象都当矩形处理结果玩家潜艇的「尖头」明明没碰到炸弹却判定死亡玩起来很憋屈。改进方法也简单给每个对象加一个略小于贴图的碰撞盒比如贴图 48×48碰撞盒设成 36×36视觉和判定就协调了。这个偏移量offset一般取(贴图宽 - 碰撞盒宽) / 2在getBounds()里返回new Rectangle(xoffset, yoffset, w, h)即可。// 在 GameObject 中统一提供碰撞盒子类可覆盖 offset public Rectangle getBounds() { int offset 6; // 贴图 48碰撞盒 36左右各缩 6 return new Rectangle(x offset, y offset, width - 2 * offset, height - 2 * offset); } // 碰撞检测处直接调用 if (player.getBounds().intersects(enemy.getBounds())) { player.hit(); }这段代码的关键是offset这个参数。它不改变任何游戏逻辑只调整判定松紧。调大 offset碰撞盒变小游戏变简单调小 offset判定变严难度上升。很多源码把 offset 写死在各个类里改起来要翻好几个文件统一到父类后只改一个数。如果你手上的源码没有这层抽象建议先做这个小重构后面调手感会轻松很多。3. 把源码跑起来环境、编译与第一个可玩版本3.1 Java 环境配置与常见启动失败排查潜艇大战源码绝大多数是纯 Java SE 项目不依赖 Spring Boot 那套东西所以环境配置很简单装 JDK配JAVA_HOME把bin目录加进PATH。但就是这三步能卡住不少人。Win11 系统下我遇到过好几次「java 不是内部或外部命令」排查下来无非三种原因JDK 装了但环境变量没配、配了但没重启终端、或者系统里同时有多个 JDK 版本导致JAVA_HOME指向了 JRE 而不是 JDK。验证方法就一条命令java -version javac -version两个都能输出版本号才算配好。如果java有输出但javac没有说明你装的是 JRE 不是 JDK得重新下 JDK 包。另外注意源码如果用了var关键字或switch表达式需要 JDK 10 以上如果只是普通 Swing 代码JDK 8 就够。我一般建议直接用 JDK 17兼容性和长期支持都稳。注意不要用 IDE 自带的 JDK 去跑命令行编译两者版本不一致时会出现「IDE 能跑、命令行报错」的玄学问题。统一用系统环境变量里的那个 JDK。3.2 编译与运行的最小命令序列假设你拿到的源码目录结构是src/下按包名分文件夹主类叫com.game.Main。最朴素的编译运行方式是这样# 1. 创建输出目录 mkdir -p out # 2. 编译所有 java 文件到 out 目录 javac -encoding UTF-8 -d out $(find src -name *.java) # 3. 运行主类注意 -cp 指向 out java -cp out com.game.Main这三条命令里有两个参数值得说。-encoding UTF-8是防止源码里有中文注释导致编译报错Windows 默认编码是 GBK不加这个参数经常出现「编码 GBK 的不可映射字符」。-d out是把编译产物和源码分开保持目录干净后面重新编译时直接删 out 就行不用去源码里翻.class文件。如果源码提供了pom.xml那更省事直接mvn clean package然后java -jar target/xxx.jar。但很多小游戏源码是「裸奔」的没有构建工具就用上面这套命令。跑通之后你会看到一个窗口弹出潜艇能上下左右移动敌人开始下落——到这一步源码就算「活」了。3.3 用 IDE 打开时最容易踩的坑命令行跑通后很多人会转到 IntelliJ IDEA 或 Eclipse 里继续改。这时候最常见的翻车是「找不到主类」或「包名不对」。原因通常是源码里的package声明和实际文件夹层级不匹配比如文件放在src/game/下但声明是package com.game;。IDE 会严格按包名找路径对不上就报错。解决办法有两个要么改package声明要么调整文件夹结构。我一般选后者因为改包名可能牵连import语句。具体操作是在 IDE 里右键源码根目录选择「Mark Directory as Sources Root」然后按包名建好com/game/层级把文件挪进去。挪完如果还有红色报错多半是import没更新用 IDE 的「Optimize Imports」一键整理即可。另外提醒一句有些源码用了绝对路径加载图片比如new ImageIcon(D:/game/img/sub.png)。这种代码换台机器就挂正确做法是用getClass().getResource(/img/sub.png)从 classpath 读。如果你跑起来窗口是黑的但没报错八成就是图片路径问题检查一下资源加载那几行。4. 改出你自己的版本从换皮到加机制4.1 换素材与调参数最快看到成果的改法跑通之后想让它「像自己的东西」最直接的两步是换素材和调参数。换素材就是把img/目录下的图片替换成你自己找的或画的注意保持文件名和尺寸一致否则要么加载失败要么碰撞盒对不上。尺寸不一致时改width、height和前面说的offset三个值即可。调参数则是改第 2 章那张表里的数值。我一般会做三组预设简单模式spawnInterval90, enemySpeed1普通模式60, 2困难模式30, 4。在GamePanel里加一个difficulty变量启动时根据选择加载不同参数。这个改动代码量很小但让项目从「demo」变成了「有设计的游戏」。// 难度配置放在 GamePanel 或单独的 Config 类里 public class Difficulty { public static final int[] SPAWN_INTERVAL {90, 60, 30}; public static final int[] ENEMY_SPEED {1, 2, 4}; private int level; // 0 简单 1 普通 2 困难 public Difficulty(int level) { this.level level; } public int getSpawnInterval() { return SPAWN_INTERVAL[level]; } public int getEnemySpeed() { return ENEMY_SPEED[level]; } }用数组存三档参数的好处是扩展方便想加「地狱模式」就在数组末尾追加一个值不用改逻辑。level作为索引越界时抛异常也能帮你快速发现配置错误。这种写法比一堆if-else清爽也符合 Java 面试题里常考的「用数据驱动代替条件分支」思路。4.2 加一个「鱼雷」机制完整改动路径换皮调参只是热身真正让源码变成自己作品的是加机制。我拿「玩家发射鱼雷」举例走一遍完整改动路径。这个机制需要四步加输入监听、加鱼雷对象、加碰撞逻辑、加冷却控制。第一步在GamePanel的键盘监听里加一个按键比如空格。按下时判断冷却是否结束结束就new Torpedo(player.getX(), player.getY())并加入torpedoes列表。第二步Torpedo类继承GameObjectupdate()里让 y 坐标递减出屏后从列表移除。第三步在碰撞检测循环里加一层遍历torpedoes和enemies相交则两者都标记为死亡。第四步冷却用一个long lastFireTime记录上次发射时间每次按键判断System.currentTimeMillis() - lastFireTime cooldown。// 发射鱼雷cooldown 单位毫秒 private long lastFireTime 0; private static final long COOLDOWN 300; public void fire() { long now System.currentTimeMillis(); if (now - lastFireTime COOLDOWN) return; // 冷却中 torpedoes.add(new Torpedo(player.getX() player.getWidth()/2, player.getY())); lastFireTime now; } // 碰撞检测里追加 IteratorTorpedo ti torpedoes.iterator(); while (ti.hasNext()) { Torpedo t ti.next(); IteratorEnemy ei enemies.iterator(); while (ei.hasNext()) { Enemy e ei.next(); if (t.getBounds().intersects(e.getBounds())) { ti.remove(); ei.remove(); score 10; break; } } }这里用Iterator而不是for-each是因为要在遍历中删除元素直接remove()会抛ConcurrentModificationException这是 Java 集合的经典坑面试题里也常考。COOLDOWN设 300 毫秒手感上大约每秒能发三发不会太密也不会太稀。score加分是顺手加的让击杀有反馈。整个改动不超过 60 行代码但游戏性提升明显。4.3 用状态机管理游戏流程原始源码往往只有一个「运行中」状态死了就System.exit(0)或者卡住不动。想做得像样一点得引入状态机菜单、游戏中、暂停、结束四个状态。实现方式很简单在GamePanel里加一个int state变量循环里根据 state 决定更新什么、绘制什么。private static final int MENU 0, PLAYING 1, PAUSED 2, GAME_OVER 3; private int state MENU; public void update() { switch (state) { case MENU: // 只响应开始键 break; case PLAYING: player.update(); updateEnemies(); checkCollisions(); break; case PAUSED: // 不更新只重绘 break; case GAME_OVER: // 响应重开键 break; } }状态机的好处是所有流程控制集中在一处加「暂停」只需在按键监听里切换state不用去改各个对象的更新逻辑。这也是 Java 面试里「状态模式」的简化版理解了这个结构再去看那些用枚举实现的正式版本会轻松很多。5. 避坑与排查潜艇大战源码里最容易翻车的五处5.1 画面闪烁现象是窗口不停抖动原因是直接在paint()里绘制解决是改用JPanel双缓冲Swing 默认的paint()每次重绘会先清屏再画清屏和绘制之间有时间差肉眼就看到闪烁。解决办法是继承JPanel而不是CanvasSwing 的JPanel默认开启双缓冲绘制在内存里完成后一次性贴到屏幕。如果源码用的是Canvas加BufferStrategy那套写法更底层但也更容易出错新手建议直接换成JPanelTimer的组合。5.2 按键没反应现象是窗口能显示但键盘无效原因是焦点不在面板上解决是setFocusable(true)加requestFocus()Swing 的键盘事件只发给有焦点的组件。如果GamePanel没有主动请求焦点按键会被窗口的其他组件截走。在构造函数里加setFocusable(true)和requestFocus()两行大部分情况能解决。如果还不行检查是不是有别的组件比如按钮抢了焦点把按钮设为setFocusable(false)即可。5.3 敌人越跑越快现象是游戏运行一段时间后敌人速度失控原因是Timer延迟累积或速度变量被重复累加解决是检查update()里有没有speed xxx这个坑很隐蔽。有些源码在update()里写了y speed但speed又在某个条件里被speed导致速度只增不减。排查方法是把speed打印出来看它是否随时间变化。正常情况速度应该是常量或按关卡切换如果每帧都在涨就是累加逻辑写错了位置。修复就是把speed的修改移到初始化或关卡切换处update()里只读不写。5.4 图片加载失败但无报错现象是对象显示为空白或黑块原因是路径用了绝对路径或大小写不匹配解决是改用getResource()并检查文件名大小写Windows 文件系统不区分大小写Linux 和 macOS 区分。源码在 Windows 上跑得好好的换到 Mac 就白屏多半是Sub.png写成了sub.png。统一用getClass().getResource(/img/sub.png)从 classpath 加载并且确保img目录在编译输出里Maven 项目放resources下裸项目手动拷到 out 目录。加载失败时getResource()返回 null加一行判空打印就能定位。5.5 打包成 jar 后资源丢失现象是命令行能跑、双击 jar 白屏原因是资源没打进 jar 或读取方式不支持 jar 内路径解决是用getResourceAsStream()替代Filenew File(img/sub.png)在 IDE 里能读到因为文件在磁盘上打成 jar 后图片在压缩包里File找不到。正确做法是用getResourceAsStream()拿输入流再交给ImageIO.read()。这个改动涉及所有资源加载处建议一开始就用流的方式写省得后面返工。6. 进阶技巧把潜艇大战源码变成可展示的作品跑通、改完、避完坑之后如果你想让这个项目在简历或作品集里拿得出手还有一步值得做加一个简单的数据持久化把最高分存到本地文件。用Properties或JSON都行我一般用Properties因为 Java 标准库直接支持不引额外依赖。// 读取最高分 private int loadHighScore() { Properties props new Properties(); try (InputStream in new FileInputStream(save.properties)) { props.load(in); return Integer.parseInt(props.getProperty(highScore, 0)); } catch (IOException e) { return 0; // 文件不存在时返回 0 } } // 保存最高分 private void saveHighScore(int score) { Properties props new Properties(); props.setProperty(highScore, String.valueOf(score)); try (OutputStream out new FileOutputStream(save.properties)) { props.store(out, submarine game save); } catch (IOException e) { e.printStackTrace(); } }这段代码用了 try-with-resources流会自动关闭不用手写finally。save.properties存在工作目录下和 jar 同级。游戏结束时比较当前分和最高分超过就调用saveHighScore。这个功能代码量不到 30 行但让项目从「一次性 demo」变成了「有记忆的游戏」展示时也多了个可讲的点。另一个提升展示效果的是加音效。Java 标准库支持Clip播放 wav 格式AudioSystem.getClip()拿到 clip 后open()音频流再start()。注意音效文件别太大否则加载会卡顿短促的 wav 最合适。播放和停止要成对背景音乐循环播放时记得在游戏结束时stop()不然关了窗口声音还在。最后说个我自己的习惯每改完一个功能就提交一次 gitcommit message 写清楚改了什么、为什么改。潜艇大战这种小项目改着改着就容易忘记原始版本长什么样有版本记录随时能回退。我当初第一次改这类源码时没做版本管理加鱼雷加出 bug 后想退回原始版本结果只能重新下一份血泪经验。希望这些能帮到你少走点弯路。本文还有配套的精品资源点击获取 Java潜艇大战游戏源码解析：从跑通到改出花样
简介这份Java潜艇大战游戏源码面向具备Java基础、希望借完整项目理解游戏开发流程的学习者与开发者可用于课程设计、毕业设计参考或自学练手。源码围绕面向对象建模展开将潜艇、鱼雷、战舰等元素抽象为独立对象并涉及Swing图形界面搭建、键盘与鼠标事件监听、多线程刷新游戏逻辑与渲染、矩形与AABB碰撞检测、得分与命中判定等核心机制同时包含音效图像资源加载和文件读写持久化玩家记录等实用环节。压缩包共78个文件约401KB以20个java源文件与36个class字节码为主体另含12个png游戏素材、4个xml配置及Eclipse工程相关文件目录结构清晰便于直接导入运行与逐模块研读。目前已有953人学习下载适合通过阅读与调试源码提升Java编程与游戏开发能力。1. 潜艇大战游戏源码一个 Java 桌面项目能带你走多远很多人第一次搜「Java实现潜艇大战游戏源码」心里想的其实是两件事一是想找一个能直接跑起来的 Java 小游戏练手二是想知道这类源码到底值不值得花时间读。潜艇大战属于典型的二维射击/躲避类玩法核心逻辑不复杂玩家潜艇在网格或像素坐标里移动敌方舰船或深水炸弹按规则下落碰撞判定触发扣血或结束。它不像 MOBA 游戏源码那样牵扯帧同步和状态回滚也不像拉霸游戏源码那样重随机数校验但麻雀虽小五脏俱全——游戏循环、事件监听、碰撞检测、资源加载、状态管理一个不少。如果你正在啃 Java 基础、准备 Java 面试题里的面向对象设计题或者想找一个能塞进简历的小项目这类源码是性价比很高的切入点。下面我按自己带人做过的路径把从看懂到跑通再到改出花样的全过程拆开讲。2. 先拆骨架潜艇大战源码里到底有哪些类2.1 从游戏循环倒推需要的对象拿到一份潜艇大战源码别急着从 main 方法一行行往下读那样很容易陷进细节里出不来。我一般先找游戏循环——通常是while(running)或者 Swing 的Timer驱动看它每一帧调用了哪些方法。一个最小可运行的潜艇大战循环里至少要做四件事处理输入、更新位置、检测碰撞、重绘画面。把这四件事对应的类名记下来你就得到了整个项目的骨架。常见的类划分是这样的GamePanel继承JPanel并实现Runnable或ActionListener负责循环和绘制Submarine或Player表示玩家潜艇持有坐标、速度、生命值Enemy或Bomb表示敌方单位通常有一个update()方法让 y 坐标递增GameObject作为父类抽出公共的 x、y、width、height 和getBounds()。如果源码里没有GameObject这层抽象说明作者是新手写法每个类各写各的碰撞矩形这种代码读起来累但改起来反而直观。提示先画一张类关系草图再读代码比直接翻源码快三倍。草图不用漂亮能看出谁持有谁、谁调用谁就够了。2.2 用一张表锁定关键字段和参数读源码时最怕的就是变量名起得随意a、b、temp满天飞。这时候别硬记直接做一张字段对照表把每个类里影响手感和难度的数值挑出来。下面是我从多份潜艇大战源码里总结出的高频参数你对照自己手上的版本填一遍基本就摸清作者的设计意图了。参数名常见写法所在类作用典型取值调整后的手感变化speed/moveSpeedPlayer玩家每帧移动像素3~6调大更灵活调太大容易穿模enemySpeedEnemy敌方下落速度1~4决定整体难度曲线spawnIntervalGamePanel生成敌方的帧间隔30~90越小敌人越密playerHP/lifePlayer初始生命值3~5直接改容错率width/height各对象碰撞矩形尺寸20~60影响判定松紧delayTimer每帧毫秒数16~3316 约 60FPS33 约 30FPS这张表的价值在于当你觉得游戏「太难」或「太无聊」时不用改逻辑只动这几个数就能验证。比如把spawnInterval从 60 改成 30敌人密度翻倍立刻能感受到压力变化。这也是为什么我建议新手先跑通再读逻辑——参数是理解设计最快的入口。2.3 碰撞检测为什么是这类源码的分水岭潜艇大战的碰撞检测通常有两种写法矩形相交和圆形距离。矩形相交用Rectangle.intersects()一行搞定适合方块贴图圆形距离要算Math.sqrt(dx*dxdy*dy) r1r2适合圆形潜艇。源码里用哪种直接反映了作者对精度的要求。我见过不少版本为了省事把所有对象都当矩形处理结果玩家潜艇的「尖头」明明没碰到炸弹却判定死亡玩起来很憋屈。改进方法也简单给每个对象加一个略小于贴图的碰撞盒比如贴图 48×48碰撞盒设成 36×36视觉和判定就协调了。这个偏移量offset一般取(贴图宽 - 碰撞盒宽) / 2在getBounds()里返回new Rectangle(xoffset, yoffset, w, h)即可。// 在 GameObject 中统一提供碰撞盒子类可覆盖 offset public Rectangle getBounds() { int offset 6; // 贴图 48碰撞盒 36左右各缩 6 return new Rectangle(x offset, y offset, width - 2 * offset, height - 2 * offset); } // 碰撞检测处直接调用 if (player.getBounds().intersects(enemy.getBounds())) { player.hit(); }这段代码的关键是offset这个参数。它不改变任何游戏逻辑只调整判定松紧。调大 offset碰撞盒变小游戏变简单调小 offset判定变严难度上升。很多源码把 offset 写死在各个类里改起来要翻好几个文件统一到父类后只改一个数。如果你手上的源码没有这层抽象建议先做这个小重构后面调手感会轻松很多。3. 把源码跑起来环境、编译与第一个可玩版本3.1 Java 环境配置与常见启动失败排查潜艇大战源码绝大多数是纯 Java SE 项目不依赖 Spring Boot 那套东西所以环境配置很简单装 JDK配JAVA_HOME把bin目录加进PATH。但就是这三步能卡住不少人。Win11 系统下我遇到过好几次「java 不是内部或外部命令」排查下来无非三种原因JDK 装了但环境变量没配、配了但没重启终端、或者系统里同时有多个 JDK 版本导致JAVA_HOME指向了 JRE 而不是 JDK。验证方法就一条命令java -version javac -version两个都能输出版本号才算配好。如果java有输出但javac没有说明你装的是 JRE 不是 JDK得重新下 JDK 包。另外注意源码如果用了var关键字或switch表达式需要 JDK 10 以上如果只是普通 Swing 代码JDK 8 就够。我一般建议直接用 JDK 17兼容性和长期支持都稳。注意不要用 IDE 自带的 JDK 去跑命令行编译两者版本不一致时会出现「IDE 能跑、命令行报错」的玄学问题。统一用系统环境变量里的那个 JDK。3.2 编译与运行的最小命令序列假设你拿到的源码目录结构是src/下按包名分文件夹主类叫com.game.Main。最朴素的编译运行方式是这样# 1. 创建输出目录 mkdir -p out # 2. 编译所有 java 文件到 out 目录 javac -encoding UTF-8 -d out $(find src -name *.java) # 3. 运行主类注意 -cp 指向 out java -cp out com.game.Main这三条命令里有两个参数值得说。-encoding UTF-8是防止源码里有中文注释导致编译报错Windows 默认编码是 GBK不加这个参数经常出现「编码 GBK 的不可映射字符」。-d out是把编译产物和源码分开保持目录干净后面重新编译时直接删 out 就行不用去源码里翻.class文件。如果源码提供了pom.xml那更省事直接mvn clean package然后java -jar target/xxx.jar。但很多小游戏源码是「裸奔」的没有构建工具就用上面这套命令。跑通之后你会看到一个窗口弹出潜艇能上下左右移动敌人开始下落——到这一步源码就算「活」了。3.3 用 IDE 打开时最容易踩的坑命令行跑通后很多人会转到 IntelliJ IDEA 或 Eclipse 里继续改。这时候最常见的翻车是「找不到主类」或「包名不对」。原因通常是源码里的package声明和实际文件夹层级不匹配比如文件放在src/game/下但声明是package com.game;。IDE 会严格按包名找路径对不上就报错。解决办法有两个要么改package声明要么调整文件夹结构。我一般选后者因为改包名可能牵连import语句。具体操作是在 IDE 里右键源码根目录选择「Mark Directory as Sources Root」然后按包名建好com/game/层级把文件挪进去。挪完如果还有红色报错多半是import没更新用 IDE 的「Optimize Imports」一键整理即可。另外提醒一句有些源码用了绝对路径加载图片比如new ImageIcon(D:/game/img/sub.png)。这种代码换台机器就挂正确做法是用getClass().getResource(/img/sub.png)从 classpath 读。如果你跑起来窗口是黑的但没报错八成就是图片路径问题检查一下资源加载那几行。4. 改出你自己的版本从换皮到加机制4.1 换素材与调参数最快看到成果的改法跑通之后想让它「像自己的东西」最直接的两步是换素材和调参数。换素材就是把img/目录下的图片替换成你自己找的或画的注意保持文件名和尺寸一致否则要么加载失败要么碰撞盒对不上。尺寸不一致时改width、height和前面说的offset三个值即可。调参数则是改第 2 章那张表里的数值。我一般会做三组预设简单模式spawnInterval90, enemySpeed1普通模式60, 2困难模式30, 4。在GamePanel里加一个difficulty变量启动时根据选择加载不同参数。这个改动代码量很小但让项目从「demo」变成了「有设计的游戏」。// 难度配置放在 GamePanel 或单独的 Config 类里 public class Difficulty { public static final int[] SPAWN_INTERVAL {90, 60, 30}; public static final int[] ENEMY_SPEED {1, 2, 4}; private int level; // 0 简单 1 普通 2 困难 public Difficulty(int level) { this.level level; } public int getSpawnInterval() { return SPAWN_INTERVAL[level]; } public int getEnemySpeed() { return ENEMY_SPEED[level]; } }用数组存三档参数的好处是扩展方便想加「地狱模式」就在数组末尾追加一个值不用改逻辑。level作为索引越界时抛异常也能帮你快速发现配置错误。这种写法比一堆if-else清爽也符合 Java 面试题里常考的「用数据驱动代替条件分支」思路。4.2 加一个「鱼雷」机制完整改动路径换皮调参只是热身真正让源码变成自己作品的是加机制。我拿「玩家发射鱼雷」举例走一遍完整改动路径。这个机制需要四步加输入监听、加鱼雷对象、加碰撞逻辑、加冷却控制。第一步在GamePanel的键盘监听里加一个按键比如空格。按下时判断冷却是否结束结束就new Torpedo(player.getX(), player.getY())并加入torpedoes列表。第二步Torpedo类继承GameObjectupdate()里让 y 坐标递减出屏后从列表移除。第三步在碰撞检测循环里加一层遍历torpedoes和enemies相交则两者都标记为死亡。第四步冷却用一个long lastFireTime记录上次发射时间每次按键判断System.currentTimeMillis() - lastFireTime cooldown。// 发射鱼雷cooldown 单位毫秒 private long lastFireTime 0; private static final long COOLDOWN 300; public void fire() { long now System.currentTimeMillis(); if (now - lastFireTime COOLDOWN) return; // 冷却中 torpedoes.add(new Torpedo(player.getX() player.getWidth()/2, player.getY())); lastFireTime now; } // 碰撞检测里追加 IteratorTorpedo ti torpedoes.iterator(); while (ti.hasNext()) { Torpedo t ti.next(); IteratorEnemy ei enemies.iterator(); while (ei.hasNext()) { Enemy e ei.next(); if (t.getBounds().intersects(e.getBounds())) { ti.remove(); ei.remove(); score 10; break; } } }这里用Iterator而不是for-each是因为要在遍历中删除元素直接remove()会抛ConcurrentModificationException这是 Java 集合的经典坑面试题里也常考。COOLDOWN设 300 毫秒手感上大约每秒能发三发不会太密也不会太稀。score加分是顺手加的让击杀有反馈。整个改动不超过 60 行代码但游戏性提升明显。4.3 用状态机管理游戏流程原始源码往往只有一个「运行中」状态死了就System.exit(0)或者卡住不动。想做得像样一点得引入状态机菜单、游戏中、暂停、结束四个状态。实现方式很简单在GamePanel里加一个int state变量循环里根据 state 决定更新什么、绘制什么。private static final int MENU 0, PLAYING 1, PAUSED 2, GAME_OVER 3; private int state MENU; public void update() { switch (state) { case MENU: // 只响应开始键 break; case PLAYING: player.update(); updateEnemies(); checkCollisions(); break; case PAUSED: // 不更新只重绘 break; case GAME_OVER: // 响应重开键 break; } }状态机的好处是所有流程控制集中在一处加「暂停」只需在按键监听里切换state不用去改各个对象的更新逻辑。这也是 Java 面试里「状态模式」的简化版理解了这个结构再去看那些用枚举实现的正式版本会轻松很多。5. 避坑与排查潜艇大战源码里最容易翻车的五处5.1 画面闪烁现象是窗口不停抖动原因是直接在paint()里绘制解决是改用JPanel双缓冲Swing 默认的paint()每次重绘会先清屏再画清屏和绘制之间有时间差肉眼就看到闪烁。解决办法是继承JPanel而不是CanvasSwing 的JPanel默认开启双缓冲绘制在内存里完成后一次性贴到屏幕。如果源码用的是Canvas加BufferStrategy那套写法更底层但也更容易出错新手建议直接换成JPanelTimer的组合。5.2 按键没反应现象是窗口能显示但键盘无效原因是焦点不在面板上解决是setFocusable(true)加requestFocus()Swing 的键盘事件只发给有焦点的组件。如果GamePanel没有主动请求焦点按键会被窗口的其他组件截走。在构造函数里加setFocusable(true)和requestFocus()两行大部分情况能解决。如果还不行检查是不是有别的组件比如按钮抢了焦点把按钮设为setFocusable(false)即可。5.3 敌人越跑越快现象是游戏运行一段时间后敌人速度失控原因是Timer延迟累积或速度变量被重复累加解决是检查update()里有没有speed xxx这个坑很隐蔽。有些源码在update()里写了y speed但speed又在某个条件里被speed导致速度只增不减。排查方法是把speed打印出来看它是否随时间变化。正常情况速度应该是常量或按关卡切换如果每帧都在涨就是累加逻辑写错了位置。修复就是把speed的修改移到初始化或关卡切换处update()里只读不写。5.4 图片加载失败但无报错现象是对象显示为空白或黑块原因是路径用了绝对路径或大小写不匹配解决是改用getResource()并检查文件名大小写Windows 文件系统不区分大小写Linux 和 macOS 区分。源码在 Windows 上跑得好好的换到 Mac 就白屏多半是Sub.png写成了sub.png。统一用getClass().getResource(/img/sub.png)从 classpath 加载并且确保img目录在编译输出里Maven 项目放resources下裸项目手动拷到 out 目录。加载失败时getResource()返回 null加一行判空打印就能定位。5.5 打包成 jar 后资源丢失现象是命令行能跑、双击 jar 白屏原因是资源没打进 jar 或读取方式不支持 jar 内路径解决是用getResourceAsStream()替代Filenew File(img/sub.png)在 IDE 里能读到因为文件在磁盘上打成 jar 后图片在压缩包里File找不到。正确做法是用getResourceAsStream()拿输入流再交给ImageIO.read()。这个改动涉及所有资源加载处建议一开始就用流的方式写省得后面返工。6. 进阶技巧把潜艇大战源码变成可展示的作品跑通、改完、避完坑之后如果你想让这个项目在简历或作品集里拿得出手还有一步值得做加一个简单的数据持久化把最高分存到本地文件。用Properties或JSON都行我一般用Properties因为 Java 标准库直接支持不引额外依赖。// 读取最高分 private int loadHighScore() { Properties props new Properties(); try (InputStream in new FileInputStream(save.properties)) { props.load(in); return Integer.parseInt(props.getProperty(highScore, 0)); } catch (IOException e) { return 0; // 文件不存在时返回 0 } } // 保存最高分 private void saveHighScore(int score) { Properties props new Properties(); props.setProperty(highScore, String.valueOf(score)); try (OutputStream out new FileOutputStream(save.properties)) { props.store(out, submarine game save); } catch (IOException e) { e.printStackTrace(); } }这段代码用了 try-with-resources流会自动关闭不用手写finally。save.properties存在工作目录下和 jar 同级。游戏结束时比较当前分和最高分超过就调用saveHighScore。这个功能代码量不到 30 行但让项目从「一次性 demo」变成了「有记忆的游戏」展示时也多了个可讲的点。另一个提升展示效果的是加音效。Java 标准库支持Clip播放 wav 格式AudioSystem.getClip()拿到 clip 后open()音频流再start()。注意音效文件别太大否则加载会卡顿短促的 wav 最合适。播放和停止要成对背景音乐循环播放时记得在游戏结束时stop()不然关了窗口声音还在。最后说个我自己的习惯每改完一个功能就提交一次 gitcommit message 写清楚改了什么、为什么改。潜艇大战这种小项目改着改着就容易忘记原始版本长什么样有版本记录随时能回退。我当初第一次改这类源码时没做版本管理加鱼雷加出 bug 后想退回原始版本结果只能重新下一份血泪经验。希望这些能帮到你少走点弯路。本文还有配套的精品资源点击获取