WOW插件运行的是Lua语言 基于游戏平台 Lua是一种结构极其灵活的动态语言 与其他动态语言不同的是 它小巧灵活 没有冗余库 整个解释器不到200k K 因此 非常适合游戏环境的上层应用 为了安全起见 WOW关闭了很多Lua函数 比如I

O读写, 多线程等. 所以这里的Lua功能十分有限, 除了一些功能性的系统库, 如Math, String等, 就是游戏本身定义的内部对象.

WOW插件现状
    在需求方面, 随着游戏的时间推移, 玩家的需求越来越固定, 也越来越标准. 以Decursive插件(一键驱散)为例, 不像从前, 只有才在用, 如今相信没有哪个玩家不知道或不用的了, 也就是说驱散这个需求已经很确定了. 

    在插件开发方面有两个问题, 第一当一个插件开发出来之后无论作者怎么努力却总也无法满足所有玩家的需求, 不同玩家的需求经常是矛盾的, 第二对于开发者, 明明另外一个插件有我需要的部分功能我却没法直接拿来用, 因为他和他的界面存储已经绑定到一起了, 我想用的话除非仿照他的思路重写.

    在这样的现状下, 我们怎样才能做的更好呢? 刚说了半天上面的概念到底和WOW插件开发有啥关系呢, 一个游戏的插件开发也能用到如此流行的思路么? 是的, 说过, 人有多大胆, 地有多大产. 不怕不敢做就怕不敢想, 因此就产生了我大胆的设想. 


插件开发架构

N层式的设计

    这是一个纵向的方式, 其设计为我们带来了软件本身需求变更解决的灵活方案, 例如, 用户对我的插件提出了多种不同的界面要求, 我无法一一满足, ok, 我可以设计出多个界面的版本让用户选择, 而我的功能和数据方面都无需改动, 用户可以在不了解你的功能算法的情况下根据你功能模块的接口来自己定制符合自己个性的界面.  再举个例子, 有的用户喜欢用SavedVariables来存储设定, 这样方便, 有的用户希望使用Config文件来存储自己的配置, 这样保存时间长便于移动, 而你可以提供2种方案的数据层来满足这样的需求.

    采用3层模式开发插件应该是一个合格开发者的基本功, 很多优秀插件的核心思路都是这样, 总结一句话, 这样的模式设计不至于让你在一个普通的需求变更的情况下手足无措, 进而从头到尾修改你的代码. 更多的代码行为可以参考我的插件ShortKey和ShortRobot的设计, 虽然没有使用面向对象, 但层次清晰体现其中. 如若定义出标准可以很方便的拆为组件.

面向组件, 服务的设计
    这是一个横向的方式, 其设计是为了更大规模的复用, 目的不仅用于一个插件中, 而是可以复用于多个插件中. 组件方式的设计主要针对业务模块, 也就是功能模块, 当然他是在只有需求相对固定的环境下才能发挥威力. 核心设计便是接口与接口间通讯的数据结构的确定, 这就是标准, 有了标准我们才能更好的实施这个方案. 现在假定有一个大家认可的标准指定委员会. 

    依然拿Decursive举例, 因为这个需求已经很大众化了, 委员会需要对他定制标准才好使得日后依照标准开发出的插件具有很强的复用性, 分析他的主要功能有两部分, 驱散和优先列表. 如下列代码所示, 分别定义了驱散与优先列表的对外服务接口, 以及接口间的通讯标准参数person(指被驱散的人). 需要注意的是通讯标准也需要定义清晰, person代表被驱散的人, 那么这个人是一个玩家的名字还是一个Unit编号(如, Partymember1, RaidMember23, target等), 如果没有明确的定义别人将无法正确使用, 因此我在这里定义person代表一个unit编号. 他们的实现细节不是委员会的事情.
 
    ok, 标准定义好了, 可以提交给插件作者, 不同的插件作者按照他们自己的喜好或思路实现了不同的驱散和优先列表功能. 例如在实现优先列表的时候, 有的作者喜欢先判断距离再查看debuff, 有的作者喜欢先查看debuff再查看距离, 有的作者喜欢简洁的判断只筛选小组内的玩家, 有的作者喜欢功能强大的判断所有友方玩家. 这样做各有个的好处, 各有个的适用范围. 玩家们就可以依据自己的喜好选择不同的优先列表组件来满足自己个性的需求. 而优先列表的组件不仅仅只适合Decursive这类的插件, 其他类型的插件只要觉得他提供的服务恰当依然可以使用, 举例, 我开发了一个确定首要保护目标的插件, 我发现某个优先级列表组件非常适合我的使用, 因此我直接拿来就用了, 免去了再开发.

    类似于Decursive这样固定的需求, 游戏中不在少数, 如果对这些需求能确立相应的标准, 依靠广大开发者建立起一个完整的组件库, 那么按需所求的插件将不再是个梦想, 普通玩家制作自己个性化的插件也不是遥不可及的目标, 到时候只需要下载相应的组件组合便成为自己的所需的插件.

面向组件的延伸
    面向控件, gzkuru在Mop上发了这样一个帖子很不错, 通过封装界面和简单的业务而成, 这也是面向组件的一个缩小化的体现. 其实对于N层设计的每一个层次或者某几个层次的组合都可做为组件开发, 而唯一的判别方式就是看你的组件是否对应着一种流行的需求. 当然标准依然是必不可少的.



最后

    本文仅代表个人观点, 另外也欢迎各种相同或不同的意见与想法共同参与探讨. 组件化的道路仍然是个未知数, 我也在不断的探索中, 毕竟与其他开发技术不同的是插件开发所受限制极大. 我希望有一天能看到各种组件百花齐放的局面, 使用者只需找到自己喜欢的积木就能搭建自己的理想的城堡.

    另外想指出一些开发者们的误区, 一些观点认为 WOW插件规模很小不需要设计, 其实规模小不是理由, 设计与其说是一种功夫不如说是一种责任, 插件都是开源的, 你不会保证没有人在用在看你的东西, 好的设计无论在阅读或在使用过程中都是赏心悦目的. 另一些观点认为, 不需要使用任何人的库, 自己的能力很强所有东西都自己写. 现在已经不是程序员是英雄的年代, 善于利用别人的经验你会得到更大的成果, 还是那句话, 站在巨人的肩膀上可以尿的更远.


Simonw 2006.10.15 / Msn: i-simon@msn.com
如有转载请注明出自及原文地址：
欢迎各位开发者能团结起来加入CWOW Developer Group