背景:
阅读文章

关于动态mud的思考

[日期:2007-05-06] 来源:  作者: [字体: ]

如果把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.这个问题要修改起来真是太复杂了。呵呵,现在唯一的解决方法就是
严格管理好现有函数,做到名称不重复就行了:)这也不是长久之计。


尊重作者 转载请注明出处52mud.com

收藏 推荐 打印 | 录入:sbso | 阅读:
相关内容      
本文评论   [发表评论]   全部评论 (0)
内容推送
52mud提供
一起回忆泥巴游戏QQ群68186072
52mud官方微信公众平台
热门评论