一、 每个开发者平台上架的商品对应一个商品mod，该mod包含对应商品的资源及发货逻辑

二、编写规范

在xxxScripts中创建一个modGoodsMain.py（该名称不可更改）（与modMain在同一目录）。

modGoodsMain的格式如上图所示。图中：

a.from common.modGoods import ModGoods

ModGoods为一个定义类，含下文的绑定属性，用于识别及加载商品mod

b.@ModGoods.Binding(name = ‘Test_Goods’, version = ‘0.1’)

Class TestModGoods(object):

该装饰器用于标识商品mod的发货类

Name为mod名称，version为我们的版本。暂时还没有实际用途

c.@ModGoods.DeliverGoods()

def deliver_test(self, entityId, type, goodsId):

该装饰器用于标识商品mod的发货函数。该函数必须在上述发货类中，并有且只有一个。

持有该商品的玩家进入游戏，或者在游戏内购买该商品，该发货函数会被调用

该函数需要3个参数，如下：

entityId：需要发货的玩家的entityId

type：商品类型。暂无实际用途

goodsId：商品对应的id。暂无实际用途

三、发货逻辑

对于简单的仅服务端的发货逻辑（如发放物品），可以直接写在发货函数内。

以下为需要客户端参与的发货逻辑（用到客户端组件的，如粒子特效，原版皮肤）的书写建议：

编写一个serverComp，一个serverSys，一个clientSys。并在modMain注册（参考demo或其他文档）

a.serverComp

普普通通的一个component。用于标识玩家该商品的状态

own: 用于保存玩家持有该商品

deliver: 用于通知serverSys给玩家发货

在modGoodsMain的发货函数中修改该comp的deliver属性

b.玩家登陆发货

在serverSys的Update函数中处理上述comp，广播发货事件给所有客户端，并设置comp的own属性。

在clientSys中监听发货事件，在事件处理函数中写实际发货逻辑（如绑定粒子）可参考demo中TestServer.Update及TestClient.OnDeliverbbParticle

c.处理AddPlayerEvent

玩家登陆时也要告知他视界内其他玩家是否需要发货。另外，视界外玩家进入视界时，也要做同样的检查。

clientSys中监听引擎AddPlayerEvent事件，发送请求事件到serverSys。

serverSys监听该请求事件，检查comp的own属性，若成功则返回发货事件。

可参考demo中的相关代码

四、注意事项

1. modGoodsMain中发货函数的所有逻辑都会在服务端运行

2. 对于需要客户端参与发货的产品，需要每次登陆及触发AddPlayerEvent时发货

3. 对于一个房间内只发放一次的商品

（这种商品应该都是只在服务端发货的）

由于每次玩家登陆都会重置entity和component，所以不要使用comp的own属性判断是否发过货。

建议在serverSys中保存一个dict，把商品的持有属性保存在该dict中，serverComp中只有deliver属性用于传递发货消息。玩家登陆时检查改dict，若已存在则跳过，达到不重复发货的效果。