1989年的八月，CARNEGIE MELLON的一个研究生在一个周末写了一个叫做TinyMUD的游戏。那是一个简单的，多用户的游戏。在互联网只要谁知道他的地址与端口（lancelot.avalon.cs.cmu.edu 4201)，那么谁就可以得到这个游戏。然而TinyMUD并不是最开始的MUD游戏，这个游戏容易使用，并且可被移植到许多UNIX系统上。这使得MUD风潮像爆炸一样风靡世界至今未衰。现在的各种MUD游戏就在你的身边，另你目不暇接。
MUDs（多用户空间）有如下的各种优点：
许多人可以一起玩；
游戏被分成许多虚拟的空间以便在一个空间的人或物不会影响到另一个空间的人或物；
所有的交互内容以文字出现，没有图片或声音；
通讯靠TCP套接字实现；
大多数代码由学校里的学生来完成维护并且可以公开地得到；
实物，空间和人物的组合可以由简单的命令来完成，而其他语言编写的MUD游戏允许有更复杂的命令和道具；
尽管MUD是为了一个严肃的目的而出现的，但是它仍然保持着原始冒险或RPG游戏的气氛；而且游戏玩家的身份并不被现实所束缚，MUD里的游戏的角色有现实虚拟如一的人，有毛茸茸的动物，有科幻故事里的英雄，以及所有可爱的，丑陋的，令人讨厌的，智慧的人，或者仅仅是一个平常的怪人。
JIM ASPENS（现在是YALE大学的老师）认为TinyMUD无足轻重，很快就会丧失掉新意。他有了些想法却又举棋不定，这对MUD游戏的优点和缺点都有一定的影响。
从地狱开始：MUD游戏--内存VS硬盘
早期的MUD游戏倾向于把大部分游戏数据放到硬盘上。当玩家需要时，空间和物体的数据从硬盘上被取出来。这种方式很慢。
TinyMUD把所有的数据都放在内存里面。这种设计假设数据不会变得特别多。实际上，对于小的MUD游戏，基于内存的数据存储是很快的。但当数据量增加得很多时，进程会开始频繁地在硬盘和内存之间交换数据。系统的负载会由于页面错误的集中出现而攀升。许多系统结构都有一个处理数量限制。ASPENS最终抛弃了TinyMUD当它在他的机器上达到了32M处理数量极限而崩溃的时候。MUD游戏的数据膨胀使问题恶化了，导致巨大的个人对象（INDIVIDUAL OBJECT），甚至后台进程。LambdaM00，运行在SparcCenter 1000上的Xerox Parc平台上，在1994年就要求有198M给予进程并且数据要占有80M的硬盘空间。
很大的基于内存的MUD游戏的表现不尽人意众所周知。尽管有大量的优秀的MUD程序员，直到很晚这个数据层的改进问题才被考虑到。有以下几点原因：
无知。很多学生懂得C语言，但几乎没有MUD程序员研究过数据库的设计。我还记得在新闻组rec.games.mud上，一个学生坚持认为基于硬盘的MUD游戏会把硬盘搞得疲劳不堪。
习惯。有很多MUD游戏是基于硬盘的。包括Marcus Rarnum（那时是DEC的员工）的UberMUD和UnterMUD和Andrew Molitor（Wesleyan大学的研究生）的TeenyMUD，是Andrew Molitor诸多计划中的一个。UberMUD，用到了b+树型数据结构，但被证明对于大多数MUD程序员是相当复杂的。UnterMUD用到了hash表，使用了很高明的缓冲技术而提高了数据访问速度。这种技术被用到了一些商业MUD产品中。但是这种数据结构不允许一些MUD程序员所喜好的操作，比如检查数据对象的总数量。UnterMUD的数据结构，也就是缓冲技术，已经被应用于其他一些服务器中，比如MUSH 2.0。
至少有一种运行得很长时间的TeenyMUD。TeenyMUD使用了一种平直的文件，这种文件使用了一种直接索引方式，和hash搜索同样有效，尽管比之于UnterMUD和UberMUD在缓冲技术方面还欠缺一点点。它的资源占用率很低，对于那些只想试用MUD一两个星期的人很适用。但是，那些喜欢小玩意的MUD程序员常常忽视了TeenyMUD因为它缺少一种可编程的环境。不言自明，如果你的服务器是完全基于内存，而你的MUD进程增长迅速使得依靠硬盘的方式变得很诱人的话，那么在这个时候要不损坏数据而更换服务器则太晚了。
基于硬盘方式不是一种万能钥匙。它使得checkpoint（当服务器运行时做备份）变得很复杂。一种技术上的意见认为基于硬盘的数据结构不会增进效率，如果这些数据够多。理论上，经常被访问的数据对象的缓冲会被放在内存中。，当需要时，这些数据就被交换到进程地址空间里面。既然对象不能因为分布状况而被组合到数据页上，任何顺序地访问大量数据的操作都会使进程运行艰难。操作系统比大多数应用程序要更善于交换数据，一个基于硬盘的数据库比一个基于内存的数据库要痛苦一些。基于硬盘方式仍然会给数据增长加上一个令人满意的上限，尽管硬盘映像会变地更大，更臃肿，有更多的碎片。
与其找寻一种复杂的方法来解决数据增长问题，许多MUD游戏宁愿依靠一种公共的约束或rm -rf（rm:Unix命令-删除）和一切从新开始者来构建数据库。很不幸，这种标志之一以及一个成功的MUD游戏的副作用就是在程序大小和子进程数量两方面的增长。————————
应该注意到硬盘，内存和cpu要占用较多的系统资源。一个50个用户的MUD游戏要占用一个FTP进程的一定比例的网络带宽而且不会使通讯显著地减慢。
在1989年和1994年之间，普通互联网主机上的内存和cpu性能增长了一到两个数量级。但是在1989年，只有很少数的人曾经登录到有额外的 CPU周期分给MUD游戏的互联网主机上，特别是一个那种能控制整个的工作站使其他进程不能以合理的反应时间运行的主机。
同时，随着MUD玩家把游戏介绍给他们的朋友，一定数量的大学生开始迷上了MUD游戏。但给予MUD的CPU周期仍然增长缓慢。这种不和谐导致了两个结果。
人们开始在任意的地方运行MUD，也不请求得到系统管理员的允许。1990年，某个使用GNU群件的人总会在一个机器上发现四到五个MUD在运行，而用户要干点实际的工作就必须杀死这些MUD进程。
在某个正在发展的虚拟社区里，掌握着可以运行MUD的资源的人总是有着很大的权力，甚至要超过他们对继续改进MUD所需投入的时间和精力。
这样我们就碰到了关于MUD的第二个问题
究竟是哪些人的游戏呢?
ASPNES认为他的游戏可能在几个星期后人们就会对之兴味索然。然而确没发生这样的情况，他于是就继续运行他的游戏。很多用户认为TinyMUD，还有他们在构建这个游戏的努力，会永远持续下去（或者至少是在他们毕业之前，还有机会接触网络的时候）。同时，ASPNES，他是一个游戏中的巫师，当游戏变得越来越大，越来越难以控制的时候，却越来越懒地维护他的 MUD游戏，不去管理资源使用，也不去观察游戏参与者的行为了。
一个用户在TinyMUD上的所建对象的数目的限制只是一个“钱”（当然是游戏中的货币）的问题。玩家需要数个便士来建造空间和对象。一个玩家开始是一分钱也没有的，但却可以通过访问别人的建筑或寻找宝藏来赚一些钱。有野心的建造者很快发现计算金钱的系统可以用宏来屏蔽掉以便不断地攫取有价值的宝藏。这对那些有野心的庞大建筑计划者很合口味。但对其他人来说，例如，他们建造了500个对象，却被告知：“你找到了一分钱！”。他们被留在了镇子的中心，以至于任何经过此地的人都必须看着这500个对象的列表。一旦这些对象被去掉，它们仍被加到数据库里直到有人发出了一个工作循环命令。
TinyMUD的一些部分以线性的方式延伸，比如街道和地下铁道。另外的部分却互相交织在一起。有些电话亭连接了四到五个方向。WESLEYAN大学的蒸气管道连接到了FLORIDA大学的校园里。台湾竟就在剑桥的旁边。还有一些谜语，包括巨洞历险的遗迹。还有住宅，准确地说，是一个住宅。。
REC ROOM是一个早期的数据库。它有一些玩具和场景。REC ROOM的主人让别人可以连到数据库上还为建造着提供了自由的外出的通道。因此任何建造了些对象的人都作了一个入口和出口同道连到了REC ROOM上，以代替数据库的线性部分。很快REC ROOM成为一个生存的场所，但也是一个交通要冲。
同时，一小部分MUD玩家在建造，而只有极少数的人在探索。更多人把TinyMUD作为一个有家具的交谈系统。曾经有过议论要是鼓励，或甚至于强迫玩家去探索。但是，定居却成为MUD游戏里与建造和探索相竞争东西。大多数服务器把交谈设置得同建造一样复杂。
当人们在一个虚拟的空间里聚集的时候，就意味着任何想搞点破坏的人可以写一个程序连到MUD上，找到那个房间，发出大量的字符，那么MUD就会死掉。
对于TinyMUD的这些已被发现的缺点，拥有资源的MUD玩家，或者从别人那里能搞到机器运行MUD的人，开始设计新的MUD游戏。这些新的MUD游戏在建造方面有某种中央建设的计划，或者至少在哪个人把什么东西放在什么地方的问题上有限制。所有这些育游戏都有更加积极的巫师。建造方面的限制导致了争吵，偶尔甚至相当有强调性和尖刻。建造者可以看到他们的杰作被巫师循环掉以减少数据库的在内存和硬盘间的交换数据。“REC ROOM现象”使建造一般空间的的人被提升到实际上的巫师的地位，他们能控制哪一个人能进入或者建造新的建筑到公共的空间里去。这些人的力量只在系统管理员之下其他人之上。
MUD玩家大多数是大学学生，他们刚刚发现所谓“言论自由”和“艺术性表达”的概念。他们通常是狂野的，也是毫无效果地把这些想法加到数据库上的项目里。而对于MUD游戏的下一个阶段的矛盾已经被埋下伏笔，而且至今仍未被解决。
哪些人拥有MUD数据库呢? 系统管理员? 巫师（在MUD游戏中有着编程和管理系统权限的人）? 还是那些挥洒了汗水建造游戏中风景的人?
一个数据库只是一个文件。如果你拷贝下来又会发生什么呢? 哪些人又有这些拷贝呢? 如果在不同的机器上有着同一个数据库的两个拷贝在运行呢?
如果MUD游戏的规则或者是管理员定的规则发生了变化，那么反对这些规则的玩家能不能摧毁他们的建筑呢? 如果玩家没有什么举动，是不是就意味着他们赞同新个规则呢? 如果玩家的建筑包含了“公共”空间或vital topological interlink呢?
玩家有没有权力参与MUD游戏? 他们有没有权力去建造呢? 对于那些公平地参与者会不会有限制呢? 对于那些在建筑上进行了投资的玩家对数据库能有影响么? (Can it be decommissioned over their protests?)
分布式MUD游戏，（就象所有其他的分布式的东西一样。） 已经被作为数据库所有权问题和所有其他常见的错误的解决方案被提出来了。而且已经有了一些初步成功的分布式MUD游戏的实验。玩家能够从一个MUD游戏毫无困难地走到另一个MUD游戏。如果被拒绝的话，人们可以简单地“拿起他们的玩具回家”。但是，分布式MUD游戏却不怎么流行。
很自然，如果用户权限的问题不被解决的话，对于那些有着用户分级的系统就不会有令人满意的解决方案。一个MUD系统管理员可能会选择去相信一些主机上的MUD系统，但是如果其中的一个MUD因为疏忽而出现了安全问题，他们可以允许制造麻烦的人从这个MUD中出去然后登录到另外的主机上。
而且，一个分布式的MUD游戏要求每个参与的MUD系统都使用同样的服务器代码，或者至少是一个同样的数据库层。我还不知道有任何的令人满意的解决方案来解决游戏玩家把游戏中的东西从一个MUD带到另一个MUD中的问题。
做你想做的，那就是规则的全部含义。
正如其他的系统的管理员所知道的，人们对于共享的计算机资源和对于真实生活的资源都同样的不是很有理性。在没有一个积极的系统管理员的情况下，开始的TinyMUD的数据库不仅变得很大而且乱七八糟。网络上有着年青的，未谙世事的年青人，他们喜欢搞破坏，而不是为自己建设。甚至能用一些简单的编程工具来制造系统灾难。在MUD上这可能变得更加糟糕，因为网络上对于匿名用户的许可使的一般人也可以对网络安全造成威协。
MUD只是游戏，但是大多数系统管理员和玩家都普遍认为MUD是很有趣的，对于大多数人，接收端的烦恼并不是很有趣。但是对于烦恼到底是什么的问题却比编程时的问题要更加痛苦。狂暴的举动或者是淫秽的内容能保护语言性的或艺术性的表达么? 或者对于那些平静的玩家是一件烦人的事情?扮演一角色会给一个玩家粗鲁的或侵虐的性格么?
当实际上没有什么社会规范时强迫玩家遵守社会规范没有什么用处。在一个MUD上，性别，种族，状态，甚至地球引力都不是他们看上去那么回事。一个人可以很好地理解，当那些忧郁的，或毛绒绒的，或那些可以飞的人坚持认为新手会在现实生活中和MUD中一样行动，所带来的混乱。而且，一种社会规范会成为一个社会团体存在的前提。一些学生利用学习的间隙想些别的事情而不是考虑关于道德的事情。
不管MUD游戏系统是不是社团，象泥(mud)水坑里会生虫一样，他们也产生了、管理机构。通常，对于系统管理员有三种理解。
有象JIM ASPNES式的“放任自流”模式。这种MUD游戏趋向于毫无规律地快速增长，也没有人去踢出那些捣乱的人。没有一个积极的管理员，许多MUD社区<使用了一种强有力的MUD客户端软件作为主持正义的义务警察。防御的功能包括：禁止问题玩家的输出。对于攻击的问题，有可能采用/usr/dict/words(是一个UNIX下的字典文件，有大概400多K字节）来把对方给赶跑，特别是当对方的客户端没有你的强大时。
另一个方面，一些MUD游戏采用了另一种转移的方式，组织了一个以可憎的行为为规范的社区，交互的集中形式是TinyMUD 的“kill”的命令。CATHARSIS是一个很多人知道的虚拟王国，那里不需劳神费事，淫秽的内容就可以被提升到艺术的高度。
一些MUD游戏采取了自动管理的模式。这种方式工作得相当不错，如果管理机器的人员就是MUD的顶级巫师，而且经常上线玩，因此熟知其他玩家，并且能观察到不断出现的问题的话。许多这样的MUD游戏也使用一种用户注册的方式，使任何一个人想玩的人都必须回复一个有效的地址。而生事的家伙也就永远toaded. 这个系统最大的缺陷就是一个独裁的MUD只会接纳喜欢，或者至少是能容忍，顶级巫师的人。......
第三个可能是在大多数有能力的玩家中选出人来产生一个合作控制的MUD游戏管理模式。有人幽默地指出道：冒险式的MUD 游戏，允许用户通过猜迷，杀死巫师直到他们也到了巫师阶段，然后才开始建造自己的东西。TinyMUD和与之类似的MUD同类有一个相似的分级方式：玩家们通过和巫师外出游历直到他们也变成巫师来取得分数。有一些运行了很长时间的MUD使用了一种合作式的管理方式，通常是又投票来决定。当巫师和玩家分成了不同的派别，互相谴责对方粗野的不正当的行为，特别是在公共的论坛里的比如USENET里，这些MUD产生了复杂的或者是丑恶的政治问题
在另一个方面，政治是现实生活的一个不可避免的部分。一些玩家可能会认为政治很好玩，但是另外的人对此报着悲观恐惧的看法。互联网正在变得越来越拥挤，而这种早期的令人喜悦的无政府的状态可能会转变为一种更复杂的，但可以接受的状态。
总结：你不能考软件来解决社会问题。
几年以前，系统管理员都在把没有用的MUD从他们的机器上删除掉。现在管理员们发现，MUD游戏为地理上分隔得很开的项目组成员在邮件列表上提供了显而易见的优势。使学生们为合作完成作业而与同学和老师保持联系，也使行动不便的学生能够有机会参与社会活动。MUD游戏让学生和其他地方的学生在网络上实时交谈，让处于城市郊区的大学没有了隔离的问题。一个虚拟的的公共机构可以让充满希望的学生，职员和贡献者们做虚拟的旅行。
很清除，更进一步的软件发展是组成稳定的MUD社区的前提。希缺资源对虚拟设区的重视和对真实社区是一样的。MUD 的数据库在运行它的服务器超过了它的处理能力时，或者系统软件变得不正常时，会被删除掉，使得建造活动和社区建设的活动受到压制。
即使有对服务器软件的升级，在一个字符界面的虚拟社区里生活的社会问题在五年里几乎没有什么变化。当有限的资源被去掉时，磨擦仍然会存在。
在MUD上有过主流媒体对“社会问题”的关注（这并不让人吃惊；网络空间里的性和死亡比数据库层面的讨论要卖座得多）但是如果那些将要成为系统管理员人认为虚拟的强奸和MUD毒瘾只是他们面对的唯一问题，他们会感到吃惊的。
MUD游戏应该是匿名的么，或者MUD的ID应该与现实生活的信息相联系? 匿名问题可能会促进反社会的行为，但是经过注册的ID免去了MUD游戏中最有用的性质：遮羞的面纱。一个妥协的方法是系统管理员不能随意进入修改身分信息。但是任何保存在文件中的信息并不是象人们想象的那样能够保密。
哪些人去建造呢? 限制建造的目标到某些特定的主题和布局可以把那些有不同想法的人排除出去。但是无法控制的建造活动会使在数据库里寻找一个目标或者搜索数据库变得不可能。一个数据太多的数据库对任何人是没有任何趣味的。
新用户应该学些什么呢? 喜欢谩骂的用户在MUD应该受到惩罚么，或者游戏里面应该有现实生活的秩序? 你能够确定的知道任何人的现实身份吗? 把你的真实的生活中的行为移植到虚拟的环境中是没有什么用的。“财富”的和“个人”的概念在虚拟的生活中并不适用。文字的交互比真实生活的交流要简单一些，只是没了语调和真实的表达。也可能在这种环境种要知道语言对别人的影响也是不可能的。如果一个用户用无意义的信息轰炸别人使得他或她不能使用MUD，那么攻击者要被认为是犯了错误吗?......
即使是简单的情况，象姓名的管理，也会是一个复杂的问题。一个MUD能够支持多少个叫DAVE的人? 那么给用户分配唯一的数字-字母的ID会不会打破这种虚拟社区里社会的气氛?
随便想一想就会看到每一个社会问题并不能靠一个代码补丁来解决。一个面向大学本科学生的MUD游戏的管理员可能会被装上一些过虑的装置来过虑一些特定的字词。学生们却又会想出一些新的方法来互相谩骂，这要比服务器上的规定的更新要快得多。既然一些人能够被一些简单的话感动，任何形式的话语很快就会变得冗长无比。
忽视这些问题的MUD系统管理员会发现他们自己碰到每一个事件时都会随意定一些规则。另一个方面，使规则生效的虚拟社区的社会情况比真实生活的变化要快很多。
“我们，世界上的MUD玩家，为了构建一个完美的数据库，宣布联合起来，并保证对于任何有能力的人都能得到kill命令的使用权力。而且在网络死掉之前提供一个备份的MUD，还要提高提示出现的频率，而且保证我们还有我们的后代有一个安全的站点可以连线。为此我们宣布并确立这个《真实世界的虚拟城邦宪法》”