※ 引述《tenyfish (何时才有发言权?)》之铭言：
: 举个例好了，我想做的MUD最终型希望玩家是带领一个NPC队伍探险
: (这是我的个人喜好，先不论有没有人要玩这种东西)
: 在研究文件时，我看完组队，装备型物件等等...
: 我可以有个基本的了解，例:与其使用force follow的指令使NPC移动
: 造成MUD可读性下降，我考虑将NPC在equip时，转化成类似装备的物件
: 虽然我并没有实作(短期也不可能动这个部份)，
: 至少，我读完文件不会直接问你" 请问如何实作它 "
: 我上面只是举例，请不要嘲笑我的外行想法。
单纯就这一点，让你，也让大家了解我的想法。
首先，要实做上面的 party，“有很多种做法”。
今天为什么要采取某种做法，有它的“诸多考量”。
比方如果今天没有跟你交流过想法，我一般也是采取 npc follow
玩家的做法，但根据 sanc 的发展经验，npc 常常会因此跟丢玩
家，“为此我要如何解决诸多像这类的问题，使 npc 确实能紧跟
玩家”，就是我接下来会思考并处理的。
那有跟你交流过想法，我就会思考 npc follow 玩家以外的做法，
看看有没有什么做法既简单，好使用，npc 又不会有跟丢的问题？
那万一没有，就采取折衷做法，先确保 npc 不会跟丢再说。
我的意思就是，做法有很多种，就像今天我们要开车从 A 点到 B
点，可以开高速公路、可以开快速道路、可以开省道、......
我的想法就是我先确定它不只一种做法，再考量采哪种做法较好，
比方我考量的做法是“开快速道路”，或许你会问“为什么不开高
速公路”？
因为我有我的考量，也就是说在我的考量里，开高速公路可行，但
比方像是 CP 值可能没有开快速道路来得优这类的。
party 有多种做法，确定的，我如果改了 party 我就会在改版文
述说我大概是做了什么样的修改，以及我为什么会那样做。
相同的，如果日后你拿到 tmi2_v3_改 发现这份 party 系统无法
满足你的需求时，你也有多种选择
1.改版它，甚至改版后发布它
2.废弃它，重写新的，甚至还能发布它
3.提出你觉得它应该要怎样会更好，我来改版它并发布
4.废弃 tmi2_v3_改
那我会尽量在正式版本发布前，尽可能地补上说明文件，如同我对
/d/area/times_check.c 的处理模式，你有抓 tmi2_v3_改 的话可
参考同目录的那一份 times_check 使用说明。
我知道那份说明可能不足以让使用者因此了解 times_check 是做
什么用的，因为在我早先的想法里，我认为实做出足以用来说明的
样本，比去写落落长的 document 还要来得实际。
但既然也有会认真看说明的人，我就会希望自己也能尽可能把说明
文件写得更完整一点。
但请先谅解我就是那种看完落落长说明也不见得会用的人，所以我
才会比较重视实际可用来 demo 的样本如 /d/area/test 下的物件
，但总之，我会比以前更重视说明文件的撰写。
LAechan