根据经验，假设未来面临人手不足的情况时，系统撰写的 原则是.. 一、好管理 二、好更新 三、好设定 四、储存的资料需与系统所在目录分隔 例如说一个国家系统，对管理者而言，假设未来自己 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