游戏设计模式读书笔记：命令模式
模式定义
-
定义：将一个请求封装成一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。
-
看图（图片资源来自于百度，侵删）
模式的理解
-
所谓命令模式说白了就是把一个方法对象化。怎么来理解这句话呢？可以看下UML图中的Command的interface，里面有个execute方法，还有一个undo方法。undo我们后面说，从内容上看这个接口非常的简单，它主要是为一个方法（execute）提供一个对象的载体。
-
这样做有什么用?
- 使你可用不同的请求对客户进行参数化；
- 对请求排队或者记录请求日志;
- 支持可撤销的操作。
- 因为一个方法的执行过程中往往是无法中断或者取消的，另外就是如果不做特殊的编码或者写相对应的方法，一个方法的执行往往不可逆。命令模式通过将方法封装成对象，进而可以制作出一个方法对象的列表，这样在顺序执行列表的过程中就可以将未执行的方法取消掉，而且保留这个列表相当于保留了一个操作的日志，在反向执行undo的操作就相当于对执行顺序进行逆转了。所以undo方法基本上是execute方法的逆向操作。
在unity中的使用
- 在这里我没有什么自己的例子，而是推荐这篇文章，这里已经很好的讲述的如何在unity中使用，并且也有了示例代码。
进一步的思考
-
《游戏设计模式》的作者也提到了是类风格化还是函数风格化的问题，他提到了JS写的代码如何实现这个模式。在我看来，C#的Action和Func一样可以替代类来实现方法的封装。因为命令模式的核心是将请求（方法）封装成对象，因此是用类或者一个delegate都是可以的。
-
那么何时使用类，又何时使用delegate呢？
- 如果有undo的需求时采用类比较好，反之可以考虑delegate。
- 如果你的方法中使用了很多的共享的数据，你考虑使用享元模式时应该使用类，如果你的execute方法还调用了父类的方法，需要使用沙盒模式时应该考虑使用类。可以说一个复杂的逻辑方法中往往代表了数据和算法以及调用其它函数，这样的话一个Action可能并不能满足你的需要，因此类是你唯一的选择。
-
命令模式的一个很大的用途在于制作录像，也就是说如果我们有一个赛车游戏，那么录像的制作可以考虑只记录玩家的操作（命令），而其它的运动交给游戏逻辑（比如加速后的移动，碰撞后受到的影响等）本身来完成。这个应该是很多录像的实现方式。但是有个问题就是如何保障只使用命令的情况下，每次的游戏过程都能保证一致性。比如说一个赛车游戏中，玩家在躲避障碍的时候发布了左转命令，录像也忠实的记录了这个命令，但是在录像播放（游戏场景重现）时，依赖游戏逻辑是否能够完全正确的重现当时的场景，并且让这个左转的命令看上去是恰当的，这个十分考验引擎的计算准确性。
-
在多人联机游戏中是否应该使用命令模式来重现其他玩家的操作？因为我一直做的竞速游戏，所以如果考虑行为的一致性应该是使用命令模式来做的，但是有个问题就是帧率太高的话，可能出现客户端无法快速响应命令的问题，尤其是设备FPS不同的情况下。因此在使用命令模式的同时，做补帧是必要的。当然这个主要针对的是位移这个问题。
