今明两天是难得有空的时间，我今天先拟好架构，明天打算一股作气 将系统雏形写好。之前其实已经写好一部份了，但因为 times_check 的关系(要改成它可以套用的)，就作废了。 写战役系统是为了节庆活动。传统上举办活动需透过 /d/event 目录 底下各活动物件的写法，我觉得那个太麻烦了，所以我其实很懒得举 办那样的活动，为了解决这问题才会想写战役系统，这样以後只需要 写脚本就好了，脚本的好处就是具有可复制性、容易理解、容易管理 及做出变化、... 预计这个东西写好後，圣殿就有区域产生器、任务系统、副本系统、 战役系统，这样艾恩葛朗特计划就可以实行。 假设使用 /open/cmds/times_check.c 做为驱动引擎，依照斜角巷的 书店写法，战役系统必包含底下函数及程式段落: static object times_check; void init() { ::init(); if(!this_files) this_files=base_name(this_object()); if(!times_check) if(catch(times_check=find_object_or_load("/open/cmds/times_check"))) return notify_fail("目前 times_check 有问题喔.\n"); 几个供 wiz 使用的 add_action(); } int times_check(string names,string files,mixed tmps) { int s,sk; string str; object ppl; if(!times_check) if(catch(times_check=find_object_or_load("/open/cmds/times_check"))) return 1; // 这函数就是 times_check 每隔一段设定时间就会来呼叫的 times_check->set_times_check(战役标签,this_files,({参数群}),下一次呼叫间隔); return 1; } 然後当有战役被触发时，使用的呼叫程式段就是 times_check->set_times_check(战役标签,this_files,({参数群}),下一次呼叫间隔) 然後再依 /std/new_ob/boat.c 的写法，boat 设有 plane 参数， 而 times_check 函数便是依该参数来决定每一个呼叫周期要做哪 些事情。 由上可知，可套用 times_check 的战役系统必然也是有设定一些 东西--也就是脚本，然後 times_check 函数再依据写好的脚本来 执行。 一般来说，总管型的战役系统的 times_check 函数需能做到底下 判断: 1.各战役脚本物件的管理及资料载入 2.同一时间多场战役的状况显示及流控管理 3.每一呼叫周期的 a.该做什麽事 b.满足什麽条件之下才做下一阶段的呼叫 c.否则就持续重覆该阶段 d.战役何时结束、失败、或中止的判断 战役脚本物件必须包含这些设定 4.每一呼叫周期至少需可做到 a.呼叫怪物并设置於指定地点 b.进行全域或特定区域广播 c.判断怪物存活情况与玩家击杀数等 . . 因此仿 /open/cmds/quest，应该要有 /open/cmds/war 这样的目 录设置，在该目录下有多个战役脚本这样。 但是，总管型的战役系统并不是良策(这也是我重写的原因之一)， 因为同一战役理论上只会在同一时间被开启一次，因此战役之间并 不需要「总管流控的物件」，各战役由各战役脚本来兼做战役管理 即可，根据之前的实验，套用 times_check 的物件即便被 update 也不会影响 times_check 的呼叫，因此由战役脚本兼做战役管理 是可行的，带来的好处就是 1.战役资料直接本地端存取 2.战役所需自行编写的相关管控函数，就直接写在该战役物件里头 　，方便其它 wiz 更容易了解该战役架构组成(因为都写在同一档) 3.仍旧可写一个 war.c 总管物件来依需要读取各战役物件的状态 4.避免 war.c 出现频繁做资料写入的情况 5.共通函数就写 war_sample.c 让各战役脚本物件 inherit 架构大致是这样，times_check.c 的利用我写得算简单，因此撰写 可套用 times_check 的战役系统应该不难。 脚本档的部份，一般来说就是仿 quest 的架构，因为 quest 也是 属於流程式的写法，并设定有可否通过任务判断、以及循环条件， 但是战役系统要做的判断较多，这部份是否适合全部脚本化，目前 仍有疑义，任务的部份因为需要较多判断的流程较少(通常只有一两 个流程需要)，所以是采让 wiz 可自定义函数的做法，但战役的话 就可能落得每一个流程都需要自定义一个函数来跑，这样就失去脚 本化的意义。 这个我今天会思考出权宜的做法。 脚本档编好後，会由 _war.c 指定转成战役脚本物件，物件会继承 sample档，因此很多函数都会写在 sample 档里头，我预期会有很 多的内定判断用函数并可传值过去，用这个来做脚本档的简化，应 该会蛮有效的，我预期这类函数会以 check_ 做为开头。 最後，脚本物件的资料结构部份，主资料当然以 mapping 格式,虽 然说一个战役理论上同一时间只能发动一次(直到结束)，但我还是 会预留同一时间(实际上会设定不能同一秒)被发动两次的情况，而 以战役标签(就是 time() 值)当做主键值，其下再串被写在脚本档 的资料。 明天大致就依所编的这些东西来撰写战役系统相关档案。我是希望 写好後就能拿教庭战争来实验，未来很多战役的显示格式会趋向固 定，但亦会保留给 wiz 自订的空间。 战役系统写完後，下一个我预计写的将是领地争战系统，我定义它 是国家系统的外挂系统，参与条件是被授予几品官职以上，即可选 择所属国辖下的领地来治理，主要游戏目的是与其它国家的领主打 仗。领地争战系统是很早就有的构想，但是卡在「副本系统」，必 须先完成副本系统才能实现战场生成。 LAechan --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 61.223.250.36 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/mud_sanc/M.1486354250.A.04A.html ※ 编辑: laechan (61.223.250.36), 02/06/2017 13:57:51