Re: [閒聊] tmi2_v3_改 目前還缺什麼？
※ 引述《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://www.ptt.cc/bbs/mud/M.1402793807.A.E41.html
推
06/15 10:06, , 1F
06/15 10:06, 1F
推
06/15 10:12, , 2F
06/15 10:12, 2F
那 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://www.ptt.cc/bbs/JinYong/M.1381937085.A.630.html
至於玩家體驗，也就是 demo 的部份，則確定是會有的。我的想法
比較簡單，就是實際拿 tmi2_v3_改 架一個 mud，再開放 cd、ls
、more 等指令給「一般玩家」，然後做出足具示範性質的區域，
則有興趣的玩家自然就可藉著 more 與實際執行後的結果，瞭解一
些基本的東西它是怎麼 work 的，關鍵在於一些細節的做法。
(以前好像也有人架過類似的，好像叫大神小站)
而現階段則是透過逐步釋出的方式，讓有程式底子、也有興趣的人
可以先看看裡面有什麼新東西。
總之還是要謝謝你，這類的反饋對 tmi2_v3_改 的釋出非常重要，
這也是我一直強調的，我很需要反饋的意見的原因。
推
06/15 10:19, , 3F
06/15 10:19, 3F
大家的想法都差不多。
※ 編輯: laechan (114.26.184.223), 06/15/2014 10:40:52
推
06/15 20:19, , 4F
06/15 20:19, 4F
→
06/15 21:37, , 5F
06/15 21:37, 5F
→
06/15 21:46, , 6F
06/15 21:46, 6F
可以先看一下 mud 目錄內的修改日誌.txt，先參考最初修改的
前三天左右大概改了什麼。我一般沒必要不會刪除 tmi2 原本有
的東西，用新的東西覆蓋時也多半都會於修改日誌裡註明。
因為這是 tmi2_v3_改，不是完全我原創的，我也打算在釋出時
使用含有 "tmi2_v3" 的名稱，但是在釋出前我一定會盡量把這
個版本用不到的東西，都集中到一個目錄內分類存放，讓使用者
在主要目錄盡可能不會看到過時的、沒必要存在的東西。
(至於拿到釋出版本的使用者要怎麼做，我就不干涉了)
※ 編輯: laechan (1.165.194.160), 06/15/2014 22:58:58
推
06/15 23:28, , 7F
06/15 23:28, 7F
討論串 (同標題文章)
mud 近期熱門文章
PTT遊戲區 即時熱門文章
