搜搜考试网MUD读音是什么啊?
来源：学生作业帮 编辑：搜搜考试网作业帮 分类：综合作业 时间：2024/05/08 15:31:00
MUD读音是什么啊?
MUD（音标不见了,就打字吧,和 妈的 差不多音）
abbr.
1. =Multiuser domain 【电脑】多位使用者区域(为一种透过网络让多人参与交谈式、探险式的角色扮演游戏)
mud
KK: []
DJ: []
MUD游戏（Multiple User Domain多用户虚拟空间游戏）.大家对MUD也许很熟悉,这就是你一直听到的,可能却始终不听不懂的“泥巴”,虽然你可能还不知道它确切是什么东西.但在泥巴一族中间,MUD就是他们第二个生存空间.
1979年第一个MUD（多用户土牢）多人交互操作站点建立.这个站点包含了各种冒险游戏、棋类游戏和丰富详尽的数据库.大受欢迎的《网络创世纪》(UO)则是真正意义上的第一个大型图形MUD,也是至尽被认为是最完善的网络游戏,玩家只要自己喜欢,可以专心做买卖,或到处游历,或什么事情也不做而随便走走,与现在网络游戏中充斥着的PK,杀戮相比,UO是一片纯粹的游戏玩家的梦寐以求的圣土,依然是网络游戏的颠峰之作,在UO上发生的很多传奇故事至尽仍被广为流传.
MUD的历史
原作: Lauren P. Burka
翻译: stoneboy
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社区
abbr.
1. =Multiuser domain 【电脑】多位使用者区域(为一种透过网络让多人参与交谈式、探险式的角色扮演游戏)
mud
KK: []
DJ: []
MUD游戏（Multiple User Domain多用户虚拟空间游戏）.大家对MUD也许很熟悉,这就是你一直听到的,可能却始终不听不懂的“泥巴”,虽然你可能还不知道它确切是什么东西.但在泥巴一族中间,MUD就是他们第二个生存空间.
1979年第一个MUD（多用户土牢）多人交互操作站点建立.这个站点包含了各种冒险游戏、棋类游戏和丰富详尽的数据库.大受欢迎的《网络创世纪》(UO)则是真正意义上的第一个大型图形MUD,也是至尽被认为是最完善的网络游戏,玩家只要自己喜欢,可以专心做买卖,或到处游历,或什么事情也不做而随便走走,与现在网络游戏中充斥着的PK,杀戮相比,UO是一片纯粹的游戏玩家的梦寐以求的圣土,依然是网络游戏的颠峰之作,在UO上发生的很多传奇故事至尽仍被广为流传.
MUD的历史
原作: Lauren P. Burka
翻译: stoneboy
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社区