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 的窗口正好适配大多数笔记本屏幕。相比用ListRectangle存平台二维数组的好处是碰撞查询是 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 角色状态对象里必须存哪些字段一个角色对象至少要有id1 是火人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一起调。下面这张表是我试过比较舒服的一组值你可以在此基础上微调参数值作用调大后的效果GRAVITY0.6每帧垂直加速度下落更快跳跃更沉JUMP_VELOCITY-11起跳瞬间垂直速度跳得更高但落地更重MAX_FALL_SPEED12下落速度上限减少高速穿透平台MOVE_SPEED4水平移动速度移动更快但容易冲过头调参时建议固定MOVE_SPEED先调JUMP_VELOCITY让跳跃高度合适再调GRAVITY让滞空时间自然最后用MAX_FALL_SPEED防止穿模。每次只改一个参数改完跑一局记录感受。不要一次改三个否则你根本不知道是哪个起了作用。5.3 一个让答辩加分的技巧把地图做成可配置大作业最容易被问「你这地图写死的吧能不能换一关」。如果你把地图抽成map.txt每行一串数字启动时读进来就能现场演示换地图。格式可以简单到每行 25 个数字用空格分隔服务端读文件填进int[][]。这样你不仅展示了联机还展示了文件 IO 和配置化思维比单纯堆功能更能说明你理解了这个项目。我自己的习惯是任何写死的常量只要它可能变就抽成配置。这个习惯在后来做真实项目时救过我很多次希望帮到你。本文还有配套的精品资源点击获取