简介这份资源是面向高校计算机相关专业学生的Java课程设计参考项目主题为双人联机小游戏森林冰火人适合作为期末大作业、课程设计或毕业设计的完整实现方案也适合刚接触Java游戏开发、希望理解联机逻辑与图形界面编程的初学者研读。压缩包共67个文件约2.42MB其中11个java源文件承载核心游戏逻辑与网络通信代码15个class为编译产物另有25张jpg、7个gif与6张png构成角色、地图与界面素材2个properties与1个xml负责配置与项目描述整体结构清晰、便于二次修改。项目代码附有注释部署后即可运行功能完善、界面美观、操作简单导师认可度较高。目前已有238人学习关注读者可从中获得完整的双人联机游戏实现思路、客户端与服务端交互参考、素材组织方式以及可直接复用的课程设计框架对快速完成高分大作业具有实际参考价值。1. 一份能跑起来的 Java 大作业双人联机森林冰火人源码拆解期末周最让人头大的不是考试是导师甩过来一句“大作业做个有交互的东西”。单机版森林冰火人网上一抓一大把但要求里带“双人联机”四个字难度直接翻倍——Socket 通信、状态同步、线程安全随便一个点没处理好就是满屏红字。这份 Java 大作业源码把双人联机小游戏森林冰火人做成了完整可运行的项目基于 Java Swing Socket 实现包含服务端和客户端两套逻辑代码带注释pom.xml 依赖清晰导入 IDEA 配好 JDK 就能跑。适合正在找 java 课程设计案例源码、需要交期末大作业或毕设初稿的同学也适合想拿一个真实网络编程案例练手的 java 基础进阶者。它不是玩具 demo而是有地图、有碰撞、有双人实时同步的完整小游戏。2. 先看架构再动手Swing 渲染 Socket 同步是怎么搭起来的2.1 为什么是 C/S 结构而不是单机改双人很多人第一反应是“我拿个单机版加个键盘监听不就行了”。翻车点在于两个玩家在两台机器上游戏状态存在谁那里如果各自维护一份地图和角色坐标A 踩了机关 B 那边不知道画面直接对不上。这份源码采用的是典型 C/S 架构——服务端持有权威游戏状态客户端只负责发送输入指令和渲染画面。服务端跑一个固定帧率的游戏循环每帧收集两个客户端的按键状态更新角色位置、检测碰撞、判断机关触发然后把完整状态广播给两个客户端。客户端收到状态后只做一件事画出来。这个选型的理由很直接状态只有一份不存在同步冲突。代价是服务端压力大、延迟敏感但对于课程设计级别的双人小游戏局域网或本机双开完全够用。常见做法是用 TCP 而不是 UDP因为森林冰火人的操作频率不高TCP 的可靠性比 UDP 的低延迟更重要——丢一个“跳”的指令角色就卡在火坑里了。2.2 项目目录结构与关键类职责拿到压缩包解压后目录大致是这样Java-task-main/ ├── pom.xml ├── src/ │ └── main/ │ └── java/ │ ├── server/ │ │ ├── GameServer.java │ │ ├── ClientHandler.java │ │ └── GameLoop.java │ ├── client/ │ │ ├── GameClient.java │ │ ├── GamePanel.java │ │ └── InputHandler.java │ ├── common/ │ │ ├── GameState.java │ │ ├── Player.java │ │ └── Message.java │ └── map/ │ ├── TileMap.java │ └── Tile.java ├── images/ │ ├── fireboy.png │ ├── watergirl.png │ ├── tile_*.png │ └── ... └── target/几个核心类的职责需要先理清楚不然后面改代码会迷路类名所在包职责GameServerserver启动 ServerSocket接受两个客户端连接ClientHandlerserver每个客户端一个线程负责收发该客户端的消息GameLoopserver固定帧率循环驱动游戏逻辑更新GameStatecommon可序列化的游戏状态快照含两个 Player 和地图状态GamePanelclientSwing 面板负责将 GameState 渲染成画面InputHandlerclient键盘监听将按键转为指令发给服务端服务端和客户端共用 common 包下的类这是关键设计——GameState 和 Message 需要序列化后走网络传输两端必须用同一份类定义。pom.xml 里没有引入额外的网络框架纯 Java 原生 Socket ObjectOutputStream/ObjectInputStream对新手友好不需要理解 Netty 或 Spring 那套东西。2.3 环境准备与首次运行在动手改代码之前先把项目跑起来。需要 JDK 8 或以上Maven 3.6IDEA 社区版就够。# 1. 确认 JDK 版本建议 8 或 11 java -version # 2. 进入项目根目录编译打包 cd Java-task-main mvn clean package -DskipTests # 3. 确认 target 目录下生成了可运行的 jar ls target/*.jar编译通过后运行顺序很重要先启动服务端再启动两个客户端。在 IDEA 里可以配置三个 Run Configuration分别指向 GameServer 的 main 方法和 GameClient 的 main 方法启动两次。# 命令行方式启动服务端默认端口 8888 java -cp target/classes server.GameServer # 另开两个终端分别启动客户端 java -cp target/classes client.GameClient java -cp target/classes client.GameClient如果客户端连不上先检查服务端是否已经监听在 8888 端口。Windows 下用netstat -an | findstr 8888Linux/Mac 用lsof -i :8888。端口被占用的话改 GameServer 里的 PORT 常量同时改客户端连接地址里的端口号两边必须一致。注意images 目录的路径在代码里可能是相对路径如果你从 target/classes 启动需要把 images 目录复制到工作目录下或者改代码里的资源加载路径为绝对路径。这是新手最容易卡住的地方。3. 核心机制拆解碰撞检测、机关触发与双人状态同步3.1 瓦片地图与 AABB 碰撞检测森林冰火人的地图不是一张整图而是由瓦片Tile拼出来的。每个 Tile 有类型空地、火池、水池、毒池、墙壁、可推动箱子、按钮、门。火男孩能走火池但不能碰水池水女孩反过来毒池两个都不能碰。这套规则全部在服务端的碰撞检测里实现。碰撞检测用的是 AABB轴对齐包围盒因为角色和瓦片都是矩形不需要复杂的物理引擎。核心逻辑在 GameLoop 的 update 方法里// 简化的碰撞检测逻辑实际代码在 GameLoop.java 中 public void updatePlayerPosition(Player player, int dx, int dy) { // 先尝试水平移动 Rectangle newBounds new Rectangle( player.getX() dx, player.getY(), player.getWidth(), player.getHeight() ); if (!checkTileCollision(newBounds, player.getType())) { player.setX(player.getX() dx); } // 再尝试垂直移动 newBounds new Rectangle( player.getX(), player.getY() dy, player.getWidth(), player.getHeight() ); if (!checkTileCollision(newBounds, player.getType())) { player.setY(player.getY() dy); } } private boolean checkTileCollision(Rectangle bounds, PlayerType type) { // 遍历与 bounds 相交的所有 Tile for (Tile tile : getTilesInRect(bounds)) { if (tile.isSolid()) return true; // 墙壁 if (tile.isLethalFor(type)) return true; // 属性相克的液体 } return false; }这里有个细节水平和垂直分开检测是为了实现“贴墙滑动”效果。如果合并检测角色碰到墙壁斜角时会直接卡死手感很差。参数方面dx 和 dy 是每帧的位移量通常由移动速度常量决定比如 SPEED 4 像素/帧。帧率固定在 60 FPS 时角色移动速度就是 240 像素/秒这个值可以根据地图大小调整。3.2 机关与按钮的状态同步游戏里的按钮、拉杆、可推动箱子状态都保存在服务端的 GameState 里。当火男孩踩上按钮时服务端检测到角色与按钮 Tile 重叠把按钮状态设为“按下”同时检查这个按钮关联的门是否应该打开。门的开闭状态也是 GameState 的一部分每帧广播给客户端。// 按钮触发逻辑在 GameLoop 中每帧调用 private void checkButtonTriggers() { for (Button button : gameState.getButtons()) { boolean pressed false; for (Player player : gameState.getPlayers()) { if (player.getBounds().intersects(button.getBounds())) { pressed true; break; } } // 只有状态变化时才更新减少不必要的网络传输 if (button.isPressed() ! pressed) { button.setPressed(pressed); // 更新关联门的状态 for (Door door : gameState.getDoors()) { if (door.getButtonId() button.getId()) { door.setOpen(pressed); } } } } }注意if (button.isPressed() ! pressed)这个判断——状态没变就不更新避免每帧都修改 GameState 导致广播的数据量无意义增大。这是网络游戏里很常见的优化思路虽然课程设计级别不一定需要但养成这个习惯对后面做更大的项目有好处。3.3 网络消息协议与序列化客户端和服务端之间的通信消息定义在 Message 类里包含消息类型和负载数据。消息类型有玩家输入上下左右跳、游戏状态同步、玩家加入/离开、游戏结束。用 Java 原生序列化实现简单直接。// Message.java 的结构示意 public class Message implements Serializable { private static final long serialVersionUID 1L; private MessageType type; private Object payload; // 工厂方法创建输入消息 public static Message input(PlayerInput input) { Message msg new Message(); msg.type MessageType.INPUT; msg.payload input; return msg; } // 工厂方法创建状态同步消息 public static Message state(GameState state) { Message msg new Message(); msg.type MessageType.STATE; msg.payload state; return msg; } }serialVersionUID必须显式声明否则两端编译版本不一致时会抛 InvalidClassException。这是血泪经验——你改了 common 包里的类客户端没重新编译连上去就崩。参数方面PlayerInput 里存的是按键的布尔状态上、下、左、右、跳每帧客户端把当前按键状态发一次服务端收到后更新对应玩家的输入缓存。提示如果要做局域网联机把客户端连接地址从 127.0.0.1 改成服务端的局域网 IP 即可。防火墙记得放行对应端口Windows Defender 默认会拦。4. 避坑与排查从连不上到画面撕裂的五个真实问题4.1 客户端启动报 Connection refused现象客户端一运行就抛异常提示 Connection refused: connect。原因服务端没启动或者端口号不一致或者服务端绑定的 IP 是 127.0.0.1 而客户端连的是局域网 IP。解决先确认服务端已经跑起来并且打印了“Server started on port 8888”之类的日志。然后检查客户端代码里 SERVER_IP 和 SERVER_PORT 两个常量确保和服务端一致。如果服务端绑定的地址是new ServerSocket(8888)它默认监听所有网卡局域网内其他机器可以连如果写的是new ServerSocket(8888, 50, InetAddress.getByName(127.0.0.1))那就只能本机连。4.2 两个客户端画面不同步一个角色瞬移现象A 客户端看到火男孩已经跳到对面平台了B 客户端看到火男孩还在原地过一会儿突然瞬移过去。原因网络延迟导致状态包到达时间不一致或者服务端广播时没有按固定顺序发送。更常见的原因是客户端在本地也做了预测移动收到服务端状态后又强行拉回产生抖动。解决这份源码的客户端是纯状态同步不做本地预测所以正常情况下不会瞬移。如果出现检查服务端 GameLoop 的帧率是否稳定——如果用了Thread.sleep(16)但实际循环体执行时间超过 16ms帧率会掉状态更新变慢。可以在循环里加一个时间补偿逻辑或者把 sleep 时间改为动态计算。另外确认两个客户端连的是同一个服务端实例别一个连本机一个连局域网另一台机器。4.3 角色卡在墙角或穿过薄墙现象角色贴着墙壁走的时候偶尔卡住不动或者速度太快时直接穿过一格厚的墙。原因AABB 碰撞检测是离散的如果每帧位移量大于墙壁厚度就会“隧穿”。另外水平垂直分开检测时如果先水平移动把角色推进了墙里再垂直移动时可能因为已经在墙内而无法脱出。解决把移动速度调小或者把墙壁厚度设为大于每帧位移量。更稳妥的做法是在移动前先做一次“如果移动后会碰撞就不移动”的判断而不是移动后再修正。源码里用的是预判式检测所以正常速度下不会穿墙。如果你改了 SPEED 常量记得同步检查地图里最薄墙壁的厚度。4.4 服务端只接受一个客户端第二个连不上现象第一个客户端正常进入游戏第二个客户端连接后没反应或直接断开。原因服务端只调用了一次serverSocket.accept()没有循环接受连接。或者 ClientHandler 线程启动后没有正确加入玩家列表。解决检查 GameServer 的 main 方法应该是while(true) { Socket socket serverSocket.accept(); new Thread(new ClientHandler(socket)).start(); }的结构。另外确认 GameState 里的 players 列表能容纳两个玩家有些实现里写死了只处理一个玩家。如果用的是线程池确认核心线程数至少为 2。4.5 图片资源加载失败画面全是色块现象游戏能跑角色能动但所有图片都显示不出来只有纯色矩形。原因images 目录不在 classpath 下或者代码里用的是相对路径而工作目录不对。IDEA 默认的工作目录是项目根目录命令行启动时是你执行 java 命令的目录。解决把 images 目录放到 src/main/resources 下用getClass().getResourceAsStream(/images/fireboy.png)加载。如果不想改代码就在启动时把工作目录切到 images 的父目录。命令行可以用-Duser.dir/path/to/project指定。最省事的办法是在 IDEA 的 Run Configuration 里把 Working directory 设为项目根目录。5. 进阶改造把课程设计变成能写进简历的项目5.1 加一个房间匹配机制现在的源码是“先到先得”服务端启动后前两个连上的客户端自动配对。如果想支持多局同时进行需要引入房间概念。每个房间有自己的 GameState 和 GameLoopClientHandler 在连接后先进入等待队列凑齐两人再创建房间。这个改造涉及服务端架构调整但核心思路不复杂把原来全局唯一的 GameState 改成 Room 对象持有GameLoop 也变成每个房间一个线程。// 房间管理器的简化示意 public class RoomManager { private final ListRoom waitingRooms new CopyOnWriteArrayList(); public synchronized Room joinOrCreate(Socket socket) { for (Room room : waitingRooms) { if (room.hasEmptySlot()) { room.addPlayer(socket); if (room.isFull()) { waitingRooms.remove(room); room.start(); } return room; } } Room newRoom new Room(); newRoom.addPlayer(socket); waitingRooms.add(newRoom); return newRoom; } }用 CopyOnWriteArrayList 是为了避免多线程遍历时并发修改。每个 Room 持有一个 GameState 和一个 GameLoop 线程玩家加入后启动循环。这个改造能让你的项目从“双人固定联机”升级为“多房间匹配”写在简历上比“实现了双人联机”有分量得多。5.2 用状态压缩减少网络传输量当前每帧广播完整的 GameState包含地图所有 Tile 的状态。地图大了之后每帧几 KB 的数据在局域网上没问题但如果你想改成公网联机或者移动端就需要压缩。常见做法是只同步变化的部分角色坐标、按钮状态、门状态地图静态部分只在客户端加载时传一次。// 增量状态包的结构 public class DeltaState implements Serializable { private int player1X, player1Y; private int player2X, player2Y; private ListButtonState changedButtons; private ListDoorState changedDoors; // 省略 getter/setter }服务端维护一个“上一帧状态”的副本每帧对比当前状态只把变化的字段打包发送。客户端收到后合并到本地状态再渲染。这个优化能把每帧数据量降到原来的十分之一左右。参数方面可以设置一个阈值变化小于 1 像素的位移不发送进一步减少包量。5.3 验证改造是否成功的三个检查点改完代码后别急着交。按下面三个检查点走一遍第一双开客户端后两个角色能独立移动互不干扰碰撞检测正常。第二让一个角色踩按钮另一个角色那边的门应该同步打开延迟不超过 100ms。第三关掉一个客户端服务端应该能检测到断开并通知另一个客户端而不是卡死或抛异常。如果要做多房间再加一条同时开四个客户端应该自动分成两个房间互不干扰。用jstack看一下服务端线程数每个房间一个 GameLoop 线程加上每个客户端一个 ClientHandler 线程四个客户端两个房间应该是 246 个业务线程数量对得上说明房间管理没泄漏。从那以后我每次拿到这种联机项目都先把服务端和客户端的消息协议画出来再动手改代码协议不清楚就改改到最后一定是玄学 bug。希望这份拆解能帮你把大作业顺利跑起来也帮你在导师面前多拿几分。本文还有配套的精品资源点击获取 Java大作业双人联机森林冰火人源码拆解：Swing+Socket实现
简介这份资源是面向高校计算机相关专业学生的Java课程设计参考项目主题为双人联机小游戏森林冰火人适合作为期末大作业、课程设计或毕业设计的完整实现方案也适合刚接触Java游戏开发、希望理解联机逻辑与图形界面编程的初学者研读。压缩包共67个文件约2.42MB其中11个java源文件承载核心游戏逻辑与网络通信代码15个class为编译产物另有25张jpg、7个gif与6张png构成角色、地图与界面素材2个properties与1个xml负责配置与项目描述整体结构清晰、便于二次修改。项目代码附有注释部署后即可运行功能完善、界面美观、操作简单导师认可度较高。目前已有238人学习关注读者可从中获得完整的双人联机游戏实现思路、客户端与服务端交互参考、素材组织方式以及可直接复用的课程设计框架对快速完成高分大作业具有实际参考价值。1. 一份能跑起来的 Java 大作业双人联机森林冰火人源码拆解期末周最让人头大的不是考试是导师甩过来一句“大作业做个有交互的东西”。单机版森林冰火人网上一抓一大把但要求里带“双人联机”四个字难度直接翻倍——Socket 通信、状态同步、线程安全随便一个点没处理好就是满屏红字。这份 Java 大作业源码把双人联机小游戏森林冰火人做成了完整可运行的项目基于 Java Swing Socket 实现包含服务端和客户端两套逻辑代码带注释pom.xml 依赖清晰导入 IDEA 配好 JDK 就能跑。适合正在找 java 课程设计案例源码、需要交期末大作业或毕设初稿的同学也适合想拿一个真实网络编程案例练手的 java 基础进阶者。它不是玩具 demo而是有地图、有碰撞、有双人实时同步的完整小游戏。2. 先看架构再动手Swing 渲染 Socket 同步是怎么搭起来的2.1 为什么是 C/S 结构而不是单机改双人很多人第一反应是“我拿个单机版加个键盘监听不就行了”。翻车点在于两个玩家在两台机器上游戏状态存在谁那里如果各自维护一份地图和角色坐标A 踩了机关 B 那边不知道画面直接对不上。这份源码采用的是典型 C/S 架构——服务端持有权威游戏状态客户端只负责发送输入指令和渲染画面。服务端跑一个固定帧率的游戏循环每帧收集两个客户端的按键状态更新角色位置、检测碰撞、判断机关触发然后把完整状态广播给两个客户端。客户端收到状态后只做一件事画出来。这个选型的理由很直接状态只有一份不存在同步冲突。代价是服务端压力大、延迟敏感但对于课程设计级别的双人小游戏局域网或本机双开完全够用。常见做法是用 TCP 而不是 UDP因为森林冰火人的操作频率不高TCP 的可靠性比 UDP 的低延迟更重要——丢一个“跳”的指令角色就卡在火坑里了。2.2 项目目录结构与关键类职责拿到压缩包解压后目录大致是这样Java-task-main/ ├── pom.xml ├── src/ │ └── main/ │ └── java/ │ ├── server/ │ │ ├── GameServer.java │ │ ├── ClientHandler.java │ │ └── GameLoop.java │ ├── client/ │ │ ├── GameClient.java │ │ ├── GamePanel.java │ │ └── InputHandler.java │ ├── common/ │ │ ├── GameState.java │ │ ├── Player.java │ │ └── Message.java │ └── map/ │ ├── TileMap.java │ └── Tile.java ├── images/ │ ├── fireboy.png │ ├── watergirl.png │ ├── tile_*.png │ └── ... └── target/几个核心类的职责需要先理清楚不然后面改代码会迷路类名所在包职责GameServerserver启动 ServerSocket接受两个客户端连接ClientHandlerserver每个客户端一个线程负责收发该客户端的消息GameLoopserver固定帧率循环驱动游戏逻辑更新GameStatecommon可序列化的游戏状态快照含两个 Player 和地图状态GamePanelclientSwing 面板负责将 GameState 渲染成画面InputHandlerclient键盘监听将按键转为指令发给服务端服务端和客户端共用 common 包下的类这是关键设计——GameState 和 Message 需要序列化后走网络传输两端必须用同一份类定义。pom.xml 里没有引入额外的网络框架纯 Java 原生 Socket ObjectOutputStream/ObjectInputStream对新手友好不需要理解 Netty 或 Spring 那套东西。2.3 环境准备与首次运行在动手改代码之前先把项目跑起来。需要 JDK 8 或以上Maven 3.6IDEA 社区版就够。# 1. 确认 JDK 版本建议 8 或 11 java -version # 2. 进入项目根目录编译打包 cd Java-task-main mvn clean package -DskipTests # 3. 确认 target 目录下生成了可运行的 jar ls target/*.jar编译通过后运行顺序很重要先启动服务端再启动两个客户端。在 IDEA 里可以配置三个 Run Configuration分别指向 GameServer 的 main 方法和 GameClient 的 main 方法启动两次。# 命令行方式启动服务端默认端口 8888 java -cp target/classes server.GameServer # 另开两个终端分别启动客户端 java -cp target/classes client.GameClient java -cp target/classes client.GameClient如果客户端连不上先检查服务端是否已经监听在 8888 端口。Windows 下用netstat -an | findstr 8888Linux/Mac 用lsof -i :8888。端口被占用的话改 GameServer 里的 PORT 常量同时改客户端连接地址里的端口号两边必须一致。注意images 目录的路径在代码里可能是相对路径如果你从 target/classes 启动需要把 images 目录复制到工作目录下或者改代码里的资源加载路径为绝对路径。这是新手最容易卡住的地方。3. 核心机制拆解碰撞检测、机关触发与双人状态同步3.1 瓦片地图与 AABB 碰撞检测森林冰火人的地图不是一张整图而是由瓦片Tile拼出来的。每个 Tile 有类型空地、火池、水池、毒池、墙壁、可推动箱子、按钮、门。火男孩能走火池但不能碰水池水女孩反过来毒池两个都不能碰。这套规则全部在服务端的碰撞检测里实现。碰撞检测用的是 AABB轴对齐包围盒因为角色和瓦片都是矩形不需要复杂的物理引擎。核心逻辑在 GameLoop 的 update 方法里// 简化的碰撞检测逻辑实际代码在 GameLoop.java 中 public void updatePlayerPosition(Player player, int dx, int dy) { // 先尝试水平移动 Rectangle newBounds new Rectangle( player.getX() dx, player.getY(), player.getWidth(), player.getHeight() ); if (!checkTileCollision(newBounds, player.getType())) { player.setX(player.getX() dx); } // 再尝试垂直移动 newBounds new Rectangle( player.getX(), player.getY() dy, player.getWidth(), player.getHeight() ); if (!checkTileCollision(newBounds, player.getType())) { player.setY(player.getY() dy); } } private boolean checkTileCollision(Rectangle bounds, PlayerType type) { // 遍历与 bounds 相交的所有 Tile for (Tile tile : getTilesInRect(bounds)) { if (tile.isSolid()) return true; // 墙壁 if (tile.isLethalFor(type)) return true; // 属性相克的液体 } return false; }这里有个细节水平和垂直分开检测是为了实现“贴墙滑动”效果。如果合并检测角色碰到墙壁斜角时会直接卡死手感很差。参数方面dx 和 dy 是每帧的位移量通常由移动速度常量决定比如 SPEED 4 像素/帧。帧率固定在 60 FPS 时角色移动速度就是 240 像素/秒这个值可以根据地图大小调整。3.2 机关与按钮的状态同步游戏里的按钮、拉杆、可推动箱子状态都保存在服务端的 GameState 里。当火男孩踩上按钮时服务端检测到角色与按钮 Tile 重叠把按钮状态设为“按下”同时检查这个按钮关联的门是否应该打开。门的开闭状态也是 GameState 的一部分每帧广播给客户端。// 按钮触发逻辑在 GameLoop 中每帧调用 private void checkButtonTriggers() { for (Button button : gameState.getButtons()) { boolean pressed false; for (Player player : gameState.getPlayers()) { if (player.getBounds().intersects(button.getBounds())) { pressed true; break; } } // 只有状态变化时才更新减少不必要的网络传输 if (button.isPressed() ! pressed) { button.setPressed(pressed); // 更新关联门的状态 for (Door door : gameState.getDoors()) { if (door.getButtonId() button.getId()) { door.setOpen(pressed); } } } } }注意if (button.isPressed() ! pressed)这个判断——状态没变就不更新避免每帧都修改 GameState 导致广播的数据量无意义增大。这是网络游戏里很常见的优化思路虽然课程设计级别不一定需要但养成这个习惯对后面做更大的项目有好处。3.3 网络消息协议与序列化客户端和服务端之间的通信消息定义在 Message 类里包含消息类型和负载数据。消息类型有玩家输入上下左右跳、游戏状态同步、玩家加入/离开、游戏结束。用 Java 原生序列化实现简单直接。// Message.java 的结构示意 public class Message implements Serializable { private static final long serialVersionUID 1L; private MessageType type; private Object payload; // 工厂方法创建输入消息 public static Message input(PlayerInput input) { Message msg new Message(); msg.type MessageType.INPUT; msg.payload input; return msg; } // 工厂方法创建状态同步消息 public static Message state(GameState state) { Message msg new Message(); msg.type MessageType.STATE; msg.payload state; return msg; } }serialVersionUID必须显式声明否则两端编译版本不一致时会抛 InvalidClassException。这是血泪经验——你改了 common 包里的类客户端没重新编译连上去就崩。参数方面PlayerInput 里存的是按键的布尔状态上、下、左、右、跳每帧客户端把当前按键状态发一次服务端收到后更新对应玩家的输入缓存。提示如果要做局域网联机把客户端连接地址从 127.0.0.1 改成服务端的局域网 IP 即可。防火墙记得放行对应端口Windows Defender 默认会拦。4. 避坑与排查从连不上到画面撕裂的五个真实问题4.1 客户端启动报 Connection refused现象客户端一运行就抛异常提示 Connection refused: connect。原因服务端没启动或者端口号不一致或者服务端绑定的 IP 是 127.0.0.1 而客户端连的是局域网 IP。解决先确认服务端已经跑起来并且打印了“Server started on port 8888”之类的日志。然后检查客户端代码里 SERVER_IP 和 SERVER_PORT 两个常量确保和服务端一致。如果服务端绑定的地址是new ServerSocket(8888)它默认监听所有网卡局域网内其他机器可以连如果写的是new ServerSocket(8888, 50, InetAddress.getByName(127.0.0.1))那就只能本机连。4.2 两个客户端画面不同步一个角色瞬移现象A 客户端看到火男孩已经跳到对面平台了B 客户端看到火男孩还在原地过一会儿突然瞬移过去。原因网络延迟导致状态包到达时间不一致或者服务端广播时没有按固定顺序发送。更常见的原因是客户端在本地也做了预测移动收到服务端状态后又强行拉回产生抖动。解决这份源码的客户端是纯状态同步不做本地预测所以正常情况下不会瞬移。如果出现检查服务端 GameLoop 的帧率是否稳定——如果用了Thread.sleep(16)但实际循环体执行时间超过 16ms帧率会掉状态更新变慢。可以在循环里加一个时间补偿逻辑或者把 sleep 时间改为动态计算。另外确认两个客户端连的是同一个服务端实例别一个连本机一个连局域网另一台机器。4.3 角色卡在墙角或穿过薄墙现象角色贴着墙壁走的时候偶尔卡住不动或者速度太快时直接穿过一格厚的墙。原因AABB 碰撞检测是离散的如果每帧位移量大于墙壁厚度就会“隧穿”。另外水平垂直分开检测时如果先水平移动把角色推进了墙里再垂直移动时可能因为已经在墙内而无法脱出。解决把移动速度调小或者把墙壁厚度设为大于每帧位移量。更稳妥的做法是在移动前先做一次“如果移动后会碰撞就不移动”的判断而不是移动后再修正。源码里用的是预判式检测所以正常速度下不会穿墙。如果你改了 SPEED 常量记得同步检查地图里最薄墙壁的厚度。4.4 服务端只接受一个客户端第二个连不上现象第一个客户端正常进入游戏第二个客户端连接后没反应或直接断开。原因服务端只调用了一次serverSocket.accept()没有循环接受连接。或者 ClientHandler 线程启动后没有正确加入玩家列表。解决检查 GameServer 的 main 方法应该是while(true) { Socket socket serverSocket.accept(); new Thread(new ClientHandler(socket)).start(); }的结构。另外确认 GameState 里的 players 列表能容纳两个玩家有些实现里写死了只处理一个玩家。如果用的是线程池确认核心线程数至少为 2。4.5 图片资源加载失败画面全是色块现象游戏能跑角色能动但所有图片都显示不出来只有纯色矩形。原因images 目录不在 classpath 下或者代码里用的是相对路径而工作目录不对。IDEA 默认的工作目录是项目根目录命令行启动时是你执行 java 命令的目录。解决把 images 目录放到 src/main/resources 下用getClass().getResourceAsStream(/images/fireboy.png)加载。如果不想改代码就在启动时把工作目录切到 images 的父目录。命令行可以用-Duser.dir/path/to/project指定。最省事的办法是在 IDEA 的 Run Configuration 里把 Working directory 设为项目根目录。5. 进阶改造把课程设计变成能写进简历的项目5.1 加一个房间匹配机制现在的源码是“先到先得”服务端启动后前两个连上的客户端自动配对。如果想支持多局同时进行需要引入房间概念。每个房间有自己的 GameState 和 GameLoopClientHandler 在连接后先进入等待队列凑齐两人再创建房间。这个改造涉及服务端架构调整但核心思路不复杂把原来全局唯一的 GameState 改成 Room 对象持有GameLoop 也变成每个房间一个线程。// 房间管理器的简化示意 public class RoomManager { private final ListRoom waitingRooms new CopyOnWriteArrayList(); public synchronized Room joinOrCreate(Socket socket) { for (Room room : waitingRooms) { if (room.hasEmptySlot()) { room.addPlayer(socket); if (room.isFull()) { waitingRooms.remove(room); room.start(); } return room; } } Room newRoom new Room(); newRoom.addPlayer(socket); waitingRooms.add(newRoom); return newRoom; } }用 CopyOnWriteArrayList 是为了避免多线程遍历时并发修改。每个 Room 持有一个 GameState 和一个 GameLoop 线程玩家加入后启动循环。这个改造能让你的项目从“双人固定联机”升级为“多房间匹配”写在简历上比“实现了双人联机”有分量得多。5.2 用状态压缩减少网络传输量当前每帧广播完整的 GameState包含地图所有 Tile 的状态。地图大了之后每帧几 KB 的数据在局域网上没问题但如果你想改成公网联机或者移动端就需要压缩。常见做法是只同步变化的部分角色坐标、按钮状态、门状态地图静态部分只在客户端加载时传一次。// 增量状态包的结构 public class DeltaState implements Serializable { private int player1X, player1Y; private int player2X, player2Y; private ListButtonState changedButtons; private ListDoorState changedDoors; // 省略 getter/setter }服务端维护一个“上一帧状态”的副本每帧对比当前状态只把变化的字段打包发送。客户端收到后合并到本地状态再渲染。这个优化能把每帧数据量降到原来的十分之一左右。参数方面可以设置一个阈值变化小于 1 像素的位移不发送进一步减少包量。5.3 验证改造是否成功的三个检查点改完代码后别急着交。按下面三个检查点走一遍第一双开客户端后两个角色能独立移动互不干扰碰撞检测正常。第二让一个角色踩按钮另一个角色那边的门应该同步打开延迟不超过 100ms。第三关掉一个客户端服务端应该能检测到断开并通知另一个客户端而不是卡死或抛异常。如果要做多房间再加一条同时开四个客户端应该自动分成两个房间互不干扰。用jstack看一下服务端线程数每个房间一个 GameLoop 线程加上每个客户端一个 ClientHandler 线程四个客户端两个房间应该是 246 个业务线程数量对得上说明房间管理没泄漏。从那以后我每次拿到这种联机项目都先把服务端和客户端的消息协议画出来再动手改代码协议不清楚就改改到最后一定是玄学 bug。希望这份拆解能帮你把大作业顺利跑起来也帮你在导师面前多拿几分。本文还有配套的精品资源点击获取