※ 引述《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