书籍链接：游戏编程模式 (tkchu.me)
重访设计模式
命令模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开
- 例子：按键输入、撤销重做
享元模式：运用共享技术来有效地支持大量细粒度对象的复用
这个模式通过将对象的数据分为两种来解决这个问题。 第一种数据没有特定指明是哪个对象的实例，因此可以在它们间分享。 Gof称之为固有状态，也有人视为“上下文无关”部分。数据的剩余部分是变化状态，那些每个实例独一无二的东西。这种模式通过在每个对象出现时共享一份固有状态来节约内存
例子：使用同一个模型进行实例渲染
观察者模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为
现代的解决办法是让“观察者”只是对方法或者函数的引用。 在函数作为第一公民的语言中，特别是那些有闭包的， 这种实现观察者的方式更为普遍
明日观察者：数据绑定
例子：成就系统
原型模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
- 给我的感觉是简化类的继承，直接把一个对象（或者说类）作为原型，而不是专门写一个抽象类来作为基本类，然后再继承一大堆出去，这样相当于省了两波，一波是省了重复属性或者方法的代码（可以直接委托到原型那里），第二波是省了创建基类和派生类的代码（用js语言比较好理解）
- 例子：javascript的原型
单例模式：保证一个类只有一个实例，并且提供了访问该实例的全局访问点，其拓展是有限多例模式。
给我的理解就是，单例模式其实就是一个全局的静态类对象，优点就是保证只有一个存在（并且在初次请求时创建并初始化），而且方便访问，问题也是由于方便访问，在不想访问的地方有可能出现问题
例子：文件操作系统封装类（不能同时写和删除）
状态模式：允许一个对象在其内部状态发生改变时改变其行为的能力
使用状态模式来使容易混淆的繁琐的ifelse代码整理得更清晰，更好改动
例子：有限状态机、并发状态机、分层状态机、下推状态机，animation blueprint
序列模式
双缓冲模式：当信息从缓冲区中读取，它总是读取当前的缓冲区。 当信息需要写到缓存，它总是在下一缓冲区上操作。
给我的理解就是，因为读取的信息是宏观上的一种最终状态（如渲染完成的画面或者处理完相互作用的实体们），所以如果在渲染到一半或者相互作用到一半就读取就会出现可见的错误（画面撕裂）或者行为不正确，因此需要先在一个缓冲区中将这个状态结果算好，再通过交换的形式来一次性显示
例子：图形学中的双缓冲
游戏循环：一个游戏循环在游玩中不断运行。 每一次循环，它无阻塞地处理玩家输入，更新游戏状态，渲染游戏。 它追踪时间的消耗并控制游戏的速度。
有很多种方式的游戏循环，有固定时间步长的，有动态时间步长的，二者各有优劣，但我感觉目前游戏引擎中（如unity和ue）使用动态时间步长的游戏循环居多。
例子：游戏引擎中的游戏循环
更新方法：通过每次处理一帧的行为模拟一系列独立对象。
给我的理解就是每一帧要update每个实体的行为，至于是如何实现这个功能，在哪个类实现，有多种选择，实体类、组件类或者委托类
例子：Unity引擎中的MonoBehaviour
行为模式
字节码：将行为编码为虚拟机器上的指令，赋予其数据的灵活性。
为了防止硬编码带来的长时间编译，将一些修改与调整以字节码的方式来进行。简单来说就是做一套工具（沙箱），来对游戏内容进行修改而不需要经过漫长的重新编译。比如使用栈式虚拟机，将字节码指令通过栈来存储调用
例子：定义基于文本的语言、图形化创作工具
子类沙箱：用一系列由基类提供的操作定义子类中的行为。
我的理解就是为了避免子类的耦合，把多种子类可能使用的功能写在基类的protect里面供子类调用，把耦合给基类负责。甚至如果沙箱方法太多，可以将多个方法集成到另外一个类中，这样只需要创建一个另外类的成员变量。为了优化还可以写一个静态的初始化函数来给成员赋值
例子：超能力系统类