炉石传说程序猿眼中游戏的事件驱动

　　我 们来看一下这个机制：食尸鬼的代码写在食尸鬼这里，诅咒的代码写在诅咒这里。如果我们把食尸鬼改为“己方随从死亡+2攻”呢?很简单，在食尸鬼这里直接改 就好。如果删除了食尸鬼这张牌呢?直接删就好了。如果我们要增加一个类似机制的卡牌呢?也很简单，加一个，上场的时候把自己加到通知列表里，就能得到通 知，并且在得到通知之后做相应的事情就好了。

　　食尸鬼给自己+1攻;诅咒教派领袖会检查这个单位是不是己方的，是己方的，就抽张牌，不是的话，不产生动作;奥秘救赎会检查更多的东西，是否是对方的回合而且是己方的单位，如果是，触发救赎。死亡这个事件通知表中并没有其他单位了，这个死亡事件结束。

　　如果有一个机制，每当有随从死掉的时候，都能及时让食尸鬼知道，然后由食尸鬼去决定它应当如何，是不是会好很多呢?比较合理的是设计一个“事件-通知”的机制，把发生的各种事件，通知到各个单位，让他们自行决定是否应当处理。

　　OK 看起来不错，那么看起来这是一个可行的方案。但是这个方案存在一个问题，就是各种各样具有特殊效果和需要结算的随从太多了，而且还要考虑法术和其他影响因 素等复杂性，这么干的话，这个函数是不是得上5000行，甚至上万行?同时改版的时候，改一张卡就得到这类来改，工作量巨大，依然不实际。而且除了“死 亡”事件，炉石里面还有很多“受伤”、“减费”等等其他事件和影响因素，每一个都会产生一个类似“死亡”的上万行的巨大函数。

　　明确上述的问题，在此探讨一下可行的方案：

　　“通知表”是炉石的事件触发机制核心，也是炉石在代码层面可以水平扩充卡池、增添各种特效的基础。每个单位产生时，会根据自己的特效，把自己注册到一些表中去。这里说的产生可能不是随从上场，而是游戏开始的时候，系统对卡牌进行初始化的时候。

　　如果从不合适的类别出发来写函数，工作量会非常大，运行效率低下，无法投入实际运行。

　　这个列表里有一个食尸鬼，一个诅咒教派领袖，还有一个奥秘“救赎”，那么我们依次通知他们，食尸鬼立刻就知道了有一个单位死了，按照既定的触发

　　举例说明：

　　顺序：

　　以上就是我认为的可行的炉石的基本实现机制。

上一页  [1] [2] 

　　有 了这样的机制，我们清楚地看到了一个事件被通知到了相关单位，触发了特效，又触发了其他的事件，事件的通知又触发了其他单位的特效处理。简单来说就是某个 随从对某个事件感兴趣，然后按顺序各自完成了自己的特效。这个模型中，我们可以添加更多的特效，更多的卡牌，只要依次实现他们自己的逻辑即可，加入新卡、 新机制，也不用修改旧代码。

　　至此我们能得出结论：不能采用“事件发生在哪里，相关的代码就写在哪里”的策略，该策略会导致超类的代码无限膨胀，每次修改的时候还得改那个几万行代码的逻辑，一旦出错就是“调皮的小精灵”。

　　每个单卡需要实现自己内部逻辑，然后就是要知道自己在初始化的时候要注册哪几个通知表即可。只要能获得及时正确的通知，就能正确地响应和实现特效。

　　我 们大概会需要抽牌、回合开始、回合结束、使用法术、使用一张牌、弃一张牌、随从产生、随从死亡、一个单位受到伤害、一个单位受到治疗、一个单位被法术命 中、奥秘被触发(这和法术被使用完全不同)、疲劳、触发战吼、触发亡语等类型的通知表。随着游戏不断推陈出新，可能还有很多其他的通知表和新事件。要注意 每个事件可能会引起其他的事件，比如小蜘蛛死了之后给食尸鬼+1攻，然后出来2个小蜘蛛，飞刀飞2刀，飞中了铸甲师，加了2点甲，又给暴乱加了2攻。

　　比如刚刚我们说的，“死亡”这个特效的事件通知表。食尸鬼对随从的死亡感兴趣，希望得到通知，所以它上场之后，就把自己注册到这个通知表里面。

　　这种“通知列表-注册-通知”的机制，在软件工程学里叫做“观察者模式”。

　　如果有玩家手牌里有严正警戒，给它-1费(最少是0);//这是严正警戒的