《游戏设计模式》(游戏编程模式)全书笔记+Unity实现

以下部分只包含笔记，具体实现及项目说明可查看Github笔记中很多都是个人理解，目的是尽量让原本抽象的概念更易懂一些关于书名——书名直译是《游戏编程模式》，但在中文版致谢页中，被翻译成了《游戏设计模式》，“设计模式”一词来源于GOF。此书(GPP)虽与编程有关，但更本质上是设计思想，所以更倾向“设计模式”这个翻译链接

英文原版中文版

通过命令数据队列或栈可以轻易实现撤销、重做、时光倒流命令数据还可以形成日志，用于复现用户行为，便于重复测试同样序列命令对各种目标的影响这些命令数据可以发送给不同的目标，比如同样的“出发，5分钟后，停止”，发送给飞机就可以变成“起飞，5分钟后，降落”，发送给轮船就成了“离港，5分钟后，抛锚”

传递的信息享元化，可以节约计算时间存储的信息享元化，可以节约占用的空间所以享元模式可以减少时间与空间上的代价

解耦，物价局改了粮价不需要挨家挨户通知公民，只需要让电视台播个新闻就好如果要挨家挨户通知，物价局必须有每个公民的地址，这显然不合理，也会浪费很多资源扩展困难——如果公民改了地址或者有新公民出生了，那还需要告诉物价局，这也很荒唐

复用生成器，而非针对每一个不同的对象做一个生成器与享元模式结合，通过配置表来实现对象的个性，将不同配置与代码解耦

Unity中Prefab本质就是此模式里的原型，而Spawner要做的只是调用Instantiate方法新的Prefab被生成以后，通过读取Dragons.txt里配置的信息来设置克隆体的名称和尺寸

注：这里为了快速实现使用txt记录配置表（我在偷懒），但实际项目里，往往使用SQL、Json、csv等方式进行配置

减少代码复用，让专门的类处理专门的事情——例如让TimeLog类来记录日志，而不是把StreamWriter的代码写到每一个类里快速访问，任何其他类都可以通过ClassName.Instance来访问单例，使用它的公开变量和方法

因为实现简单，而且使用方便，所以有被滥用的趋势滥用单例会促进耦合的发生，因为单例是全局可访问的，如果不该访问者访问了单例，就会造成过耦合——例如如果播放器允许单例，那石头碰撞地面后就可以直接调用播放器来播放声音，这在程序世界并不合理，而且会破坏架构如果很多很多类和对象调用了某个单例并做了一系列修改，那想理解具体发生了什么就困难了对多线程不太友好——每个线程都可以访问这个单例，会产生初始化、死锁等一系列问题

使流程清晰化、结构化简化判断逻辑，比如嘴的状态是洗牙，那就不应该做出咀嚼的行为；必须是在憋气，那就不应该做出呼吸的行为

状态机（自动机）是我最喜欢的一种设计模式，因为这样设计的程序逻辑清晰，稳定性也很强作者对switch case下的状态机理解并不深刻，一般情况下，状态机需要两个switch case，一个用于处理状态变化，另一个用来处理状态行为相比状态类，个人更喜欢switch case的方法，虽然状态类有其有点，但缺点也非常明显——当状态量较大时，代码量激增，可读性也很差，状态变化和状态行为都需要大量的信息传递，十分不便

SwitchCase版本，用按键控制一盏冷暖灯，关灯状态下，按一次打开暖光，再按切换为白光，再按变为暖白光，再按关闭状态类版本，交通灯 停止、通行、闪烁、等待的切换

双缓冲模式

当一个缓冲准备好后才会被使用——就像一个集装箱装满才会发货一样；当一个缓冲被使用时另一个处于准备状态，就形成了双缓冲在渲染中广泛使用，一帧准备好后才会被渲染到屏幕上——所以准备时间太长就会导致帧率下降

游戏循环

可参考脚本生命周期

更新方法

同上，实际上是Unity通过反射在生命周期不同时刻调用MonoBehaviour中的相关方法

字节码

享元模式、原型模式中，不同的属性被存储在数据库中，而字节码是将行为存在数据库中可用于实现可视化脚本编辑工具

子类沙箱

子类使用基类方法，或在基类方法上扩展

类型对象

其实是享元模式、原型模式的一种应用，以不同数据（而不是不同类）区分对象类型

组件模式

本质上是功能的模块化，延伸了面向对象的解耦思想U3D的编程思想就是面向组件的，MonoBehaviour的子类都可作为组件挂在GameObject上

事件序列

就像银行办事需要排号一样——每个顾客要处理的事都是一个事件，编号后就形成了天然的事件序列，银行会按一定规则来依次处理队列中的事件一般在底层实现，但宏观上依然存在，例如RTS游戏中通过Shift对一些单位下达前往不同位置的命令Unity中协程可以用来做消息队列，防止同帧产生大量的计算

服务定位器

类似单例模式，在运行时寻找组件（而不是运行前赋值）Unity中GetComponent，FindObjectOfType，Find等方法都可帮助实现相关服务的查找，但此类反射方法要避免在运行时高频循环调用拓展——还可以建立一个运行前赋值的服务注册中心（当然也可运行中赋值），其他需要服务的对象在运行时去注册中心查找相关服务，这样做一方面可以避免全局反射的恶果，一方面可以保留服务定位器带来的解耦优势——单例模式也可使用这样的方法来替换（对象注册中心）