游戏设计模式阅读笔记9——序列模式（更新方法）

一、意图

        通过每次处理一帧的行为模拟一系列独立对象。

二、动机

         简单的更新，会堆积在游戏循环代码中。随着需要更新的对象越来越多，循环就会越来越杂乱无章。更新方法就是用来优化这个简单的循环逻辑。

三、更新方法

        简单的修复：定义抽象的updata（）方法。每个游戏实体封装自己的行为。这样就可以保持游戏循环的整洁，便于添加和移除实体。

         每一帧，游戏循环遍历集合，调用每个对象的updata（）函数。

         当然，也不是所有的游戏对象都需要更新，比如：棋牌游戏的棋子等。但也会需要更新动画等，所以这个模式也会被用到。

适用情况：

        

        状态模式可以在这里帮助我们存储状态。

        逐帧更新并不是真同步。比如A在B之前更新，则B更新时就会看到A更新后的技能。使用双缓冲模式就可以无视AB的更新顺序。

        当更新与增加对象和删除对象的行为一起时，也会出现不想出现的效果。比如：增加对象时，却不想让他更新，这时可以简单的添加一个更新对象总数来控制，每次更新一定量的对象就结束了。

        如果你在更新时，移除对象，且位于你更新对象之前，移除操作就会造成，漏掉一个更新的对象。这个可以在移除时强制更新一次列表，也可以在每次更新完再移除。只是给该移除的对象一个状态（比如死亡）。

四、实例代码

1.游戏对象简单类：

2.游戏世界类

 3.游戏更新

         但这里将Entity作为主类，再使用继承来定义不同的行为。不是一个很好的做法。

        多用“对象组合”，而非“类继承”。

        解决方法：使用组件模式。 这样，updata就是实体的组件而不是在Entity类中，这样就避开了为了定义和重用行为而创建实体所需的复杂类继承层次。只需要混合和组装组件。

更改后的实体：

        游戏循环代码到了每个实体的内部 。就如游戏引擎Unity的updata函数。

        这个模式就分离了游戏世界的构成和实现。每个类去实现自己的updata需要的实例，方法。整个计时器又是由游戏一致管理。

五、游戏更新的方法总结

        1.实体类

                如果需要的实体种类不多，可以使用。但不是主流的做法。只能使用继承来重用代码。

        2.组件类

                 组件可以进一步解耦单一实体中的各个部分。

        3.委托类

                可将类的部分行为委托给其他对象。将updata放在委托类中。

六、并不是所有对象都需要更新

       有的对象可能停用了，可能超出屏幕了，可能还没有解锁。就不用去每帧遍历它。

        可以使用单独的集合保存活动对象，在速度比内存要求高时，可以的优化。

        或者两个集合都同步修改，一个活跃的集合一个不活跃的集合。当修改一个时，两个同步更新。