tmi2_v3_改 - MUD Game

抱歉沒有講得很清楚。

我希望日後所有拿到 tmi_v3_改 的使用者(架站者)，不會對 tmi2_v3_改
的「使用」產生太大的困擾。

為此，需要先溝通一些重要的基礎設定，因為這些設定就是我接下來開始
要動用到的東西，是 tmi2_v3_改 的核心部份。

依照優先順序，最優先的就是

是不是使用 "level"、"stat"、"race"、"skill" 等等的欄位。

因為它們關係到函數的名稱。

與這個問題相關，但是「現階段並不重要」的問題是

1.tmi2_v3_改 是不是多種族?

一開始多種族 => 之後就算要改單一種族也簡單
一開始就單種族 => 等於一開始沒有種族 => 之後要改成多種族就會比
較複雜
所以我設定一開始至少兩個種族。

2.tmi2_v3_改 是不是有兩種等級制?

我前篇有提過 tmi2_v3_改 採等級制，是因為我希望它與東方式的 mud
有顯著區別，所以它會有等級制(沒意外的話會採 "level" 欄位)。

但是要不要多種等級制則是屬於使用者將來為自己 mud 所設計的風格
問題，就像 D3 也是後期才導入巔級設定，它是可以在後期導入的。

3.屬性幾個的問題

我並不贊成 mp、魔力、魔法方面的素質採單一看 "int" 的做法，因為
它不合理。

相同的，敏捷、命中、閃躲、暴擊機率等只看單一的 "dex"也不合理。

我基本上會為 tmi2_v3_改 撰寫很多的欄位讀取函數，例如說:

一般 mud 讀 str 屬性 : ppl->query("stat/str")

tmi2_v3_改 讀 str 屬性 : ppl->query_stat("str")

如果你想要依 tmi2_v3_改 所設計有六個屬性的世界，改成只有四個屬
性的世界，上述的做法是辦得到的:

int query_stat(string str)
{
if(str=="agi") str="dex";
else if(str=="mag") str="int";

return data["stat"][str];
}

反之，如果一開始只有四個屬性的世界，要改成六個屬性就沒那麼好改
，就我所認為的，一開始 5~6 個屬性，使用者比較不會覺得困擾。

5.其它(位階、聲譽、背包格、..)

這跟 2. 一樣都是可以由使用者依據自己 mud 的風格來決定要不要有
，就像 sanc 最早是使用 "warexp" 這個欄位代表戰功，但後期我將它
解釋為 "戰功聲望"，讓它也具有聲望的意義，但基本上 tmi2 一開始
是沒有 "warexp" 這個東西的。

一開始沒有，後來有，就代表 tmi2_v3_改 一開始不見得要導入。

反之，如果導入了，使用者要變更其欄位名稱或是取消它就會很困難。


然後另一種關鍵問題是陣亡懲罰。

我前篇提過我會採等級不倒扣的機制，在這情況下就要有相對應的其它配
套措施，來改善採用這種機制會產生的缺點。

例如「玩家經驗歸零了，但是技能熟練度沒有歸零」就是一種。

例如「玩家 base 經驗歸零了，job 經驗沒有歸零」也是一種。(RO)

我採技能熟練度的設計，純粹是因為 tmi2_v3_改 將來必定有技能的緣故
。(job 則是後天可決定的風格問題)

然後即便採用技能熟練度，使用者也可以視自己 mud 的需要導入技能點的
設計(甚至要兩種並存、改良版等也可)，關鍵在於

a.加熟練度的呼叫必須函數化 → 使用者才有辦法將其無效化
b.玩家升級時的呼叫也必須函數化 → 使用者才能靠改函數達到目的
c.增加技能的呼叫也必須函數化

(但函數化不是萬能的)

以及所謂「稱呼」的問題，就像 "stat" 如果稱為屬性，那其它要稱為什
麼？這也很重要，卻是最常被忽略的。

最後提一個重要的設定。

我一開始就會為 tmi2_v3_改 打造一個基礎的遊戲環境，它會包括一座初
始的城鎮，一兩個練功區，以及一個需攻略的地方。每一位拿到這份遊戲
並把它架起來的人，都可以透過創造一個新角色去做攻略，攻略完成，遊
戲就算結束。

之後就是拿到這份遊戲的人的事，看它是要繼續練功，還是用它來寫新遊
戲、寫怎樣的遊戲等，就是由他來決定的。

例如最簡單的，如果使用者一直為它加區域，理論上這遊戲就能一直玩下
去，甚至還可以透過 tmi2_v3_改 所附的任務、副本等系統，去加任務、
加副本、加各種東西，使遊戲包含的內容更多元。

當然前提是我有辦法改完它，目前我還沒把握，只能一步一步來，並透過
逐步釋出的方式讓大家知道我又改了或加了什麼。


laechan

--