2018年6月28日，独立开发者Andrew Zigler在个人博客上重新评估了一种比他年纪还大的游戏形式——MUD（Multi-User Dungeon，也写作MUSH、MOO，统称MU*）。这是一种完全由文字构成的多人虚拟世界，玩家通过Telnet协议或专门的客户端软件登录，屏幕上没有图片，只有房间描述、物品清单和你敲下的动词指令。
Zigler的判断很直接：图形游戏挤不掉MUD，因为文字省下的是美术资产成本，不是开发成本。真正的门槛仍然是系统设计、内容写作和长期运营。原文没有给出用户规模或增长数据，能证明的只是一部分小众社区还在，个别项目已经运行了几十年。
三种MUD：从打怪升级到协作写故事
在MUD里，角色站在一个"房间"里。房间可以是狮穴、荒原，也可以是珊瑚礁。玩家输入get sword这样的指令，复杂一点的系统甚至支持look at gemstones on tiara式的完整语句。
这套玩法和单人互动小说（IF）同源，区别在于MUD是实时的、多人协作或对抗的。它更接近一种多人实时互动小说，而不是简化版的图形网游。
不同MUD对"世界"的定义差异很大。有的偏战斗升级——系统代替GM，打怪、升级、管理背包；有的偏自由创作——没有规则和道具，玩家靠即兴写作推进剧情；中间还有大量混合型。
前者本质是一本可编程的规则手册，替代了桌游里骰子和GM的活；后者放弃规则，把环境当画布。两种极端之间，才是大多数MUD实际运行的样子。
省下画笔，省不下工时
图形游戏里，模型、场景、特效各有各的制作成本，预算不够就得砍效果。MUD不一样：想描述的任何东西，付出的都是同一种代价——文字。这是Zigler全文最核心的一个对照。
| 维度 | 图形游戏 | MUD/文本游戏 |
|---|---|---|
| 资产成本 | 建模、场景、特效各自计价，可分级砍预算 | 都换算成文字，单价相对统一 |
| 开发周期 | 视预算和团队规模而定 | 仍需数月到数年打磨世界观、机制、内容 |
| 访问方式 | 独立客户端或平台商店 | Telnet协议或专用客户端 |
| 服务器运维 | 图形游戏同样需要长期维护 | 同样需要，代码库容易随社区消失而失传 |
省下美术，不等于省下开发。Zigler当时在用JavaScript引擎Ranvier做实验，他承认：即便有现成框架，一支团队要做出内容扎实、系统平衡的MUD，也可能要花上数月甚至数年——写世界观、写房间描述、调打怪机制，工作量不比图形游戏轻松。他还提到，用Ranvier搭出来的MUD里，当时几乎没有已经发布或有人气的项目，不少老牌代码库也面临同样的问题。
文本世界的门槛，从"要不要画图"挪到了"能不能持续写下去"。很多MUD社区起来得快，消失得也快，源码一丢就再也回不来。
视障玩家和独立开发者，各自会怎么用它
MUD最实在的受益者，是图形界面帮不上忙的人。视障玩家可以用屏幕阅读器实时朗读终端文字，很多MUD还提供选项关掉ASCII地图之类的视觉化元素，让文本更适合朗读。语速调得够快的玩家，靠声音提示和触发器，能跟视力正常的玩家打得一样顺手。
关注无障碍体验的产品人员，可以把这个当作一个现成的对照标准：一款新游戏如果关掉视觉元素就完全不能玩，说明它的无障碍设计还停在表面。真正做到位的做法，是像MUD一样，把关键信息本身就写进文字，而不是靠额外补丁堆出来。
独立开发者做文字互动产品，可以把MUD/文本引擎当成低成本验证叙事玩法的一条路：不需要建模师和特效师，先把系统和内容写扎实。但代价要提前算清楚——预算要从建模转到写作和运营，团队小的话，光把内容库填满就可能跑上大半年。Ranvier当时缺少跑出来的成功案例，说明这条路没有捷径可抄。
图形游戏受限于预算能画出什么，MUD受限于你愿不愿意写下去。
访问方式在Zigler写作时仍是Telnet客户端，或者玩家自制的辅助工具，带着记录、配色、别名、计时器这些功能。接下来值得盯的两件事，原文都没有给出答案：Ranvier这类开源引擎能不能跑出一个被验证的项目，以及老牌MUD服务器还能靠没人维护的代码撑多久。