简介这是一份基于Java开发的泡泡堂联机版游戏源码包面向对Java网络编程与游戏开发感兴趣的初学者和进阶学习者演示了如何在经典炸弹人玩法中加入多人实时对战能力。项目整体采用面向对象设计将玩家、泡泡、地图与爆炸效果等拆分为独立类联机部分基于Socket与ServerSocket实现客户端-服务器通信负责位置更新、动作指令与状态同步可用来深入理解网络延迟处理、预测与回滚等基础优化思路加深对状态同步机制的认识。压缩包为ZIP格式大小约507KB轻量易部署通过阅读源码与运行效果可以快速梳理由单机逻辑扩展到联机对战的核心流程。目前已吸引643人学习下载版本号bomb_man0.3表明该工程正处在迭代优化阶段适合作为课程设计、毕业设计或游戏开发入门的参考资料。 去年整理电脑的时候翻出一个大学时代的课程设计——用 Java 写的泡泡堂联机版。当时为了应付答辩代码写得比较糙但整体框架是完整的Socket 通信、多线程房间、泡泡爆炸、道具拾取都有。后来我花了两天时间重写了一遍把网络层和游戏逻辑拆干净又补了一些并发上的细节整个过程踩了不少坑。这篇就当是复盘笔记把这个项目的架构思路、核心代码和一些典型问题都摊开来讲想练手 Java 网络编程或者准备写游戏类课设的同学可以直接照着搭。1. 项目概述与整体设计思路1.1 泡泡堂联机版到底要做哪些事先梳理一下一个能跑起来的联机泡泡堂至少需要三块东西图形界面、游戏逻辑、网络通信。图形界面负责显示地图、角色、泡泡和爆炸效果这是玩家直接感知的部分游戏逻辑负责角色的移动、放置泡泡、泡泡倒计时爆炸、水柱传播、碰撞检测和道具效果网络通信则把两个玩家连接到同一局游戏里保证双方看到的战场状态是一致的。这三块如果全部耦合在一起写项目会很快失控。尤其是联机部分一旦你在处理网络消息的线程里直接改游戏界面或者把游戏逻辑混进消息解析流程里后期调试会极其痛苦。所以第一步要想清楚分层。我当时是这样拆的客户端-服务器C/S架构一台机器开服务器端程序负责转发消息和维护全局状态每个玩家运行客户端连接服务器。网络层单独封装客户端和服务器之间的所有通信都走消息协议不直接调方法。游戏逻辑和渲染分离逻辑层只管状态变化渲染层定时读取状态去画画面。这个设计不是拍脑袋定的而是因为泡泡堂这种游戏人数不多、地图不大用简单的 C/S 架构就足够支撑没必要上帧同步那套重型的 ECS 架构。核心目标就两个一是代码结构清楚二是好复现、好演示。1.2 技术选型为什么是 Socket 多线程 Swing选型上我用的是一套非常“教科书”的组合Java Socket 做 TCP 通信多线程处理并发连接Swing 做界面渲染。有人可能觉得 Swing 太古老了但作为个人项目和课设来说它有一个不可替代的优势Java 原生自带零依赖开箱即用。你不需要搭 JavaFX 的环境也不用引入 LWJGL 那一堆底层库写完就能跑这对大多数人的场景来说是最稳妥的。TCP 的选择也很自然。泡泡堂不像 FPS 或者格斗游戏那样对延迟极度敏感玩家操作频率低状态变化相对稀疏TCP 的可靠传输反而省去了处理丢包重传的麻烦。你可以把精力集中在游戏逻辑本身上。多线程则是联机的必然要求。服务器需要同时接待多个客户端连接每个连接如果独占一个线程去读消息是最直观的模型客户端也需要一个独立的线程去监听服务器推送的状态更新否则 UI 线程一阻塞界面就卡死。注意这套组合虽然经典但有一个问题——Swing 不是线程安全的。任何对界面组件的更新都必须回到事件分发线程EDT里去执行否则会出现诡异的界面异常。这个我后面会专门讲。2. 核心模块拆解与实现要点2.1 服务器端连接管理与游戏房间服务器端是联机的“大脑”本质上做三件事接收连接、管理房间、转发状态。接收连接用ServerSocket监听一个固定端口每来一个新连接就丢给一个独立的ClientHandler线程去处理。这个线程会循环读取客户端发送的消息然后根据消息类型执行对应的操作——比如加入房间、移动角色、放置泡泡等。房间的抽象也很关键。每个房间有房间号、玩家列表、地图数据、游戏状态这些字段。用一个ConcurrentHashMapInteger, GameRoom来保存所有房间key 是房间号value 是房间对象。为什么用ConcurrentHashMap而不是HashMap因为多个客户端线程可能同时操作房间集合普通 HashMap 在多线程环境下扩容时会形成环形链表直接导致 CPU 100% 和死循环这个坑我踩过一次以后只要是并发场景一律用并发集合。服务器消息处理的伪代码public class ClientHandler implements Runnable { private Socket socket; private BufferedReader in; private PrintWriter out; private GameRoom room; Override public void run() { try { String line; while ((line in.readLine()) ! null) { Message msg Message.parse(line); switch (msg.type) { case JOIN: room RoomManager.joinRoom(msg.playerName); break; case MOVE: room.broadcast(msg); break; case PUT_BUBBLE: room.broadcast(msg); break; case QUIT: room.leave(this); return; } } } catch (IOException e) { e.printStackTrace(); } } }这里有个非常重要的细节房间内所有玩家的位置、泡泡等信息到底由谁维护我的方案是服务器做权威处理——也就是所有逻辑都跑在服务器端客户端只做输入和显示。每个玩家要移动时客户端发送一条“我想去左边”的消息服务器判断这个方向能不能走有没有墙、有没有泡泡然后把最终位置广播给所有客户端。这样做的好处是防止作弊而且逻辑一致性天然有保障。缺点是服务器压力稍微大一点但对这个规模的项目完全不是问题。2.2 客户端界面渲染与操作反馈客户端的结构比较标准一个GameFrame主窗口包含游戏画布GamePanelGamePanel继承JPanel并重写paintComponent方法来绘制整个战场。渲染的核心思路是界面只是状态的投影。客户端本地维护一份“游戏状态”对象里面保存当前地图、所有玩家的位置、泡泡列表、爆炸动画的进度等。网络线程收到服务器广播的消息后修改本地状态渲染线程根据状态去画图。两个线程之间要通过同步机制保护共享状态我在代码里用的是synchronized锁住状态对象或者用volatile修饰需要立即可见的标志位。paintComponent方法里读取状态时也加上锁确保不会读到一半被其他线程改掉。键盘操作部分用键监听器处理KeyListener。这里有个经验不要直接在按键事件里发网络消息尤其是keyPressed会被自动重复触发的情况——你按住方向键不动系统会自动产生大量按键事件如果你每个事件都发一条移动消息服务器会收到海量垃圾流量。合理做法是维护一个SetInteger pressedKeys在按键事件里往集合里添加或移除键值然后由一个游戏循环定时检查这个集合决定当前要往哪个方向移动。玩家移动的处理流程// 按键监听只修改按键状态不直接发消息 public void keyPressed(KeyEvent e) { pressedKeys.add(e.getKeyCode()); } public void keyReleased(KeyEvent e) { pressedKeys.remove(e.getKeyCode()); } // 游戏循环定时检查按键状态发移动消息 public void gameLoop() { while (running) { int dx 0, dy 0; if (pressedKeys.contains(KeyEvent.VK_UP)) dy -1; if (pressedKeys.contains(KeyEvent.VK_DOWN)) dy 1; if (pressedKeys.contains(KeyEvent.VK_LEFT)) dx -1; if (pressedKeys.contains(KeyEvent.VK_RIGHT)) dx 1; if (dx ! 0 || dy ! 0) { NetworkManager.sendMove(dx, dy); } Thread.sleep(50); } }2.3 游戏核心逻辑泡泡、爆炸与碰撞检测泡泡堂的灵魂是泡泡机制放置泡泡 → 倒计时 → 爆炸产生水柱 → 水柱碰到障碍物或地图边缘停止 → 玩家碰到水柱死亡。实现上我用一个Bubble类来封装每个泡泡的状态public class Bubble { private int row, col; // 所在格子 private long createTime; // 放置时间 private int range; // 爆炸范围默认1格 private boolean exploded; // 是否已爆炸 }服务器端用一个ListBubble保存所有未爆炸的泡泡每隔一小段时间检查一次createTime和当前时间的差值是否到了 1.5 秒。到了就把这个泡泡的exploded置为 true然后广播爆炸消息。爆炸的核心是水柱传播计算。从泡泡所在格子出发向上下左右四个方向分别延伸range格遇到地图障碍物就停止遇到另一个泡泡会触发连锁爆炸遇到玩家则标记该玩家为死亡。这个逻辑写在一个BombService.explode(int row, int col, int range)方法里返回一个包含所有受影响格子坐标的集合。水柱传播的核心代码public SetPoint calculateExplosion(int row, int col, int range, GameMap map) { SetPoint affected new HashSet(); affected.add(new Point(row, col)); int[][] directions {{-1,0},{1,0},{0,-1},{0,1}}; for (int[] d : directions) { for (int step 1; step range; step) { int nr row d[0] * step; int nc col d[1] * step; if (map.isWall(nr, nc)) break; // 墙壁挡住 if (map.isBrick(nr, nc)) { affected.add(new Point(nr, nc)); // 砖块被炸掉但水柱不穿过 break; } affected.add(new Point(nr, nc)); // 空地继续延伸 } } return affected; }碰撞检测则是这个项目里最容易出 bug 的地方。角色的位置我直接用格子坐标来管理不用像素坐标做精确碰撞——这借鉴了《以撒的结合》这类游戏的设计思路角色虽然看起来是连续移动的但底层逻辑判断全部基于网格。每次移动请求服务器先计算目标格子检查该格子是否可通行如果可通行则更新玩家坐标否则站在原地不动。这样碰撞检测的复杂度从逐像素的矩形求交降到了一个二维数组的索引查询性能几乎为零开销而且天然不会出现角色卡在墙里的问题。3. 联机同步机制让两个玩家看到同一个战场3.1 状态同步与命令同步怎么选联机游戏同步有两种主流方案状态同步和命令同步帧同步。状态同步是服务器把自己认为的“世界状态”直接发给客户端客户端收到后渲染。优点是实现简单、逻辑清晰、便于反作弊缺点是网络流量大——每个玩家移动一步都要广播整个状态。命令同步则是服务器只转发玩家的操作指令所有客户端运行同一套逻辑代码各自计算下一步的状态。这种方式流量小但要求所有客户端的逻辑完全一致任何一丝偏差都会导致游戏画面分叉。我这个项目选择的是状态同步。原因很简单泡泡堂的玩家数量少最多 4 人地图也小状态数据就那么几十个字段广播一次也就几百字节完全够用。如果你想往更多人的方向扩展或者做更复杂的物理模拟再考虑帧同步也不迟。消息的格式设计比较朴素类型|参数1|参数2|参数3...比如玩家加入JOIN|玩家名玩家移动MOVE|玩家ID|方向X|方向Y放置泡泡PUT_BUBBLE|玩家ID|行|列泡泡爆炸EXPLODE|行|列|范围|影响格子数游戏结束GAME_OVER|胜利者ID每条消息用换行符结尾TCP 的readLine()能非常方便地逐行解析。3.2 消息协议设计与踩过的坑消息协议看起来简单但里面藏着一个很典型的网络编程坑粘包/拆包问题。TCP 是一个字节流协议它不保证你每次readLine()读到的就是对方一次println()发送的内容。可能你一次写了 3 条消息对方一次性收到了 3 条连在一起的字节流也可能你写一条很长的消息对方分两次才读完。如果每条消息之间没有明确的分隔符或者长度字段解析就会错乱。我当时的处理方案是用“分隔符”法也就是每条消息末尾加一个特殊标记比如\n。服务端用BufferedReader.readLine()读取它会等读到换行符才返回一行完整数据这天然解决了粘包问题。但有人会问如果消息里面本身含有换行符怎么办消息内容里会有吗我的协议规定消息内容里不允许出现换行符所有字段用|分隔这样就彻底避免了歧义。这个限制在需求里写清楚就行实现上是最省事的。还有一个更隐蔽的问题消息顺序。TCP 保证字节顺序是可靠的但在多线程环境下如果你的客户端有多个线程同时往同一个Socket的PrintWriter里写数据println本身是同步的但多个线程的调用顺序是不确定的。这可能导致消息发出的顺序和逻辑上的顺序不一致。比如你先发了”放置泡泡“又发了”移动“但服务器可能先收到”移动“。解决办法很简单所有发送操作都通过同一个发送器来执行避免多线程并发调用PrintWriter。我在客户端封装了一个NetworkManager所有发送方法都走这个类内部用一个synchronized块锁住 writer 对象。4. 实操过程中最常见的麻烦与排查思路4.1 客户端界面卡死网络阻塞拖死 UI 线程这是我第一次联调时遇到的第一个问题。客户端连上服务器后界面直接卡住不动点任何按钮都没反应。原因很简单我在事件分发线程里调用了阻塞式的socket.getInputStream().readLine()这个调用会一直等待服务器数据导致整个 UI 线程被挂起。解决办法就是把网络读取逻辑放到一个独立的线程里。客户端的NetworkListener线程专门负责循环读取服务器消息解析后更新本地游戏状态。UI 只负责在paintComponent中渲染状态二者互不干扰。切记任何可能阻塞的操作网络 IO、文件读写、数据库查询都不能放在 Swing 的事件分发线程里。这是 Swing 开发的铁律。4.2 两个玩家画面不同步共享状态被并发修改第一版测试的时候两个玩家各自连上服务器但双方看到的对方位置经常不一致——服务器明明已经广播了新位置有一方却还显示旧位置。我排查了很久发现问题出在客户端本地维护的玩家列表上。当时我用了普通的ArrayListPlayer来保存玩家信息网络线程收到消息后调用player.setX(x)修改对象属性渲染线程同时又在读取player.getX()。两个线程对同一个对象的读写没有加锁导致渲染线程可能读到旧值。解决方案是把玩家列表改成CopyOnWriteArrayList或者对列表的每次读写都加synchronized。我在这个项目里更推荐CopyOnWriteArrayList因为玩家的读写比例非常悬殊——读操作渲染远多于写操作网络更新刚好切中这个集合的适用场景。写时复制会带来一点内存开销但在这个数据量下完全无所谓。4.3 游戏结束后服务器线程泄漏还有一个问题是在连续开多局游戏之后出现的服务器越来越卡最终连接失败。用jstack看了线程快照发现大量ClientHandler线程还活着但对应的客户端早已断开。原因是我在客户端点关闭窗口时Socket 确实断了但服务器端的BufferedReader.readLine()一直阻塞着没有收到任何异常。Windows 和 Linux 下表现还不完全一样——有时客户端异常断开后服务器要过很久才能感知到 TCP 连接已经死了。解决办法是在服务器端设置一个“心跳”机制客户端每隔 3 秒发一条 PING 消息服务器若超过 10 秒没收到某个客户端的任何消息就强制关闭这个连接并回收线程。同时在readLine()返回 -1 或者抛出SocketException时要保证执行清理逻辑把线程从房间中移除。心跳检测代码public class HeartbeatTask implements Runnable { private MapString, Long lastHeartbeat new ConcurrentHashMap(); Override public void run() { while (running) { long now System.currentTimeMillis(); for (String clientId : lastHeartbeat.keySet()) { if (now - lastHeartbeat.get(clientId) 10000) { // 超过10秒无心跳强制移除 removeClient(clientId); } } Thread.sleep(3000); } } }4.4 并发工具类遗漏导致死锁多线程联机的项目中死锁是个很难复现又很致命的问题。我遇到过这样一次两个玩家同时放置泡泡服务器端一个线程在广播爆炸消息时要遍历房间内所有玩家逐个发送另一个线程同时处理某个玩家退出房间要先从玩家列表中移除该玩家再发送离开消息。这两个操作如果都在不加控制的情况下一个持有players列表的锁另一个持有room对象的锁就可能出现循环等待。我的规避策略是统一加锁顺序所有涉及房间状态的操作都先锁房间对象再锁玩家列表绝不反向加锁。并且尽量缩小锁的范围不要在锁内部执行网络 IO 这种耗时操作。广播消息前先复制一份玩家列表快照然后在锁外面逐个发送。// 正确做法先在锁内复制快照再在锁外发送 ListClientHandler snapshot; synchronized (room) { snapshot new ArrayList(room.players); } for (ClientHandler handler : snapshot) { handler.send(message); }这看起来是小细节但在并发场景下一个无意的锁顺序颠倒可能就是一次线上事故的根源。4.5 界面闪烁与双缓冲最后说一个跟并发无关但很影响体验的问题画面闪烁。第一版运行时角色移动过程中整个画面有严重的闪烁感尤其在频繁重绘时更明显。这是因为JPanel默认的重绘方式是一边擦除背景一边重绘两个操作之间若出现“空窗期”屏幕就会闪。解决办法是双缓冲Swing 里其实自带这个能力只要在JPanel构造函数里调用setDoubleBuffered(true)就能打开。如果自定义渲染逻辑也可以用BufferedImage先把整幅画面画到内存中再一次性把图像绘制到屏幕。对于这个项目的画面复杂度来说Swing 自带双缓冲已经足够不用额外处理。5. 常见问题速查表这里整理一下我在整个开发过程中遇到的高频问题做成表格方便大家对照排查。现象根因解决办法客户端连接后界面无响应网络阻塞在 UI 线程网络读取单独开线程两个玩家看到的位置不同步共享状态并发读写无保护用CopyOnWriteArrayList或加锁长时间运行后失去响应客户端断开但服务器未感知添加心跳检测和超时机制操作偶发失灵按键被长期按住消息风暴使用按键集合 游戏循环节流气泡爆炸范围不对边界处理缺失数组越界加边界判断和地图越界检查画面闪烁未开启双缓冲setDoubleBuffered(true)消息偶尔解析错误多线程并发写 Socket统一用发送器加锁发送玩家退出后房间仍占满异常分支未清理资源finally中关闭连接并移除最后再分享一个有点偏门的经验如果你在 Windows 上跑这个项目防火墙可能会拦截 Socket 连接。第一次运行时如果客户端一直连不上服务器先别急着改代码看一眼有没有弹出防火墙拦截提示。我就是在那折腾了半小时之后才意识到连接不是代码 bug而是系统安全策略把端口给拦了。开发联机项目的时候把自己的程序加入防火墙白名单是最容易忽略的第一步。还有一个建议是把服务器端的-Xmx调大一点默认堆大小可能会莫名溢出不存在的内存虽然泡泡堂的数据量很小但jstack排查问题时能少一个干扰项。后来我习惯在启动命令里显式写java -Xmx256m -jar Server.jar就没再见过OutOfMemoryError。这个项目从零到跑通核心代码量其实不大难的是把网络、线程、逻辑和渲染四块捏合在一起而不崩。写 Java 游戏的价值也正在这里它不是 CRUD每一处设计都需要你同时考虑并发、状态一致性和用户体验。做完这一趟你对 Java 并发包的理解绝对会上一个台阶。本文还有配套的精品资源点击获取