首先我们应该知道mudos提供哪些服务
我们可以从许多lib中找到我们需要什么
假设我们的lib还是拥有很多现在mud的特性 比如战斗 人物和世界
我们需要一些最基本的东西
比如 master.c user.c login.c <include>
你完全可以使用不一样的文件名 甚至修改出自己的mudos
你也可以完全使用一个成熟的lib来修改 不过这里要讨论的不是这些。
我们需要一个指令目录 一个系统配置文件的目录 一个数据保存的目录 一个帮助文档的目录 一个安全系统 一个角色系统 一个战斗系统(如果你是战斗类的 根本不需要这个)
一个网络服务提供系统(这个一定需要吗？可以不需要) 一个核心守护 一个时间系统(如果你的mud只有简单的时间概念 也根本不需要这个) 一个处理文字的系统
我们可以找出很多lib都有的通性 这些文件可以这样描述：
// Daemons
// maintains information on legitimate character creation
#define CHAR_D "/secure/daemons/chard"
// support to chinese character
#define CHINESE_D "/secure/daemons/chinesed"
// handles fighting events
#define COMBAT_D "/secure/daemons/combatd"
// handling core daemon state
#define CORE_D "/secure/daemons/cored"
// handles the loading and rehashing of verbs
#define COMMAND_D "/secure/daemons/cmd_d"
// handles domain state and build rooms
#define DOMAINS_D "/secure/daemons/domains_d"
// emote daemon
#define EMOTE_D "/secure/daemons/emoted"
// the management daemon a user connects to before determining their real body
#define LOGIN_D "/secure/daemons/logind"
// handles mud's Quests
#define QUEST_D "/secure/daemons/questd"
// handles security of Lpmud
#define SECURITY_D "/secure/daemons/securityd"
// handles intermud services
#define SERVICES_D "/secure/daemons/servicesd"
// management daemon of time/disasters/scenario
#define TIME_D "/secure/daemons/timed"
// handles update events
#define UPDATE_D "/secure/daemons/updated"
// virtual daemon
#define VIRTUAL_D "/secure/daemons/virtuald"
// handling vote security
#define VOTE_D "/secure/daemons/voted"
构架lib 最先要考虑的不是针对一个游戏 而是一个游戏支持所必需的内容 连接 服务 和表现 而我觉得 可扩展性 在经历这么多年以后 对于Mud而言 已经日益重要
1.指令
是玩家接触mud world的直接界面 没有好的指令 就算这个角色不是blind 也会感到看不到东西的感觉 所以最基本的指令 是look say quit who 等等 注意say代表的是交流的意思 而不是现在mud的含义-"说"
2.数据保存
正式开启mud world的时候必须考虑的问题 你可以使用传统的文件保存方式 也可以采用msql/mysql数据库方式 要注意的是 不要以为传统的方式是一个无效的或者无能的方式
不过利用高效的mysql方式 还是比较好的 这里的数据 不要单纯的认为是玩家本体的数据 一个mud不单单只有这些数据 更多的数据可能出现 比如地图(rooms) 动作(emotes) 物件((objects) 技能(skills)
3.安全系统
传统的es安全模式借助于uid系统，这是快10年的系统了。而每个LPC Library都可能会有自己的系统。注意一个mud往往有三部分构成 分的比较明白的就是mudos 还有两部分是 LPMud 和 LPC Library 的说法。比如常说的 ES TIM-II NIGHTMARE 都是LPC LIbrary
而ES3 就是 ES LPMud，比如fy3这个LPmud 使用的ES lib library。安全的做法很多 而且没有一种是绝对安全的 毕竟这个mud系统先基于unxi更基于internet。但是目的只有两个：安全和使用性。安全是指能保证原创者的利益，使用性是指能发挥使用这个LPC lib的人的自主性，不要单单认为是设计者或者是大家说的巫师(wizard)。
4.角色系统
如果你的lpmud不需要角色，那么这个可能对于你是无足轻重的。如果你要求体现完美的人物特性，那么复杂而不冗余的系统是需要的。一般角色所要表现的东西都应该考虑一下。传统需要的是 表现 生命 动作和交流。
5. 战斗系统
首先 确定你的lpmud是否需要战斗 这里的战斗是指比较复杂的战斗 包括西方的魔法和东方的战斗 都是战斗。战斗系统的表现方式有很多种 需要提醒的是 心跳并不是唯一处理战斗的方式。就好像现在很多游戏都使用既时系统 但是还有很多的游戏在采用回合或者半回合的方式。ES的lib比较东方化 但是带有明显的西方mud的特性 就是心跳来处理普通技 而传统武侠是没有skill perform的区分的。记住，没有心跳一样可以战斗。战斗要处理的事情就是 怎么决定出手(心跳是AI处理的一种途径) 怎么决定结果（伤害 回避等等） 怎么决定仇杀等等 表现方式(描述)
6 网络服务系统
更多的服务被包含到intermud3中，mudos显得更像是一个server服务提供者，最多可以达到4-5个端口，可以用来提供包括http/mail/ftp/finger/telnet/等等服务 其实我们可能根本不需要这么多 一个最基本的telnet或者ftp用来处理一些文件服务 一个简单的UDP交流可以用来保持相关mud之间简单交流。另外 文件自动更新功能 数据统一风格 分站区域互连和漫游也在考虑的范围之内
7.时间系统
一个时间系统，用来保持整个Mud的发展，天气/灾难/故事的发生都可以归纳到这一类。良好的时间系统可以用来纪录mud world的历史，这方面参考国外的mud可以收益良多。好的系统已经出现了时间 天气 季节 区域 灾难等等的结合。东方太阳西方雨。
一些基本的设置用来维持一个LPC lib，而作一个LPMud，还需要更多的变化和环境。不仅仅是一个LPC lib。就好像一个linux系统 单单只有内核是不行的。
我的概念中有三部分的东西
作者:darks 发表时间:2001年6月9日 09:19
--------------------------------------------------------------------------------
Mudos是LPmud的driver 他提供最基本的一些函数和事件 以便设计者可以利用这些函数构架出一个LPmud 而LPmud中有一部分称为LPC library，比如ES lib,Lima lib等等，Library拥有一些基本的系统，包括connect的处理和character的处理等等，最基本的一种lib就是随mudos发布所带的Lil，这个lib可以称做lib的典范，没有任何地图，只有一个void，这个lib不能用来游戏，根本不能常规的称之为LPmud，但是这确实是一个lib，该有的都有了。Library的特点就是共同性，不管这个游戏是什么，这个Lib都不需要怎么改动。比如基本的dbase treemap继承什么的 都是属于ES lib的范围，但是一些技能，一些任务系统(至少我以前看到的都是属于整个LPmud范畴)都是LPmud范围的。fy3的task系统，在有坐标的mud中已经可以看作是一个lib范围的设计了。因为程序和数据已经分开，不需要修改系统就可以变化出新的内容。我现在不太清楚国内的mud对任务系统是不是已经分化出来了。但是挺多的任务在我的影响中和地图、人物(LPMud本身)是分不开的。这些任务只能说是整个LPMUD的一部分，用Nightmare的话来说，就是：这部分属于 This LPMud，但是不是 This LPC Library的一部分，使用这部分代码许可权归This LPmud的管理者，而不需要通过LPC library设计者的许可。 也就是说，将一个Mud的使用或者改写许可分为两部分，只要拥有Lib的使用许可，你都可以使用，所以你可以使用ES lib来架设任何自己设计的Mud，因为这个lib是被Annihilator许可的。但是你不可以随便拿个Mud的架，因为还有很多内容不是ES lib的范畴，而属于那些Mud的管理者。
简单的来说，就是MUD是一个整体，是一个独特的个体。而Mud library可以是一个基础，可以在lib基础上，制作出很多类似的Mud。
如果当你的设计Mud Library的时候，加入了共性的任务结构，也就是说，可以应用于符合规则设计出来的世界。那么不管世界如何改变，这个系统都会被适用。这才能说是，这个Lib的任务系统。由于事件的共性化非常复杂，所以没有一开始就提出来，但是我倒是很希望能归入lib中，这样子，基于这个lib开发的LPmud，将具备极佳的任务扩展性。
--------------------------------------------------------------------------------
两袖清风
MUD本身就是在模拟一个相当复杂的世界，要想把他们都归纳出一个包罗万象的共性出来，可能吗？或者说容易吗？
作者:jackyboy 发表时间:2001年6月9日 22:14
--------------------------------------------------------------------------------
darks认为我们的目标应该放在哪一部分上？
是lpc library？还是driver?
对于一个MUD，我们关注的是外在表现多于内在的实现方式，是么？
由一个系统的外在我们怎么去归纳出来这个作为基础的MUD LIBRARY呢？
到底目标是哪个？我觉得有好多概念性的东西如果不说得够通俗易懂的话，怕少有人能明了一个提案的意图，乃至最终加入进来。这方面的解释我想一来也可以让自己更加肯定什么是最需要去做的，二来也可以让更多的人明白和加入。应该多做做这个事。：）
说实话，有时候我看了发出来的帖子不知道是有所获还是无所获，即使有所获也是有点混沌似的。：）
--------------------------------------------------------------------------------
JackyBoy
关注的是外在的表现
作者:darks 发表时间:2001年6月11日 09:14
--------------------------------------------------------------------------------
但是外在的表现的扩展性需要有好的lib支持，比如，使用了数据库和不使用数据库的lib，他所能表现的东西差不多，但是扩展性差了很多。比如拥有fy的task系统，修改这个任务系统就非常方便，也很容易扩展，但是不是这种的，就比较困难。driver我不认为非得修改，因为专门有人在为这个工作。driver有时候是和mudlib不可分的，因为一个lib的撰写总是和一个特定编译出来的driver联系在一起。由于driver的特殊性，我觉得发布的时候，不应该包含driver。而mudlib显然和这个不同。
简单的来说，我们关注外在表现，但是这个只有在一个共同的底层lib上才能发挥出来。或者是基于ES或者基于Lima或者其他。。。而基于ES lib的Mud，国内已经开发的很多了。这个lib基本上已经被开发的差不多了。如果再想求突破，比较困难。就好像现在的很多游戏都是用Quake3引擎，当然游戏本身和Quake3完全不一样。但是如果Quake3引擎没有突破，那么整个游戏，也就看上去是那样子的。:)
Blizzard的优点在于将成熟技术的潜力发挥到极点，他的游戏技术不是最前卫的，但是确实最成熟的。基于成熟的技术，可以将游戏的可玩性发挥及至而无技术后患。目前的国内基于ES的Mud就是类似这种情况。但是现在Blizzard本身也很难突破starcraft了，所以他们开始使用3D，使用这个以前不成熟，但是现在已经完全成熟的技术。我想，我们也该这么做了吧。比如简单的说，数据库的使用，就应该被拿出来，别担心现在的环境，mysql已经大行其道，而等你开发完成，估计早已经是非常成熟的环境了。
开发一个东西，应该将效果定在周期以后的环境，我是这么认为的。
尊重作者 转载请注明出处52mud.com
