原先 n 个属性，要改成 n-m 或是 n+m，事实上都是办得到的，
我的原意是不希望拿到 tmi2_v3_改 的人，还需要做复杂的修改
才能达到他想要的结果。
但是因为属性关系到很多“释出前就得写好”的部份，例如战斗
就是一种，将来释出的版本一定会包含最基本可 work 的战斗相
关函数(例如闪格挡函数)，而这些函数也必然地一定会读取一些
属性数值来做计算，所以这些也需在一开始就先有基本的模型资
料。例如我一定会读取到的资料:
str 方面: 要计算攻击力
agi 方面: 要计算回避力
con 方面: 要计算基础抵伤
.
.
所以不需要担心后续要增加或是减少属性，就如同 tmi_v3 一开
始是四个属性:
> score 它们分别对映
[ Laechan ] "stat" : ([
Dexterity : 17 "dexterity" : 17,
Constitution : 10 "constitution" : 10,
Intelligence : 15 "intelligence" : 15,
Strength : 18 "strength" : 18, ])
而我要把 agi 及 int 加进去，就是一种增加属性的动作，如果
我能成功办到，就代表将来所有 tmi2_v3_改 的使用者也能办到
，而且会比我现阶段要做的修改还要简单。
(像我还要先把上面那些字串换成简单的 dex con int str...)
而且读取数值的部份，大都会透过函数的方式，它们会有共通的
源头，将来就只需动源头即可，则此时玩家资料字段的增减，就
无需对系统做大幅度的修改，像 sanc 就是存在的时间太久、大
家以前又都习惯直接读数值的方式，印象中 sanc 光是做底下的
两项修改就耗费极大心力与极多时间:
把 ppl->add("exp",n) 改成 ppl->add_exp(n)
把 ppl->add("warexp",n) 改成 ppl->add_warexp(n)
总之，很多字段的数值读取与增减，会尽量函数化，目的就是减
少拿到 tmi2_v3_改 的使用者在修改上的困扰，所以你不必太过
担心，唯一需担心的只有一点：修改的复杂度。
我举例：
从 es2 mudlib 要改成看 level 的西式 mud 困难!
从 tmi2 mudlib 要改成看 level 的西式 mud 相对简单!
所以一开始就要“慎选” mudlib，比方如果你想架 mud，但你
发现 tmi2_v3_改 并不适合架你想架的 mud 时就千万别选，不
然后续的修改既复杂又麻烦，还不一定能改完。
(经验谈了，想当初我也拿过 es2 mudlib 认真改了半个月..)