提供一些建议。(虽然我还是要说，我真的没时间) 依照经验，很多东西都可以资料库化，举一个最常见的怪物掉落 物，比方在 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","一间房间"); 或 是其它的写法----即便它可以 work。 也最好别有太多的自定义项，例如自己鸡婆自定 set_short 函数，当 然你可以这样写: void set_short(string str) { ::set_short(str); . . } 最好的做法，是你觉得 set_short 应该有什麽东西可以新增或修改的 地方，就去改源头的 set_short 使它相容於你所想要新增的功能或是 想看到的结果。 一个多人共同开发的 mud，如果不一开始就把集中化管理、以及凡事遵 循既有的框架(没有这个框架就要先去写)这两个重要原则带进来，并且 跟所有的 wiz，做一下约定的话，很容易就会流於各写各的，然後随着 时间的过去，mud 发展到某一程度後才想回过头来做管理、做调整，就 会很累。 因为一个很现实的问题是，可能参与草创期及发展期的 wiz 很多，但之 後他们可能会因为一些现实人生上的种种因素退出，这时留下的人可能 会很难去 调整 这些前人们的遗作。 框架要讲到很细的话，随便举例，房间叙述，举个 sanc 的例子 炽热沙漠 刚刚步出绿洲, 发现沙漠上方的阳光依然令人身上的水份快速蒸 发, 你庆幸自己刚刚有找到绿洲小歇一番, 而远方的地平线却冒 出了一丝丝慢慢上升的炊烟, 你不禁加快脚步, 向西方迈进 。 明显出口有: east 和 west. 每个人有每个人写叙述的方式，这里提的是一个很客观的问题，就是叙 述里面到底要不要有「你」这个字。 例如说「你不禁加快脚步, 向西方迈进」，可是上面有 east 跟 west 两个出口，我明明是要往 east 啊，叙述却写我要往 west? 不过从来也没有 sanc 的玩家抗议过这个问题，就是发现到这件事，才 促成了我想以三段叙述法来建构区域房间叙述的想法并付诸实行。 所以其实还有个超现实的问题: 你认真写的东西，有多少人会认真看? 这个问题你有想过吗? 当然可能你背後有其它的目的，可以使你忽略这 一点啦.. 我一向认为 mud 可做为类似分镜动画这一类的工具。 像这样，分镜动画阶段(假设它真的是这部电影的分镜动画) https://www.youtube.com/watch?v=Yqlx0Hl9rE0 参考分镜动画後拍成电影的样子 https://www.youtube.com/watch?v=GkcOibsy_tc 对这部电影的拍摄团队来说，制作分镜动画远比实际拍成电影来得简单 ，而且在分镜动画阶段可以做非常多所需的各种修改，并立即呈现修改 後的结果。 当分镜动画修改到没问题後，再依它去拍电影，就会拍得很顺，因为他 们会知道需要哪些画面、以及需要演员们去配合什麽。 动画<你的名字>也有类似这样的分镜阶段，不过动画本来这个就很常见 https://www.youtube.com/watch?v=j9zal_zRG2U mud 也类似这样的东西，而且相对廉价，更易於修改，理论上，一个游 戏在开发阶段，是可以透过先弄成 mud，来 demo 玩起来的感觉。 所以我虽然说我目前并不鼓励任何人投入 mud 多人游戏的开发，但是 我蛮鼓励拿 mud 来做为游戏制作的前期开发或辅助开发工具。 但是它要做为一个称职的工具，就像我前篇提到的，它就必须要能提供 开发支援环境组件包。或至少，要有各种易於支援开发的工具。 这也是我当初弄 tmi2_v3_改 的原始用意之一，我希望它易於拿来架站 ，而且是 一个人 也能架起来的。(只是後来种种因素我没继续改下去) 我会比较希望看到的是大家着眼在让 mud 拥有 工具 的功能，而不是到 现在 2019 年了还期望一个新 mud 会有新血、新玩家的注入，台湾 mud 发展的黄金时间已经过去了。 如果是希望 mud 能做为什麽东西的雏形、或是做为 demo 用的工具，我 会觉得比较有意义一点，我本身在未来两个多月就会把 tmi2_v3_改 用 在公司某个案子的 demo 上，因为 mud 有 heart_beat、有 call_out、 有 read_file 等，有这几个就够我快速 demo 出一些东西了，再藉由这 些东西依照我的想法於既定的时间一一呈现，我很容易就能看到它们跑起 来的样子，而产生一些感觉，再依这些感觉去做後续的调整修改等。 而这东西对我未来撰写 sanc 的战役系统也会有帮助。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.33.66.104 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/mud/M.1563187709.A.2F6.html