们假设有这么一个游戏设定,

玩家之间可以通过派遣军队来攻打对方的城市 (军队由各种级别的士兵组成), 另外, 当一个玩家的军队路过某玩家城市附近的时候, 则在一定条件下经过城市的玩家会得到一个警告信息.

事件过程模拟:
  我们已经讲过只有事件才会影响玩家资源变化的轨迹,

所以在每次处理事件之前都会有一次隐含的计算事件当事玩家资源的过程.
  现在我们假设玩家
A要出兵攻打玩家B的城市(在从出发到B城市的路上会经过玩家C的城市的附近), 这里的事件处理是如何的呢è首先系统会通过距离及速度的公式得出A到达C城市附近的时间, 并产生一个经过C城市的事件

  这时产生一个事件
E1 A==>C   type=pass

by    src=A  dest=B 

startTime=400   Endtime=800

   于是到达系统的时间800的时候, 系统根据事件EC1的类型调用相关的事件处理例程处理此事件,于是在处理完EC1的时候, 会产生下一个事件,

EC2为到达B城市的事件
E2 A==>B  

type=fight    src=A  dest=B 

startTime=400   Endtime=1000

  于是到系统的1000时间点时, 系统根据事件类型, 调用战斗事件的处理例程,

并得到结果, 此时可能会再产生一个新的返回事件, 放入系统的事件队列.

   以上是一个简单的事件, 让我们再多一点思考:

假如由于城市C升级了相关科技, 它能够监测到有玩家军队经过的范围扩大了,

那我们要怎么做呢? 我们说, 一个城市如果升级科技,

系统会为其建立一个科技升级的事件:
E-Upgrade 

type=upgrade  src=C dest=NULL  startTime =500 EndTime=600

   这个事件的开始时间为其开始升级科技的时间,

结束时间为科技升级完成的时间, 于是当系统到时间600的刻, 开始调用升级科技相关的例程来处理此事件,

由于此事件增加了城市的监测范围, 它会更新所以dest=C type=pass by的事件(根据相关公式计算相关时间), 如果此时军队已经进入更新科技后的监测范围而没进入原来的监测范围,

那么我们说它会把原来的E1 AèC   type=pass by    src=A 

dest=B  startTime=400   Endtime=800事件更新并把它放到比它晚一个系统时间最小单位的事件队列中去 (这个新的事件相当于一个衍生时间, 根据我们前面的假定,

衍生事件是要晚于源事件的)
E1-up  A==>C   type=pass by    src=A 

dest=B  startTime=400   Endtime=601

   另外再举一个例子就是如果玩家取消了这个军队的行程呢?

这时我们会删除此事件, 并创建一个返回事件(如果途中经过其他城市会先创建一个新的pass

by的事件).

  以上大概是对事件模型的应用的一些解释. 这里我们还有一个问题, 如果模拟多方城市参与的军团作战呢?

这里的作战单位应该是多对多了似乎需要再对这个机制进行一下扩充

  最后再讨论一下事件的处理机制:
  个人认为事件的处理可以有两种方式: 查询时处理/定时处理.

  查询时处理: 我们知道,

事件是自用户交互而产生的, 假如没有用户交互, 就不会有事件的产生,

而我们处理事件也是为了让用户得到有效和及时的数据. 查询时处理的原则就是只有在用户请求更新数据的时候我们才处理在此系统时间点之前的所有事件(在没有用户处理前对于事件的处理是毫无意义的 (同样对于事件的处理只要我们能够按照顺序和把握时间点那么所有的结果都会是正确的),

查询时处理的好处就是可以保证系统负荷在没有用户请求的时候会很低.

它的特点是对于用户来说它看的信息是即时和正确的, 但是事件的处理可能不是实时的.

  但查询时处理有一个致命的弱点就是虽然用户得到的信息可以说是即时和正确的, 但是这只限于通过系统内部的查询机制来获取数据, 由于事件的处理的不实时性, 这可能会导致一些需要无法很好的完成: 发生某个事件时发送email通知玩家, 这一点就不好完成. 另外一个缺点可能是如果系统积累了太多事件等待处理,

可能处理第一个用户的请求时所需的时间相对较长.

  于是我们引入了定时处理的机制, 定时处理来说就是以系统时间的最小单位为一个时间片来对系统的事件进行处理,

这种好处是能够保证事件的发生始终是实时而准确的. 保证了实时通知的需要可以很好的完成.

另外考虑以下几种常见的情况:

  系统停机维护==> 停止资源增长,

这个其实还算简单, 主要是更新一些事件的发生时间和玩家资源计算的最后时间就ok

  基本到这里了, 关于事件机制就写到这吧, 其实一个webgame取胜的关键还是创意… 其他的都是小问题…