技能系统设计笔记 7

记录时间：2009年12月14日

更依赖于事件的技能设计方案

如果我们将技能事件的定义和功能扩展，会发现其实远程技能，近程技能的共通点。前期设计中，我们只考虑了事件的瞬时性，换句话说，我们认为只有瞬时发生，并只发生一次的逻辑才属于技能事件。如果我们在事件上加入时间，变化性等特点，可以惊喜的发现原来近程/远程技能的逻辑是如此统一。

我们可以尝试用新的事件结构来描述近程和远程技能

 

就像上面所描绘的一样，近程技能和远程技能在设计上达成了统一。近程/远程技能在技能控制，时序更新，事件触发和结果派发的各个关键点上的逻辑达成了一致，它们之间的差异性被转移到事件本身中。采用这种设计，技能的实现并没有带来多余的效率损耗。

当然上面的设计也带来了其它层面上的设计变动，而且这种变动会深刻的影响与技能系统相关模块的设计。就是事件本身在终端间的同步。新的设计将事件本身设计为一个有时序的逻辑个体，就像对前期设计的剖析一样，一段有时序的逻辑，必然需要在时序的多个关键点上进行网络同步，因为我们不仅关心它的最终结果，也同样关心它的变化。

等一下再来考虑同步的问题，我们先集中精力设计一下技能事件的处理流程。

技能事件本身有可能会产生新的事件（考虑一次攻击可能会随机的带来DEBUFF效果）。当然我们也可以继续扩展事件本身，让它把所有可能产生的新逻辑都囊括到自己本身中，这样就不会有新事件产生了。但这种选择会导致技能事件本身变得过于庞大和脆弱，因为新的事件类型可能会在设计后期被发现，这时候需要重新回来扩展事件的结构，并且这种修改是线性的，一个新改动可能会影响所有已经定义好的设计。

最后我们还是选择了让事件本身保持简洁和概念一致，攻击事件   恢复事件   BUFF事件   等等等等，新的功能由新的事件来完成，旧的事件和处理方式不受到后期需求变动的影响。

就像前面剖析的一样，事件的结果对于双方是唯一一致的。事件也许会产生新的事件，但不要影响现在事件的处理。在前期设计中，我们产用事件产生时立即发放给双方的方式，这里的问题有三个

1.事件的处理不一致，这在前面已经说明了

2.可能会导致事件处理死循环，如果一个事件产生新事件，新事件再产生新事件。。。。。。。。。

3.只能处理没有生命期的事件

立即派发的方式不可取，我们可以选择采用LazySend的方式。在新的设计中，所有事件都在产生时被抛送到一个全局的事件管理器中，等待管理器去定期的更新和处理。当然这样事件的产生和处理就不在同一个时间片中执行了，但考虑到网络延时和事件管理器的更新频率，这个问题也没什么关系。