本帖最后由 小篱 于 2015-12-7 16:34 编辑


　　假如副本能同时掉落金币、经验、体力、背包物品，那么副本就同时依赖这些模块，也就是说这些模块中任意一个的接口发生变化时，我们就不得不修改副本模块的代码。再来看背包，副本、任务、宝箱、商店都会改动背包的数据，所以这些模块同时依赖于背包模块，所以如果我们改动了背包的接口，这些模块的代码都要修改。

　　很显然，这里是一个很不合适的M*N的关系。所以我们需要加一个分发模块作为“中介”，抽象物品作为“载体”。所有的调用模块都只依赖分发模块，它们只需要知道需要添加或消耗抽象物品，而不关心具体维护对应数据的模块。分发模块负责将抽象物品分发到不同的数据模块。这样一来M*N的关系就变成了M+N。

　　2. 配表更加灵活

　　就拿副本掉落举例子。如果没有抽象物品，当策划想让副本掉落金币时，可能会在表里加一列，定义为金币。等过了几天想换成掉经验，于是通知程序修改代码……又过了几天觉得还是换成背包物品比较好，于是又多加了几列，再通知程序修改代码……更杯具的是，如果到后期新开放了积分系统，好多配表都需要添加积分这一列。这样显然不是很灵活。

　　如果有设计恰当的抽象物品，很多产出和消耗都可以配成抽象的物品，策划可以很灵活自由地修改数值。程序这边也很方便，只需要写一次解析抽象物品配置的代码。

　　3. 方便交换数据

　　例如抽卡功能，服务器需要把抽出的结果返回给客户端显示，这时直接使用抽象物品这个数据结构来交换数据，定义消息接口时不用关心具体产出物品的类型。 另一方面，不管抽象物品实际是金币还是背包物品或是能量，客户端总是要以相似的形式在界面上显示出来：常见的一个图标、图标下方有物品的名字、图标的右下角是数量。有了抽象物品这个结构后，只需要正确处理好对抽象物品的显示，所有系统的界面都可以直接调用了，而不关心那个系统所要展现的具体是个什么东西。

　　分发模块设计

　　分发模块上文已经大略介绍过了，可以简单地理解为一个代理，其功能是把对抽象物品的操作映射到对实际数据的操作。

　　分发模块主要定义这三个接口：

　　Add(CommonItem) 添加一项抽象物品

　　Remove(CommonItem)删除一项抽象物品

　　Has(CommonItem) 判断玩家是否拥有一份抽象物品

　　另外一个要解决的问题是，有的数据不是直接附加于玩家本身的，比如英雄经验应该附加于某个英雄上，技能经验应该附加于某个技能上，等等。所以我们在添加一项抽象物品时，可能还需要一些额外的上下文数据（英雄id，技能id，宠物id等），这些上下文数据应该是触发操作的环境中可以获取的。例如对于打副本，上下文数据中就应该包含当前出战的英雄，副本模块应该负责将自己的上下文数据告知分发模块，以供其正确分发。

　　所以最后分发模块的接口这样定义：

　　Add(CommonItem, Context) 添加一项抽象物品

　　Remove(CommonItem, Context)删除一项抽象物品

　　Has(CommonItem, Context) 判断玩家是否拥有一份抽象物品

　　其中Context中包含由调用者感知的上下文数据。可能的问题是：如果数据配置有总是，当发现要添加的抽象物品是英雄经验时，上下文数据中并不包含英雄id（可能是开宝箱触发的），那么此时无法正确添加。坦率地说，这种问题现在想不到好的解决办法，这也是抽象统一接口所带来的代价吧！

　　相关阅读：开发笔记：游戏逻辑模块组织及数据同步

锐亚教育，游戏开发论坛|游戏制作人|游戏策划|游戏开发|独立游戏|游戏产业|游戏研发|游戏运营| unity|unity3d|unity3d官网|unity3d 教程|金融帝国3|8k8k8k|mcafee8.5i|游戏蛮牛|蛮牛 unity|蛮牛