抱歉沒有講得很清楚。 我希望日後所有拿到 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 --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.165.184.126 ※ 文章網址: http://webptt.com/m.aspx?n=bbs/mud/M.1402195005.A.A36.html ※ 編輯: laechan (1.165.184.126), 06/08/2014 10:38:15