读《游戏设计模式》有感

电子书链接

《游戏设计模式》

章节总结

命令模式

• 将请求封装为独立的对象，从而实现对请求的参数化、队列化
• 优点
  • 高度解耦
  • 撤销和重做：通过保存命令历史实现，如果不使用命令模式很难实现
• 缺点
  • 代码量爆炸
• 实践用处：监听用户输入就是个很典型的命令模式

享元模式

• 简单理解就是将一个类里的完全公用的属性抽离出来，用单独的一块内存存储，而不是每个类的实例都去维护一块自己的，浪费内存。
• 比如我们要绘制一片森林，这些树大部分长得一样，那么它们就有相同的纹理、树叶、树枝等属性，这类属性就抽离出来。
• 在性能方面，与枚举有可比性

单例模式

• 单例顾名思义就是某个类全局只声明了一个实例，并向全局提供了访问这个实例的访问点。
• 通常为了确保该类只能被声明一次，该类的构造函数会写成私有属性，通过对外暴露静态属性instance防止多次构造。
• 优点
  • 没有使用到的时候，不会创建实例，节约内存
  • 虽然是单例，但是可继承。比如FileSystem是一个单例，但是我们可以在其基础上，根据不同的系统或平台抽象出其他文件系统，比如区分索尼和任天堂，就可以用 SonyFileSystem : FileSyetem 和 WiiFileSystem。
• 缺点：根本原因就是它是一个全局变量
  • 代码可读性差
  • 促进耦合的发生
  • 并行不友好：游戏开发中难免会用到多线程，如果多个线程都想使用某个单例，那就会带来竞争、死锁等问题。
• 实践用处：
  • 文件系统
  • 媒体系统
  • 网络模块

状态模式

• 使用有限状态机（FSM）的模式
• 优点
  • 使用传统的分支判断，容易遗漏分支条件，且可拓展性极差，每有一个新状态的延伸，都会引入一堆bug和新的分支
  • 同一状态下的所有操作、转移代码都放在一起，可读性好
• 实践用处：
  • 角色模型动作状态转换控制（一般先画状态转移图STD，再在代码中用enum和switch分支实现转移，进阶写法不用switch，用状态委托）
  • 并发状态机，比如FPG类，除了模型动作，持枪动作也是要考虑的，但是两者的状态转换不同，只是需要同样的input

双缓冲模式

• 当前缓冲用于完成实时的任务（比如当前帧的场景绘制），下一缓冲需要提前利用资源进行计算，等待下一帧的使用
• 交换缓冲区用交换指针或引用来实现