游戏事件管理器

旨在处理相对复杂的行为逻辑。类似于行为树，只是多了与服务器的通信，记录事件的进度和完成度。相当于整个游戏的管理。自身实现了事件的进度管理，具体如何使用通过GameEventAction的子类实现。可以调用游戏中的其他模块。

事件内容

触发条件

即事件何时被激活，比如进入某个场景，比如达成某个成就，比如完成某个任务等。

开启条件

事件的触发条件成立了，但是也不是什么时候都会开启，比如进入某个界面，同时某个道具的数量要大于10个，那么某个道具大于10个就是开启条件，触发条件是达到了事件的检查门槛，但能否开启还要看触发条件。

所在场景

大部分事件都是发生在特定的场景下的，尤其是教学引导的步骤。对断开重进游戏非常重要。

行为列表

事件的具体执行步骤，每一步做什么，都会进行记录。

行为的前置依赖

后面的行为可能需要前面的行为的结果，但是前面行为的结果并不会被存入数据库，此时，当重进游戏直接执行的行为的前一个行为刚好是无记录的行为时，就需要先执行这个无记录的行为，而且是递归向前查找的。

事件的并发处理

事件是支持也必须支持并发的。同时存在多个执行的事件是必要的。但是同一个事件一次只能执行一个。

如何记录事件

记录事件的进度，每一个行为做到了哪一步，还要记录事件的状态（未开启，进行中，已完成）单独一个字段记录是否完成过，如果可以重复的事件，还需要记录是否已经完成过。

事件开始发送请求

事件每个阶段开始发送请求

事件结束发送请求

断开重连 事件开启时需要某种特定的条件，但是还未执行完中途退出了，再进入游戏后，事件要继续执行时，这个事件所需要的场景已经不在。这里的场景分为一级界面和其他级界面。一级界面形如主城进入游戏后主动弹出，二级界面形如商城进入游戏后被动弹出，是在一级界面之上的界面。

等待重新触发：进入游戏后开启事件时，事件应该判定所需的场景是否存在，如果不存在就不放入执行队列中，等待重新触发。这种适合那种场景是进入游戏自动弹出的那种一级界面，比如主城。如果是商城这种二级界面，需要用户主动点击打开的就不确定何时才会再开启了。

主动弹出场景，等待重新触发：进入游戏直接将事件所需的场景弹出，等待事件被触发后继续执行。

这里还是有个问题，那就是用户触发的二级界面不在进入游戏后就会主动弹出的一级界面之上，而是在后续的一级界面，比如战斗场景替换了主城，此时可以用UI管理器记录当前场景的状态，进入游戏后依次弹出，这样事件就不用管弹出场景的事情了。（目前没有使用这种方式，还是使用的2）

结合以上的分析，我们可以做如下处理，进入游戏需要判定场景是否存在，如果不存在不执行，后续通过触发重新开启。如果场景存在就直接加入执行队列。所以，为了更好的管理事件，需要不同场景的行为就不要放到一个事件中，因为一个事件中的行为是有连续性的，发生在不同场景的行为断掉之后很难复原。所以不同场景中的行为要分到不同的事件中处理。

行为之间的依赖关系如何解决 我们可以在行为列表中添加一列，标识是否需要前一个行为的支持。这样也可以递归执行之前的行为，但是服务器在处理的时候不会返回错误，也不会更改当前的进度。

数据表结构

游戏事件表

行为表

行为类型表

触发条件类型表

条件表

条件类型表

结语

https://gitee.com/sarsgame/gds/tree/master/cfw/gameEvent

相关代码：

https://gitee.com/lecoolgame_framework/cfw/tree/CocosAndLaya/gameEvent

另外附上游戏开发常用工具地址

https://gitee.com/sarsgame/gametools

https://gitee.com/sarsgame/gds