关于动态mud的思考

[Odysseus]

关于动态mud的思考

作者:Super　　发表时间:2001年8月29日 19:14
--------------------------------------------------------------------------------

如果把MUDOS看成是一个进程的话，那么我们写的那些守护进程都可以算是多线程了。

偶也谈谈心里面的一些想法吧，我看了MUD-BUILDER里面的一些关于动态MUD的文章，
觉得那种形式的MUD才是理想的MUD，也就是说，一个MUD创建出来以后，会由玩家来
操作和修改这个MUD，也就是说，刚开站时候的LIB跟玩过一段时间以后的LIB完全不
一样了，现在MUD里面在这方面唯一成功的就是留言版，里面总是新内容，所以有些
玩家是专门到MUD里面来看留言的。

现在的大部分玩家为什么都说MUD没有意思呢？因为他们付出了相当大的努力以后也
无法改变他们的环境，这样的话，就很难给他们成就感，没有成就感就没有动力继续
玩下去了，试想一下，如果一个玩家一个月没上线的话，上来一看，发现周围的一切
都变了样了，以前的XX派被灭了，然后又产生了好多XXX派。

作为MUD，应该让玩家最大限度的来改变他周围的环境来给他足够的成就感，我记得看
过一篇E文文章，介绍游戏的可玩性的，里面说影响游戏最大的因素就是要让玩家感
到满足，无论是哪个方面的，我们的MUD既然定位在给大家创造一个交流的环境，那么
最主要的就要让玩家在这个多人的环境中，真正的实现梦想中的自我。

关于这些方面的实现呢，我认为关键是要建立好一个对动态物件的save & restore
方案，在什么情况下保存，怎么保存，保存成什么格式，这些都是重点问题。再其次
就是关于对玩家离线的解决方案，假如一个玩家拿了一个什么什么宝物，如果离线的话
我们岂不是永远都拿不到了。所以要对离线的玩家做一定的处理，或者用玩家自己写
TRIGGER的形式，或者用AI来实现玩家离线。这些都是要考虑的。最关键的问题是
要对整个MUD里面的所有物件有一个统一的管理机制，比方说吧，现在的MUD，有些
物品不保存，有些保存，所以就造成了玩家身上的某些可以保存的物品（money)越来
越多，这样是不太好的。
mud-builder.com上面有一些这些方面的文章，然后水木mud_builder版的精华区也
有相关文章，有兴趣的朋友可以去看看。



作者:jackyboy　　发表时间:2001年8月30日 12:10
--------------------------------------------------------------------------------

恩super的话挺在理。
对动态物件的存储真的很重要。
游戏里很多的实体（可能是程序，可能是一些组织帮派什么的，也可能是一个物品）都应该
有一整套的产生，运行，销毁的方案。由一类物品衍生出另一批物品，就象人，有70年代的
，有80年代的，虽然都是人，可是各个年代有各个年代的人。
这样MUD就有了历史了。对历史的记录也是个需要做的工作。
游戏的场景也不应该是一成不变的。
当然这好象难度不小，要考虑的东西比较多。不过人也是由程序生成的呀（DNA看起来不就
相当于是一个程序？：））


作者:Super　　发表时间:2001年9月1日 20:25
--------------------------------------------------------------------------------

：：动态MUD的物件：：
由于做成动态MUD的话，里面的物件的创建也必须遵循一定的规则。
比如说，一个包子由面粉和肉做成。一栋房子里面有冰箱就可以保存食物。
这些东西的实现，我认为使用LPC的inherit最好不过了，我们可以利用inherit
来自由组合，创造出很多新的东西，比如说，我们做了一个钱包（pocket.c)
里面有装钱的一些函数，当你买了一个钱包以后，实际上我们的character就继承
了pocket.c这个文件，让我们的角色可以使用钱包里面的一些函数。

另外在我的单机上，我的user.c里面实际上是一个继承了好多东西的一个物件。
首先继承了hand.c(手),里面有get(),drop(),hit()等函数，然后继承了
foot.c(脚)里面有kick.c,go()等函数，然后在制作user.c的时候，如果要做
一个没有手的残疾人，就十分方便了，只要继承脚，不要继承手就行了。

如果所有的物件都以这种形式存在的话，就可以取缔目前的cmd系统，完全由各种
各样的子继承来实现不同的函数，这样的话，编写新的东西也十分方便了。


作者:jackyboy　　发表时间:2001年9月1日 20:44
--------------------------------------------------------------------------------

这也就是个度和方式的问题吧。

以前是按一个人身上的功能类别来归为 管名字的，管状态的，管伤害的，管移动的。。。
这时候归类出来的有的是几类物品所具有的一些共性的，比如name和move

按super那样说也不错。蛮有意思的。可是具体实施起来是否就光有SUPER看到的好处了呢？
是不是会在某些方面带来一些麻烦呢？


作者:Super　　发表时间:2001年9月1日 21:08
--------------------------------------------------------------------------------

呵呵，麻烦是大大的有的。
首先对编写人的思维严谨性是个大的考验。

其次是对继承权限的管理，要管理得十分的严格，要不然的话，到时候产生一些
猪头人身的东西也不奇怪的。

而且代码也会不太好读了。。。
因为做到这个份上，很多可以看得到的东西都是由很多小东西组成的了。

还有一个冲突的问题，就是继承的函数的冲突，这个是个相当重要的问题。
物件细节化了，就难免会会发生一些函数冲突的问题，比如说吧，你的手(hand.c)
提供了get()函数，但是有一种手套，也提供了get()函数，这样的话，就必须
在MUDOS层对inherit做一定的修改，使其拥有选择的功能，或者是可以做成分级
管理的inherit.这个问题要修改起来真是太复杂了。呵呵，现在唯一的解决方法就是
严格管理好现有函数，做到名称不重复就行了:)这也不是长久之计。

以上转引自www.niub.net论坛