尧图网页设计 
简介面向Java初学者与数据结构学习者的课程设计大作业基于GUI实现双人联机小游戏“森林冰火人”程序已测试通过、可直接运行适合用作课程设计、算法练手及游戏开发入门项目。压缩包共包含68个文件除11个Java源码与15个class编译文件外还配有大量jpg、gif、png图片素材以及properties配置文件、xml设置文件和README说明文档整体体积仅2.42MB目录结构清楚源码、图片资源与编译产物分区存放便于按模块阅读和二次开发。已有698人学习下载。借助完整项目与配套资料读者可以深入理解界面事件处理、双人联机协作机制以及数据结构与算法在碰撞检测、状态管理等环节的实际运用整套程序经过测试可直接启动也可作为期末大作业或课程设计的重要参考。项目结构直观程序入口与功能模块划分清晰适合教学演示或大作业模板。1. 大一下Java大作业——双人联机小游戏森林冰火人这个包到底怎么用大一下Java大作业——双人联机小游戏森林冰火人多数时候是一个躺在压缩包里的课程设计而不是能立刻运行的产品。第一批坑往往不在代码而是入口类在哪、JDK版本选哪个、两张网卡为什么连不通。这类项目的典型构成是用Swing画双人操作的界面用Socket做局域网TCP房间用多线程把两位玩家的状态同步起来再把森林冰火人的合作闯关规则拆成地图、角色、机关三类对象。它能帮你过课程设计也能在答辩现场讲出东西。适合三类人想跑通示例并读懂关键代码的、想拿这个包改造成自己作品的、想弄清楚两台电脑怎么共享一个游戏世界的学生。2. 玩法拆成需求从双人操作到网络同步的四个硬骨头不管是自己写还是拿现成包改造都得先把玩法翻译成程序语言。森林冰火人不是对战是双人合作火人免疫火池和火宝石冰人免疫冰池和冰宝石两个人一起踩开关、躲水池、拿宝石才能到终点。落到Java课程设计这个级别真正的技术点只有四个地图规则怎么存、画面怎么动、双方怎么连、状态怎么同步。先把这四个硬骨头啃下来后面读代码才有方向。2.1 玩法拆成规则地图、角色与碰撞地图本质上是一张二维网格。常见做法是用int数组存格子类型0是空地1是墙2是冰池3是火池4是水池再单独标记宝石和开关的位置。这样写的好处是地图即数据画图和碰撞检测都从一个数组里取答辩时老师说“你这关怎么加的”你只要回答“改二维数组”就够了。int[][] map { {1, 1, 1, 1, 1, 1}, {1, 0, 0, 0, 0, 1}, {1, 0, 3, 2, 0, 1}, {1, 0, 0, 0, 0, 1}, {1, 1, 1, 1, 1, 1} };逻辑说明把地图和角色分开是面向对象里最基础的责任分离。上面数组里3和2两个格子分别代表火池和冰池火人走3没事冰人走2没事水对两个角色都是即死。判断逻辑不要写在paint方法里要写在独立的碰撞检测方法里否则画面一复杂重绘和逻辑搅在一起程序会越来越难改。碰撞检测我推荐“四角内缩法”。角色在地图上有一个矩形包围盒取四个角对应的格子只要任一格子是致命地形就判定死亡。四角比中心点判断准比“整个包围盒逐格扫描”快代码也不长。核心参数是那2像素的内缩量角色贴墙时视觉上已经擦到墙边但包围盒四角稍稍缩进来不会一碰墙就死也不会看着没碰到就死亡这个手感来自实测调整不是数学算出来的。int left (p.x 2) / TILE_SIZE; int right (p.x p.width - 2) / TILE_SIZE; int top (p.y 2) / TILE_SIZE; int bottom (p.y p.height - 2) / TILE_SIZE; if (isLethal(map[left][top]) || isLethal(map[right][top]) || isLethal(map[left][bottom]) || isLethal(map[right][bottom])) { p.alive false; }逻辑说明TILE_SIZE是每格像素数比如32角色宽高一般取28左右留出视觉上的活动余量。p.x和p.y是角色左上角坐标。内缩2像素后四角落在哪个格子再去查地图数组对应值。这个做法也适合开关和门门是普通地图格开关是道具踩到时直接把门格子的值从1改成0。2.2 画面怎么动起来Swing游戏循环与键绑定Swing不是游戏引擎但做课设足够。基础是继承JPanel重写paintComponent把地图、角色、宝石一张张画上去JFrame只负责窗口外壳键盘输入优先用键绑定Key Bindings而不是KeyListener。原因很实际KeyListener在中文输入法弹出、窗口失焦时会丢按键联机游戏里方向键丢一次对面玩家可能就掉进水池了这是很常见的翻车点。游戏循环有两种常见写法。第一种用javax.swing.Timer定时触发重绘代码简单但回调运行在Swing事件线程上不能在里面做阻塞读取。第二种单独开一个线程跑while循环适合联机项目因为Socket读取天然是阻塞的。我一般用第二种并且用System.nanoTime计算帧间隔而不是每次Thread.sleep(16)。sleep本身误差不大但Windows上计时器精度一般累积多了画面会一抖一抖。Thread gameLoop new Thread(() - { long last System.nanoTime(); while (running.get()) { long now System.nanoTime(); if (now - last 16_000_000L) { // 约60帧/秒 updateGame(); panel.repaint(); last now; } } });逻辑说明running用AtomicBoolean或volatile boolean目的是让窗口关闭时能干净退出循环。16_000_000L单位是纳秒相当于16ms一帧想降到30帧就改成33_000_000L。这里不用sleep是因为循环里没有阻塞时忙等能让帧间隔更均匀代价是让出一部分CPU第5章会讲怎么控制这个消耗。updateGame里做的事包括读键盘状态、更新角色位置、检查碰撞、发送网络消息repaint只是请求重绘真正绘制在Swing事件线程里执行。2.3 联机走TCP为什么不是UDP、不是HTTP课程设计阶段联机方案我没有犹豫过用TCP的ServerSocket和Socket。UDP延迟更低适合动作游戏但你要自己处理丢包、乱序、重复包这已经超出“大一下Java大作业”的合理范围了HTTP轮询连“实时”都算不上还要额外搭一个Web服务端。TCP保证字节按序到达你只需要把消息按行切开网络层就算稳住了。方案实时性要自己处理的问题大作业适合度TCP Socket中等粘包/半包、断线高UDP Socket高丢包、乱序、重发低HTTP 轮询低连接开销、延迟大低选TCP还有一个理由老师的答辩问题会集中在“你用什么协议为什么”你只要说出“TCP按序到达适合小规模双人联动劣势是队头阻塞但两个玩家之间的消息量很小影响可以忽略”这一句话里信息量就够了。如果非要显得更专业再补一句“双人实时对战UDP更有优势但课程设计需要在可靠性上省时间所以选了TCP”。网络结构也有两种布置。第一种是房间制其中一台电脑跑服务端另一台填IP加入第二种是大厅制服务端跑在公网或教室某台机器上两个玩家都去连它。大作业用房间制最简单不用买服务器答辩现场两台笔记本开着就能演演示失败的概率最低。2.4 双人同步的核心多线程与共享状态两个玩家不在同一台机器上数据要跨网络同步这背后其实是一个多线程问题。一局游戏里至少有两条网络读线程玩家1的读线程和玩家2的读线程都要把消息推进同一个游戏状态。如果两个线程直接写同一个角色对象你就在制造数据竞争。常见做法是网络线程只负责把消息放进一个线程安全队列游戏逻辑线程从队列取消息再更新角色。队列相当于一个缓冲闸门把“网络到达的节奏”和“游戏画面的节奏”解开。// 收消息只做一件事入队 BlockingQueueMessage incoming new LinkedBlockingQueue(); Thread reader new Thread(() - { String line; while ((line in.readLine()) ! null) { incoming.put(Message.parse(line)); } }); reader.start(); // 逻辑线程每帧取出并应用 Message msg incoming.poll(); if (msg ! null) { applyMessage(msg); }逻辑说明LinkedBlockingQueue的put和poll都是线程安全的不需要额外加synchronized。poll不阻塞取不到就返回null正好配合游戏循环的帧节奏如果用take逻辑线程就会被网络消息阻塞住画面更新反而不稳定。这条队列是联机项目里性价比最高的基础设施比你去处理synchronized共享角色对象要省心得多。3. 拿到zip先找四样再动手入口类、地图资源、网络线程和启动脚本拿到一个压缩包我从来不会先双击运行。第一步是把它解压到一个没有空格的路径比如D:\fireice然后开始找四个东西入口类、地图数据、网络线程、启动方式。这四样找齐了这个项目在你心里就有了轮廓后面改代码心里不慌。3.1 入口类速查main、ServerSocket、JFrame三个关键词没有README时最快定位方式是全局搜索。在IDEA里用CtrlShiftF或者在项目根目录直接用命令行搜。我自己习惯先搜三个关键词main(对应入口ServerSocket对应服务端JFrame对应窗口。这三个词能让你在五分钟内知道项目从哪启动、有没有房间概念、界面入口叫什么。grep -rn public static void main --include*.java . grep -rn ServerSocket --include*.java . grep -rn JFrame --include*.java .逻辑说明grep -r递归搜索n显示行号--include*.java只查Java源码。如果项目用了Maven或Gradle入口信息在pom.xml或build.gradle里的mainClass不过大一下的作业很少用构建工具常见的是直接用IDE运行或写批处理脚本。搜到多个main时不要慌用“哪个类里出现JFrame或ServerSocket”来判断哪个是图形入口另一个通常是测试入口。3.2 地图与素材int数组、CSV还是图片文件地图数据放在哪里决定你改一个关卡要动多少代码。常见有三种形态写在Java类里的int二维数组放在根目录的文本文件或CSV以及直接用图片格子拼出来的地图。第一种最容易读第二种修改方便第三种依赖图片文件如果压缩包里素材缺失地图就会显示成一堆黑块。找到地图定义后先数一数行数和列数再找到TILE_SIZE这个常量这两个值直接决定窗口大小。常见套路是JFrame.setSize(cols * TILE_SIZE 边框, rows * TILE_SIZE 边框)如果窗口开出来位置不对、角色飘在地图外面十有八九是这里没对齐。如果需要自己加一关不要新建一个类直接在同一个关卡数据类里加一个static int[][] LEVEL_2再把关卡编号做成参数传给地图加载方法这样最不容易出错。3.3 网络线程Server、Client、转发逻辑在哪个类搜完ServerSocket后把所有出现这个词的位置标出来。服务端类的工作一般有三块accept()等待连接、读一个客户端的消息、把消息写给另一个客户端。有些代码会把这三个动作写在一个循环里两个玩家消息互相等待看起来能跑但实际上一方不发消息另一方就收不到更新这就是“队友不动”最常见的原因。如果项目里只有一个Socket类而没有ServerSocket说明它可能是“两人直连”模式也就是一台机器既是服务端又是客户端。直连模式写法更简洁但只能在固定拓扑下工作而且通常没有重连机制。大作业用哪种都行关键是答辩时你要能说清楚你的房间里谁在accept、谁在connect。3.4 命令行编译与运行没有IDE也能跑不管原来用什么IDE我都建议花十分钟把命令行编译跑通。原因很实在答辩现场不一定有IntelliJ老师机器上可能只有JDK命令行能跑你就永远有一个不依赖IDE的后悔药。先确认javac -version能看到版本再执行下面的命令。# 假设源码在 src 下入口类叫 game.Main javac -encoding UTF-8 -d out src/game/*.java # 单机调试不启动网络 java -cp out game.Main --local # 房主监听 8888 端口 java -cp out game.Main --host 8888 # 加入指到房主IP java -cp out game.Main --join 192.168.1.23 8888逻辑说明-encoding UTF-8是必选项Windows中文环境默认GBK不加这一句源码里的中文注释全部乱码字符串也可能直接报错。-d out把class文件输出到out目录避免源码和字节码混在一起。--local这个参数是我的习惯用法先不开网络用来单独测地图、碰撞和操作手感联机工程里单机模式是最高频的调试手段务必保留。如果压缩包里已经有run.bat或run.sh先读它大概率能还原作者当时的运行环境。bat里常见的set JAVA_HOME...、set CLASSPATH...比你自己猜入口类可靠得多。环境变量如果没配好最典型的现象是javac不是内部或外部命令这个时候去把JDK的bin目录加到Path不要重装JDK浪费时间的血泪经验。4. 让两台电脑共享一个世界最小可复现的双人联机实现这一章给出一套可以直接抄的联机骨架。它不是森林冰火人的完整代码但负责解决“两台电脑怎么同步”这最玄学的一块。完整游戏的地图、机关、胜负判定都挂在这个骨架上你只需要把游戏逻辑填进对应方法。4.1 一条消息走天下先定协议再写代码联机最忌边写代码边定协议。消息格式不统一服务端转发、客户端解析、日志打印都要跟着改改到后面自己都分不清哪个类是问题重灾区。我推荐文本行协议一行消息用竖线分隔字段开头是消息类型后面是参数。文本协议肉眼可读出了问题可以直接打印日志看比对象流黑匣子舒服太多。// Message.java —— 行协议编解码 public class Message { public String type; // P位置 S跳跃 C聊天事件 public String[] args; public static Message parse(String line) { String[] parts line.split(\\|); Message m new Message(); m.type parts[0]; m.args java.util.Arrays.copyOfRange(parts, 1, parts.length); return m; } public static String of(String type, Object... args) { StringBuilder sb new StringBuilder(type); for (Object arg : args) { sb.append(|).append(arg); } return sb.toString(); } }逻辑说明parse负责把P|0|128|96|1拆成类型P和参数数组[0,128,96,1]of负责反向组装。参数顺序要固定例如P|角色ID|x|y|场景号场景号留给多关卡用没有多关卡时可以省略。协议定好后所有网络代码都只和Message打交道游戏玩法改了不需要动传输层。选择竖线而不是逗号或JSON理由是解析成本低也不会出现在坐标和角色ID里。如果用JSONJava自带的JSONObject在部分JDK里要引第三方包大作业里增加依赖不值得。如果你的角色名字或聊天文本里有竖线做一个简单转义比如把输入里的|替换成全角竖线收发再转回来这是文本协议唯一的代价。4.2 服务端房间两个accept加一个转发循环服务端表面上是“服务器”实际就是一个消息中转站。两个玩家先连上之后任何一个人发来的消息原样转发给另一个人。架构上这叫中继好处是两人的IP和端口互不关心坏处是服务端要挂在整个对局期间。房间制里房主电脑同时跑游戏和服务端性能完全扛得住。// GameServer.java —— 服务端骨架 try (ServerSocket server new ServerSocket(8888)) { System.out.println(房间已开等待玩家1...); Socket p1 server.accept(); System.out.println(玩家1已加入); Socket p2 server.accept(); System.out.println(玩家2已加入开局); Socket[] players {p1, p2}; for (int i 0; i 2; i) { int idx i; Thread t new Thread(() - { try (BufferedReader in new BufferedReader( new InputStreamReader(players[idx].getInputStream(), UTF-8))) { String line; while ((line in.readLine()) ! null) { Socket other players[1 - idx]; PrintWriter out new PrintWriter( other.getOutputStream(), true); out.println(line); // 原样转发 } } catch (Exception e) { System.out.println(玩家 (idx 1) 断开); } }); t.start(); } // 阻塞主线程防止房间提前关闭 Thread.sleep(Long.MAX_VALUE); }逻辑说明accept()是阻塞调用第一次等玩家1第二次等玩家2两人齐了才继续。两个线程各读一个客户端读到一行就写给另一个。1 - idx这个写法很关键读0号写给1号读1号写给0号。PrintWriter第二个参数true表示自动flushprintln后消息立刻送出省去手动flush。如果不想让主线程挂住可以把服务端放在new Thread(() - runServer()).start()里但注意不要放在Swing事件线程里否则窗口会卡在“等待加入”。端口号的选择有讲究。8888只是演示实际推荐8020到8999之间的端口避开8080、8000这些常见网管端口也避开系统预留端口。同一个网段下两台机器防火墙会拦陌生端口教室的Windows机器经常默认拦截Java入站解决办法是第一回运行弹窗时点“允许访问”或者让两台机器连同一个手机热点热点环境下两台机器通常在同一子网联机成功率比校园网高不少。4.3 客户端循环收消息、改状态、触发重绘客户端同时干三件事画界面、读本机按键、读网络消息。如果都放在Swing事件线程界面会因为网络阻塞而假死。正确姿势是网络读线程独立运行把收到的消息放进队列游戏循环每帧从队列取一条消息更新角色位置然后repaint。// GameClient.java —— 客户端骨架 Socket socket new Socket(serverIp, 8888); BufferedReader in new BufferedReader( new InputStreamReader(socket.getInputStream(), UTF-8)); PrintWriter out new PrintWriter(socket.getOutputStream(), true); BlockingQueueMessage incoming new LinkedBlockingQueue(); Thread reader new Thread(() - { String line; try { while ((line in.readLine()) ! null) { incoming.put(Message.parse(line)); } } catch (Exception e) { System.out.println(与房间的连接断开); } }); reader.start(); // 游戏循环里每帧取一条消息 Message msg incoming.poll(); if (msg ! null) { if (P.equals(msg.type)) { int id Integer.parseInt(msg.args[0]); int x Integer.parseInt(msg.args[1]); int y Integer.parseInt(msg.args[2]); game.remotePlayers[id].setTarget(x, y); } }逻辑说明socket连接后in负责读服务器转发来的消息out负责把本机操作发出去。poll不阻塞每帧取一条如果消息比帧多就慢慢消化如果帧比消息快就返回null继续画。setTarget在这里不直接改坐标而是记一个目标位置交给插值逻辑平滑过去4.4会细说。发送端更简单。你只需要在角色移动后调用out.println(Message.of(P, id, x, y, scene))。发送频率建议每帧一次或不高于20次每秒。不要等到“松手才发”联机游戏要的是连续轨迹不是起终点。如果键盘按下和松开都被监听就都发出去对方就可以用“按住状态”判断方向而不是靠坐标差值反推。这里有个容易被忽略的参数坐标发出去之前最好转成整数浮点坐标带小数发出去占用空间大而且两边浮点运算一不一样步画面就飘。4.4 远端玩家插值把网络迟滞藏进两像素里无线网络下消息延迟波动个二三十毫秒很正常。对方在A点发的坐标到你这时他已经跑到B点了如果直接设坐标你会看到对方瞬移。常见做法是给远端玩家加一个“目标位置”每帧让它以固定速度靠近目标而不是直接赋值。这样延迟造成的跳跃会被平滑成一段短距离追赶观感上不再是瞬移。// 远端玩家每帧插值 Player p game.remotePlayers[id]; int dx p.targetX - p.x; int dy p.targetY - p.y; int dist Math.abs(dx) Math.abs(dy); if (dist 0 dist 24) { // 距离很近了直接归位 p.x p.targetX; p.y p.targetY; } else if (dist 0) { p.x Integer.signum(dx) * 2; // 每帧最多移动2像素 p.y Integer.signum(dy) * 2; }逻辑说明Integer.signum返回-1、0或1让角色朝目标方向走。2像素这个数是移动速度下限太大会让人物发飘太小会拖着走。dist 24的24是归位阈值这个阈值决定“追到多近就算追上”网络正常时路径短一两帧就追上网络抖动时则表现为略微延迟但不会瞬移。真实项目里这套插值还要带上“最后一次收到消息的时间”超过300ms没收到就判定对方网络差停止移动而不是原地漂移。5. 避坑双人联机项目最常见的5个翻车现场联机项目的坑很多不是语法错误而是逻辑时序问题。下面几条是我自己在大作业上翻过车、也给同学救过场的场景按“现象—原因—解决”来写省得你逐个踩。5.1 队友站着不动先怀疑转发逻辑而不是怪网络现象本机操作正常队友那边屏幕上的“你”不动或者反过来你看队友不动。 原因九成是服务端只accept了没转发。常见写法错误是服务端里只读了一个客户端另一个客户端的消息根本没进入读取循环还有的是把两个客户端都读了但没写“把A读到的消息发给B”这一步。 解决在服务端每个转发分支加日志打印“收到来自0的消息转发给1”。不要靠肉眼盯屏幕判断网络是否通先看控制台有没有输出。日志对联机项目来说就是呼吸灯没有它网络问题就是个黑匣子。System.out.println(收到玩家 idx 的消息: line); // 转发到另一个客户端 otherOut.println(line);加了日志以后队友不动的原因会立刻现形如果服务端根本没打印说明消息没到服务端如果打印了但队友不动说明转发或客户端解析有问题。这样排查一次比自己瞎改半天下一次联机快得多。5.2 关掉窗口进程还在8888端口被占现象关掉游戏窗口后再次启动提示Address already in use: bind。任务管理器里能看到一个Java进程没退。 原因Swing默认的窗口关闭行为是隐藏窗口不是退出JVM。网络线程还阻塞在accept()或readLine()上JVM不会主动退出端口自然一直被占。 解决在创建JFrame后设置setDefaultCloseOperation(EXIT_ON_CLOSE)并在窗口关闭事件里关闭Socket。如果之前写的是HIDE_ON_CLOSE就先把这一行找出来改掉。frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // 如果想做“提示后退出”挂窗口监听 frame.addWindowListener(new WindowAdapter() { Override public void windowClosing(WindowEvent e) { running.set(false); socket.close(); // 让reader线程的readLine抛异常退出 } });逻辑说明socket.close()是强制让阻塞在readLine()的线程抛异常线程结束游戏循环也退出进程自然消失。注意windowClosing里还能做“保存配置”这类善后但不要在这里弹模态框等用户点击窗口关闭事件线程会一直等你。5.3 对象流卡死别用ObjectInputStream做实时游戏现象双方都连接成功但一条消息都收不到偶尔抛EOFException或InvalidClassException。 原因ObjectOutputStream和ObjectInputStream配对使用时写端有缓冲区writeObject后必须flush()对方才会真正读数据。而且readObject()是阻塞式等待整个对象序列化完毕两个客户端互相等待就成了死锁。 解决我的建议是放弃对象流改用4.1的文本行协议。如果作业代码里已经用了对象流最小修复是给每个writeObject后面加flush()reset()可以在重复发送对象引用时避免缓存旧值但治标不治本。类型不一致的问题来自两边用了不同版本或不同包路径的类把类定义复制到两边的同学心里就知道多痛了。5.4 CPU占用100%游戏循环少了固定节拍现象游戏能玩但笔记本风扇狂转电量哗哗掉。 原因游戏循环写成while(running){ update(); repaint(); }没有任何帧间隔控制。repaint本身不一定每秒60次但update和碰撞检测的循环跑满一个CPU核心。 解决给循环加一个节拍器16ms一帧的阈值用System.nanoTime比较更省CPU的做法是忙等改为sleep(1)到sleep(16)或者用LockSupport.parkNanos。在课程设计层面Thread.sleep(16)已经完全够用但注意sleep要放在每帧末尾并且把“sleep被中断”的异常处理掉。while (running.get()) { long frameStart System.nanoTime(); updateGame(); panel.repaint(); long cost System.nanoTime() - frameStart; long sleepMs 16 - cost / 1_000_000; if (sleepMs 0) Thread.sleep(sleepMs); }逻辑说明这个写法先算这一帧花了多少时间再补足剩下的时间到16ms。如果一帧已经超过16ms直接进入下一帧不自欺欺人地凑帧数。也可以把16换成1000 / 60这样帧率意图一目了然。5.5 输入法抢按键用键绑定替代KeyListener现象中文输入法开着按W、A、S、D角色没反应按一下空格却输入一个汉字或符号角色在游戏里原地罚站。 原因KeyListener直接监听键盘事件输入法软件会截走按键Java拿不到真正的keyCode焦点在文本框或输入法候选窗上时也会丢事件。 解决改用Swing的键绑定机制把KeyStroke映射到Action。下面的代码给角色1绑定W键的按下和松开。InputMap im panel.getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW); ActionMap am panel.getActionMap(); im.put(KeyStroke.getKeyStroke(W), p1_up_pressed); im.put(KeyStroke.getKeyStroke(released W), p1_up_released); am.put(p1_up_pressed, new AbstractAction() { public void actionPerformed(ActionEvent e) { game.handleKey(1, KeyButton.UP, true); } }); am.put(p1_up_released, new AbstractAction() { public void actionPerformed(ActionEvent e) { game.handleKey(1, KeyButton.UP, false); } });逻辑说明WHEN_IN_FOCUSED_WINDOW意思是只要窗口有焦点子组件都能响应按键不会因为焦点停在某个按钮上就失效。变量名p1_up_pressed只是为了识别动作对应到KeyStroke.getKeyStroke(W)。另一个角色用方向键UP/DOWN/LEFT/RIGHT写法和W完全一致。这个改动对游戏手感改善很大但凡做联机项目我都会先换键绑定再调网络少踩一个隐形地雷。6. 进阶技巧从状态同步到帧同步答辩演示的3个加分点6.1 从状态同步到帧同步前面的方案是状态同步发坐标收坐标自己插值。帧同步是另一条路双方只交换“操作”比如“玩家1按下W”“玩家2松开方向右键”然后两台机器各自跑同一份游戏逻辑。好处是网络流量极小只要操作顺序一致画面天然一致代价是逻辑代码里不能有浮点数运算、不能有随机数否则微小的不一致会像雪球一样滚大。课程设计做帧同步最容易被老师认可但也要先把项目里所有物理计算改成int坐标或定点数工程量不小。如果时间紧状态同步加插值已经能交出80分的作品。6.2 心跳与断线提示联机对局里有一件事比延迟更可怕玩家掉线了你不知道。常见做法是让客户端每隔500ms发一条H|心跳消息服务端转发给对面任何一方连续1秒没收到心跳消息就在界面中央提示“对手网络中断”。实现只需要在4.3的队列里加一种消息类型再记录lastReceiveTime游戏循环每帧检查一次时间差超过1000ms就显示提示。这套机制不要求断线重连但能让双方体面退出答辩演示时如果现场断网你能立刻指出来老师反而觉得你考虑全面。6.3 答辩演示脚本我不推荐开场直接连两台电脑。演示顺序应该是单机模式先跑一关展示地图和基本操作再切换联机模式开着控制台的日志让老师看到“玩家1已加入”“收到玩家0的消息P|0|128|96|1”这样的输出比任何截图都有说服力。老师问“为什么用TCP”时就按2.3那两句话答。问“两个人不同步怎么办”把插值那段代码指给他看说“远端位置每帧向目标靠近不是直接赋值所以延迟不会变成瞬移”。最忌讳的是忘掉退出流程演示完窗口一关端口还占着下一组同学连不上。我做联机项目有个习惯先写一个只打印消息的假客户端不画界面专门测服务端转发服务端日志正常了再写真正的游戏客户端。这个习惯让我少加了两次班后来也成了我接手别人网络代码的第一步。把这个习惯带进你的大作业里你会发现自己排查网络问题的速度快很多。希望帮到你。本文还有配套的精品资源点击获取 Java双人联机小游戏森林冰火人大作业：Socket多线程实战解析
简介面向Java初学者与数据结构学习者的课程设计大作业基于GUI实现双人联机小游戏“森林冰火人”程序已测试通过、可直接运行适合用作课程设计、算法练手及游戏开发入门项目。压缩包共包含68个文件除11个Java源码与15个class编译文件外还配有大量jpg、gif、png图片素材以及properties配置文件、xml设置文件和README说明文档整体体积仅2.42MB目录结构清楚源码、图片资源与编译产物分区存放便于按模块阅读和二次开发。已有698人学习下载。借助完整项目与配套资料读者可以深入理解界面事件处理、双人联机协作机制以及数据结构与算法在碰撞检测、状态管理等环节的实际运用整套程序经过测试可直接启动也可作为期末大作业或课程设计的重要参考。项目结构直观程序入口与功能模块划分清晰适合教学演示或大作业模板。1. 大一下Java大作业——双人联机小游戏森林冰火人这个包到底怎么用大一下Java大作业——双人联机小游戏森林冰火人多数时候是一个躺在压缩包里的课程设计而不是能立刻运行的产品。第一批坑往往不在代码而是入口类在哪、JDK版本选哪个、两张网卡为什么连不通。这类项目的典型构成是用Swing画双人操作的界面用Socket做局域网TCP房间用多线程把两位玩家的状态同步起来再把森林冰火人的合作闯关规则拆成地图、角色、机关三类对象。它能帮你过课程设计也能在答辩现场讲出东西。适合三类人想跑通示例并读懂关键代码的、想拿这个包改造成自己作品的、想弄清楚两台电脑怎么共享一个游戏世界的学生。2. 玩法拆成需求从双人操作到网络同步的四个硬骨头不管是自己写还是拿现成包改造都得先把玩法翻译成程序语言。森林冰火人不是对战是双人合作火人免疫火池和火宝石冰人免疫冰池和冰宝石两个人一起踩开关、躲水池、拿宝石才能到终点。落到Java课程设计这个级别真正的技术点只有四个地图规则怎么存、画面怎么动、双方怎么连、状态怎么同步。先把这四个硬骨头啃下来后面读代码才有方向。2.1 玩法拆成规则地图、角色与碰撞地图本质上是一张二维网格。常见做法是用int数组存格子类型0是空地1是墙2是冰池3是火池4是水池再单独标记宝石和开关的位置。这样写的好处是地图即数据画图和碰撞检测都从一个数组里取答辩时老师说“你这关怎么加的”你只要回答“改二维数组”就够了。int[][] map { {1, 1, 1, 1, 1, 1}, {1, 0, 0, 0, 0, 1}, {1, 0, 3, 2, 0, 1}, {1, 0, 0, 0, 0, 1}, {1, 1, 1, 1, 1, 1} };逻辑说明把地图和角色分开是面向对象里最基础的责任分离。上面数组里3和2两个格子分别代表火池和冰池火人走3没事冰人走2没事水对两个角色都是即死。判断逻辑不要写在paint方法里要写在独立的碰撞检测方法里否则画面一复杂重绘和逻辑搅在一起程序会越来越难改。碰撞检测我推荐“四角内缩法”。角色在地图上有一个矩形包围盒取四个角对应的格子只要任一格子是致命地形就判定死亡。四角比中心点判断准比“整个包围盒逐格扫描”快代码也不长。核心参数是那2像素的内缩量角色贴墙时视觉上已经擦到墙边但包围盒四角稍稍缩进来不会一碰墙就死也不会看着没碰到就死亡这个手感来自实测调整不是数学算出来的。int left (p.x 2) / TILE_SIZE; int right (p.x p.width - 2) / TILE_SIZE; int top (p.y 2) / TILE_SIZE; int bottom (p.y p.height - 2) / TILE_SIZE; if (isLethal(map[left][top]) || isLethal(map[right][top]) || isLethal(map[left][bottom]) || isLethal(map[right][bottom])) { p.alive false; }逻辑说明TILE_SIZE是每格像素数比如32角色宽高一般取28左右留出视觉上的活动余量。p.x和p.y是角色左上角坐标。内缩2像素后四角落在哪个格子再去查地图数组对应值。这个做法也适合开关和门门是普通地图格开关是道具踩到时直接把门格子的值从1改成0。2.2 画面怎么动起来Swing游戏循环与键绑定Swing不是游戏引擎但做课设足够。基础是继承JPanel重写paintComponent把地图、角色、宝石一张张画上去JFrame只负责窗口外壳键盘输入优先用键绑定Key Bindings而不是KeyListener。原因很实际KeyListener在中文输入法弹出、窗口失焦时会丢按键联机游戏里方向键丢一次对面玩家可能就掉进水池了这是很常见的翻车点。游戏循环有两种常见写法。第一种用javax.swing.Timer定时触发重绘代码简单但回调运行在Swing事件线程上不能在里面做阻塞读取。第二种单独开一个线程跑while循环适合联机项目因为Socket读取天然是阻塞的。我一般用第二种并且用System.nanoTime计算帧间隔而不是每次Thread.sleep(16)。sleep本身误差不大但Windows上计时器精度一般累积多了画面会一抖一抖。Thread gameLoop new Thread(() - { long last System.nanoTime(); while (running.get()) { long now System.nanoTime(); if (now - last 16_000_000L) { // 约60帧/秒 updateGame(); panel.repaint(); last now; } } });逻辑说明running用AtomicBoolean或volatile boolean目的是让窗口关闭时能干净退出循环。16_000_000L单位是纳秒相当于16ms一帧想降到30帧就改成33_000_000L。这里不用sleep是因为循环里没有阻塞时忙等能让帧间隔更均匀代价是让出一部分CPU第5章会讲怎么控制这个消耗。updateGame里做的事包括读键盘状态、更新角色位置、检查碰撞、发送网络消息repaint只是请求重绘真正绘制在Swing事件线程里执行。2.3 联机走TCP为什么不是UDP、不是HTTP课程设计阶段联机方案我没有犹豫过用TCP的ServerSocket和Socket。UDP延迟更低适合动作游戏但你要自己处理丢包、乱序、重复包这已经超出“大一下Java大作业”的合理范围了HTTP轮询连“实时”都算不上还要额外搭一个Web服务端。TCP保证字节按序到达你只需要把消息按行切开网络层就算稳住了。方案实时性要自己处理的问题大作业适合度TCP Socket中等粘包/半包、断线高UDP Socket高丢包、乱序、重发低HTTP 轮询低连接开销、延迟大低选TCP还有一个理由老师的答辩问题会集中在“你用什么协议为什么”你只要说出“TCP按序到达适合小规模双人联动劣势是队头阻塞但两个玩家之间的消息量很小影响可以忽略”这一句话里信息量就够了。如果非要显得更专业再补一句“双人实时对战UDP更有优势但课程设计需要在可靠性上省时间所以选了TCP”。网络结构也有两种布置。第一种是房间制其中一台电脑跑服务端另一台填IP加入第二种是大厅制服务端跑在公网或教室某台机器上两个玩家都去连它。大作业用房间制最简单不用买服务器答辩现场两台笔记本开着就能演演示失败的概率最低。2.4 双人同步的核心多线程与共享状态两个玩家不在同一台机器上数据要跨网络同步这背后其实是一个多线程问题。一局游戏里至少有两条网络读线程玩家1的读线程和玩家2的读线程都要把消息推进同一个游戏状态。如果两个线程直接写同一个角色对象你就在制造数据竞争。常见做法是网络线程只负责把消息放进一个线程安全队列游戏逻辑线程从队列取消息再更新角色。队列相当于一个缓冲闸门把“网络到达的节奏”和“游戏画面的节奏”解开。// 收消息只做一件事入队 BlockingQueueMessage incoming new LinkedBlockingQueue(); Thread reader new Thread(() - { String line; while ((line in.readLine()) ! null) { incoming.put(Message.parse(line)); } }); reader.start(); // 逻辑线程每帧取出并应用 Message msg incoming.poll(); if (msg ! null) { applyMessage(msg); }逻辑说明LinkedBlockingQueue的put和poll都是线程安全的不需要额外加synchronized。poll不阻塞取不到就返回null正好配合游戏循环的帧节奏如果用take逻辑线程就会被网络消息阻塞住画面更新反而不稳定。这条队列是联机项目里性价比最高的基础设施比你去处理synchronized共享角色对象要省心得多。3. 拿到zip先找四样再动手入口类、地图资源、网络线程和启动脚本拿到一个压缩包我从来不会先双击运行。第一步是把它解压到一个没有空格的路径比如D:\fireice然后开始找四个东西入口类、地图数据、网络线程、启动方式。这四样找齐了这个项目在你心里就有了轮廓后面改代码心里不慌。3.1 入口类速查main、ServerSocket、JFrame三个关键词没有README时最快定位方式是全局搜索。在IDEA里用CtrlShiftF或者在项目根目录直接用命令行搜。我自己习惯先搜三个关键词main(对应入口ServerSocket对应服务端JFrame对应窗口。这三个词能让你在五分钟内知道项目从哪启动、有没有房间概念、界面入口叫什么。grep -rn public static void main --include*.java . grep -rn ServerSocket --include*.java . grep -rn JFrame --include*.java .逻辑说明grep -r递归搜索n显示行号--include*.java只查Java源码。如果项目用了Maven或Gradle入口信息在pom.xml或build.gradle里的mainClass不过大一下的作业很少用构建工具常见的是直接用IDE运行或写批处理脚本。搜到多个main时不要慌用“哪个类里出现JFrame或ServerSocket”来判断哪个是图形入口另一个通常是测试入口。3.2 地图与素材int数组、CSV还是图片文件地图数据放在哪里决定你改一个关卡要动多少代码。常见有三种形态写在Java类里的int二维数组放在根目录的文本文件或CSV以及直接用图片格子拼出来的地图。第一种最容易读第二种修改方便第三种依赖图片文件如果压缩包里素材缺失地图就会显示成一堆黑块。找到地图定义后先数一数行数和列数再找到TILE_SIZE这个常量这两个值直接决定窗口大小。常见套路是JFrame.setSize(cols * TILE_SIZE 边框, rows * TILE_SIZE 边框)如果窗口开出来位置不对、角色飘在地图外面十有八九是这里没对齐。如果需要自己加一关不要新建一个类直接在同一个关卡数据类里加一个static int[][] LEVEL_2再把关卡编号做成参数传给地图加载方法这样最不容易出错。3.3 网络线程Server、Client、转发逻辑在哪个类搜完ServerSocket后把所有出现这个词的位置标出来。服务端类的工作一般有三块accept()等待连接、读一个客户端的消息、把消息写给另一个客户端。有些代码会把这三个动作写在一个循环里两个玩家消息互相等待看起来能跑但实际上一方不发消息另一方就收不到更新这就是“队友不动”最常见的原因。如果项目里只有一个Socket类而没有ServerSocket说明它可能是“两人直连”模式也就是一台机器既是服务端又是客户端。直连模式写法更简洁但只能在固定拓扑下工作而且通常没有重连机制。大作业用哪种都行关键是答辩时你要能说清楚你的房间里谁在accept、谁在connect。3.4 命令行编译与运行没有IDE也能跑不管原来用什么IDE我都建议花十分钟把命令行编译跑通。原因很实在答辩现场不一定有IntelliJ老师机器上可能只有JDK命令行能跑你就永远有一个不依赖IDE的后悔药。先确认javac -version能看到版本再执行下面的命令。# 假设源码在 src 下入口类叫 game.Main javac -encoding UTF-8 -d out src/game/*.java # 单机调试不启动网络 java -cp out game.Main --local # 房主监听 8888 端口 java -cp out game.Main --host 8888 # 加入指到房主IP java -cp out game.Main --join 192.168.1.23 8888逻辑说明-encoding UTF-8是必选项Windows中文环境默认GBK不加这一句源码里的中文注释全部乱码字符串也可能直接报错。-d out把class文件输出到out目录避免源码和字节码混在一起。--local这个参数是我的习惯用法先不开网络用来单独测地图、碰撞和操作手感联机工程里单机模式是最高频的调试手段务必保留。如果压缩包里已经有run.bat或run.sh先读它大概率能还原作者当时的运行环境。bat里常见的set JAVA_HOME...、set CLASSPATH...比你自己猜入口类可靠得多。环境变量如果没配好最典型的现象是javac不是内部或外部命令这个时候去把JDK的bin目录加到Path不要重装JDK浪费时间的血泪经验。4. 让两台电脑共享一个世界最小可复现的双人联机实现这一章给出一套可以直接抄的联机骨架。它不是森林冰火人的完整代码但负责解决“两台电脑怎么同步”这最玄学的一块。完整游戏的地图、机关、胜负判定都挂在这个骨架上你只需要把游戏逻辑填进对应方法。4.1 一条消息走天下先定协议再写代码联机最忌边写代码边定协议。消息格式不统一服务端转发、客户端解析、日志打印都要跟着改改到后面自己都分不清哪个类是问题重灾区。我推荐文本行协议一行消息用竖线分隔字段开头是消息类型后面是参数。文本协议肉眼可读出了问题可以直接打印日志看比对象流黑匣子舒服太多。// Message.java —— 行协议编解码 public class Message { public String type; // P位置 S跳跃 C聊天事件 public String[] args; public static Message parse(String line) { String[] parts line.split(\\|); Message m new Message(); m.type parts[0]; m.args java.util.Arrays.copyOfRange(parts, 1, parts.length); return m; } public static String of(String type, Object... args) { StringBuilder sb new StringBuilder(type); for (Object arg : args) { sb.append(|).append(arg); } return sb.toString(); } }逻辑说明parse负责把P|0|128|96|1拆成类型P和参数数组[0,128,96,1]of负责反向组装。参数顺序要固定例如P|角色ID|x|y|场景号场景号留给多关卡用没有多关卡时可以省略。协议定好后所有网络代码都只和Message打交道游戏玩法改了不需要动传输层。选择竖线而不是逗号或JSON理由是解析成本低也不会出现在坐标和角色ID里。如果用JSONJava自带的JSONObject在部分JDK里要引第三方包大作业里增加依赖不值得。如果你的角色名字或聊天文本里有竖线做一个简单转义比如把输入里的|替换成全角竖线收发再转回来这是文本协议唯一的代价。4.2 服务端房间两个accept加一个转发循环服务端表面上是“服务器”实际就是一个消息中转站。两个玩家先连上之后任何一个人发来的消息原样转发给另一个人。架构上这叫中继好处是两人的IP和端口互不关心坏处是服务端要挂在整个对局期间。房间制里房主电脑同时跑游戏和服务端性能完全扛得住。// GameServer.java —— 服务端骨架 try (ServerSocket server new ServerSocket(8888)) { System.out.println(房间已开等待玩家1...); Socket p1 server.accept(); System.out.println(玩家1已加入); Socket p2 server.accept(); System.out.println(玩家2已加入开局); Socket[] players {p1, p2}; for (int i 0; i 2; i) { int idx i; Thread t new Thread(() - { try (BufferedReader in new BufferedReader( new InputStreamReader(players[idx].getInputStream(), UTF-8))) { String line; while ((line in.readLine()) ! null) { Socket other players[1 - idx]; PrintWriter out new PrintWriter( other.getOutputStream(), true); out.println(line); // 原样转发 } } catch (Exception e) { System.out.println(玩家 (idx 1) 断开); } }); t.start(); } // 阻塞主线程防止房间提前关闭 Thread.sleep(Long.MAX_VALUE); }逻辑说明accept()是阻塞调用第一次等玩家1第二次等玩家2两人齐了才继续。两个线程各读一个客户端读到一行就写给另一个。1 - idx这个写法很关键读0号写给1号读1号写给0号。PrintWriter第二个参数true表示自动flushprintln后消息立刻送出省去手动flush。如果不想让主线程挂住可以把服务端放在new Thread(() - runServer()).start()里但注意不要放在Swing事件线程里否则窗口会卡在“等待加入”。端口号的选择有讲究。8888只是演示实际推荐8020到8999之间的端口避开8080、8000这些常见网管端口也避开系统预留端口。同一个网段下两台机器防火墙会拦陌生端口教室的Windows机器经常默认拦截Java入站解决办法是第一回运行弹窗时点“允许访问”或者让两台机器连同一个手机热点热点环境下两台机器通常在同一子网联机成功率比校园网高不少。4.3 客户端循环收消息、改状态、触发重绘客户端同时干三件事画界面、读本机按键、读网络消息。如果都放在Swing事件线程界面会因为网络阻塞而假死。正确姿势是网络读线程独立运行把收到的消息放进队列游戏循环每帧从队列取一条消息更新角色位置然后repaint。// GameClient.java —— 客户端骨架 Socket socket new Socket(serverIp, 8888); BufferedReader in new BufferedReader( new InputStreamReader(socket.getInputStream(), UTF-8)); PrintWriter out new PrintWriter(socket.getOutputStream(), true); BlockingQueueMessage incoming new LinkedBlockingQueue(); Thread reader new Thread(() - { String line; try { while ((line in.readLine()) ! null) { incoming.put(Message.parse(line)); } } catch (Exception e) { System.out.println(与房间的连接断开); } }); reader.start(); // 游戏循环里每帧取一条消息 Message msg incoming.poll(); if (msg ! null) { if (P.equals(msg.type)) { int id Integer.parseInt(msg.args[0]); int x Integer.parseInt(msg.args[1]); int y Integer.parseInt(msg.args[2]); game.remotePlayers[id].setTarget(x, y); } }逻辑说明socket连接后in负责读服务器转发来的消息out负责把本机操作发出去。poll不阻塞每帧取一条如果消息比帧多就慢慢消化如果帧比消息快就返回null继续画。setTarget在这里不直接改坐标而是记一个目标位置交给插值逻辑平滑过去4.4会细说。发送端更简单。你只需要在角色移动后调用out.println(Message.of(P, id, x, y, scene))。发送频率建议每帧一次或不高于20次每秒。不要等到“松手才发”联机游戏要的是连续轨迹不是起终点。如果键盘按下和松开都被监听就都发出去对方就可以用“按住状态”判断方向而不是靠坐标差值反推。这里有个容易被忽略的参数坐标发出去之前最好转成整数浮点坐标带小数发出去占用空间大而且两边浮点运算一不一样步画面就飘。4.4 远端玩家插值把网络迟滞藏进两像素里无线网络下消息延迟波动个二三十毫秒很正常。对方在A点发的坐标到你这时他已经跑到B点了如果直接设坐标你会看到对方瞬移。常见做法是给远端玩家加一个“目标位置”每帧让它以固定速度靠近目标而不是直接赋值。这样延迟造成的跳跃会被平滑成一段短距离追赶观感上不再是瞬移。// 远端玩家每帧插值 Player p game.remotePlayers[id]; int dx p.targetX - p.x; int dy p.targetY - p.y; int dist Math.abs(dx) Math.abs(dy); if (dist 0 dist 24) { // 距离很近了直接归位 p.x p.targetX; p.y p.targetY; } else if (dist 0) { p.x Integer.signum(dx) * 2; // 每帧最多移动2像素 p.y Integer.signum(dy) * 2; }逻辑说明Integer.signum返回-1、0或1让角色朝目标方向走。2像素这个数是移动速度下限太大会让人物发飘太小会拖着走。dist 24的24是归位阈值这个阈值决定“追到多近就算追上”网络正常时路径短一两帧就追上网络抖动时则表现为略微延迟但不会瞬移。真实项目里这套插值还要带上“最后一次收到消息的时间”超过300ms没收到就判定对方网络差停止移动而不是原地漂移。5. 避坑双人联机项目最常见的5个翻车现场联机项目的坑很多不是语法错误而是逻辑时序问题。下面几条是我自己在大作业上翻过车、也给同学救过场的场景按“现象—原因—解决”来写省得你逐个踩。5.1 队友站着不动先怀疑转发逻辑而不是怪网络现象本机操作正常队友那边屏幕上的“你”不动或者反过来你看队友不动。 原因九成是服务端只accept了没转发。常见写法错误是服务端里只读了一个客户端另一个客户端的消息根本没进入读取循环还有的是把两个客户端都读了但没写“把A读到的消息发给B”这一步。 解决在服务端每个转发分支加日志打印“收到来自0的消息转发给1”。不要靠肉眼盯屏幕判断网络是否通先看控制台有没有输出。日志对联机项目来说就是呼吸灯没有它网络问题就是个黑匣子。System.out.println(收到玩家 idx 的消息: line); // 转发到另一个客户端 otherOut.println(line);加了日志以后队友不动的原因会立刻现形如果服务端根本没打印说明消息没到服务端如果打印了但队友不动说明转发或客户端解析有问题。这样排查一次比自己瞎改半天下一次联机快得多。5.2 关掉窗口进程还在8888端口被占现象关掉游戏窗口后再次启动提示Address already in use: bind。任务管理器里能看到一个Java进程没退。 原因Swing默认的窗口关闭行为是隐藏窗口不是退出JVM。网络线程还阻塞在accept()或readLine()上JVM不会主动退出端口自然一直被占。 解决在创建JFrame后设置setDefaultCloseOperation(EXIT_ON_CLOSE)并在窗口关闭事件里关闭Socket。如果之前写的是HIDE_ON_CLOSE就先把这一行找出来改掉。frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // 如果想做“提示后退出”挂窗口监听 frame.addWindowListener(new WindowAdapter() { Override public void windowClosing(WindowEvent e) { running.set(false); socket.close(); // 让reader线程的readLine抛异常退出 } });逻辑说明socket.close()是强制让阻塞在readLine()的线程抛异常线程结束游戏循环也退出进程自然消失。注意windowClosing里还能做“保存配置”这类善后但不要在这里弹模态框等用户点击窗口关闭事件线程会一直等你。5.3 对象流卡死别用ObjectInputStream做实时游戏现象双方都连接成功但一条消息都收不到偶尔抛EOFException或InvalidClassException。 原因ObjectOutputStream和ObjectInputStream配对使用时写端有缓冲区writeObject后必须flush()对方才会真正读数据。而且readObject()是阻塞式等待整个对象序列化完毕两个客户端互相等待就成了死锁。 解决我的建议是放弃对象流改用4.1的文本行协议。如果作业代码里已经用了对象流最小修复是给每个writeObject后面加flush()reset()可以在重复发送对象引用时避免缓存旧值但治标不治本。类型不一致的问题来自两边用了不同版本或不同包路径的类把类定义复制到两边的同学心里就知道多痛了。5.4 CPU占用100%游戏循环少了固定节拍现象游戏能玩但笔记本风扇狂转电量哗哗掉。 原因游戏循环写成while(running){ update(); repaint(); }没有任何帧间隔控制。repaint本身不一定每秒60次但update和碰撞检测的循环跑满一个CPU核心。 解决给循环加一个节拍器16ms一帧的阈值用System.nanoTime比较更省CPU的做法是忙等改为sleep(1)到sleep(16)或者用LockSupport.parkNanos。在课程设计层面Thread.sleep(16)已经完全够用但注意sleep要放在每帧末尾并且把“sleep被中断”的异常处理掉。while (running.get()) { long frameStart System.nanoTime(); updateGame(); panel.repaint(); long cost System.nanoTime() - frameStart; long sleepMs 16 - cost / 1_000_000; if (sleepMs 0) Thread.sleep(sleepMs); }逻辑说明这个写法先算这一帧花了多少时间再补足剩下的时间到16ms。如果一帧已经超过16ms直接进入下一帧不自欺欺人地凑帧数。也可以把16换成1000 / 60这样帧率意图一目了然。5.5 输入法抢按键用键绑定替代KeyListener现象中文输入法开着按W、A、S、D角色没反应按一下空格却输入一个汉字或符号角色在游戏里原地罚站。 原因KeyListener直接监听键盘事件输入法软件会截走按键Java拿不到真正的keyCode焦点在文本框或输入法候选窗上时也会丢事件。 解决改用Swing的键绑定机制把KeyStroke映射到Action。下面的代码给角色1绑定W键的按下和松开。InputMap im panel.getInputMap(JComponent.WHEN_IN_FOCUSED_WINDOW); ActionMap am panel.getActionMap(); im.put(KeyStroke.getKeyStroke(W), p1_up_pressed); im.put(KeyStroke.getKeyStroke(released W), p1_up_released); am.put(p1_up_pressed, new AbstractAction() { public void actionPerformed(ActionEvent e) { game.handleKey(1, KeyButton.UP, true); } }); am.put(p1_up_released, new AbstractAction() { public void actionPerformed(ActionEvent e) { game.handleKey(1, KeyButton.UP, false); } });逻辑说明WHEN_IN_FOCUSED_WINDOW意思是只要窗口有焦点子组件都能响应按键不会因为焦点停在某个按钮上就失效。变量名p1_up_pressed只是为了识别动作对应到KeyStroke.getKeyStroke(W)。另一个角色用方向键UP/DOWN/LEFT/RIGHT写法和W完全一致。这个改动对游戏手感改善很大但凡做联机项目我都会先换键绑定再调网络少踩一个隐形地雷。6. 进阶技巧从状态同步到帧同步答辩演示的3个加分点6.1 从状态同步到帧同步前面的方案是状态同步发坐标收坐标自己插值。帧同步是另一条路双方只交换“操作”比如“玩家1按下W”“玩家2松开方向右键”然后两台机器各自跑同一份游戏逻辑。好处是网络流量极小只要操作顺序一致画面天然一致代价是逻辑代码里不能有浮点数运算、不能有随机数否则微小的不一致会像雪球一样滚大。课程设计做帧同步最容易被老师认可但也要先把项目里所有物理计算改成int坐标或定点数工程量不小。如果时间紧状态同步加插值已经能交出80分的作品。6.2 心跳与断线提示联机对局里有一件事比延迟更可怕玩家掉线了你不知道。常见做法是让客户端每隔500ms发一条H|心跳消息服务端转发给对面任何一方连续1秒没收到心跳消息就在界面中央提示“对手网络中断”。实现只需要在4.3的队列里加一种消息类型再记录lastReceiveTime游戏循环每帧检查一次时间差超过1000ms就显示提示。这套机制不要求断线重连但能让双方体面退出答辩演示时如果现场断网你能立刻指出来老师反而觉得你考虑全面。6.3 答辩演示脚本我不推荐开场直接连两台电脑。演示顺序应该是单机模式先跑一关展示地图和基本操作再切换联机模式开着控制台的日志让老师看到“玩家1已加入”“收到玩家0的消息P|0|128|96|1”这样的输出比任何截图都有说服力。老师问“为什么用TCP”时就按2.3那两句话答。问“两个人不同步怎么办”把插值那段代码指给他看说“远端位置每帧向目标靠近不是直接赋值所以延迟不会变成瞬移”。最忌讳的是忘掉退出流程演示完窗口一关端口还占着下一组同学连不上。我做联机项目有个习惯先写一个只打印消息的假客户端不画界面专门测服务端转发服务端日志正常了再写真正的游戏客户端。这个习惯让我少加了两次班后来也成了我接手别人网络代码的第一步。把这个习惯带进你的大作业里你会发现自己排查网络问题的速度快很多。希望帮到你。本文还有配套的精品资源点击获取