下面的东西是今天停机后用闲暇时间写出来的，本人多年没有接触过Mud了，有错之处在所难免，我本人记性也不太好。总的来世是套用面向对象的思想往这里套的。不过Mud是c架构的系统，套上去有不合适的地方估计会很多，反正是随便乱说的。没有涉及到具体计算，因为对系统运行所有情况都不了解，想计算也没有办法计算，而且本人在这方面也不太擅长。纯粹的思想性研讨。下面正文：

新来玩这个没有多久，以前在清华内混，没有玩过北大的Mud，对这个不太熟悉说错了请抱歉。而且这么多年没有接触Mud了，对Mud方面记忆混乱在所难免，欢迎大家指正，我这里就算是抛砖引玉了。

个人一直认为Mud最大的问题就是他对Object处理机制上，这方面垃圾清理机制优化的不完善是导致一系列系统故障的根源。这方面图形Mud就比文字有优势得多，很多时候他可以把那些压力分担给客户端执行，服务器端只需要保留各种各种物品的即时状态，不需要保留对象属性、执行方法以及和对象具现相关的其他乱七八糟的东西，服务器端也就可以支持几千人上万人的同时在线（当然上万人就要好服务器了，烂的肯定不行）。这方面文字Mud再优化也很难达到，毕竟所有处理都在服务器那端，文字处理再轻也承受不了啊。

典型的对象比如说一个NPC，一把木剑，Mudos在载入的时候把这个物品的属性，方法之类的一起载入进来，然后一直保留直到这个物品被销毁才从内存撤离。而逻辑上按照正常人理解的机制应该说你用到这把木剑了，系统从硬盘读取木剑的属性和方法到内存里面，你用完木剑扔在地上，这把木剑使用结束相关内存里面的属性和方法应该可以销毁。实际操作上不会如此，一般来说为了避免频繁访问，都是预先将Object读入内存你使用完了也不会即时销毁，这也是为了防止别的对象对该对象的再使用。但是这样子一来就有一个问题就是，当大量闲置对象存在内存并且不停使用对象依附的方法的时候对系统就产生了许多无用的负担。现在很多主流解决方法是智能解决闲置对象，每个周期搜索内存中闲置对象，只要超过阀值将对象缓冲到廉价存储上，空闲出系统资源给热对象使用，减少系统负担。这样有一个问题是，典型的比如有的NPC我一个心跳要随机计算一个动作体现出来怎么办？缓冲到廉价存储的含义就是如果没有触发基本上不允许他自动发动作，这样子一来比如流氓他老人家要打出晃荡，地痞他老人家要泡小妹不久都没法实现了？或者有人说那这个世界不久死了？还不如以前那样，虽然系统脆弱点，但是好玩啊？实际上你想想一个典型的Mud，比如有100人在线，每秒平均发出5个指令，有1000个NPC每秒要产生一个动作，比如100个玩家相关有1万个物品需要处理，每个物品产生交易量就按照1/10每秒算，实际上服务器的负荷超过（5×100+1000+10000/10）/秒，而且关键因素在于这些计算都在服务器，我相信比起很多图形Mud服务器负担要重很多，实际上你很难期待一个Mud能够支撑起几千人问题就在这里，如果有几千人，不算NPC增加，和玩家相关的负担就提高几十倍。

按照我的想法其实这个问题其实有两种解决办法，一种是优化底层核心代码，对象处理机制上进行优化，采取优先级策略，重要的关键对象始终占据内存，一般对象有闲置时间，只有对他进行触发了才载入内存。（比如射雕英雄传带有读的方法，如果你带在身上的时候没有读这本书，射雕英雄传只是一个公共对象，你身上只有一个携带射雕英雄传的属性，当你读他的时候，射雕英雄传这个公共对象产生一个子对象挂上你你就可以正常读这本书了，读完子对象超过闲置时间被父亲收回，内存上就不会有很多个射雕英雄传对象。也就是说不是说整个游戏产生了100本射雕英雄传，系统就应该产生100个射雕英雄传这个对象，只是产生热使用的几个相关对象，对系统负荷也就相对减轻了）这里面还有一个问题是游戏中常常会衍生出大量的自动执行对象，比如盗宝人、蒙面杀手之类，每个心跳要进行随机计算，实际上个人感觉这种对象要严格管理，系统级控制总量，严格执行无效对象及时回收，否则他们对系统压力是最大的。还有一个办法就是设置一个上层管理机制，全局管理触发事件，也就是说触发事件和盗宝人或者蒙面杀人没有关系了，不是他们发起了，有天神告诉盗宝人到时间了你要往东走一步，盗宝人就走了一步，告诉蒙面杀手你到了随机砍一个这个房间里面玩家的时间了，他才能根据算法杀一个人，这样子一来当系统负荷到极限就可以管理统一少发指令控制住整个系统的稳定性，对于单个玩家来说感受也不会有明显差异，不会感觉到和以前明显的差距。

上面修改核心个人感觉难度比较大的，但是单单设置一个上层管理机制，将所有NPC自动触发机制回收统一管理，将非活动NPC统一记录缓冲闲置对象我觉得对系统还是有帮助的，至少这样子一来除了玩家的负担以外，由他们衍生的其他对象产生的负担有一个系统总控管理，系统lag出问题了查查总控负担是不是过重就知道问题出哪儿了，修改闲置也就有的放矢，解决有些非正常事件发生也有一个很好的监控窗口。而且还有一个好处就是可以产生一些很好玩的东西，比如说本心跳我让满足条件的物品有50%产生出来放在指定的房间，其他物品等下次机会了，或者迷宫地图由控制中心每个间隔随机计算部分地图。或者诸如此类原先会增加每个对象方法从而增加系统负担的事情，统一处理以后基本上压力也就没了。强化全局管理属性，从而减弱单个对象的方法实现，减少对系统的负担，增加一些全局变化，提供一些依附在单个对象上无法实现的意图。

另外谈谈数据极限问题，以前我弄XYJ的时候也一样碰到这个问题，当有人数据到了100M以上的时候你就要担心会不会数据溢出了，现有做法就是设计转世系统，让人重新开始，我以前做法是做了一个全新的地图，将经验值转换，比如除1万转换到新地图，当然你也很难回到原来地图来，玩法也要变变，噱头也要改改，算法也要修改，技能也要转换，工作很多，难度不小，以前自己做缺陷也不少，现在想想这个估计要花不少人力的事情，如果这里有人力可以考虑考虑，估计5，6个人花个半年一年差不多。

• Zglb：这样有一个问题是，典型的比如有的NPC我一个心跳要随机计算一个动作体现出来怎么办？缓冲到廉价存储的含义就是如果没有触发基本上不允许他自动发动作，这样子一来比如流氓他老人家要打出晃荡，地痞他老人家要泡小妹不久都没法实现了？或者有人说那这个世界不久死了？

其实不完全是。貌似许多npc是当前房间出现玩家后才会有心跳执行动作，这样没人时就是闲置，消耗的资源不多，不过还是要占用内存

修改核心，全局管理，这个我最赞成，呵呵，lpc就是很明显的面对对象的操作方式，有优点也有缺点，缺点就是object等。要我看，还有众多的函数和物件，每一个都是一个文件，甚至函数内部调用的其他基础函数也是独立的文件，这个在数据读写上的消耗也很多

• Seagate：我这里触发的意思是，玩家和NPC交互了才算触发，比如说一个NPC在地图里面，有人在房间里面，没有和他交互，这时候实际上这个NPC是闲置的，大概就是这个意思。这时候他不停发动作有时候也受不了，其实很多都是这种情况，Mud这方面做的很差，而且碎片太多，我那时候开发的时候就发现一个一个小文件真的受不了，Java也是如此，但是人家最后打包的，比这好一点。
• Zgbl：嗯，mud文件太多，就是有一种碎片的感觉，哎
• Jason：指出一个根本的错误：图形网游的服务器端计算量比文字MUD大的多得多。
• Huoyu：大肯定是大一点的，大得多，倒是不见得。

其实一般网游的server端，没那么复杂，都是一些简单的计算，血量，攻击，限制什么的。地图会有个简单的文件来标识什么坐标能走，什么坐标不能走什么的

搞过海盗王的server端，server端程序，相当小。

• Jason：玩家A放一个大招，谁应该看得见，谁看不见，光这个计算量就吓人。
• Huoyu：这没什么计算量吧，一自己为起点，搜索大招范围内有没有人，不麻烦吧，要么一圈，要么前面一个方块，确定坐标范围后，查找范围里的人，绝对绝对比客户端复杂的图形计算省力很多吧
• Seagate：但是图形端有一个好处就是很多计算可以放在客户端，就看做Server端的人想不想那么做了，典型的就是金庸群侠传就把很多计算放在客户端，导致被人在客户端修改内存攻破，这个虽然很可笑，但是也看出来那东西人家是可以减负的。我们文字Mud完全不可行，而且随着上线人数上升，配套的NPC和物品数量上升更快，这导致游戏里面运行的对象太多，有时候不是说总内存或者总CPU不够用，而是管理这么多对象也会导致资源紧张。管理几千个对象和几万个对象以及几十万个对象完全要求不同的设计理念。否则肯定会有很多很多问题。
• Jason：一个正常的网游，必须在服务器端完成所有的数据计算，判断，检查工作。

客户端只负责绘制和输入命令。这样，mud和网游是完全一样的。

• Huoyu：sg说的不对。。。。mud在规则计算方面，应该是和图形游戏一样的。所有的对象，图形游戏都在服务器端都存在的，数据量绝对比mud多，计算量也大。关键是人家可以用更好的语言来写

mudos。。。。能和linux比么。。。。能和更小的定制系统比么。。。。慢就慢在mudos

• Seagate：mudos没办法人家都是多少年前的产品了，就如此了。不想现在有更多更好的技术可以用。
• Ddid：FluffOS

新一代的MUDOS

• Huoyu：是什么啊，能移植现在的过去么？
• Seagate：估计要迁移也要做很多工作吧？可能理念都不一样了。
• Huoyu：新东西，一定要接受嘛
• Seagate：FluffOS

我看了一下，似乎从Mudos修改过来，有一些东西确实不错，至少能够支持64位系统这个对我们就很有意义，而且和Mudos 22兼容的，如果我们的和Mudos 22兼容应该移植不会有太大麻烦，而且架设在64位系统上数值20亿上限问题就自然解决了。可以弄个台式机安装一个64位系统比如Windows 2003之类试试就知道好坏了，或者Linux 都行。都有相应的64位发行版本。安装一个虚拟机就行。

• Jason：不支持并发，FluffOS的性能没有本质的提升。
• Huoyu：我这可以提供一个虚拟机给予测试
• Ddid：32位的系统上也可以run啊，有一个测试的lib可以试试 lpuni 不过是E文的。
• Seagate：32位系统有很多问题，如果能够迁移到64位系统服务器端效率能够提高很多，比如说Int型32系统是2^31，64位系统就变成2^63位，差了无数倍。应该还有很多好处，不过有的地方可能自己要注意注意，看看32-》64有没有问题，涉及比特等等有可能会有问题，这要测试才能发现。