尧图网页设计 
简介这份资源是面向高校计算机相关专业学生的Java课程设计参考项目以经典双人联机小游戏「森林冰火人」为主题适合作为期末大作业、毕业设计或课程设计的高分模板也适合刚接触Java游戏开发的初学者研读学习。压缩包共67个文件约2.42MB包含11个java源码文件、15个class编译文件、2个properties配置与1个xml配置另有25张jpg、7张gif和6张png图片素材覆盖游戏逻辑、角色控制、地图资源与联机通信等模块。项目代码附带注释结构清晰部署后即可运行已有239人学习关注。读者可从中获得完整的双人联机游戏实现方案理解客户端与服务端通信、角色状态同步、碰撞检测与关卡资源加载等核心思路并可直接在此基础上修改扩展用于课程答辩或二次开发具有较高的参考与复用价值。1. 森林冰火人双人联机版Java大作业里最容易被低估的通信设计森林冰火人这个题材在 Java 大作业里出现的频率极高但绝大多数版本都是单机双人——两个玩家挤在同一块键盘上一个按 WASD一个按方向键。真正把它做成双人联机小游戏的人少得多原因不是玩法复杂而是联机这件事本身在 Java 课程体系里缺少一个「刚好够用」的落点。你如果正在找一份能拿高分、又能讲清楚技术含量的 Java 项目源码森林冰火人的双人联机版恰好卡在一个甜区游戏逻辑不重但网络通信、状态同步、多线程管理这些加分项一个不少。这篇文章面向两类人一是需要交 Java 大作业、想做出差异化的学生二是刚学完 Java 基础、想找一个完整项目把 Socket、多线程、Swing 串起来的自学者。我会按「通信架构怎么选 → 服务端和客户端怎么写 → 游戏状态怎么同步 → 踩过哪些坑 → 怎么在答辩时讲出深度」这条线走代码可以直接抄参数可以照着调坑我替你踩过了。2. 联机架构选型为什么我最终用 TCP 短连接 状态广播而不是 RMI 或 UDP2.1 三种候选方案的实际对比做双人联机小游戏Java 里能走的路大概三条RMI远程方法调用、TCP Socket 长连接、UDP 数据报。我一开始图省事试了 RMI结果发现两个致命问题——一是 RMI 的注册表机制在校园网环境下经常因为端口被拦而连不上二是每次远程调用都走序列化延迟波动大角色移动会有明显的「一顿一顿」。UDP 倒是快但森林冰火人这种游戏对丢包的容忍度很低火人踩到水坑的判定如果丢了一帧玩家就会觉得「我明明没碰到水怎么死了」这种玄学体验在答辩现场是灾难。最终我选的是 TCP 长连接 服务端权威状态广播。具体来说服务端维护一份完整的游戏世界状态两个玩家的坐标、地图上的宝石收集情况、机关状态、通关判定客户端只负责发送输入指令上下左右和渲染服务端下发的状态。这样做的好处是逻辑统一不会出现两个客户端各算各的导致状态不一致。方案延迟表现实现难度状态一致性适合场景RMI高50-200ms波动低好局域网内非实时应用TCP长连接中10-50ms中好双人/小规模联机游戏UDP低5-20ms高差大规模实时对战2.2 通信协议设计一条消息该长什么样协议设计是很多人写大作业时最容易糊弄过去的地方。我见过不少源码直接用 Java 对象序列化往 Socket 里塞能跑但一旦要加新字段就得两边同时改调试时也看不到明文。我采用的是「长度前缀 JSON 体」的文本协议每条消息格式如下[4字节消息长度][JSON字符串]JSON 里至少包含type字段来区分消息类型。实际用到的消息类型有这些// 消息类型常量定义 public class MsgType { public static final String JOIN join; // 客户端请求加入 public static final String INPUT input; // 客户端上报按键 public static final String STATE state; // 服务端广播世界状态 public static final String START start; // 服务端通知游戏开始 public static final String OVER over; // 服务端通知游戏结束 public static final String CHAT chat; // 预留玩家文字交流 }用长度前缀的原因是 TCP 是流式协议你不加长度标记接收端根本不知道一条消息从哪结束。JSON 体则方便调试——你甚至可以用 telnet 手动发一条消息测试服务端逻辑。提示JSON 解析库用 Jackson 或 Gson 都行但注意在客户端和服务端使用同一个版本否则可能出现字段名大小写不一致的坑。2.3 线程模型一个连接一个线程够不够服务端我用的是「主线程 accept 每客户端一个读线程 一个广播线程」的模型。对于双人游戏来说两个客户端就是两个读线程广播线程每 50ms 向所有客户端推送一次完整状态。50ms 对应 20 帧/秒的同步频率对于森林冰火人这种非格斗类游戏完全够用。// 服务端广播线程核心逻辑 public class BroadcastTask implements Runnable { private final ListClientHandler clients; private final GameWorld world; Override public void run() { while (true) { try { // 每50ms推送一次世界状态 Thread.sleep(50); String stateJson world.toJson(); for (ClientHandler c : clients) { c.send(MsgType.STATE, stateJson); } } catch (InterruptedException e) { break; } } } }这里有个参数值得说Thread.sleep(50)不是随便定的。如果你调到 20ms网络包数量翻倍校园网环境下反而容易拥塞调到 100ms角色移动会有肉眼可见的延迟。50ms 是我在宿舍 WiFi 和教室有线网下都测过的平衡点。3. 从零搭出可运行的服务端与客户端关键代码与参数调优3.1 服务端启动类与端口选择服务端入口类我写得尽量简单方便答辩时讲清楚流程public class GameServer { // 端口选1024以上避免Linux下非root无法绑定 private static final int PORT 9527; public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(PORT); System.out.println(服务端已启动监听端口 PORT); GameWorld world new GameWorld(); ListClientHandler clients new ArrayList(); // 启动广播线程 new Thread(new BroadcastTask(clients, world)).start(); while (true) { Socket socket serverSocket.accept(); ClientHandler handler new ClientHandler(socket, world, clients); clients.add(handler); new Thread(handler).start(); System.out.println(玩家接入 socket.getInetAddress()); } } }端口我选了 9527纯粹是好记。实际部署时如果这个端口被占用换 10000 以上的任意端口都行。注意serverSocket.accept()是阻塞的所以主线程会停在这里等连接这正好符合我们的需求。3.2 客户端连接与输入采集客户端这边要处理两件事一是连接服务端并保持心跳二是采集键盘输入并发送。Swing 的KeyListener有个经典问题——焦点丢失后按键就失效了。我的做法是在游戏面板上强制requestFocusInWindow()并且用KeyAdapter而不是KeyListener少写两个空方法。// 客户端输入采集与发送 public class InputSender extends KeyAdapter { private final ClientConnection conn; public InputSender(ClientConnection conn) { this.conn conn; } Override public void keyPressed(KeyEvent e) { String dir null; switch (e.getKeyCode()) { case KeyEvent.VK_UP: dir up; break; case KeyEvent.VK_DOWN: dir down; break; case KeyEvent.VK_LEFT: dir left; break; case KeyEvent.VK_RIGHT: dir right; break; } if (dir ! null) { // 只发方向不发坐标坐标由服务端算 conn.send(MsgType.INPUT, {\dir\:\ dir \}); } } }这里的关键设计是客户端只发方向不发坐标。很多人写联机游戏时习惯客户端算好新坐标再发给服务端服务端只做转发。这种做法在双人游戏里会出大问题——两个客户端可能同时算出冲突的坐标服务端不知道该信谁。让服务端做唯一权威客户端只表达意图是更稳妥的做法。3.3 游戏状态同步服务端如何计算和下发服务端收到输入后不是立刻改坐标而是把输入存到对应玩家的「当前输入」字段里然后在广播线程的每次循环中统一计算// GameWorld中的每帧更新逻辑 public void tick() { for (Player p : players) { String dir p.getCurrentInput(); if (dir null) continue; int nx p.getX(); int ny p.getY(); switch (dir) { case up: ny - SPEED; break; case down: ny SPEED; break; case left: nx - SPEED; break; case right: nx SPEED; break; } // 碰撞检测地图、机关、另一个玩家 if (canMoveTo(nx, ny, p)) { p.setX(nx); p.setY(ny); } p.setCurrentInput(null); // 消费掉本次输入 } checkGemCollection(); checkLevelComplete(); }SPEED这个参数我设的是 4 像素/帧配合 50ms 的广播间隔角色移动速度大约是 80 像素/秒。这个速度在 800x600 的游戏窗口里手感刚好太快容易掉进陷阱太慢玩起来着急。你可以根据自己地图的格子大小调整但建议保持在 3-6 之间。注意p.setCurrentInput(null)这行不能省。如果不消费掉输入玩家松开按键后角色还会一直移动因为服务端会反复执行同一个方向。4. 联机同步避坑指南五个让我熬夜到三点的真实问题4.1 现象两个客户端画面不同步火人看到自己在岸上水人看到火人在水里原因客户端各自做了本地预测移动但没有等服务端确认就渲染了。当网络稍有抖动两边预测结果不一致。解决关掉客户端本地预测所有移动等收到STATE消息后再更新画面。代价是操作有一点点延迟感但双人合作游戏对这点延迟不敏感一致性更重要。4.2 现象游戏运行几分钟后客户端突然卡死服务端日志显示发送缓冲区满原因广播线程发送速度超过了客户端读取速度TCP 的发送缓冲区被填满write阻塞导致整个广播线程卡住。解决给每个客户端的发送操作加一个独立线程或线程池并且设置socket.setSendBufferSize(8192)限制缓冲区大小。更简单的做法是如果某个客户端连续 3 次发送超时直接踢掉它不要让一个慢客户端拖垮所有人。4.3 现象在教室演示时两个电脑连不上宿舍里却正常原因教室网络做了 AP 隔离同一 WiFi 下设备之间不能直接通信。解决这是环境问题代码层面无解。备选方案是带一个手机热点两台电脑都连热点或者用本机开两个客户端窗口演示服务端和客户端都在同一台机器上用127.0.0.1连接。答辩前一定要提前踩点。4.4 现象JSON 解析偶尔抛异常提示「Unterminated string」原因TCP 粘包。两条消息的字节流被合并成一次read返回接收端按一条消息解析就出错了。解决严格按照「先读 4 字节长度再读对应长度字节」的方式接收。不要用BufferedReader.readLine()因为 JSON 里可能包含换行符。// 正确的消息读取方式 public String readMessage(DataInputStream in) throws IOException { int len in.readInt(); // 先读长度 byte[] body new byte[len]; in.readFully(body); // 再读完整内容 return new String(body, StandardCharsets.UTF_8); }4.5 现象游戏结束后重新开始宝石收集状态没有重置原因GameWorld对象是复用的checkLevelComplete()后只重置了玩家坐标忘了重置宝石的collected标志。解决写一个reset()方法把所有可变状态列一个清单逐一重置。这个 bug 很隐蔽因为第一次玩完全正常只有重开才会暴露。5. 让大作业拿高分的三个进阶技巧状态压缩、回放录制与答辩演示5.1 用位运算压缩状态包把带宽降下来如果你的答辩老师喜欢问「性能优化」这里有一个可以讲的点。完整状态 JSON 大概 300-500 字节其实可以压缩。玩家坐标用两个short各 2 字节宝石状态用一个int的每一位表示一颗宝石是否被收集32 颗以内够用机关状态同理。这样一条状态消息可以压到 20 字节以内。// 状态压缩示例坐标宝石位图 public byte[] toCompactBytes() { ByteBuffer buf ByteBuffer.allocate(16); for (Player p : players) { buf.putShort((short) p.getX()); buf.putShort((short) p.getY()); } buf.putInt(gemBitmask); // 每bit代表一颗宝石 buf.putInt(switchBitmask); // 每bit代表一个机关 return buf.array(); }这个技巧不一定要真的用上但在答辩时能讲清楚「为什么可以这样压」和「压缩后客户端怎么解」就是加分项。5.2 录制对局回放一个让老师眼前一亮的附加功能回放的本质很简单服务端每次广播状态时顺便把这条状态追加写入一个文件。回放时按时间戳逐条读取并渲染即可。实现成本很低但演示效果很好——你可以录一段两人完美配合通关的回放答辩时直接播放比现场操作更稳定。// 状态录制追加写入 public void record(String stateJson) { try (FileWriter fw new FileWriter(replay.log, true); BufferedWriter bw new BufferedWriter(fw)) { bw.write(System.currentTimeMillis() | stateJson); bw.newLine(); } catch (IOException e) { // 录制失败不影响游戏主流程 } }注意文件写入要放在独立线程或异步执行否则会拖慢广播频率。5.3 答辩演示的检查清单最后说一个血泪经验大作业的分数不只取决于代码还取决于演示是否顺利。我当年答辩时前面一个同学因为现场网络问题演示失败直接降了一档。所以提前做好这些准备检查项具体操作备注本机双开服务端两个客户端同机运行最稳妥的兜底方案热点备用手机开热点两台笔记本连接提前测试连通性回放文件预录一段通关回放网络彻底失败时播放端口检查netstat -an确认端口未被占用换端口只需改一个常量日志级别演示时关掉 DEBUG 日志避免控制台刷屏我现在的习惯是任何联机项目答辩前一定在本机用127.0.0.1完整跑三遍再用两台设备跑一遍最后把回放文件放在桌面最显眼的位置。这套流程帮我扛过了两次现场翻车。希望帮到你。本文还有配套的精品资源点击获取 Java大作业森林冰火人双人联机版：TCP通信与状态同步实战
简介这份资源是面向高校计算机相关专业学生的Java课程设计参考项目以经典双人联机小游戏「森林冰火人」为主题适合作为期末大作业、毕业设计或课程设计的高分模板也适合刚接触Java游戏开发的初学者研读学习。压缩包共67个文件约2.42MB包含11个java源码文件、15个class编译文件、2个properties配置与1个xml配置另有25张jpg、7张gif和6张png图片素材覆盖游戏逻辑、角色控制、地图资源与联机通信等模块。项目代码附带注释结构清晰部署后即可运行已有239人学习关注。读者可从中获得完整的双人联机游戏实现方案理解客户端与服务端通信、角色状态同步、碰撞检测与关卡资源加载等核心思路并可直接在此基础上修改扩展用于课程答辩或二次开发具有较高的参考与复用价值。1. 森林冰火人双人联机版Java大作业里最容易被低估的通信设计森林冰火人这个题材在 Java 大作业里出现的频率极高但绝大多数版本都是单机双人——两个玩家挤在同一块键盘上一个按 WASD一个按方向键。真正把它做成双人联机小游戏的人少得多原因不是玩法复杂而是联机这件事本身在 Java 课程体系里缺少一个「刚好够用」的落点。你如果正在找一份能拿高分、又能讲清楚技术含量的 Java 项目源码森林冰火人的双人联机版恰好卡在一个甜区游戏逻辑不重但网络通信、状态同步、多线程管理这些加分项一个不少。这篇文章面向两类人一是需要交 Java 大作业、想做出差异化的学生二是刚学完 Java 基础、想找一个完整项目把 Socket、多线程、Swing 串起来的自学者。我会按「通信架构怎么选 → 服务端和客户端怎么写 → 游戏状态怎么同步 → 踩过哪些坑 → 怎么在答辩时讲出深度」这条线走代码可以直接抄参数可以照着调坑我替你踩过了。2. 联机架构选型为什么我最终用 TCP 短连接 状态广播而不是 RMI 或 UDP2.1 三种候选方案的实际对比做双人联机小游戏Java 里能走的路大概三条RMI远程方法调用、TCP Socket 长连接、UDP 数据报。我一开始图省事试了 RMI结果发现两个致命问题——一是 RMI 的注册表机制在校园网环境下经常因为端口被拦而连不上二是每次远程调用都走序列化延迟波动大角色移动会有明显的「一顿一顿」。UDP 倒是快但森林冰火人这种游戏对丢包的容忍度很低火人踩到水坑的判定如果丢了一帧玩家就会觉得「我明明没碰到水怎么死了」这种玄学体验在答辩现场是灾难。最终我选的是 TCP 长连接 服务端权威状态广播。具体来说服务端维护一份完整的游戏世界状态两个玩家的坐标、地图上的宝石收集情况、机关状态、通关判定客户端只负责发送输入指令上下左右和渲染服务端下发的状态。这样做的好处是逻辑统一不会出现两个客户端各算各的导致状态不一致。方案延迟表现实现难度状态一致性适合场景RMI高50-200ms波动低好局域网内非实时应用TCP长连接中10-50ms中好双人/小规模联机游戏UDP低5-20ms高差大规模实时对战2.2 通信协议设计一条消息该长什么样协议设计是很多人写大作业时最容易糊弄过去的地方。我见过不少源码直接用 Java 对象序列化往 Socket 里塞能跑但一旦要加新字段就得两边同时改调试时也看不到明文。我采用的是「长度前缀 JSON 体」的文本协议每条消息格式如下[4字节消息长度][JSON字符串]JSON 里至少包含type字段来区分消息类型。实际用到的消息类型有这些// 消息类型常量定义 public class MsgType { public static final String JOIN join; // 客户端请求加入 public static final String INPUT input; // 客户端上报按键 public static final String STATE state; // 服务端广播世界状态 public static final String START start; // 服务端通知游戏开始 public static final String OVER over; // 服务端通知游戏结束 public static final String CHAT chat; // 预留玩家文字交流 }用长度前缀的原因是 TCP 是流式协议你不加长度标记接收端根本不知道一条消息从哪结束。JSON 体则方便调试——你甚至可以用 telnet 手动发一条消息测试服务端逻辑。提示JSON 解析库用 Jackson 或 Gson 都行但注意在客户端和服务端使用同一个版本否则可能出现字段名大小写不一致的坑。2.3 线程模型一个连接一个线程够不够服务端我用的是「主线程 accept 每客户端一个读线程 一个广播线程」的模型。对于双人游戏来说两个客户端就是两个读线程广播线程每 50ms 向所有客户端推送一次完整状态。50ms 对应 20 帧/秒的同步频率对于森林冰火人这种非格斗类游戏完全够用。// 服务端广播线程核心逻辑 public class BroadcastTask implements Runnable { private final ListClientHandler clients; private final GameWorld world; Override public void run() { while (true) { try { // 每50ms推送一次世界状态 Thread.sleep(50); String stateJson world.toJson(); for (ClientHandler c : clients) { c.send(MsgType.STATE, stateJson); } } catch (InterruptedException e) { break; } } } }这里有个参数值得说Thread.sleep(50)不是随便定的。如果你调到 20ms网络包数量翻倍校园网环境下反而容易拥塞调到 100ms角色移动会有肉眼可见的延迟。50ms 是我在宿舍 WiFi 和教室有线网下都测过的平衡点。3. 从零搭出可运行的服务端与客户端关键代码与参数调优3.1 服务端启动类与端口选择服务端入口类我写得尽量简单方便答辩时讲清楚流程public class GameServer { // 端口选1024以上避免Linux下非root无法绑定 private static final int PORT 9527; public static void main(String[] args) throws IOException { ServerSocket serverSocket new ServerSocket(PORT); System.out.println(服务端已启动监听端口 PORT); GameWorld world new GameWorld(); ListClientHandler clients new ArrayList(); // 启动广播线程 new Thread(new BroadcastTask(clients, world)).start(); while (true) { Socket socket serverSocket.accept(); ClientHandler handler new ClientHandler(socket, world, clients); clients.add(handler); new Thread(handler).start(); System.out.println(玩家接入 socket.getInetAddress()); } } }端口我选了 9527纯粹是好记。实际部署时如果这个端口被占用换 10000 以上的任意端口都行。注意serverSocket.accept()是阻塞的所以主线程会停在这里等连接这正好符合我们的需求。3.2 客户端连接与输入采集客户端这边要处理两件事一是连接服务端并保持心跳二是采集键盘输入并发送。Swing 的KeyListener有个经典问题——焦点丢失后按键就失效了。我的做法是在游戏面板上强制requestFocusInWindow()并且用KeyAdapter而不是KeyListener少写两个空方法。// 客户端输入采集与发送 public class InputSender extends KeyAdapter { private final ClientConnection conn; public InputSender(ClientConnection conn) { this.conn conn; } Override public void keyPressed(KeyEvent e) { String dir null; switch (e.getKeyCode()) { case KeyEvent.VK_UP: dir up; break; case KeyEvent.VK_DOWN: dir down; break; case KeyEvent.VK_LEFT: dir left; break; case KeyEvent.VK_RIGHT: dir right; break; } if (dir ! null) { // 只发方向不发坐标坐标由服务端算 conn.send(MsgType.INPUT, {\dir\:\ dir \}); } } }这里的关键设计是客户端只发方向不发坐标。很多人写联机游戏时习惯客户端算好新坐标再发给服务端服务端只做转发。这种做法在双人游戏里会出大问题——两个客户端可能同时算出冲突的坐标服务端不知道该信谁。让服务端做唯一权威客户端只表达意图是更稳妥的做法。3.3 游戏状态同步服务端如何计算和下发服务端收到输入后不是立刻改坐标而是把输入存到对应玩家的「当前输入」字段里然后在广播线程的每次循环中统一计算// GameWorld中的每帧更新逻辑 public void tick() { for (Player p : players) { String dir p.getCurrentInput(); if (dir null) continue; int nx p.getX(); int ny p.getY(); switch (dir) { case up: ny - SPEED; break; case down: ny SPEED; break; case left: nx - SPEED; break; case right: nx SPEED; break; } // 碰撞检测地图、机关、另一个玩家 if (canMoveTo(nx, ny, p)) { p.setX(nx); p.setY(ny); } p.setCurrentInput(null); // 消费掉本次输入 } checkGemCollection(); checkLevelComplete(); }SPEED这个参数我设的是 4 像素/帧配合 50ms 的广播间隔角色移动速度大约是 80 像素/秒。这个速度在 800x600 的游戏窗口里手感刚好太快容易掉进陷阱太慢玩起来着急。你可以根据自己地图的格子大小调整但建议保持在 3-6 之间。注意p.setCurrentInput(null)这行不能省。如果不消费掉输入玩家松开按键后角色还会一直移动因为服务端会反复执行同一个方向。4. 联机同步避坑指南五个让我熬夜到三点的真实问题4.1 现象两个客户端画面不同步火人看到自己在岸上水人看到火人在水里原因客户端各自做了本地预测移动但没有等服务端确认就渲染了。当网络稍有抖动两边预测结果不一致。解决关掉客户端本地预测所有移动等收到STATE消息后再更新画面。代价是操作有一点点延迟感但双人合作游戏对这点延迟不敏感一致性更重要。4.2 现象游戏运行几分钟后客户端突然卡死服务端日志显示发送缓冲区满原因广播线程发送速度超过了客户端读取速度TCP 的发送缓冲区被填满write阻塞导致整个广播线程卡住。解决给每个客户端的发送操作加一个独立线程或线程池并且设置socket.setSendBufferSize(8192)限制缓冲区大小。更简单的做法是如果某个客户端连续 3 次发送超时直接踢掉它不要让一个慢客户端拖垮所有人。4.3 现象在教室演示时两个电脑连不上宿舍里却正常原因教室网络做了 AP 隔离同一 WiFi 下设备之间不能直接通信。解决这是环境问题代码层面无解。备选方案是带一个手机热点两台电脑都连热点或者用本机开两个客户端窗口演示服务端和客户端都在同一台机器上用127.0.0.1连接。答辩前一定要提前踩点。4.4 现象JSON 解析偶尔抛异常提示「Unterminated string」原因TCP 粘包。两条消息的字节流被合并成一次read返回接收端按一条消息解析就出错了。解决严格按照「先读 4 字节长度再读对应长度字节」的方式接收。不要用BufferedReader.readLine()因为 JSON 里可能包含换行符。// 正确的消息读取方式 public String readMessage(DataInputStream in) throws IOException { int len in.readInt(); // 先读长度 byte[] body new byte[len]; in.readFully(body); // 再读完整内容 return new String(body, StandardCharsets.UTF_8); }4.5 现象游戏结束后重新开始宝石收集状态没有重置原因GameWorld对象是复用的checkLevelComplete()后只重置了玩家坐标忘了重置宝石的collected标志。解决写一个reset()方法把所有可变状态列一个清单逐一重置。这个 bug 很隐蔽因为第一次玩完全正常只有重开才会暴露。5. 让大作业拿高分的三个进阶技巧状态压缩、回放录制与答辩演示5.1 用位运算压缩状态包把带宽降下来如果你的答辩老师喜欢问「性能优化」这里有一个可以讲的点。完整状态 JSON 大概 300-500 字节其实可以压缩。玩家坐标用两个short各 2 字节宝石状态用一个int的每一位表示一颗宝石是否被收集32 颗以内够用机关状态同理。这样一条状态消息可以压到 20 字节以内。// 状态压缩示例坐标宝石位图 public byte[] toCompactBytes() { ByteBuffer buf ByteBuffer.allocate(16); for (Player p : players) { buf.putShort((short) p.getX()); buf.putShort((short) p.getY()); } buf.putInt(gemBitmask); // 每bit代表一颗宝石 buf.putInt(switchBitmask); // 每bit代表一个机关 return buf.array(); }这个技巧不一定要真的用上但在答辩时能讲清楚「为什么可以这样压」和「压缩后客户端怎么解」就是加分项。5.2 录制对局回放一个让老师眼前一亮的附加功能回放的本质很简单服务端每次广播状态时顺便把这条状态追加写入一个文件。回放时按时间戳逐条读取并渲染即可。实现成本很低但演示效果很好——你可以录一段两人完美配合通关的回放答辩时直接播放比现场操作更稳定。// 状态录制追加写入 public void record(String stateJson) { try (FileWriter fw new FileWriter(replay.log, true); BufferedWriter bw new BufferedWriter(fw)) { bw.write(System.currentTimeMillis() | stateJson); bw.newLine(); } catch (IOException e) { // 录制失败不影响游戏主流程 } }注意文件写入要放在独立线程或异步执行否则会拖慢广播频率。5.3 答辩演示的检查清单最后说一个血泪经验大作业的分数不只取决于代码还取决于演示是否顺利。我当年答辩时前面一个同学因为现场网络问题演示失败直接降了一档。所以提前做好这些准备检查项具体操作备注本机双开服务端两个客户端同机运行最稳妥的兜底方案热点备用手机开热点两台笔记本连接提前测试连通性回放文件预录一段通关回放网络彻底失败时播放端口检查netstat -an确认端口未被占用换端口只需改一个常量日志级别演示时关掉 DEBUG 日志避免控制台刷屏我现在的习惯是任何联机项目答辩前一定在本机用127.0.0.1完整跑三遍再用两台设备跑一遍最后把回放文件放在桌面最显眼的位置。这套流程帮我扛过了两次现场翻车。希望帮到你。本文还有配套的精品资源点击获取