Java大作业双人联机森林冰火人：Socket同步与碰撞判定实战

简介：这是一份面向高校计算机相关专业学生的Java课程设计资源，以经典双人联机小游戏「森林冰火人」为题材，适合用作期末大作业、毕业设计或Java学习练手项目。资源包共67个文件，包含11个java源码文件、15个class编译文件、2个properties配置与1个xml文件，另有25张jpg、7张gif和6张png图片素材，压缩包约2.42MB，代码注释齐全，新手也能看懂。项目采用Java开发，涵盖双人联机通信、角色控制、地图碰撞检测与关卡逻辑等核心模块，界面美观、操作简单、功能完善，下载后简单部署即可运行。目前已有238人学习下载，作者自述该项目为手打98分作品，获导师认可。对于需要快速完成课程设计或毕设的同学，可直接参考其目录结构与实现思路，省去从零搭建的时间，具有较高的实际参考价值。

1. 从一份 Java 大作业说起：双人联机森林冰火人到底难在哪

很多人第一次看到「Java 大作业-双人联机小游戏森林冰火人项目源码」这个标题，第一反应是去搜一份能直接跑的代码，改个包名就交上去。但真正动手做过的人都知道，森林冰火人这个玩法的坑不在画面，而在双人联机的状态同步和火人/冰人两套互斥规则。单机版你只要管一个角色的碰撞和跳跃，联机版你要同时处理两个客户端的输入、服务端的权威判定、以及「火人碰到火池回血、冰人碰到火池掉血」这种对称但相反的判定逻辑。这份大作业之所以被当成高分项目，是因为它把 Java 基础里的集合、多线程、Socket 通信、Swing 绘图全串起来了，而不是单纯堆一个能动的方块。

这篇文章面向三类人：正在找 Java 课程设计案例源码的学生、想用一个小项目把 Java 网络编程和面向对象串起来练手的人、以及需要一份能讲清楚「双人联机小游戏怎么落地」的参考方案的开发者。我会按「先讲清楚这个项目由哪些模块组成 → 再给出可复现的服务端和客户端骨架 → 最后把联机同步和碰撞判定里最容易翻车的地方摊开讲」的顺序推进。你不需要先看完一整套 Java 面试八股文才能动手，但至少要会写类、会用Thread、能看懂Socket的基本读写。下面所有代码都是骨架级示例，参数和端口按你本机环境改，重点是让你理解每一层在干什么。

2. 森林冰火人的模块拆解：服务端、客户端、地图与角色状态

2.1 为什么这个项目必须拆成四层而不是一个类写完

很多同学写大作业的习惯是Main.java里塞两千行，窗口、键盘监听、碰撞检测、绘图全在一起。单机小游戏这样写还能跑，一旦要双人联机，问题立刻暴露：两个客户端各自维护一份地图和角色位置，谁说了算？如果客户端 A 说自己跳到了平台上，客户端 B 看到的是掉进岩浆，这局就没法玩了。所以森林冰火人联机版必须拆成四层：服务端权威层负责接收两个客户端的输入、计算角色最终位置、广播状态；客户端渲染层只负责画和发按键；地图数据层用一份共享的二维数组描述哪些格子是火池、冰池、平台、门；角色状态层用对象保存每个玩家的坐标、速度、存活状态。拆开之后，服务端是唯一真相来源，客户端只是「显示器 + 键盘」。

常见做法是用ServerSocket起一个服务端，两个Socket分别对应火人和冰人。服务端每收到一个方向键就更新对应角色的速度，然后在固定 tick（比如 60 次/秒）里做碰撞和位置积分，再把两个角色的坐标打包广播。客户端收到坐标后只做插值渲染，不做任何判定。这样即使两个客户端性能不一样，画面也不会出现「我这边到了、你那边没到」的分裂。

2.2 地图用二维数组还是对象列表：选型理由和参数

地图表示方式直接决定碰撞检测的写法。用二维int[][]是最省事也最适合大作业的方案：0 表示空地，1 表示平台，2 表示火池，3 表示冰池，4 表示火门，5 表示冰门。每个格子固定 32×32 像素，地图 25 列 × 15 行就是 800×480 的窗口，正好适配大多数笔记本屏幕。相比用List<Rectangle>存平台，二维数组的好处是碰撞查询是 O(1)：角色坐标除以 32 取整就能拿到所在格子，判断格子类型即可决定是阻挡、伤害还是通关。

参数上我一般会固定这几个：TILE_SIZE = 32、GRAVITY = 0.6、JUMP_VELOCITY = -11、MOVE_SPEED = 4、MAX_FALL_SPEED = 12。重力每帧加到垂直速度上，跳跃时把垂直速度设成负值，水平速度由按键直接设定。这些数值不是随便写的：重力 0.6 配合跳跃初速 -11，跳跃高度大约 3 个格子，刚好能跳上森林冰火人里常见的两层平台；如果重力调到 1.0，跳跃会变得很「沉」，手感立刻变差。服务端和客户端必须用同一套常量，否则会出现客户端预测和服务端判定不一致的玄学问题。

2.3 角色状态对象里必须存哪些字段

一个角色对象至少要有：id（1 是火人，2 是冰人）、x、y（像素坐标）、vx、vy（速度）、onGround（是否踩地）、alive（是否存活）、atDoor（是否到达自己颜色的门）。少一个都会在联机时出问题。比如没有onGround，你就无法区分「站在平台上按跳跃」和「在空中按跳跃」，会导致二段跳 bug；没有alive，火人掉进冰池后客户端还在画他，服务端却已经判定死亡，两边状态就分叉了。

public class Player { public int id; // 1=火人, 2=冰人 public double x, y; // 像素坐标 public double vx, vy; // 速度 public boolean onGround; public boolean alive = true; public boolean atDoor = false; public Player(int id, double x, double y) { this.id = id; this.x = x; this.y = y; } }

这段代码的关键点是所有字段都用public只是为了大作业演示方便，真实项目里应该用 getter/setter 或 record。x、y用double而不是int，是因为速度积分会产生小数，用int会累积舍入误差，角色移动会一卡一卡。id决定这个角色碰到火池还是冰池会受伤，这个映射关系写在服务端的碰撞逻辑里，不要放到客户端。

3. 用 Socket 把双人联机跑通：服务端广播与客户端输入的最小实现

3.1 服务端启动与双客户端接入的代码骨架

服务端要做三件事：监听端口、等两个客户端连上、开两个线程分别读它们的输入。下面是最小可跑骨架，端口用 8888，实际改成本机没被占用的端口即可。

public class GameServer { private static final int PORT = 8888; private static Player[] players = new Player[2]; private static PrintWriter[] outs = new PrintWriter[2]; public static void main(String[] args) throws IOException { ServerSocket server = new ServerSocket(PORT); System.out.println("等待两名玩家加入..."); for (int i = 0; i < 2; i++) { Socket socket = server.accept(); final int id = i + 1; players[i] = new Player(id, id == 1 ? 100 : 200, 100); outs[i] = new PrintWriter(socket.getOutputStream(), true); new Thread(() -> handleClient(socket, id)).start(); } new Thread(GameServer::gameLoop).start(); } private static void handleClient(Socket socket, int id) { try (BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream()))) { String line; while ((line = in.readLine()) != null) { // 输入格式: "LEFT", "RIGHT", "JUMP", "STOP" applyInput(id, line); } } catch (IOException e) { System.out.println("玩家 " + id + " 断开"); } } }

server.accept()会阻塞，直到第一个客户端连上才继续，所以两个客户端必须都启动后游戏才开始。handleClient里用BufferedReader按行读，是因为我们约定客户端每次发一个动作字符串加换行，比直接读字节流好解析。applyInput根据动作改对应玩家的vx或vy，注意这里只改速度，不改坐标，坐标统一在gameLoop里算。

3.2 固定 tick 的游戏循环与状态广播

游戏循环是整个联机同步的心脏。不要用while(true)裸跑，那样 CPU 会飙到 100%，而且不同机器帧率不一样，物理表现会漂移。正确做法是固定时间步长，比如每 16 毫秒跑一次逻辑，也就是大约 60 tick/秒。

private static void gameLoop() { final long TICK_MS = 16; long last = System.currentTimeMillis(); while (true) { long now = System.currentTimeMillis(); if (now - last < TICK_MS) continue; last = now; for (Player p : players) { if (!p.alive) continue; p.vy += 0.6; // 重力 if (p.vy > 12) p.vy = 12; // 最大下落速度 p.x += p.vx; p.y += p.vy; resolveCollision(p); // 碰撞与伤害判定 } broadcast(); } } private static void broadcast() { StringBuilder sb = new StringBuilder(); for (Player p : players) { sb.append(p.id).append(",") .append((int) p.x).append(",") .append((int) p.y).append(",") .append(p.alive ? 1 : 0).append(";"); } for (PrintWriter out : outs) { if (out != null) out.println(sb.toString()); } }

TICK_MS = 16是经验值，对应 60Hz，和大多数显示器刷新率接近，画面不会明显撕裂。resolveCollision里做三件事：判断角色脚下格子是不是平台来决定onGround；判断角色所在格子是火池还是冰池，再结合id决定扣血还是回血；判断是否到达对应颜色的门。广播格式用分号分隔两个玩家、逗号分隔字段，客户端按同样规则解析即可。注意广播的是(int)取整后的坐标，减少带宽，客户端渲染时再做插值。

3.3 客户端按键采集与渲染循环

客户端要做的是：连服务端、开一个线程收广播、主线程用 Swing 画画面、键盘监听把按键发出去。按键不要每帧都发，按住方向键时每 50 毫秒发一次就够，否则服务端会被刷屏。

public class GameClient extends JPanel { private static PrintWriter out; private static int fireX = 100, fireY = 100; private static int iceX = 200, iceY = 100; public static void main(String[] args) throws IOException { Socket socket = new Socket("127.0.0.1", 8888); out = new PrintWriter(socket.getOutputStream(), true); new Thread(() -> { try (BufferedReader in = new BufferedReader( new InputStreamReader(socket.getInputStream()))) { String line; while ((line = in.readLine()) != null) { parseState(line); // 更新 fireX/fireY/iceX/iceY } } catch (IOException ignored) {} }).start(); JFrame frame = new JFrame("森林冰火人 - 双人联机"); GameClient panel = new GameClient(); frame.add(panel); frame.setSize(800, 480); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); frame.setVisible(true); frame.addKeyListener(new KeyAdapter() { public void keyPressed(KeyEvent e) { switch (e.getKeyCode()) { case KeyEvent.VK_A: out.println("LEFT"); break; case KeyEvent.VK_D: out.println("RIGHT"); break; case KeyEvent.VK_W: out.println("JUMP"); break; } } }); while (true) { panel.repaint(); try { Thread.sleep(16); } catch (InterruptedException ignored) {} } } }

127.0.0.1是本机测试用的，如果两台机器联机，改成服务端所在机器的局域网 IP。parseState按分号和逗号拆字符串，把坐标赋给fireX、fireY、iceX、iceY。repaint()每 16 毫秒调一次，和 60Hz 对齐。键盘监听里只处理按下，不处理松开，所以角色会一直朝一个方向走，真实项目里要加keyReleased发STOP。这个骨架跑起来后，你会看到两个窗口各自控制一个角色，服务端控制台打印状态，联机链路就通了。

4. 联机同步与碰撞判定里最容易翻车的五个坑

4.1 现象：两个客户端角色位置对不上，一个在平台上另一个在岩浆里

原因几乎总是客户端也做了物理计算。很多同学图省事，在客户端按键后直接改本地坐标，服务端广播回来又覆盖一次，两边积分步长不一致就分叉了。解决方法是客户端只发输入、只渲染广播坐标，所有vy += gravity、x += vx全部只在服务端做。客户端可以加一点插值让移动平滑，但绝不能改判定用的坐标。

4.2 现象：火人碰到火池反而掉血，冰人碰到冰池也掉血

这是伤害判定写反了。森林冰火人的规则是「火人怕冰池、冰人怕火池」，代码里要用id做映射。常见错误是写if (tile == FIRE_POOL) damage(p)，忘了判断p.id。正确写法是：if (tile == FIRE_POOL && p.id == 2) hurt(p);和if (tile == ICE_POOL && p.id == 1) hurt(p);。回血逻辑同理，火人进火池回血、冰人进冰池回血。这个坑血泪经验是：写完一定要用两个角色分别踩两种池子测一遍，别只测一个。

4.3 现象：角色卡在平台边缘抖动，或者穿过薄平台掉下去

原因是碰撞检测只判断了角色中心点所在格子，没有判断脚下。角色宽高各 32 像素，中心点在格子边界时，中心点可能还在空中，脚已经踩到平台了。解决方法是取角色底部中心点(x + 16, y + 32)所在格子判断是否平台，同时用vy > 0限制只有下落时才判定落地，避免上升时被平台顶住。如果平台只有一格厚，还要在落地后把y吸附到格子顶部，即y = row * 32 - 32，否则下一帧又会因为重力穿下去。

4.4 现象：服务端广播频率太高，客户端画面一顿一顿的

broadcast()如果每 tick 都发，60 次/秒的字符串拼接和网络写会占不少 CPU，尤其是两个客户端都在同一台机器上时。常见优化是每 2 到 3 个 tick 广播一次，客户端用线性插值补帧。另一个坑是PrintWriter没有 flush，导致消息攒在缓冲区里延迟发送。用new PrintWriter(out, true)的自动 flush，或者每次println后手动flush()。如果发现延迟忽高忽低，先查这个。

4.5 现象：第二个客户端连上后第一个客户端卡死

原因是accept()在主线程里循环，第二个accept()阻塞时主线程没法处理第一个客户端的输入。解决方法是每接一个客户端就开一个线程读它的输入，主线程继续accept。另外players和outs数组被多个线程读写，严格来说要加锁或用ConcurrentHashMap，大作业里至少保证outs的写操作在广播线程里串行执行，避免两个线程同时println导致输出交错。

5. 把大作业做成能讲清楚的项目：验证方法与一个手感调优技巧

5.1 用日志和回放验证联机一致性

交大作业之前，我一般会加一个简单的状态日志：服务端每 60 tick 把两个玩家的坐标写进log.txt，格式是tick,id,x,y,alive。然后写个脚本对比两个客户端收到的坐标序列和服务端日志是否一致。如果客户端坐标和服务端日志偏差超过 2 像素，说明插值或解析有问题。这个验证方法比肉眼盯着看靠谱得多，答辩时也能拿出来说明你做过一致性检查。

// 服务端 gameLoop 里每 60 tick 追加一行 if (tick % 60 == 0) { try (FileWriter fw = new FileWriter("log.txt", true)) { for (Player p : players) { fw.write(tick + "," + p.id + "," + (int)p.x + "," + (int)p.y + "," + (p.alive ? 1 : 0) + "\n"); } } catch (IOException ignored) {} }

tick是循环计数器，每跑一次gameLoop加一。FileWriter的第二个参数true表示追加模式，不会覆盖之前的日志。这个日志文件在排查「为什么这局角色突然死了」时特别有用，相当于给联机过程装了个黑匣子。

5.2 跳跃手感调优：三个参数一起改才有效

森林冰火人的手感核心在跳跃。单独调JUMP_VELOCITY效果有限，必须和GRAVITY、MAX_FALL_SPEED一起调。下面这张表是我试过比较舒服的一组值，你可以在此基础上微调：

调参时建议固定MOVE_SPEED，先调JUMP_VELOCITY让跳跃高度合适，再调GRAVITY让滞空时间自然，最后用MAX_FALL_SPEED防止穿模。每次只改一个参数，改完跑一局，记录感受。不要一次改三个，否则你根本不知道是哪个起了作用。

5.3 一个让答辩加分的技巧：把地图做成可配置

大作业最容易被问「你这地图写死的吧，能不能换一关」。如果你把地图抽成map.txt，每行一串数字，启动时读进来，就能现场演示换地图。格式可以简单到每行 25 个数字，用空格分隔，服务端读文件填进int[][]。这样你不仅展示了联机，还展示了文件 IO 和配置化思维，比单纯堆功能更能说明你理解了这个项目。我自己的习惯是：任何写死的常量，只要它可能变，就抽成配置。这个习惯在后来做真实项目时救过我很多次，希望帮到你。

本文还有配套的精品资源，点击获取