谈谈任务过程中遇到瞎眼效果的解决思路

chengsan

还没有全面玩北侠，只是有人介绍任务tr经常因为瞎眼效果被中断，针对每一个场景临时打补丁，只能使tr越来越难以维护。
现在提出一个根本性的模块化解决思路，同时也能增加各种任务共用一些模块代码的可能。
1、将大任务流程拆解为一个个基本模块，每个模块有编号、调用方法、实现方法。
2、大任务采用变量记录所需模块、顺序，跟踪调用各个模块。
每完成一个模块，进行完成判断、差错判断、额外的执行指令，根据需要执行下一个模块，或者执行一个公共的返回模块。

这样的好处是大任务流程和子模块分离，便于维护。在开发任务的时候，差错控制和完成判断成为编制任务的核心。每个子模块也便于编写调试。编写全自动一次性完成几个大任务，流程也更容易控制。

zgbl

面向对象，模块化设计，好方法

zgbl

顶一个，觉得721的class最适合

chengsan

原帖由 zgbl 于 2009-8-12 12:47 PM 发表
顶一个，觉得721的class最适合

是啊，用7.21，你的tr解决问题的方法就更宽广了。我习惯很多tr都集成在一起，部分代码共用。
没发现mush支持class的显示方式，很多触发器都是集合在一起。

littlexi

完全不懂啊。。。。

muxiao

mush就这点不方便

ddid

不完全同意哦，MUSH的Trigger可以在脚本里自己生成、触发、销毁……，也就是说即使MUSH的设置里没有一个Trigger，在脚本里一样自由使用Trigger，即Trigger使用脚本维护……

chengsan

原帖由 ddid 于 2009-8-12 02:14 PM 发表
不完全同意哦，MUSH的Trigger可以在脚本里自己生成、触发、销毁……，也就是说即使MUSH的设置里没有一个Trigger，在脚本里一样自由使用Trigger，即Trigger使用脚本维护……

又了解mush一个优点。zmud保存的.mud文件也是特殊格式，虽说所有的内容都能导出到文本，但是部分特殊用法res list变量的值、特殊tr，重新导入，无法还原。导致的原因可能是一些非规范性用法，比如把多个rec变量 %push到一个list变量。也可能是zmud后期扩展了一些界面上的修改功能，基本的命令里没有加上。
mush应该不会犯这样的错误，可能也不允许那些特殊用法。