Re: [闲聊] tmi2_v3_改 目前还缺什么?

楼主: laechan (挥泪斩马云)   2014-06-14 15:08:32
※ 引述《tenyfish (何时才有发言权?)》之铭言:
: 1. 开发此Mudlib_改的目的:
: L大有说过是希望能在现有的TMI2 MudLib做改良更新
: 目前看来,需要做修改的内容也非常的多,
: 也加入了许多一般Mudlib不一定有的新功能及概念,
: 所以它就以一个Mudlib的范本是否会有太"创新"的问题?
: 例:虚拟物件系统,wield,equip->wear等
: 毕竟没有在Sanc待过的人或许要花一些时间了解这些系统?
: 注:DS的Q&A里有提到,很多人都会问他可不可以把一些做好的系统给砍了
: 因为他们看不懂(汗)
: 小弟是认为可以先把它当然一个新的MUD看待,
: 逐步加入新系统并且实验之后,再Debug进入稳定版本。
tmi2_v3_改 有的东西,使用者可以不要用。
很多东西是基于 sanc 的经验,以虚拟物品系统为例,传统的
物品就是“实体的物件”,而虚拟物品则是以“资料串”替代
传统实体的物件来描述一件物品,事实上它们所占用的资料量
是差不多的,但是我们也知道,mud 大部份放在身上的物品
1.你平常根本不会去刻意看它
2.顶多按指令 i 的时候它会跟着其它许多物品一起显示
3.解任务的物品, 解完前物品有的得放在身上
4.绝大多数的物品都是为了 sell all 时卖掉赚钱
而这样的东西却得占用一个“物件空间”。sanc 最早认为这
会是“问题”的原因,是因为几乎每一个玩家都有一个叫做“
生命水晶”的不可丢弃物品,那么 200 个玩家同时在线,就
会产生 200 个物件,一般物件会占用的就是 objects() 函数
传回的那个东西,以现在的 sanc 为例
========== 程式执行区 ==========
sizeof(objects())=12760.
========== 程式执行区 ==========
虚拟物品系统存在的目的,就是想减少物件数的占用。
很多我为 tmi2_v3_改 加入的新东西,都是基于类似的出发点
,例如其中一个是“根据 sanc 的发展经验”,sanc 是based
on tmi2 mudlib 且已发展近 15 年的 mud,tmi2_v3_改 同样
也是 based on tmi2 mudlib,因此我会执著地认为,有些东西
与其等使用者日后才发现“啊..当初应该要这么做”,那还不
如我先把这些东西先写出来塞进 tmi2_v3_改 里头。
但是使用者不一定要用这些东西,而我也不认为使用者要无视
这些东西的存在是一件很困难的事。
至于 wield、equip -> wear,底下是 demo:
> wear sword <= sanc 惯用的
你装备上小短剑(short sword).
> remove sword <= sanc 惯用的
你卸下了小短剑(short sword).
> wield sword
你装备上小短剑(short sword).
> unwield sword
你卸下了小短剑(short sword).
> equip cloak
你装备上小披风(cloak).
> unequip cloak
你脱下了小披风(cloak).
相同的例子还有底下:
> chat *test <= sanc 惯用的
【闲聊】你笑道:‘测试一下东东。’
> chat* test <= 其它 mud 惯用的,tmi2_v3_改 也可以用
【闲聊】你笑道:‘测试一下东东。’
这就是 global aliases 的好用之处。
_wield.c、_unwield.c、_equip.c、_unequip.c 这四个指令就
占用四个物件空间(它们都是 inherit DAEMON),改成两个指令
就等于少掉两个占用空间,你可以想像 global aliases 所定义
的那些东西其实就具有“虚拟”的概念。
有一个现实面的问题就是“我无法预知‘谁’会拿 tmi2_v3_改
去用”,从而“先从他熟悉的 mud 的角度设想因此我应该要怎
么改 tmi2_v3_改”,这办不到。所以我才会发出“如果你觉得
tmi2_v3_改 不适合用来架你想架的 mud,那请不要用”的建议
然后,为了让使用者了解 tmi2_v3_改 是不是适合用来架自己想
架的 mud,我会实际拿它来架一个 mud,并欢迎有兴趣的人过来
接触看看。我会把 cd、more、ls 指令放在 /cmds/std 下就是
基于这个原因。
这个 mud 不会发展成像 sanc 那种规模的世界,我可以确定至
少它是有终点的而且不会花费太长的时间。它的存在意义就在于
demo 出以 tmi2_v3_改 所架构的世界就是长这样的具体意象。
: 2. Documentation
: 其实MudLib非常非常之多(如果考虑国外未中文化资源)
: DS Mudlib 的好处是它文件档及Help都还满完善的,
: 这对于开发者来说是一件很重要的事情,
: 毕竟每个Mudlib多少都有自己开发的Verb,
: 如果要能让开发者了解程式架构和想法,
: 除了范本,说明文件是十分重要的。
这部份是我最弱的地方,但我会尽量把 document 写完整一点。
我自己本身对 sanc 的相关 document 根本也没怎么看,而且我
也很懒,但即便如此,我最后还是大改了 sanc,所以我比较重视
这一块,“就算有人跟我一样懒,他还是可以拿 tmi2_v3_改 架
出 mud”,我想努力确保这种可能性。
我自己则证明了即便我没怎么看 tmi2 原生的一些 document 我
还是能介入核心的修改,并尽量将这些历程纪录起来于修改日志
里,就是希望让大家知道“我是怎么做到的”。
而且与其啃文件不如实际来问我比较快,比方在 mud 板或者是
mud_sanc 板发问,我有看到就会回,回文的同时就留下纪录了,
日后根据这些纪录写成的文件,至少也会比较易读易懂一点。
光是看我在 tmi2_v3_改 的修改上所写的一些文件,就可以了解
我写 document 并不是照着正规的做法在写的。
: 3. 部份网页接口
: 某方面来说,我觉得“重生的世界”有一些相当创新的系统
: 先不论其优缺点,我觉得能以网页即时提供某些资讯,
: 对于当代的游戏者是十分友善的。
: (就像我平常不可能在纯文字画面下处理Mysql数据库,连显示都要下参数)
我比较懒(前面说过了)。
tmi2_fluffos_v3 这一份打包档,有包含 www 的东西。
我知道它是干嘛的,sanc 的 nobu 也 demo 给我看过,但我很
懒得研究。
那假设我是把 mud 架在 win 的机子上,一般我的做法是
1.让该机子跑 IIS
2.把根目录指向 mud 里的某个目录
(若是架在 linux 更简单,架 apache 跑 php 跟 shell)
这样我就可以让 mud 周期性地产生一些东西,放在那个目录里
头,使用者再透过我写好的 asp 网页,去读取放在那个目录里
的结果,甚至还可做到一些 request/response 的应用。
这我以前在公司里就做过了,它确实是可行的。
那我会这么做就是因为我对 tmi2 所提供的 http 架构不熟,如
果我熟的话我直接用就好,因为我不熟,我才会用上述迂回的方
式。
我要强调的一点就是 tmi2 有提供 http 方面的应用。
但是不一定要用那个才能实现 www 与 mud 之间的连结。
: 4. 数据库(mysql等)连结
: 就DS的作者,他的说法是,有Driver理论上可行,但他不会。
: 如果可以,我想听听大大在这方面的想法。
呵我也不会。
: 上面没什么提及游戏内容,因为我觉每个人心目中的游戏都是不一样的。
: 就像DS说,如果你摸完觉得要改很多地方,你应该换一个MudLib。
: 所以就先以自己的概念出发吧!
没想到大家的想法都差不多XD
以我最近写的 simul intermud 为例,我是先写了,然后我想说去
搜一下相关资料,才发现原来人家早就提出类似的想法(不是做法)
1.一样是先找可信任的站当做 server 端
2.跟 server 端注册,并 follow 其协定
3.这样就能远端频道互连
更早之前,我也是先写了 sanc 现在在用的副本系统,之后才在大
陆的网站发现人家 2007 年就已经有在构思这样的东西了。
所以我宁愿趁现在还在修改的期间,就把一些我觉得有必要的系统
放进去,使用者就算不用也没关系,总比日后需要从头写一个新的
东西要好,或至少要从头写的时候,有东西可参考。
我最近就改写了 /std/user/autoload.c 下的两个函数,而我参考
的就是这两个函数原本的code。如果原本没有这两个函数我就得从
头写起,从头写也可以,会比较累及花时间。
: 最后是我个人的发问:
: 以现今的硬件设备,实体物件还是会造成设备太大的负担吗?
其实并不会。
我着重的是资料处理的方便性,实体物件固然所见即所得,要调用
也简单,但是依 sanc 的发展经验(jymud 也有类似历程)它有几个
缺点
1.总是会有遗失的困扰
2.发展到后期物件存在于各自的目录,造成管理困扰
3.写物件很烦人,对位阶越大干得越久的 adm/imm 越会如此
4.绝大部份的物件都只是“摆在那里”,平常根本没作用,但是就
因此占用了一个物件位置,越看越烦
所以才有虚拟化的构想。不然以现今的硬件架构来说,比方台中的
nova 随便组一台 6000~8000 的文书桌机,就胜过十年前所谓的顶
级 mud 专用机子的效能了,也不需要 kk 那种分布式系统架构,光
是应用 fluffos 提供的 port 分流,上面的机子拿来跑千人同时在
线也没问题,固定 ip 只要用像是 hinet 提供的光世代就够用了。
现在反而是“机子如果不架在学术网络,就要负担每月的电费、网
路费等费用”会比较困扰而已,我自己是已经先提拨 sanc 10 年份
的这些费用出来了。
LAechan

Links booklink

Contact Us: admin [ a t ] ucptt.com