MUD 危險了 ? - MUD Game

提供一些建議。(雖然我還是要說，我真的沒時間)

依照經驗，很多東西都可以資料庫化，舉一個最常見的怪物掉落
物，比方在 RO 打死一隻波波利，會掉以下的東西

掉落物品 (Renewal)
粘稠液體 55%
加勒結晶 15%
綠色藥草 5%
葡萄 2%
蘋果 0.05%
笨拙短劍 0.05%
波波利卡片 0.01%

簡單的掉落做法，是在怪物生成時就把這些[物件] move 到怪物
身上，則玩家打死怪物時自然就掉落這些物品。

加上機率的設定時，則常見的做法是

int die()
{
int r=random(10000);
switch(r)
{
case 0: 掉落波波利卡片; break;
case 1..5: 掉落笨拙短劍; break;
case 6..10: 掉落蘋果; break;
case 11..210: 掉落葡萄; break;
.
.

而後則進化為直接在怪物的 create 裡面做設定

set("mob_drop",([
波波利卡片: 1, 代表 0.01%
笨拙短劍 : 5, 代表 0.05%
蘋果 : 5, 代表 0.05%
葡萄 : 200, 代表 2.00%
.
.


不管怎麼進化，當 mud 發展到一個程度、怪物量也多到一個程度
時，就會發現一個問題: 我怎麼管理這些怪物的掉落物設定?

(我希望一個 mud 從開發階段到成熟階段，不要再重蹈這些歷程)

這時最合理也最便於管理的做法就是集中式資料庫。

例如我有一個資料庫物件 /data/mob_drop.c，而波波利這個怪物
的檔名是 /x/xxx/mob/bobori.c，則這隻怪物在 mob_drop.c 裡頭
的掉落物設定資料設計如下:

mapping mob_drop([
"/x/xxx/mob/bobiri:([
波波利卡片: 1,
笨拙短劍 : 5,
蘋果 : 5,
葡萄 : 200,
.
.
]),
]);

mapping mob_drop(string files)
{
return mob_drop[files];
}

然後只要統一在 monster.c 裡頭的 die 函數裡面加這個程式段即可

mapping mob_drop_data;
object mob_drop=find_object("/data/mob_drop");
string files=base_name(this_object());

// 如果這隻怪物有設定怪物掉落物資料
if(!undefinedp(mob_drop_data=mob_drop->mob_drop(files)))
{
執行怪物掉落的相關判斷;
}

這樣 mob_drop.c 就能寫各種增刪改及各種資料撈取的函數，就能達
到集中化管理的目的。

這個集中化管理的概念，還可延伸到任何各式各樣原本傳統上都寫在
物件內的東西，例如最常見的 add_action、各商店小販販售的物品、
房間出現的 NPC、自編的任務等。

集中化管理的好處，就是隨時可以綜觀整個資料群，你看到的都會是
整體，而不是每一個個體，這樣你的調整才會是在考量到整體的情況
下去做的。

再來談框架，框架並不是指下面的東西

inherit ROOM;

void create()
{
::create();
set("short","一間房間");
set("long",@LONG
這是一間簡單的房間。

LONG
);
set("exits",([
"east":__DIR__"002",
"west":__DIR__"003",
]));
reset();
}

而是指一種每個人在為這個 mud 寫各種物件或程式段時，必須遵循的
東西。例如，假設這個 mud 設定 short 時是這樣做的

set_short("一間房間");

那所有 wiz 在寫房間時就最好別使用 set("short","一間房間"); 或
是其它的寫法----即便它可以 work。

也最好別有太多的自定義項，例如自己雞婆自定 set_short 函數，當
然你可以這樣寫:

void set_short(string str)
{
::set_short(str);
.
.
}

最好的做法，是你覺得 set_short 應該有什麼東西可以新增或修改的
地方，就去改源頭的 set_short 使它相容於你所想要新增的功能或是
想看到的結果。

一個多人共同開發的 mud，如果不一開始就把集中化管理、以及凡事遵
循既有的框架(沒有這個框架就要先去寫)這兩個重要原則帶進來，並且
跟所有的 wiz，做一下約定的話，很容易就會流於各寫各的，然後隨著
時間的過去，mud 發展到某一程度後才想回過頭來做管理、做調整，就
會很累。

因為一個很現實的問題是，可能參與草創期及發展期的 wiz 很多，但之
後他們可能會因為一些現實人生上的種種因素退出，這時留下的人可能
會很難去 調整 這些前人們的遺作。

框架要講到很細的話，隨便舉例，房間敘述，舉個 sanc 的例子

熾熱沙漠
剛剛步出綠洲, 發現沙漠上方的陽光依然令人身上的水份快速蒸
發, 你慶幸自己剛剛有找到綠洲小歇一番, 而遠方的地平線卻冒
出了一絲絲慢慢上升的炊煙, 你不禁加快腳步, 向西方邁進 。

明顯出口有: east 和 west.

每個人有每個人寫敘述的方式，這裡提的是一個很客觀的問題，就是敘
述裡面到底要不要有「你」這個字。

例如說「你不禁加快腳步, 向西方邁進」，可是上面有 east 跟 west
兩個出口，我明明是要往 east 啊，敘述卻寫我要往 west?

不過從來也沒有 sanc 的玩家抗議過這個問題，就是發現到這件事，才
促成了我想以三段敘述法來建構區域房間敘述的想法並付諸實行。

所以其實還有個超現實的問題: 你認真寫的東西，有多少人會認真看?

這個問題你有想過嗎? 當然可能你背後有其它的目的，可以使你忽略這
一點啦..


我一向認為 mud 可做為類似分鏡動畫這一類的工具。

像這樣，分鏡動畫階段(假設它真的是這部電影的分鏡動畫)
https://www.youtube.com/watch?v=Yqlx0Hl9rE0

參考分鏡動畫後拍成電影的樣子
https://www.youtube.com/watch?v=GkcOibsy_tc

對這部電影的拍攝團隊來說，製作分鏡動畫遠比實際拍成電影來得簡單
，而且在分鏡動畫階段可以做非常多所需的各種修改，並立即呈現修改
後的結果。

當分鏡動畫修改到沒問題後，再依它去拍電影，就會拍得很順，因為他
們會知道需要哪些畫面、以及需要演員們去配合什麼。

動畫<你的名字>也有類似這樣的分鏡階段，不過動畫本來這個就很常見
https://www.youtube.com/watch?v=j9zal_zRG2U

mud 也類似這樣的東西，而且相對廉價，更易於修改，理論上，一個遊
戲在開發階段，是可以透過先弄成 mud，來 demo 玩起來的感覺。

所以我雖然說我目前並不鼓勵任何人投入 mud 多人遊戲的開發，但是
我蠻鼓勵拿 mud 來做為遊戲製作的前期開發或輔助開發工具。

但是它要做為一個稱職的工具，就像我前篇提到的，它就必須要能提供
開發支援環境組件包。或至少，要有各種易於支援開發的工具。

這也是我當初弄 tmi2_v3_改 的原始用意之一，我希望它易於拿來架站
，而且是 一個人 也能架起來的。(只是後來種種因素我沒繼續改下去)

我會比較希望看到的是大家著眼在讓 mud 擁有 工具 的功能，而不是到
現在 2019 年了還期望一個新 mud 會有新血、新玩家的注入，台灣 mud
發展的黃金時間已經過去了。

如果是希望 mud 能做為什麼東西的雛形、或是做為 demo 用的工具，我
會覺得比較有意義一點，我本身在未來兩個多月就會把 tmi2_v3_改 用
在公司某個案子的 demo 上，因為 mud 有 heart_beat、有 call_out、
有 read_file 等，有這幾個就夠我快速 demo 出一些東西了，再藉由這
些東西依照我的想法於既定的時間一一呈現，我很容易就能看到它們跑起
來的樣子，而產生一些感覺，再依這些感覺去做後續的調整修改等。

而這東西對我未來撰寫 sanc 的戰役系統也會有幫助。


--