简介这套Java课程设计源码实现了一个MUD多人在线游戏的简单模拟面向高校Java课程设计、期末大作业及毕业设计场景尤其适合需要高分项目的学生参考与二次开发。项目来自吉林大学高分课程设计作者自述为个人手打98分代码注释完整从登录、地图探索到交互指令等核心环节均有呈现新手也能较快读懂整体结构和完整流程。zip压缩包共32个文件其中10个Java源文件与16个class文件构成核心运行代码另含Eclipse工程配置.project/.classpath/.prefs及UML图.ucd/.acd/.cld等辅助内容工程结构清晰包体仅55KB部署非常简单。目前已有110人学习下载属于轻量且完整的课程设计范例。资源提供经过严格调试的工程可直接导入IDE运行系统功能完善、界面直观既适合课程设计答辩演示也可作为毕业设计进一步扩展的基础。1. 一篇Java课程设计里的MUD多人在线游戏凭什么能拿高分先给结论这道题的高分点不在“会写Java语法”而在“能处理并发连接”。MUDMulti-User Dungeon多人在线文字地牢是最早的在线游戏形态所有交互都是命令行文本走房间、看描述、说话、打怪。吉大这道课程设计选它是因为它在一份源码里同时考了Socket编程、多线程协作、文本协议设计和集合的并发安全比学生管理系统的含金量高一个档次。这套方案适合两类人正在做Java课程设计、想从“能用”做到“高分”的学生以及想补足网络编程短板的Java开发者。下文按选型、实现、避坑、提分的顺序展开所有代码都以能直接跑通为目标。2. 从“聊天室”到“世界模拟”MUD的核心架构怎么定2.1 为什么课程设计选MUD一个项目吃透Java核心MUD的关键是“MUD多人在线”这五个字。它不像单机文字冒险游戏玩家自己一个人玩就行它要求所有在线玩家共享一个世界状态A在房间1B在房间2A走到房间2时B要能看到A进来。这就逼着你在代码里维护一份全局共享的房间-玩家映射表并且所有线程访问它时都要保证安全。这种“共享状态 并发读写”恰好是Java课程设计最想考察的东西。选MUD还有个现实原因不依赖图形界面、不依赖数据库。很多课设题目让你做Swing界面的管理系统最后评分重心落在界面美观度上反而把业务逻辑弱化了。MUD整个项目可以只用一个控制台窗口评分点全在服务端逻辑上界面唯一要做的就是把服务端回显一行行打出来。对课程设计来说这等于把有限的课设时间全花在了Java核心技术点上。我一般会建议在“聊天室”和“MUD”之间选后者。聊天室的代码骨架和MUD高度相似但要命的差异在于聊天室没有地图、没有房间概念所有消息全局广播并发模型简单很多MUD多了一层“房间”作为广播范围玩家移动时要跨房间切换这一层恰好是网络编程里“有状态连接”的典型场景。做完MUD再回头看聊天室会发现聊天室只是MUD把房间数设为1的特例。评阅老师看MUD项目通常分三档能单人进入游戏、能逛地图、能look和say这是及格再加多人在线A说的话B在同一房间能看到这是良好处理了掉线清理、房间容量限制、并发消息不串线就是高分档。下面所有设计都按第三档来配代码量不大但每个决策都要有理由。2.2 网络层选型课程设计用BIO还是NIONetty要不要引这是动手前必须拍板的第一个选型。直接说结论课程设计场景下推荐BIO阻塞IO线程池不引NettyNIO只在题目明确要求时才碰。原因一句话MUD的指令流量极低一个玩家一次操作就几十字节一条Socket连接大部分时间在等待输入阻塞模型完全扛得住。BIO的每一个连接对应一个线程代码读起来就是“读一行、处理、写回”不需要处理selector事件循环和ByteBuf。课设答辩时老师如果问“为什么不用Netty”你可以答“本项目的网络模型是每个连接独立线程Netty的异步模型对这类低流量协议反而增加复杂度”这个回答在课设层面站得住。但BIO有一个天花板要提前说清楚线程数和连接数1:1连接多了线程数会涨。课设演示规模一般在一百个连接以内线程池控制在50~100就没问题。如果有人想把连接数干到几千那BIO会先崩NIO必须上但那种规模已经不是课设范围了。网络部分的工程代码骨架长这样public class MudServer { private ServerSocket serverSocket; private final ExecutorService clientPool new ThreadPoolExecutor(8, 50, 60L, TimeUnit.SECONDS, new ArrayBlockingQueue(200), new ThreadPoolExecutor.CallerRunsPolicy()); private final ConcurrentHashMapInteger, Player onlinePlayers new ConcurrentHashMap(); public void start(int port) throws IOException { serverSocket new ServerSocket(port); while (true) { Socket socket serverSocket.accept(); clientPool.execute(new ClientHandler(socket, this)); } } }这里线程池参数值得逐个说。核心线程数8最大50队列容量200。8对应CPU核心数的两倍左右做房间广播时占CPU的活很轻8个起跑足够50是连接数上限的保险丝防止有人写个死循环狂开连接把服务器打爆队列200是缓冲如果50个线程都在忙新连接先排队等线程比直接拒绝体验好。CallerRunsPolicy是兜底策略队列也满了谁提交谁执行保证服务端主线程自己处理一个连接不至于丢任务。NIO的反例我也见过有人用Selector写MUD消息来了在事件循环里处理业务结果业务里执行了阻塞操作把事件循环堵住整个服务器的所有玩家都卡顿。这类问题排查极费时间。所以没有明确要求就老老实实用BIO把时间省下来打磨协议和世界逻辑。2.3 协议与消息格式按行文本协议还是JSON服务端和客户端之间跑什么格式的消息是第二个选型。MUD场景下有两种主流做法我分别说一下适用边界。第一种是纯文本按行协议。每条消息以\n结尾指令格式统一为“动词 空格 参数”。服务端返回时第一行是消息类型标记比如NOTICE、ROOM、PRIVATE、SYSTEM后面跟正文。好处是调试方便Windows的cmd下敲telnet都能当客户端手动测试每一行都能肉眼看到。坏处是字段多了以后解析逻辑会变繁琐比如一条消息里要带“发送者、原命令、目标接收人”就要自己约定分隔符。第二种是JSON消息。定义一个Message类序列化成字符串。好处是字段有语义加新字段不破坏旧解析器坏处是要引第三方库而且答辩时老师可能把JSON消息放到放大镜下问“这个字段为什么这么设计”。两种方案的取舍点在于你是否计划后续给MUD套Web前端。有Web前端计划就上JSON纯课程设计演示就文本协议。消息体如果选JSON常见用法是这样public class Message { private String type; // ROOM / PRIVATE / SYSTEM private String from; // 发送者昵称 private String content; // 消息正文 private long timestamp; // 服务端接收时间 public String toJson() { return new Gson().toJson(this); } }我的建议是优先选文本协议因为MUD的历史形态就是Telnet文本流用文本协议最能体现这个题目的原汁原味答辩时还能讲一句“这个协议兼容Telnet客户端”。不管选哪种消息边界一律靠行尾的\n不要靠定长字节块或特殊的二进制帧这样TCP下的半包粘包问题至少压掉一半。3. 把MUD跑起来工程骨架、游戏主循环与关键参数3.1 工程骨架与核心类设计先给一个可以直接对着建的Maven工程结构Java 8以上都能跑mud-server/ ├── pom.xml └── src/main/java/com/example/mud/ ├── server/ │ ├── MudServer.java // 入口启动监听 │ ├── ClientHandler.java // 单连接处理线程 │ └── CommandProcessor.java // 指令解析与分发 ├── game/ │ ├── WorldMap.java // 房间与邻接关系 │ ├── Room.java // 房间对象 │ ├── Player.java // 玩家状态 │ └── GameLoop.java // 心跳与NPC调度 └── common/ └── Message.java // 消息结构文本协议下可简化这个骨架遵循一个基本原则网络层和游戏逻辑层解耦。ClientHandler拿到一行字符串后不做业务判断直接丢给CommandProcessorCommandProcessor返回的结果也只是“要发给谁、发什么”的描述。这样以后想从BIO换成NIO游戏逻辑一行不用改。pom.xml里大概率只配三样东西编译版本、编码、可选的一个JSON库。如果你走纯文本协议连依赖都不需要跑起来只需要javac和java两个命令。编译版本建议定Java 11或17但要注意机器上装的JDK必须对应不然启动时直接报“源发行版错误”。properties maven.compiler.source11/maven.compiler.source maven.compiler.target11/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /propertiesproject.build.sourceEncodingUTF-8这一行很多人漏配。Windows环境下Maven默认按GBK读源文件代码里的中文字符串字面量会变成乱码运行起来整个游戏描述全是乱码。先配好编码后面少踩一个坑。3.2 连接管理与玩家上线流程服务端启动的代码在2.2已经给了这里直接进连接处理。ClientHandler是每个客户端独占的线程它的上线流程三步走先读一行“name 昵称”校验昵称不重复然后创建Player对象放进onlinePlayers最后把玩家加入出生房间的玩家集合并向同房间其他玩家广播一条“xxx进入了游戏”。public class ClientHandler implements Runnable { private final Socket socket; private final MudServer server; private PrintWriter out; private BufferedReader in; private Player player; public void run() { try { in new BufferedReader(new InputStreamReader( socket.getInputStream(), StandardCharsets.UTF_8)); out new PrintWriter(new OutputStreamWriter( socket.getOutputStream(), StandardCharsets.UTF_8), true); login(); String line; while ((line in.readLine()) ! null) { server.getCommandProcessor().dispatch(this, line.trim()); } } catch (IOException e) { // 网络异常只打日志不要在这里做业务 } finally { logout(); } } }这里有两个容易忽略的点。第一PrintWriter的autoFlush参数要设为true否则服务端写回的消息会一直积在缓冲区里客户端半天看不到回显。第二socket流的编码必须显式指定UTF-8别依赖平台默认编码。Windows默认GBKLinux默认UTF-8不显式指定的话同一套代码在两种系统上表现不一样这是课设答辩前突然翻车的高频原因。下线流程要特别注意finally里的logout()必须把玩家从onlinePlayers、当前房间玩家集合里都移除还要广播“xxx离开了游戏”。漏掉这一步常见的后果是其他玩家在房间里能看到一个永远不发消息的“幽灵”而且服务器内存里堆积无法回收的对象。3.3 游戏指令解析与房间移动逻辑指令分发是MUD的“路由器”一行输入进来拆成动词和参数再路由到对应处理。常见做法是先建一个指令名到处理方法的映射表这样加新指令只需要往map里put一行不需要改分发逻辑public class CommandProcessor { private final MapString, ConsumerCommandContext commands new HashMap(); private final WorldMap worldMap; public CommandProcessor(WorldMap worldMap) { this.worldMap worldMap; commands.put(look, this::handleLook); commands.put(move, this::handleMove); commands.put(say, this::handleSay); commands.put(who, this::handleWho); commands.put(help, this::handleHelp); commands.put(quit, this::handleQuit); } public void dispatch(ClientHandler handler, String rawLine) { String[] parts rawLine.split(\\s, 2); // 最多拆两段动词 剩余参数 String verb parts[0].toLowerCase(); String arg parts.length 1 ? parts[1] : ; CommandContext ctx new CommandContext(handler, verb, arg); ConsumerCommandContext action commands.get(verb); if (action null) { handler.sendLine(未知指令输入 help 查看帮助); } else { action.accept(ctx); } } }split(\s, 2)这里的关键是limit2。它把“say hello world”拆成动词say和参数“hello world”而不是把中间的空格全部切开。如果漏掉这个limit“say hello world”会被拆成三个单词参数只剩“hello”广播出去的文本后半截就丢了而且不好排查。移动指令是MUD里最能体现“多人在线”的操作。handleMove的逻辑从当前房间的方向表中查出目标房间ID不存在就回复“这个方向没有出口”存在就把玩家从旧房间移除、加入新房间给玩家发新房间描述给新房间其他人广播“xxx从西边走了进来”。private void handleMove(CommandContext ctx) { Player p ctx.getHandler().getPlayer(); Room current worldMap.getRoom(p.getCurrentRoomId()); String dir ctx.getArg().toLowerCase(); Integer targetId current.getExit(dir); if (targetId null) { ctx.getHandler().sendLine(这个方向没有出口。); return; } worldMap.movePlayer(p, current.getId(), targetId); ctx.getHandler().sendLine(worldMap.getRoom(targetId).describe()); broadcastToRoom(targetId, p.getName() 从 dir 方向走了进来); }移动的并发场景有一个要留意的点玩家A和玩家B同时从两个房间互相移动如果房间玩家集合不是线程安全的两个线程同时修改同一个集合会导致数据覆盖。解决方式很简单房间玩家集合用CopyOnWriteArraySet遍历和移除都不会抛ConcurrentModificationException。注意广播时要先拿房间玩家列表的副本再遍历不要在遍历的时候让别的线程改集合。3.4 世界地图数据与NPC模拟地图数据建议写在一个文本文件里用“房间ID|名称|描述|出口”的格式存服务启动时一次性加载进WorldMap。这么做的好处是把数据和逻辑分开调地图描述不用改代码重编译文档也好写。一个四房间的校园地图可以长这样1|南门广场|你站在吉大校园南门外的广场上人来人往。|north:2,east:3 2|中心大道|一条笔直的大道两侧是教学楼。|south:1,north:4 3|图书馆|图书馆大门敞开着安静得能听见翻书声。|west:1 4|行政楼|行政楼前有块大石碑。|south:2加载逻辑按行split(\|)出口字段再用逗号切分、冒号分隔方向与目标ID。这里有一个常见的解析错误地图文件最后一行的结尾如果多了一个换行按行读取后split会得到一个空字符串导致解析出空房间。处理办法是每行先trim再判断isEmpty空行直接跳过。地图加载完做一次连通性校验从每个房间出发能走回出生点避免演示时走进死胡同出不来。NPC模拟是拉开差距的小点。常见做法是给某些房间配置一个“学生NPC”用一个定时任务每3秒让NPC随机选择一个可行走的出口移动进入房间时给房间内玩家推送一条“一个穿校服的学生急匆匆跑了进来”。实现只需要一个ScheduledExecutorServiceScheduledExecutorService scheduler Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(this::npcTick, 0, 3, TimeUnit.SECONDS);npcTick方法里做的事很简单遍历所有NPC对每个NPC随机挑一个当前房间的出口做一次移动并向新房间广播消息。这段代码在答辩时很加分因为它体现了你有“游戏世界自治”意识而不只是做一个响应式的命令处理器。注意ScheduledExecutorService的线程池大小设为1就够NPC数量一般不超过10个不需要多线程。4. MUD开发避坑指南五个常见翻车点与排查方法4.1 客户端连上后什么回显都没有现象telnet能连上端口但敲了指令没有任何响应或者过很久才收到一堆堆在一起的文字。原因有两类各占一半概率。第一类是PrintWriter没开autoFlush服务端写的内容滞留在缓冲区第二类是BufferedReader按行读但客户端发来的消息末尾只有\r没有\nreadLine一直等不到换行。解决PrintWriter构造时传true每个业务回合结束后手动调一次out.flush()双保险给客户端协议文档里写明“每条指令以回车换行结尾”。排查时先用telnet 127.0.0.1 端口连一下如果telnet有回显而你的客户端没有问题在客户端如果telnet也没回显问题在服务端写回路径优先检查flush和Socket的shutdownOutput有没有被误调。4.2 两个玩家在同一房间但互相看不到对方现象A说话B收不到B移动A这边房间描述没变化。这是典型的Room玩家集合选错了数据结构。House里用了ArrayList或HashMap两个线程同时add时导致集合内部状态损坏或者遍历时抛ConcurrentModificationException被try-catch吞掉消息就此消失。解决换成CopyOnWriteArraySet或者在所有读写房间集合的地方统一加synchronized(room)。注意锁定对象必须是同一个Room实例锁客户端线程对象是锁不住的因为每个连接线程是独立的锁自己等于没锁。排查时可以开两个客户端分别登录打日志看addPlayer时集合的size变化大概率看到size是负数或者与在线人数对不上。4.3 服务端运行一小时后内存占用高到吓人现象刚启动时内存占用正常跑一段时间后内存只升不降最后卡死。原因大概率是玩家下线只关了Socket没有清理onlinePlayers和房间集合里的引用。Java的Socket关闭不会自动通知业务层的对象移除你觉得玩家退出了但Player对象还被ConcurrentHashMap引用着永远无法被GC回收。解决在finally里统一调用logout()并让logout本身是幂等的——重复调用不报错。排查时用jmap -histo:live 进程ID看哪些类的实例数量异常如果Player和ClientHandler对象数量一直涨就是下线清理没做全。还有一个隐蔽点心跳超时踢人。如果一个客户端异常断电服务端的readLine会抛异常并走到finally这没问题但如果客户端只是网络闪断而Socket没报错服务端的readLine会一直阻塞这个线程和玩家对象就永远挂在那。给Socket加上setSoTimeout(300000)5分钟没数据就强制断开走下线流程。4.4 中文消息和地图描述变成乱码现象地图描述、玩家昵称、say的内容全是问号或乱码。原因是Socket流用了平台默认编码Windows下默认GBK服务端用UTF-8读两边错位。解决无论客户端服务端统一用new InputStreamReader(socket.getInputStream(), StandardCharsets.UTF_8)而且要保证源码文件本身是UTF-8保存。另一个坑是Maven编译时如果不指定编码可能把源文件里的中文转成GBK字节码再在运行时当成UTF-8读出乱码。在pom.xml里配好project.build.sourceEncodingUTF-8之后重新clean再compile别用增量编译编码问题改完不彻底。4.5 广播消息时有时无同一条指令有人收到有人没收到现象A说了一句话同房间B收到了C没收到重新登录C又正常了。这多半是广播逻辑里出现了竞态发送方先遍历房间玩家列表恰好在遍历过程中有人离开离开代码关闭了连接于是往一个已关闭的PrintWriter上写异常被吞掉导致后续的玩家收不到。解决广播前先判断out.checkError()写完后也调一次checkError()确认没有IO错误把广播和房间玩家增删放在同一个锁块里保证“要么都发到要么都发不到”的一致性。实际修改时我给Room加了一个synchronized方法broadcast(String message)内部遍历副本逐条发送发送失败就把对应玩家标记为待清理再由主循环统一移除。这样每个玩家的收信状态是确定性的不会再出现随机丢消息。5. 让课程设计从“能用”变“高分”验证方法与进阶技巧5.1 用压测脚本证明你的MUD是真“多人在线”手工开两个客户端验证在线交互是课设的及格线。想验证并发下的稳定性我习惯写一个几十行的压力脚本用Python起20个线程每个线程循环执行“登录→随机移动→说话→退出”跑10分钟观察服务端有没有异常堆栈和消息丢失。这个脚本不挑环境Python标准库就能跑import socket, threading, random, time rooms [north, south, east, west] def client(i): s socket.create_connection((127.0.0.1, 9000), timeout5) s.sendall(fname 玩家{i}\n.encode(utf-8)) for _ in range(50): cmd random.choice([say hello, look, fmove {random.choice(rooms)}]) s.sendall(cmd.encode(utf-8)) s.recv(4096) time.sleep(0.1) s.close() for i in range(20): threading.Thread(targetclient, args(i,)).start()脚本里每个客户端随机挑指令跑完这20个线程后看一下服务端日志里有没有IOException、连接拒绝、以及消息总条数。如果服务端实际收到的指令数和客户端发送数一致并发这关就算过了。答辩时拿出“50个并发连接、消息零丢失”的记录比任何口头描述都有说服力。5.2 两个显眼的加分功能断线重连与房间日志断线重连是性价比很高的加分项。给Player增加一个token字段客户端登录时服务端生成token返回断线重连时携带token和上次的房间ID服务端校验后恢复玩家到原房间并向房间广播“xxx重新连接了”。实现不难但效果显眼它把课设从“作业”提升到了“系统”的层面。另一个是房间内消息队列。每个房间保留最近20条聊天记录新玩家进入时先补发历史记录这样玩家退出再回来不会失去上下文。这两个功能加在一起你的MUD就有了“状态持久化”的雏形面试聊项目时也能往分布式会话管理上引。最后是我个人的交付习惯写完MUD后我会把一份大概30条指令的验收清单存下来从登录、移动、说话、查询在线用户、违规指令到连续快速输入每次都先跑完整清单再交代码。这个习惯帮我避免过不少交付前才发现的尴尬问题。日志上给每个在线玩家加上最近活动时间戳服务端每5分钟打印一次在线人数和线程池活跃线程数这段日志直接证明“多人在线”是真的在不同线程上并发跑的。希望这篇笔记能帮到正在啃MUD课设的你。本文还有配套的精品资源点击获取