推 FlashGet:好文推 09/20 14:24
→ dasskabusk:不知道你們有沒有玩過網頁遊戲erepublic, 那個寫成mud 09/21 23:16
→ dasskabusk:應該會比較像是現代人會玩的mud吧... 09/21 23:16
根據經驗，假設未來面臨人手不足的情況時，系統撰寫的
原則是..
一、好管理
二、好更新
三、好設定
四、儲存的資料需與系統所在目錄分隔
例如說一個國家系統，對管理者而言，假設未來自己 mud
有 100 個國家，那麼第一優先要考量的，就是如何方便
管理者存取、更動這 100 個國家的資料，即便它們可能
有各自的目錄，例如 /k/taiwan, /k/japan, /k/china..
以上面為例，一種可行的做法，就是將一些比較有共通性
質的資料(如國名、國家成員、國家發展數值、..)，共同
存在一個資料檔裡，例如 kingdom.o 這樣，而把一些比
較細的、比較傾向國家自有屬性的(如國家馬匹、國家藥
水、國家武防等)，存在該國自己的目錄下，如 horse.o
、potion.o、...等。
這樣管理者在閱覽一般資料時，只需讀取 kingdom.o 的
資料即可，而且在做這類資料的更新時也可以一次解決。
再來是資料檔的儲存部份，一般來說偷懶的做法是，比方
系統是寫在 /adm/kingdom 目錄下，那可能資料檔也是放
在同一個目錄或子目錄，它最明顯的缺點就是「資料的獨
立備份不易」，因為一個 mud 不可能只有一個系統，若每
個系統都這樣子做，則這些資料檔的儲存就沒有集中性，
比方說我們今天做了全系統的備份，然後一個禮拜過去了
，系統檔其實都沒有更動，有更動的只有「資料」時，那
麼只備份這些資料其實就可以了，以這點為考量的話，若
能讓這些資料檔都集中存放於某個目錄(如 /data)，那就
只需備份這個目錄下的所有資料即可，系統檔則等有更新
再備份就行了。
以這種做法為例的話，則國家的資料檔也應該這樣做，例
如各國的資料也是存在 /data/k/taiwan, japan, ... 這
些目錄之下，而各國物件實際的目錄下，只放「物件檔」
這樣不僅管理方便，儲存、備份也方便，其缺點就是資料
檔跟物件檔不在同一個目錄，為此，就需要撰寫能方便讀
取資料檔的介面，也就是所謂的「管理者介面」以及「使
用者介面」。
再來講系統的撰寫，一般寫法有幾種.
一、集中式
將所有東西都寫在同一個 .c 檔裡頭，連同使用者介
面、管理者介面。最常見的是「指令」，例如說拍賣
指令，區分成使用者語法以及管理者限定的語法這類
的。再來就是單一房間式的，例如「拍賣場」。
這類系統以「小型」的為佳，程式行數不多這類的，
各 mud 常見的典型集中式系統就是「商店系統」。
二、函數集中式、架構分散式
例如說以國家系統為例，它可能就有像 kingdom.c、
horse.c、weapon.c、armor.c、army.c、...等物件，
每個物件各自掌管一些功能。
而一般它們可能都存在著共通的使用函數，這些函數
亦可能被集中為 king_function.c 這樣。
這樣的好處是，往後國家想新增新的東西，例如魔力
塔，那就寫一個 magic_tower.c，寫好後「掛上去」
即可。
三、分層繼承、外掛功能程式
例如一個具集中化傾向的系統(如家族)，寫出來程式
幾千行，而且資料是儲存在本物件內的，那基本上可
以將它們拆成..
group1.c -- 核心的函數、副程式
group2.c -- inherit group1.c
定義 void init() 內的各指令及函數
group3.c -- inherit group2.c
玩家/使用者實際可進入的房間
group4.c -- 讓 groupX.c 做外部呼叫用的物件
它的好處是仍保有集中化的設計，但是又有基本的區
別，使各 groupX.c 不會過度肥大，以聖殿為例..
檔名 bytes 程式行數
========================================
new_group_1.c 18196 602
new_group_2.c 25125 969
new_group_3.c 17490 626
new_group_program.c 22104 800
========================================
近3000行
此外，聖殿還有..
檔名 bytes 程式行數
========================================
new_group_badge.c 6694 235 族徽相關
new_group_rank.c 13271 442 族階相關
.
.
========================================
若這些全都寫在一起，光是閱讀上就相當麻煩，因此
採行上面的做法，而將族徽、族階這些以「外掛程式
」的型式額外掛上去。
然後，一個撰寫系統經常會遇到的情況，就是很多東西其
實都會重覆寫到，那麼，將這些重覆的東西獨立出來寫成
函數或副程式，就是一個直覺的想法，優點自然就是程式
行數可縮短、系統可簡化、閱讀性佳、修改容易等等。
結論是..
一、一個系統在撰寫前，一定要先經過規劃，思考一下該
怎麼寫、採什麼架構、如何存取資料、使用者介面、
管理者介面、....等等。
二、一個系統的撰寫，不光是為了讓使用者在使用上具有
便利性，還需考量讓管理者(不只有撰寫者本身)也能
方便管理，這樣的系統才能稱的上是親和的系統。
三、系統撰寫應力求簡化，使程式本身好閱讀。比方一個
系統可能是你五年前寫的，那當五年後你想再去修改
它時，我相信你不會希望發生「我怎麼看不懂自己寫
過的程式啊」這樣的事情的。
Laechan
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 210.61.157.53