简介：面向初学Java与数据结构的学生，这份大一下课程设计实现经典“森林冰火人”双人联机玩法，覆盖GUI开发、事件响应、双人协作逻辑等知识点，适合作为Java大作业或算法练手项目。压缩包共68个文件，约2.42MB，其中包含11个java源码、15个class编译文件、7个gif动画与31张jpg/png图片素材，另有properties配置、xml工程文件和README说明文档，目录结构清晰，便于直接导入运行和学习。程序已经过测试可正常运行，源码与资源文件齐全，读者可对照代码理解界面绘制、角色控制和联机交互的实现思路，也可在此基础上扩展功能完成课程设计。目前已有698人学习下载，适合需要快速上手Java GUI小游戏开发的同学参考。
1. 双人联机森林冰火人：大一下最有“项目感”的Java练手目标
班里三十个人交Java大作业，二十八个是图书管理系统和计算器，剩下一两个敢碰联机小游戏的，基本就是高分预定。不是因为他们代码写得有多花哨，而是“大一下”这个阶段，能把Java基础、面向对象、集合框架、多线程、Socket网络编程、Swing界面这些东西同时串进一个能玩的项目里，本身已经说明你把这些知识点学活了。森林冰火人这个选题最讨巧的地方在于：它规则足够简单——火人和冰人各自行动、互相配合过关，但“双人联机”这四个字又把难度从单机搬到了两台电脑之间的实时通信上。这篇笔记就按我后来带学弟学妹做这个题目的完整套路，把方案选型、核心代码、踩坑记录和打包交付一次讲完。
2. 联机方案怎么选：Swing界面上跑TCP，别想复杂了
2.1 为什么大作业首选Socket：Netty、RMI这些不是不香，是答辩时说不清
很多同学一上来就搜“Java 联机游戏 框架”，看到Netty、RMI、WebSocket一脸兴奋，觉得用了这些才显高级。但你要清楚大作业的验收逻辑：老师看重的是你能否把代码讲清楚、能否现场演示、能否说清每一步为什么这么写。Netty的Reactor线程模型你解释起来费劲，RMI的远程调用在某些网络环境下配置起来让你抓狂，最后发现全部精力耗在环境上而不是游戏本身，这就是典型的“技术选型脱离场景”。
大一下阶段做双人联机，我的建议只有一条：用Java自带的ServerSocket和Socket，跑TCP协议，消息格式用简单的文本协议。TCP自带连接管理、可靠传输、数据有序到达，你不用处理丢包重传；文本协议调试时一眼能看懂，抓个包就能排查问题。UDP虽然传输更快，但大作业不需要那点性能优势，反而要自己处理丢包、乱序、连接状态，纯给自己挖坑。至于端口，选一个像6000这样的高位端口，避开容易被占用的8080、3306，也避开了需要管理员权限才能绑定的1024以下端口。
2.2 主机-客户端结构：把服务端代码和客户端代码拆成两个类
联机方案定为TCP之后，第一个动作是决定连接拓扑。双人联机最简单可靠的形式是“一主一从”：一方启动服务器作为主机，另一方填IP地址和端口作为客户端加入。这个模式不需要独立的服务器机器，主机既跑游戏又做转发，对森林冰火人这种每秒钟只同步几次状态的慢节奏游戏来说，负载完全可控。
服务端的核心逻辑就是监听端口、等客户端连入、握手成功后进入游戏转发状态。我用一个单独的GameServer类来管理，避免和客户端代码混在一起。最小可运行的监听代码大概是这样的：
// GameServer.java —— 仅保留核心监听与连接建立 import java.io.*; import java.net.*; import java.util.concurrent.CopyOnWriteArrayList; public class GameServer { private ServerSocket serverSocket; // CopyOnWriteArrayList：遍历时允许并发修改，安全性比ArrayList好 private static CopyOnWriteArrayList<Socket> clients = new CopyOnWriteArrayList<>(); public void start(int port) throws IOException { serverSocket = new ServerSocket(port); System.out.println("服务器已启动，等待玩家加入..."); while (true) { Socket socket = serverSocket.accept(); // 阻塞等待客户端连接 clients.add(socket); System.out.println("玩家接入：" + socket.getInetAddress().getHostAddress()); // 每个客户端单独开一个线程处理收发，防止一个客户端阻塞影响另一个 new Thread(() -> handleClient(socket)).start(); } } private void handleClient(Socket socket) { try (BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream(), "UTF-8"))) { String msg; while ((msg = in.readLine()) != null) { broadcast(msg, socket); } } catch (IOException e) { System.out.println("客户端断开：" + socket.getInetAddress()); } finally { clients.remove(socket); try { socket.close(); } catch (IOException ignored) {} } } private void broadcast(String message, Socket from) { for (Socket s : clients) { if (s == from) continue; // 不回传给发送者，由本地直接执行 try { PrintWriter out = new PrintWriter( new OutputStreamWriter(s.getOutputStream(), "UTF-8"), true); out.println(message); } catch (IOException e) { System.out.println("转发失败：" + s.getInetAddress()); } } } public static void main(String[] args) throws IOException { new GameServer().start(6000); } }代码的逻辑很清楚：accept()阻塞等待玩家，每连上一个就存入clients列表并新建线程处理，handleClient循环读取一行消息，读到了就通过broadcast转发给另一个玩家。注意PrintWriter的第二个参数true表示自动刷新，不写这个参数你发出去的数据会因为缓冲不到达对端，这是新手最容易忽略的细节。另外，我在输入输出流的构造里都明确指定了UTF-8编码，后面打包运行时乱码问题就少了一半。
2.3 消息协议：先握手，再同步状态
服务端转发什么消息、按什么格式转发，这决定了整个联机系统的复杂度。我的选择是“按键指令同步”：客户端把玩家自己的操作实时发过去，对端收到后解析、驱动对端屏幕上的角色移动。消息格式极其简单，一行字符串，用竖线分割类型和参数，例如：
move|PLAYER1|left|1 jump|PLAYER1|1不需要序列化对象，不需要JSON库，手写解析加拼接不超过二十行。为什么不用ObjectOutputStream直接传对象？因为不同JDK版本之间序列化兼容性有时候很微妙，而且肉眼不可见，排错难度大。文本协议打开控制台就能看到消息在跑，课堂演示时说“看，我这里按了D键，消息就发出去了”，说服力拉满。
客户端的连接代码对应如下，连接成功后立即进入游戏主界面：
// GameClient.java —— 建立连接并启动读线程 import java.io.*; import java.net.*; public class GameClient { private Socket socket; private BufferedReader in; private PrintWriter out; private GamePanel panel; // 后面第4章会写的画面类 public void connect(String serverIp, int port) throws IOException { socket = new Socket(serverIp, port); in = new BufferedReader(new InputStreamReader( socket.getInputStream(), "UTF-8")); out = new PrintWriter(new OutputStreamWriter( socket.getOutputStream(), "UTF-8"), true); System.out.println("连接成功：" + serverIp + ":" + port); // 读线程持续接收服务器转发过来的对方操作 new Thread(() -> { String msg; try { while ((msg = in.readLine()) != null) { if (panel != null) panel.handleRemoteMessage(msg); } } catch (IOException ignored) {} }).start(); } public void sendMove(String direction) { out.println("move|" + direction); } }参数说明里有两个点值得注意。第一是连接超时，Socket构造器如果不指定超时，连接不上时会卡住十几秒甚至更久，我建议connect前先调socket.setSoTimeout(3000)，连不上就快速报错；第二是IP地址，客户端连接时填的是主机的局域网IP，不是自己的IP，这个错误我见过至少五次，两台机器连不上先看这个。心跳消息我在这个最小实现里没有加，但正式提交时建议每两秒发一行heartbeat，服务端八秒没收到就判定掉线并通知另一端。
3. 森林冰火人的玩法核心：一个“世界”两份逻辑
3.1 双角色机制是道很好的状态机题
森林冰火人的核心规则提炼出来其实很清晰：火人能走过火池、但不能碰冰池；冰人能走过冰池、但不能碰火池；有些门需要两人站到对应的两个机关上才会打开。这套机制特别适合用面向对象表达。不要在一张Map里塞一堆String，把角色行为和状态封装成两个类，代码可读性会提升一个档次。
我一般这么组织数据结构：一个GameWorld类保存整个关卡的地图二维数组，每个格子的类型用枚举定义；FirePlayer和IcePlayer各自持有自己的坐标和一个“当前能走的格子集合”：
// GameWorld.java —— 地图格类型定义与角色移动判断 public class GameWorld { // 格子类型：FIRE_FLOOR 火池，ICE_FLOOR 冰池， // NORMAL 普通地砖，WALL 墙，GATE 门，SWITCH 机关 public enum TileType { FIRE_FLOOR, ICE_FLOOR, NORMAL, WALL, GATE, SWITCH } private TileType[][] map; // 行列二维数组，行是y方向，列是x方向 private int rows, cols; public GameWorld(TileType[][] map) { this.map = map; this.rows = map.length; this.cols = map[0].length; } // 判断角色能否移动到目标格子 public boolean canMove(int x, int y, boolean isFirePlayer) { if (x < 0 || y < 0 || x >= cols || y >= rows) return false; // 越界 TileType tile = map[y][x]; if (tile == TileType.WALL) return false; // 属性克制判断：火人过火池、冰人过冰池都是安全的 if (tile == TileType.FIRE_FLOOR) return isFirePlayer; if (tile == TileType.ICE_FLOOR) return !isFirePlayer; return true; } }这段代码把整个游戏的碰撞规则压缩到了一个方法里，后续移动、AI寻路、联机同步都复用它。注意棋盘类游戏坐标系和屏幕坐标系很容易搞混：这里x对应列、y对应行，二维数组第一层是行也就是y方向。代码里我特意给参数顺序写了注释，因为真的有人在传参时把map[y][x]写成map[x][y]，然后角色贴图全乱套。
3.2 碰撞检测：用“目标格判定”而不是像素检测
森林冰火人的移动逻辑走的是网格制——角色从一格走到另一格，不是像素级自由移动。这极大简化了碰撞检测：不需要矩形相交算法，不需要考虑贴图边缘的像素重叠，只需要判断“目标位置那个格子里有没有障碍”。这就是我在canMove里的做法，逐格判定替换成整个碰撞系统的唯一入口。
移动的执行方法写起来顺手很多，以火人为例：
// FirePlayer.java —— 角色移动与机关触发逻辑 public class FirePlayer { private int x, y; // 当前所在格子坐标 private boolean isAlive = true; public boolean move(int dx, int dy, GameWorld world) { if (!isAlive) return false; int newX = x + dx; int newY = y + dy; if (!world.canMove(newX, newY, true)) return false; // 火人传入true x = newX; y = newY; // 踩到机关：通知世界对象更新门状态 world.onPlayerStep(x, y); return true; } public boolean isOnSwitch(GameWorld world) { return world.getTile(x, y) == GameWorld.TileType.SWITCH; } }参数dx和dy取值就是{-1, 0, 1}，一次只传一个方向。这个设计让上下左右四个方向的按键处理代码对称，不会出现“按D往左跑”的经典bug。机关的联动需要在GameWorld里维护一个“当前激活的机关数量”计数器，当两个机关都被踩住时开门，有一个松开就关门。这里有个小设计：如果追加“只有冰人踩的机关才算数”这类条件，就把角色类型也传进onPlayerStep，这对大作业拿加分很有效，因为老师最喜欢问“你这个机关的触发条件能不能改”。
3.3 同步的真相：别人动什么，你只播什么
联机同步方案我选择的是“指令同步+本地即时执行”，这是网络游戏领域最常见的技术路径之一。每个客户端对自己控制的角色有绝对权威，按键按下的一瞬间本地角色立即移动、画面立刻响应，同时把移动消息通过服务器转发给另一端；对方收到消息后，把对应的角色移动到指定坐标，但不会把这个角色的行为当作输入再回传。这种方案的好处是玩家体验极佳，不用等网络回来，坏处是如果两台机器状态差异变大，会出现“我看到他在左边，你看到他在右边”的现象。
在类设计上要守住一条线：本地玩家的操作直接调用自己的move方法，远端玩家的操作则走GamePanel.handleRemoteMessage。我给两个角色分别命名firePlayer和icePlayer，消息里带上角色标识，解析消息时按标识路由到正确的实例上：
// GamePanel.java 中消息路由的关键片段 public void handleRemoteMessage(String msg) { String[] parts = msg.split("\\|"); if (parts.length < 2) return; if ("move".equals(parts[0])) { String direction = parts[1]; int dx = 0, dy = 0; switch (direction) { case "left": dx = -1; break; case "right": dx = 1; break; case "up": dy = -1; break; case "down": dy = 1; break; default: return; } // 远端玩家是火人还是冰人，决定调用哪个实例 if ("fire".equals(parts[2]) && firePlayer != null) { firePlayer.move(dx, dy, world); } else if ("ice".equals(parts[2]) && icePlayer != null) { icePlayer.move(dx, dy, world); } repaint(); } }一个关键设计点是在同步时不携带“目标坐标”，只携带“移动方向”。原因是坐标依赖状态，如果对端状态已经有偏差，传坐标会把偏差固定下来；传方向让对端同样基于自己的世界状态去计算新位置，网络抖动导致的一两帧偏差会被后续操作自然纠正。这个思路在答辩时提出来非常加分，它直接亮出了你对联机系统和状态一致性的理解深度。
4. Swing渲染与双人输入：别让你的游戏“看起来”像控制台程序
4.1 Swing跑游戏主循环的三个约定：EDT、Timer、双缓冲
图形界面如果做得糙，联机做得再好也白搭。大一下的Java课，Swing是你唯一能稳稳拿分的选择——JavaFX虽然也能做，但多数学校的课程里根本没教过，答辩时老师一眼就能看出你是在课外补的，反而容易问倒你。Swing做游戏界面的核心不是“会建窗口”，而是懂三条约定。
第一条约定是UI操作全部在事件分发线程（EDT）里执行，不要在接收Socket消息的线程里直接调repaint，那会触发跨线程访问Swing组件的并发问题，轻则界面闪烁、重则直接抛异常。我一般做法是：在GamePanel里维护一个“待处理消息队列”，网络读线程往里塞消息，EDT的定时器每次tick时从队列取消息并更新画面。
第二条约定是游戏循环用Swing的javax.swing.Timer而不是while(true)死循环。Timer反复触发actionPerformed作为一帧，默认间隙16毫秒约60帧，完全够用。而真正的死循环会卡住EDT，窗口拖动、按钮点击全部假死。这个坑我在第一次做贪吃蛇时踩过，进程还在跑，界面已经无响应了。
第三条约定是双缓冲，Swing的JPanel默认就是双缓冲的，你只要不手贱重写update方法就不会闪。绘制时也尽量在paintComponent里全量重绘，不要试图“只画变化的部分”，省不了多少性能还容易画花。
4.2 键盘监听：KeyListener丢焦点怎么办
双人联机意味着要对两个玩家的键盘输入做区分。如果是两台电脑联机，这个问题很简单——每台电脑各管各的键盘，本机按键控制本机角色。但如果是“一台电脑上双人玩”的本地模式，你就需要给两个玩家分配不同的按键，比如玩家1用WASD，玩家2用方向键。这里最大的坑是KeyListener绑定在组件上，一旦焦点被按钮或输入框抢走，监听就没用了。
我推荐的做法是给两个玩家各维护一个boolean[4]的按键状态数组，然后用KeyAdapter做按下和释放的回调，在有焦点问题的组件上主动补requestFocusInWindow()：
// GamePanel.java —— 键盘输入监听与按键状态维护 import javax.swing.*; import java.awt.event.*; public class GamePanel extends JPanel { private boolean[] p1Keys = new boolean[4]; // 玩家1：WASD private boolean[] p2Keys = new boolean[4]; // 玩家2：方向键 // 按键映射：索引0=上，1=下，2=左，3=右 private int[][] bindings = { {KeyEvent.VK_W, KeyEvent.VK_S, KeyEvent.VK_A, KeyEvent.VK_D}, {KeyEvent.VK_UP, KeyEvent.VK_DOWN, KeyEvent.VK_LEFT, KeyEvent.VK_RIGHT} }; public GamePanel() { // 必须Focusable才能接收键盘事件 setFocusable(true); addKeyListener(new KeyAdapter() { @Override public void keyPressed(KeyEvent e) { handleKey(e.getKeyCode(), true); } @Override public void keyReleased(KeyEvent e) { handleKey(e.getKeyCode(), false); } }); } private void handleKey(int keyCode, boolean pressed) { for (int player = 0; player < 2; player++) { for (int i = 0; i < 4; i++) { if (keyCode == bindings[player][i]) { p1Keys[i] = pressed; // 这里只写了p1，实际应该按player分开写 } } } } }注意上面示例里我是用p1Keys数组示范按键判定的逻辑，实际写代码时应该改成二维数组pressed[2][4]，第一个维度是玩家序号，第二个维度是方向索引。两个玩家同时按键时不会互相覆盖，因为两个玩家的按键映射是分离的，哪怕他们在同一台电脑上操作也不会冲突。其实在联机模式下，本机只处理一个玩家的输入，本地模式才用这套双玩家绑定，我想强调的还是“按键状态不丢”这个核心问题——pressed和released是成对事件，只处理按下不处理释放，角色就会“跑起来停不住”。
4.3 画面渲染顺序：先地板，再机关，再角色
绘制顺序有一点模式化的经验：先把整个地图块根据类型画出来，再画机关和门，最后画两个角色，另外角色身上标清名字，区分谁是谁。这样迭代顺序清晰：从底层往上叠，后面的绘制内容会盖住前面的，角色永远显示在地图之上。
坐标换算的逻辑值得单独说明。地图是行列的抽象世界，画到屏幕上需要乘上瓷砖的像素宽高。我习惯把瓷砖尺寸设成40像素，一个13x11的关卡正好是520x440像素的窗口。关键参数是瓷砖尺寸必须统一在一处定义，不要散落在地图类、绘制类、碰撞类里各写一遍，后期调尺寸时只改一个常量：
public static final int TILE_SIZE = 40; protected void paintComponent(Graphics g) { super.paintComponent(g); for (int y = 0; y < world.getRows(); y++) { for (int x = 0; x < world.getCols(); x++) { // 根据tile类型挑选颜色或贴图 java.awt.Rectangle rect = new java.awt.Rectangle( x * TILE_SIZE, y * TILE_SIZE, TILE_SIZE, TILE_SIZE); g.setColor(switchColor(world.getTile(x, y))); g.fillRect(rect.x, rect.y, rect.width, rect.height); } } // 最后画角色：使用角色世界坐标乘以瓷砖尺寸换算屏幕位置 if (firePlayer != null) { g.setColor(java.awt.Color.ORANGE); g.fillOval(firePlayer.getX() * TILE_SIZE, firePlayer.getY() * TILE_SIZE, TILE_SIZE, TILE_SIZE); } // icePlayer同理，用蓝色绘制 }这里我用fillOval先顶替角色贴图，等美术资源准备好后再换成Image绘制。逻辑不变，先把框架跑起来，再美化，这个节奏更适合大作业这种时间紧、目标为“能交、能演示”的场景。
5. 联机森林冰火人最容易翻车的5个地方
5.1 现象：两台电脑连不上，客户端卡住不动
表现是输入IP和端口点连接后，界面没反应，过十几秒才报超时。原因有两类：一是IP地址填错，明明主机的局域网IP是192.168.1.20，填成192.168.1.2，或者填了127.0.0.1指向本机；二是主机的防火墙拦截了Java进程的入站端口，Windows默认会拦。解决方法是先ping主机的IP确认网络通，再关闭主机的防火墙或单独放行6000端口，最后确认客户端填的确实是主机的IP而不是自己的IP。这个坑在现场演示时出现概率极高，强烈建议正式答辩前用两台真实电脑完整演练一遍，并且把“关闭防火墙”写进README。
5.2 现象：画面严重闪烁，角色拖影
表现是游戏窗口像老式电视在闪，角色旁边拖着残影。原因是paintComponent里没有清屏，或者线程模型跑飞了。很多人以为多画几笔是闪的原因，其实更常见的是在非EDT线程里调了repaint反复触发重绘，和Swing的计时器打架。解决方法是确保所有画面更新都走javax.swing.Timer的actionPerformed，不要在Socket读线程里直接调repaint；同时检查是否在paintComponent第一行调super.paintComponent(g)，这一步负责把上次的画面清干净。双缓冲的事Swing默认做好了，不用自己动手，反而是这些习惯问题更值得注意。
5.3 现象：角色松开按键还在继续跑
表现是角色像“有惯性”一样，按下方向键松开后它还在走。原因是只处理了keyPressed，没有处理keyReleased。Swing不会自动记住你的按键状态，按下和抬起是两个独立事件，不处理抬起事件，按键状态就一直认为还是按着的。解决方法是补全KeyAdapter的keyReleased，把对应方向的状态置为false。另一个隐蔽原因是焦点被切走，窗口失焦后keyReleased事件没有触发，所以出现“走丢了”的假象，比较稳妥的做法是在窗口失焦时把所有按键状态清零。
5.4 现象：服务端退出后端口还占用，第二次启动报BindException
表现是第一次运行完关掉程序，再启动时报java.net.BindException: Address already in use。原因是Socket和ServerSocket没有关干净，进程虽然结束了，但操作系统还在TIME_WAIT状态。解决方法是两点：一是程序里保证退出时调用socket.close()和serverSocket.close()；二是用try-with-resources包裹连接对象，即使异常退出也会自动关闭。如果还是占着端口，Windows下netstat -ano查进程号和PID，再taskkill强制结束，这是运维习惯，不是程序问题。
5.5 现象：打包成JAR后中文全部变成问号
表现是双击JAR运行，游戏里的“开始”“设置”“得分”全部变成乱码。原因特别简单，编译时的字符编码和打包时的编码不一致，或者运行时JVM没使用UTF-8解析。解决方法统一从三个层面处理：所有.java源文件保存为UTF-8编码；编译命令javac -encoding UTF-8；运行命令java -Dfile.encoding=UTF-8 -jar。另外，第2章代码里我特意给输入输出流都指定了UTF-8，如果不写，Windows默认GBK，Socket跨平台传中文开关消息时就会乱。这个坑很多人要拖到答辩前一晚才遇到，早点处理能省一整晚的睡眠。
6. 从能玩到能交：打包、验收与一点优化习惯
代码写完了，接下来要干的事是让老师能一键跑起来。不要默认老师会用IntelliJ IDEA打开你的代码，很多老师习惯命令行跑。我建议你交付时给出两个入口：一个提供可执行的JAR包，另一个保留源码目录结构。
打包最简单的路线是IDEA的Artifacts功能：File -> Project Structure -> Artifacts -> JAR -> From modules with dependencies，选择包含main方法的类（建议做一个专门的GameLauncher入口类，同时提供“创建主机”和“加入主机”两个按钮，避免玩家需要命令行传参），构建完就能得到一个独立运行的JAR。命令行下验证这套交付物是否合格只需三步：
# 第一步：确认JDK版本满足要求 java -version # 第二步：启动服务端/主机 java -Dfile.encoding=UTF-8 -jar ForestAndFireBoy.jar # 第三步：另一台机器连接 java -Dfile.encoding=UTF-8 -jar ForestAndFireBoy.jar --join 192.168.1.20验收时给自己列一个清单逐项打勾：两台电脑防火墙是否放行、主机能创建房间、客户端能加入、双人在各自屏幕都能看到两个角色同时移动、门和机关状态一致、掉线时另一端有提示不崩溃、窗口关闭后Java进程真的退出（这个很好检查，任务管理器里看有没有残留的java进程）。这些跑通了，大作业的现场演示就成功了一大半。
最后说两个容易被忽视但会让老师眼前一亮的小优化。第一个是消息收敛：联机同步时不要每帧发消息，而是检测到按键状态变化时再发，否则一秒几十条无意义消息会暴露你的性能设计短板。第二个是给游戏加一个简单的暂停逻辑：双方都按空格才继续，这个实现不难，但体现的是对游戏体验细节的思考，答辩时你能主动讲出这两条，就说明你不是在“交作业”，而是在“做项目”。
我自己当年这个题目做砸过一个小细节：主机端一切正常，客户端角色移动总比主机慢半拍。查了一晚上，最后发现是发送消息时每次都new了一个PrintWriter，导致输出流被反复重建和关闭。后来统一改成在连接建立时创建一次、持有复用，问题立刻消失。这种教训你遇过一次就会长记性，所以我特别建议你在写联机模块时就先设计好流的生命周期，不要等功能跑通再回头优化。做这样的项目，本来就该先犯错再修复，在试错里把Java基础、网络编程和调试手段一起练扎实。希望帮你避开我当年那些不必要的坑，让你把时间花在真正拉开差距的玩法设计和答辩展示上。
本文还有配套的精品资源，点击获取
