go.c功能实现的几点思考设置(zz)

vast

作者:waiwai 更新日期:2004-02-16 类别:MUD文档->系统开发 总浏览/今日:20/1
1.巫师房间禁止
老系统是写在房间的valid_leave中做判断，似乎比较罗嗦和烦琐。。。
比如系统公告室进入巫师会议厅，以前是在系统公告室中的valid_leave
中写，但如果在巫师会议厅set("wiz_only",1)，然后在go.c里面写：
if( obj ->query("wiz_only") && !wizardp(me))
return notify_fail(HIB"突然一个蓝色的精灵出现在眼前说道：“此方向通往天界福地，凡人不得入内。”n"NOR);
这样似乎更简洁方便些，只需要在需要禁止的房间set一个参数即可。

2.巫师留言板的禁止
老系统习惯在房间内写block_cmd()，可能是习惯，总要把设置写在
房间里面，每个房间都加一些类似的重复代码，有必要吗？
这个问题，可以也set一个参数，比如：set("wiz_board",1)
然后在系统留言板总控文件内的read和post处判断不是巫师就不能在
这个房间内的留言板留言，也不能阅读不就行了。

3.item_desc的问题(属于look.c范围)
比如系统公告室以前是这么设置的：
set("item_desc" , ([
"east": "房子里云雾缭绕，什么也看不清楚。n",
]));

也就是在系统公告室看巫师会议厅是：房子里云雾缭绕，什么也看不清楚。

这个问题如果修改look.c可以更简便些，比如look.c中的look_room_item()里：

if( env->query("no_look_room") || env->query("fangbian_room") ) {

msg = env->query("no_look_room");

// 在这里做总比在每个ROOM做来得好
if( wizhood(me) != "(admin)" ) {
                if (stringp(msg)) {
                        write(msg);
                        return 1;
                } else
return notify_fail(WHT"那里云雾缭绕，什么也看不清楚。n"NOR);
} else {

if(env->query("fangbian_room") )
return notify_fail(WHT"那里是茅厕，你有偷窥狂吗？n"NOR);
else
return look_room(me, env);
}

} else {
...............
...............

只要在巫师会议厅set("no_look_room",1)就可以默认实现原先的look east的描述。
以上设置默认为厕所的房间也自然实现了，不必在room里面再写多余的东西了。
如果某个房间在其他房间看这里不能看，还可以自己写有特色的描述，比如：
set("no_look_room","看啥啊，大傻蛋！n")
只要这样就简单的在要实现功能的房间内实现自己的功能了，而不是一个房间的功能
要牵扯上几个房间。。。


4.特殊房间，比如厕所
if( obj ->query("fangbian_room") && !wizardp(me)) {
inv_me=all_inventory(obj);
sizeinv=sizeof(inv_me);
while (sizeinv--) {
if (inv_me[sizeinv]->is_character() && inv_me[sizeinv]->query_temp("marks/sit") ) {
if(inv_me[sizeinv]->query("gender") == "男性" && me->query("gender") == "女性")
    return notify_fail(HIG"里面有男人在如厕呢，你个女人进去不太好吧？n"NOR);

if(inv_me[sizeinv]->query("gender") == "女性" && me->query("gender") == "男性")
      return notify_fail(HIG"里面有女人在如厕呢，你个大男人进去不太好吧？n"NOR);
}
}
}
这样，即使系统中有100个厕所，也没必要在每个与厕所相通的room里面写判断了。

5.背人及跟随的问题
有很多地方禁止不到一定参数的玩家进入，但如果设置不严，背人进去也就简单的进去了，那么
系统设置就形同虚设了，而在每个房间内写也是很罗嗦的，简单的直接在go.c里面就实现得了。
另外follow.c后不能进入的房间，一个级别低的玩家follow一个高的也会自动进入了。。。

// 跟随参数很多弊病，所以某些房间禁止跟随进入，在这里先行阻止掉
// 背人的问题也是问题很多，所以最好此类房间内设置limit_leader
// 不能跟随也不能背人进入。。。
if( obj ->query("vip_room")
|| obj ->is_player_home()
|| obj ->query("limit_leader")
|| obj ->query("fangbian_room") ) {

if( me->query_leader() && userp(me) )
  return notify_fail(CYN"那里不能跟随别人进入！n"NOR);

if ( present("corpse", me) )
return notify_fail(HIG"背着个尸体你还能过去？n"NOR);

inv_me=all_inventory(me);
sizeinv=sizeof(inv_me);

while (sizeinv--) {
      if (inv_me[sizeinv]->is_character())   
      return notify_fail(HIG"背着别人过去？省省吧！n"NOR);
}

}

所以背人和跟随应该一同禁止，才是最可靠的。

6.坐骑的问题
if( ridee && !wizardp(me) && userp(me) ) {
if( obj ->query("sleep_room") )
return notify_fail(HIG"你不能骑着坐骑进入睡房。n"NOR);

if( obj ->query("no_ridee") )
return notify_fail(HIG"你不能骑着坐骑进入那里。n"NOR);

}

这样就首先实现了至少睡房不能进入，其次no_ridee的房间不能进入。
曾经是一个小破房间，没站几个人，里面10多匹马，我不知道，那是人睡的地方，还是马圈。

7.坐骑状态及轻功问题
坐骑bug一直是历史悠久的问题了，我想玩家如果在一个地方可以用各种花样把轻功加的很高
那么除非他一辈子都骑着马，别下来走路，这个问题，首先应该在mount.c里面在玩家骑上坐
骑之前，把玩家身上的坐骑轻功参数清0一次，然后再在go.c里面做个判断清除：
if( userp(me) && !ridee && me->query_temp("ride/dodge")>0 ) {
    me->add_temp("apply/dodge",-me->query_temp("ride/dodge"));
    me->set_temp("ride/dodge",0);
if( me->query_temp("ridee"))
me->delete_temp("ridee");
}

在go.c里面这样加个判断，至少还可以避免很多room里面是move形式后的轻功问题及坐骑状态。
比如经典的南海之滨的swim，还有高老庄的climb等。。。以及写的很差劲的drive的地方，老
系统的gobed的地方。。。

8.最简单的关门设置
if( userp(me) && wizhood(me) != "(admin)" ) {
        if( obj->query("day_shop")
        && ( day_event() == "event_night" || day_event() == "event_midnight"))
        return notify_fail(GRN+obj->query("short")+NOR GRN" 晚上关门了，你还是等天亮再来吧！n"NOR);
          }
这是最简单的关门设置，day_shop的意思当然是白天营业的店铺，还需要在look.c里面加相应的
判断，以实现此时look店铺方向是关门了的某某描述等。。。
但这个设置有一个小问题，比如你白天进去了，这个店铺里面还有个房间，如果你在里面那个房
间，而现在刚好天黑了，你也就不能通过店铺出来了，所以这里还需要相应改一下，这只是个例子。



所以，其实很多东西的实现，应该从源头去设置才是最好的，避免了去找很多room，里面写了很多
东西而结果并不理想，维护的时候也乱糟糟的。。。

notme

这个思路是很好的
我前段时间还想对吃喝方面加点丰富的描述
就是对食物设个eat_msg之类的
现在的食物都是拿起某某咬了几口,看起来没食欲

vast

食物的改动会不会比较麻烦？
现在好像大多数食物都是直接add_action,加上了一个eat动作

roserain

这样也许在感觉上是方便了
但是会增加服务器的负载吧
命令是用得最多的东西
房间却不是，如果在房间里面加个性化东西，虽然麻烦但是只有触发了才会判断
而在命令里加每次执行都会判断一轮，多余的消耗不言而喻

religiose

现在有些地方靠背人还是能进去的吧!~:mad:

jason

爱思考的好巫师，呵呵。
不过你的思路基本都是错误的。
look,go等命令是全局性的。写look的时候不可能知道今天有茅厕。今天你加入了对茅厕的判断，将来又出现了露天温泉怎么办？或者有美女在河里洗澡又怎么办？
其实现在的全局性代码中已经有了很多这样不好的代码，通用代码特例化。

不过，目前大多数mudlib的思路是由房间的add_action去屏蔽look。这就出现了你说的弊端，重复代码太多。
解决这个问题有两个思路，一个是让这些房间的重复代码写到/inherit里去，然后大家inherit.

另一个思路，以look为例，在look的时候调用被look对象的on_look_me()函数，由被look对象来决定返回给玩家什么信息。on_look_me的函数可以定义在 ITEM甚至更基本的基类里，每个物件都可以实现他。这是通常使用的软件设计思路：影响到谁就由谁来决定。

同理，能不能进入一个房间不该由当前房间的valid_leave决定，而应该由目的房间的valid_enter决定。这样物件之间的依赖性才能降低到最小。不过这是es2的架构问题，现在也不可能去改了。呵呵

whuan

jason是大牛

从本篇帖子我获得了一些思考，并且在go.c里面实现了房间的最大人数限制。

huoyu

  楼上的，你回了一张2年前的帖子。。。挖坟啊？？？

jason

在本版，这是很新的帖子了，哈哈哈。
其实我当初做mud的时候没觉得mudlib有什么不好，还学到了很多东西。
不过这么多年软件做下来，发现问题真的不少。

huoyu

那你搞个新的框架好了。。。mud实在是老啊。。。