写到现在，有几个问题。
首先是怪物的定义部份，战役系统应该支援“虚拟怪物设定”，这部份
我打算借用区域产生器的做法，让 wiz 在设定战争时就同时设定好怪
物资料，但是又不会产生实体档案。
也就是 clone 出怪物 sample 档，再 set 值进去给怪物，然后再将设
值好的怪物 move 到指定位置。
然后，战役系统也应该支援“借用实体怪物的资料来设定”，这部份很
简单就是只要给的值是 file 类型，就先 clone 出怪物 sample 档,再
clone 出该 file 所指向的怪物出来，然后把它的资料设定到 sample
mob，再将设值好的 sample mob move 到指定位置。
而不应该直接将“实体存在的怪物”clone 出来后 move 到指定位置，
否则:
1.wiz 就必须先写出实体怪物
2.大家都写实体怪物的结果就是战争怪物将难以控管
但是虚拟化设定有其它问题，当怪物需设定的资料很多时，会变得难以
脚本化。而且怪物若无实体档，将来要做 all mob list 时也会漏掉战
争怪物的部份。
我再研究一下这部份怎么做比较理想。原则仍是“一场战役只需撰写一
个脚本，脚本档内就包含了这场战役所需要的所有设定，这样才能单纯
化。若以这个做为前提的话，“共通战争怪物继承档”就变成必定会做
的事情，然后该继承档包含
1.如果怪物会四处走动时的处理
2.如果怪物有特攻时的处理
3.如果怪物阵亡时会做特殊事情时的处理
然后目录资料结构可能会变成
/open/cmds/war/ 主目录
/open/cmds/war/分类/ 分类目录
/open/cmds/war/分类/战役/ 战役主目录
/open/cmds/war/分类/战役/脚本档 该战役的脚本档
/open/cmds/war/分类/战役/脚本物件档 该战役的脚本物件档(以 war read 产生)
/open/cmds/war/分类/战役/各怪物档 该战役会用到的所有怪物(战役执行中产生)
同一个战役下的所有东西都会在同一个目录，然后同分类的战役
也会在同一目录。前者的好处就是在做怪物列表时，依照怪物档
名就能知道它是属于哪一个战役，后者的好处就是比方分类名使
用的是 wiz 名，那该分类下的所有战役就是该 wiz 写的＆管理
，列表时就很清楚。
然后配套措施就是要写一个管理系统。
LAechan