※ 引述《tenyfish (何时才有发言权?)》之铭言： : 就我看了一下档案内容及说明文，几点回馈: : (以一个入门者的观点来讲) : 1. 说明档 : 十分详细，函数及变数都有标出来， : 我个人会建议，把"特别系统"的说明分成一个文件 : ->相关档案 : ->修改会影响的其他系统 : ->游戏内相关指令 : 而.h里面直接注解说明宣告(我发现你vobj.h有做了) : .o里面范例注解每个栏位 如果确定会写系统的说明文件，那麽 .h 档的注解就不会写得 太详细。一般会先写完系统才写说明文件，若在写系统的过程 中耗费太多时间在注解上，会影响系统的撰写。 注解一般是我写给自己以及 more 的人加减参考用的，因为如 果系统没有一气呵成完成，隔几天後我可能会忘记一些重要的 段落，注解的用意就是避免我忘记那些段落，或是我认为那是 很重要的段落这样，例如 vobjd.c 里面有一段.. void set_ob_data(string keyname,string tmp) { mixed tmps=explode(tmp,";"); int i,j=sizeof(tmps); string tmp2; mapping ob_data=([]),keydata=([]); // ({"名称","编号","单位","种类","叙述",价格,携带量,能否交易,能否贩售}) if(j>0) ob_data["name"]=tmps[0]; 标亮绿色那一段就是很容易忘记其顺序与代表的意义，才会注 解在那边。 至於 .o 档要注解....很困难，但我会在说明文件里面补上栏 位说明，并请使用者与系统档对照。 我也会在同一说明文件里面加上「系统的建立、使用及移除」 一项，说明建立系统的过程，以及哪些东西会使用到这个系统 ，以及怎麽使它无效化。但以 chinesed.c 来说其实我就不可 能建议使用者「移除」它，因为太多东西都跟 chinesed.c 有 关，在这情况下在「建立」与「使用」上我会讲得比较详细， 而这其实就是建议使用者「顶多修改它就好而不要移除它」， 「如果真的要移除它，那乾脆连 tmi2_v3_改 也一起移除」。 : 2. 关於LPC入门者 : 以DS的方法是，他Q&A建议你以非wiz身份完成一些范例任务 : 并在中间观察相对应档案的内容，了解room的设定 : 然後自己设计自己的一个区域和任务，它的文件有一些lpc教学 : 像是ob->的用法之类的 Spock@FF 以前有写了一系列的 LPC 使用教学，写那些是很累 的，而且看完後能不能懂、懂了是否就因此会了，都是因人而 异。 LPC 教学也不是 tmi2_v3_改 应该包含的东西，从「改」这个 字就可以知道，如果说 tmi2_v3 原生就有 LPC 教学相关，那 麽 tmi2_v3_改 就会有，反之，tmi2_v3 本来就没有这东西的 话，tmi2_v3_改 要有就得花时间新增。 我也不建议完全没 LPC 基础的人架 tmi2_v3_改，那太花时间 ，而且违背我释出 tmi2_v3_改 的本意─我不希望拿它架站的 人必须花很多时间才能架出一个站。对於一个完全没基础的人 来说，tmi2_v3_改 跟 tmi2_v3 事实上是一样的东西。 所以我还是比较建议有 LPC 底子并实际当过 wiz 的人，才较 适合使用 tmi2_v3_改 来架站。花时间写 LPC 教学文件是 ok 的，但以重要性及优先度来说它并非我现阶段的优先选项，而 且我以前也写过，根据我自己对自身的了解，我常常写到一半 就突然不写了。(那真的很烦..) : 3. 关於一些较常见的系统 : 可以以"参见XXX mud 某系统使用" : 例:一开始先建议使用者体验Sanc并且使用哪些功能 : 毕竟说明文件是开发工作上很花心力的部份 我之所以没说出「如果对当 wiz 有兴趣，sanc 也欢迎大家来 当 wiz」这样的话，是因为有前车之监，我曾收过一个 wiz， 结果他一来就自己四处 more 导致「不该看的也看了」，然後 就产生误解，例如他看了某个房间: #include "mudlib.h" inherit ROOM; . . 根据 #include 规则当使用 " " 时，它会先找物件所在目录 下有没有 "mudlib.h"，没有的话才去 /include 目录下找， 所以这房间是可 update 的，但是它的 #include 写法是错误 的，对一个来之後想自己 more 的 wiz 来说就会令他产生误 解，认为房间就是要 #include "mudlib.h"。或是: void init() { add_action("push_xxx","push"); } int push_xxx(string str) { if(!str || str=="") { write("你要 push 什麽?\n"); return 1; } 正确应该是要 return notify_fail("你要 push 什麽?\n"); 诸如此类的东西非常多。 sanc 存在太久规模也太大了，导致 sanc 并没有真正适合新 手 wiz 的教学环境(最大的原因是因为我自己很懒)。 但是 tmi2_v3_改 就不一样了，如果我以後用 tmi2_v3_改 架 站的话，我就欢迎完全没基础的人来当 wiz，因为我不必担心 他四处 more 会看错什麽、误会什麽，所有的 code 也都会公 开，并欢迎已架站的人引用。 : 4. 以我自己开发的需求来说，这版有map或wizmap的功能吗 如果是指指令 map 的话，tmi2_v3_改 有塞一个我在 2001 年 写的 /cmds/std/_gps.c 指令: > map <= 透过 global_aliases 的设定 map = gps $* GPS 卫星定位系统 目前所在位置: [水池广场] ｜ 口─口 ｜ 口─口 ｜ 口 口 口 ｜ ｜ ｜ 口─⊕─口─口─口─口─口 ｜ ｜ ｜ 口 口 口 ｜ 口 ｜ 口─口 ｜ 只要是超过 10 年的东西，很容易看到一个「特色」就是我很 少用宣告 mapping 的方式去储存资料，而多半是把 mapping 资料 "set" 到物件本身，例如: if(mark==1) set("pos/"+x+"#"+y+"#",HIC"⊕"NOR); else if(mark!=1 && env_name==base_name(home_env)) { set("pos/"+x+"#"+y+"#",HIC"⊕"NOR); return 1; } else if(query("pos/"+x+"#"+y+"#")) set("pos/"+x+"#"+y+"#",HIC"口"NOR); 所以 /cmds/std/_gps.c 基本上也算是会造成误解的存在，但 因为我在改 tmi2_v3 的过程中需要它，所以才暂时放上去。 (所以那个档才没有 // laechan@sanc ... for tmi2_v3_改， 相同的情况还有 /cmds/std/_note.c，都是很早以前写的，但 note 在 2005 有经过改版，情况就比 gps 好一点) 如果要重写一个新的...老实说我看过别的 mud 也有这东西， 它们指令的执行结果，比我写的好多了，因为我没受过程式的 正规训练，有受过正规训练的人对「递回」的使用会更得心应 手，没受过训练如我「反正写出来能用就好了管它那麽多」。 (包括 findmob 也是，justinj@sanc 写的也比我写的好) 不过如果你就是指 map 这个指令的话，我可以花点时间重写 一个新的，但有一点必须说明的是，map 的最大弱点就是无法 正确显示「exits 设定为传统迷宫类型的区域」，例如: 往002←001-002→往001 回圈式出口设计 所以实际上 tmi2_v3_改 的 map 是与其它 mud 不同的，它是 一种新的 map，在目前的 sanc 也已实装，底下是 demo: http://imgur.com/QBaTwVG.jpg 这个才是我理想中的 map，也是 tmi2_v3_改 会内建的东西， 但即便如此它还是有包含传统的显示方式，这个 _gps.c 指令 里面就有: if(!map_d) if(catch(map_d=find_object_or_load("/adm/daemons/map_d"))); if(map_d) if(tmps=map_d->get_path_and_num(base_name(home_env))) { map_d->show_maps(tmps[0],tmps[1]); return 1; } map_d 就是用来管理类似上面那种地图的，如果所在位置符合 map_d 所管理的那种新型态区域，它就做 show_maps 的动作， 不符合时就显示传统的 map 型式。 现阶段 tmi2_v3_改 是没有 /adm/daemons/map_d.c 的因为还 没实装到那里。 LAechan --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.26.184.223 ※ 文章网址: http://webptt.com/cn.aspx?n=bbs/mud/M.1402793807.A.E41.html 那 4 指的是就是上面说的 map 吗? 对於 LPC 学习的部份我举 annihilator 大大以前曾提过的事情， 他以前曾提到他在写 es2 mudlib 时，曾考虑要拿掉 set, query, add, delete 等等「没效率」的做法，这跟我曾举例的「为什麽我 有时不选择走高速公路，而选择走快速道路」的例子类似。 因为有诸多考量。 考量之一就是监於当时的 wiz 大多熟悉 set/query/add/delete的 方式，而且是已经很熟悉了，考量到这些人希望他们可以比较容易 入门 es2 mudlib，所以 annihilator 才保留了这些呼叫方式。 那所谓 LPC 的入门学习，究竟是要从「写物件开始」还是「从正 规的程式语法开始学起」？这没有定论。从前者学起就是会看到一 堆 create()、init()、set、add_action、....，我自己就是从这 些开始学起，却导致不爱看说明文件的我花费了异常多的时间才开 始用到 mapping、mixed 等变数，以及 sscanf、member_array 等 函数，而在我使用到这些变数之前我已经写了超多的物件，造成了 超多难以挽回的情况。 那从正规的程式语法学起呢？那也不适合我，因为我既不爱看说明 文件，也没有受过正规的程式语言训练，但是从正规学起有个好处 ，就是有程式概念的人写出来的物件，会比较具逻辑性，运作效率 也较好，底下的差异就是例子 set("exits/north",__DIR__+"002"); set("exits/south",__DIR__+"003"); vs set("exits",([ "north":__DIR__+"002", "south":__DIR__+"003", ])); (後者的执行效率较好) 所以其实我也不想(也不能)建议一个初学者应该从什麽角度进入到 LPC 的世界，根据历史经验，通常是会建议从写物件开始，就如同 你上面也提过的(大家的想法其实差不多)，建议使用者一边观察程 式的执行结果，一边 more 与物件内的程式段落对照，这也是我一 开始的学习方式，它的效果很好，而且也容易参考仿照。 但是它对於「学习 LPC」帮助不大，除非是像西域奇人番僧一样， 一直修练外功的他居然可以另辟蹊径，由外而内，内功居然也因此 练到异常强的境界，但是这种人是很少的，至少我没看过光是只写 区域、怪物、武防等物件，就能写到能改 mudlib 的人。 http://webptt.com/cn.aspx?n=bbs/JinYong/M.1381937085.A.630.html 至於玩家体验，也就是 demo 的部份，则确定是会有的。我的想法 比较简单，就是实际拿 tmi2_v3_改 架一个 mud，再开放 cd、ls 、more 等指令给「一般玩家」，然後做出足具示范性质的区域， 则有兴趣的玩家自然就可藉着 more 与实际执行後的结果，了解一 些基本的东西它是怎麽 work 的，关键在於一些细节的做法。 (以前好像也有人架过类似的，好像叫大神小站) 而现阶段则是透过逐步释出的方式，让有程式底子、也有兴趣的人 可以先看看里面有什麽新东西。 总之还是要谢谢你，这类的反馈对 tmi2_v3_改 的释出非常重要， 这也是我一直强调的，我很需要反馈的意见的原因。 大家的想法都差不多。 ※ 编辑: laechan (114.26.184.223), 06/15/2014 10:40:52 可以先看一下 mud 目录内的修改日志.txt，先参考最初修改的 前三天左右大概改了什麽。我一般没必要不会删除 tmi2 原本有 的东西，用新的东西覆盖时也多半都会於修改日志里注明。 因为这是 tmi2_v3_改，不是完全我原创的，我也打算在释出时 使用含有 "tmi2_v3" 的名称，但是在释出前我一定会尽量把这 个版本用不到的东西，都集中到一个目录内分类存放，让使用者 在主要目录尽可能不会看到过时的、没必要存在的东西。 (至於拿到释出版本的使用者要怎麽做，我就不干涉了) ※ 编辑: laechan (1.165.194.160), 06/15/2014 22:58:58