提供一些建议。(虽然我还是要说，我真的没时间)
依照经验，很多东西都可以数据库化，举一个最常见的怪物掉落
物，比方在 RO 打死一只波波利，会掉以下的东西
掉落物品 (Renewal)
粘稠液体 55%
加勒结晶 15%
绿色药草 5%
葡萄 2%
苹果 0.05%
笨拙短剑 0.05%
波波利卡片 0.01%
简单的掉落做法，是在怪物生成时就把这些[物件] move 到怪物
身上，则玩家打死怪物时自然就掉落这些物品。
加上机率的设定时，则常见的做法是
int die()
{
int r=random(10000);
switch(r)
{
case 0: 掉落波波利卡片; break;
case 1..5: 掉落笨拙短剑; break;
case 6..10: 掉落苹果; break;
case 11..210: 掉落葡萄; break;
.
.
而后则进化为直接在怪物的 create 里面做设定
set("mob_drop",([
波波利卡片: 1, 代表 0.01%
笨拙短剑 : 5, 代表 0.05%
苹果 : 5, 代表 0.05%
葡萄 : 200, 代表 2.00%
.
.
不管怎么进化，当 mud 发展到一个程度、怪物量也多到一个程度
时，就会发现一个问题: 我怎么管理这些怪物的掉落物设定?
(我希望一个 mud 从开发阶段到成熟阶段，不要再重蹈这些历程)
这时最合理也最便于管理的做法就是集中式数据库。
例如我有一个数据库物件 /data/mob_drop.c，而波波利这个怪物
的档名是 /x/xxx/mob/bobori.c，则这只怪物在 mob_drop.c 里头
的掉落物设定资料设计如下:
mapping mob_drop([
"/x/xxx/mob/bobiri:([
波波利卡片: 1,
笨拙短剑 : 5,
苹果 : 5,
葡萄 : 200,
.
.
]),
]);
mapping mob_drop(string files)
{
return mob_drop[files];
}
然后只要统一在 monster.c 里头的 die 函数里面加这个程式段即可
mapping mob_drop_data;
object mob_drop=find_object("/data/mob_drop");
string files=base_name(this_object());
// 如果这只怪物有设定怪物掉落物资料
if(!undefinedp(mob_drop_data=mob_drop->mob_drop(files)))
{
执行怪物掉落的相关判断;
}
这样 mob_drop.c 就能写各种增删改及各种资料捞取的函数，就能达
到集中化管理的目的。
这个集中化管理的概念，还可延伸到任何各式各样原本传统上都写在
物件内的东西，例如最常见的 add_action、各商店小贩贩售的物品、
房间出现的 NPC、自编的任务等。
集中化管理的好处，就是随时可以综观整个资料群，你看到的都会是
整体，而不是每一个个体，这样你的调整才会是在考量到整体的情况
下去做的。
再来谈框架，框架并不是指下面的东西
inherit ROOM;
void create()
{
::create();
set("short","一间房间");
set("long",@LONG
这是一间简单的房间。
LONG
);
set("exits",([
"east":__DIR__"002",
"west":__DIR__"003",
]));
reset();
}
而是指一种每个人在为这个 mud 写各种物件或程式段时，必须遵循的
东西。例如，假设这个 mud 设定 short 时是这样做的
set_short("一间房间");
那所有 wiz 在写房间时就最好别使用 set("short","一间房间"); 或
是其它的写法