嘛，明後天解析这个东西，用跟以前不同的方法。未来有一个重要 的东西要做，就是 quest 内有 instance、instance 内有 quest, 但是这两个东西我都遗忘了重要的部份: quest: 与搜集物品及打怪有关的部份(当初写给 norr 的) 这部份我看能不能透过法师进阶转职任务去找到蛛丝马迹 instance: 全部忘得一乾二净, haha...... quest 先不管(反正到时可以写外挂硬干)，instance 必须先找回过 去的 coding 记忆。 第一部份 全部(或大部份)重要的函数及变数列表 static mixed instance_files=({}); static mapping instance_comm=([]); static mapping instance_data=([]); static mapping instance_mobs=([]); static mapping instance_mob_datas=([]); static mapping instance_npcs=([]); static mapping ppl_instance=([]); static string instance_names,instance_paths; static string instance_ob,instance_author, instance_virtual,instance_map2data, instance_id1,instance_id2; static int instance_multi,instance_cd_times; int map2data(string tmap); int instance_set(object room,mixed tmps); int instance_del(object room,mixed tmps); varargs mixed instance_data(string str1,string str2); varargs void instance_channel(object room,int k,string str); varargs int create_instance(string ppl_name,mixed usr,string diff,string mode); varargs int birth_npcs(object room,string npc_files,string tmp); varargs int birth_mobs(object room,mixed tmps,string names,int lv,string diff); varargs int init_instance(object room,object ppl); mixed random_map(int Width,int High,int p); int instance_set(object room,mixed tmps); int instance_del(object room,mixed tmps); object find_npc(object room,mixed tmps); 第二部份 回想与猜想 01、理论上这东西是「每一个副本控制物件」的继承档，而它有 create_instance 代表玩家「进副本时」就是呼叫控制物件 去产生对应的副本区域，一个玩家同一时间只能在同一副本 产生一个副本区域，所以产生的副本区域一定被储存在某处 ，推测是 /std/new_ob/instance_rooms.c (不是这次重点) 02、在 create_instance 内，ppl_name 一般是 this_player() ，mixed usr 是包含 ppl 在内的全部玩家(例如同队玩家), diff 是难度字串，mode 是 single/非single 字串。 03、依这种写法，任务内要使用到副本的话，就一定要写相对应 的副本控制物件，这部份避无可避；副本控制物件写好後， 自然就可 create_instance，this_player() 呼叫该函数後 就会产生副本区域「同时」自己也会被 move 进副本区域内 04、instance_ob 的大部份东西不用看了，create_instance 会 用就行了。 05、大抵上，仍是采借用现存区域房间的做法较方便，但要使用 虚拟房间也可以: laechan/001.c : 实体房间范例 laechan/002.c : 虚拟房间范例 laechan/003.c : 借用实体房间但地图路线自订的范例 laechan/004.c : 多层式副本(类似幻想神域某一类型区域) 06、理论上，若在 quest 的某步骤呼叫 create_instance 的话 ，在呼叫的同时会视为玩家已完成该步骤，这时玩家若在副 本内 recall 或 quit 的话，再回到任务触发处试图再接该 任务时就会无法接(因为该步骤已完成)。 所以最好还是别这样写。 另一方面，则最好在玩家「闯过」该副本後，直接设定玩家 已闯过该任务某一步骤的标记，让玩家得以继续解该任务， 是比较合理的做法。实务上，stepX_npc 可设定为玩家绝对 无法抵达的房间，玩家自然无法 quest here about xxx 去 完成该步骤─只有「闯过」副本，系统才会标记玩家已解完 该步骤。 实验主要针对的是这个部份，第 n 步骤会提示玩家去哪里下 instance -enter，我会找现存副本来测，并修改最後一格的 判断: 1.没有相关任务标记的玩家: 照原本的副本流程结束 2.有着相关任务标记的玩家: 会跑不同的流程 闯过後会设定任务标记 然後再测试被设定完任务标记的玩家，能否继续接任务 (我可能会修改 _quest.c 为 stepX_npc 增加第三种型态， 这个主要用在 quest show 及 quest shows 上面) 第三部份 实验 暂定明天再做，任务步骤大概 4 个差不多，副本随便找一个简单 的来改。 (编辑中) --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.46.142.104 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/mud_sanc/M.1503067685.A.80C.html ※ 编辑: laechan (111.253.175.38), 08/19/2017 20:37:46