← 全部标签
# 设计模式
19 篇页面
页面
游戏开发事件队列Event Queue事件队列 (Event Queue) 用一个先进先出队列，把“发送消息或事件”和“处理它”在时间上解耦：发送方入队后立即返回，接收方在自己方便的时候再取出处理。它比观察者和命令模式多做的一件事是时间上的解耦，适合“推”与“拉”两端节奏不同的场合（例如音频请求），代价是全局可见、世界状态可能已经改变，以及可能出现隐蔽的反馈回环。游戏开发享元模式Flyweight Pattern享元模式 (Flyweight Pattern) 把对象的数据拆成可共享的“内在状态”和每个实例独有的“外在状态”，让大量对象共用一份内在状态。森林里成千上万棵树共用一份网格和纹理，以及瓦片地图中每格只存一个指向共享地形对象的指针，都是它的典型应用。游戏开发单例与服务定位器Singleton & Service Locator单例 (Singleton) 同时承诺两件事：一个类只有一个实例，并且提供全局访问点。Nystrom 认为它在游戏里弊大于利，因为单例本质上就是全局变量。服务定位器 (Service Locator) 是更灵活的“近亲”：它同样给出全局访问点，但调用者只依赖抽象服务接口，具体实现由定位器在运行时或编译期决定，还可以退化为空服务。两者都应当慎用，首选仍是直接把对象传进去。游戏开发原型模式Prototype Pattern原型模式 (Prototype Pattern) 的核心思想是“一个对象可以生成与自己相似的对象”：生成器持有一个原型实例，通过 clone() 复制出类和状态都相同的新对象。Nystrom 认为这个设计模式本身在现代游戏中很少是最佳答案，更有价值的是“原型委托 (delegation)”用于数据建模，让数据条目继承另一条目的属性，减少重复。游戏开发双缓冲Double Buffer双缓冲 (Double Buffer) 让一系列按顺序执行的修改，在外界看来像是瞬间、同时完成的：类内部保留“当前缓冲”和“下一缓冲”两份状态，读取总是读当前缓冲，写入总是写下一缓冲，改完后用一次原子交换让新状态整体生效。图形里的前后缓冲是最经典的例子；同样的思路也能让一帧内依次更新的游戏对象互相看到的都是上一帧的一致状态。游戏开发命令模式Command Pattern命令模式 (Command Pattern) 把一次方法调用“物化”成对象，从而可以存储、传递、延迟执行、排队或撤销。游戏里最典型的三种用法是：可配置的按键映射、让玩家输入和 AI 共用同一套“驱动角色”的接口、以及撤销/重做。游戏开发子类沙盒Subclass Sandbox子类沙盒 (Subclass Sandbox) 让基类提供一组受保护的“提供的操作”和一个抽象的沙盒方法，派生类只用这些操作来实现沙盒方法。这样大量派生类（例如几十种超能力）只耦合到基类，不直接接触引擎的各个系统；代价是基类会越来越臃肿，变成脆弱基类。游戏开发字节码模式Bytecode Pattern字节码模式 (Bytecode Pattern) 把行为编码成虚拟机 (VM) 能执行的指令序列，让行为拥有数据一样的灵活性：可以热加载、与引擎核心隔离（沙盒化），还可以由非程序员编写。它是全书最复杂的模式，代价是要写编译器或创作工具，调试器也用不上了，而且这类小语言容易无节制地膨胀。游戏开发对象池Object Pool对象池 (Object Pool) 预先一次性分配一组可复用对象，需要时从池里取一个未使用的对象并初始化，用完标记为未使用，而不是逐个 new/delete。它能避免频繁分配的开销和堆碎片，常用于粒子、子弹、正在播放的声音等。代价是池大小要调校、同时活跃的数量有上限、复用的对象不会被自动清零，在有 GC 的环境里还可能让本该回收的对象一直活着。游戏开发数据局部性Data Locality数据局部性 (Data Locality) 是一种优化思路：CPU 读取内存时会把相邻的一整条缓存行一起载入，所以把数据按处理顺序连续存放，就能大幅减少缓存未命中。具体手段包括：组件按类型存进连续数组，不再到处跟随指针；把活跃对象排在前面；把冷热数据拆开。代价是要放弃一部分继承、接口与指针带来的抽象。游戏开发游戏循环与更新方法Game Loop & Update Method游戏循环 (Game Loop) 让游戏时间的推进与玩家输入和处理器速度脱钩：每一轮非阻塞地处理输入、更新状态、渲染，并跟踪真实时间来控制节奏；最常推荐的做法是“固定更新步长、可变渲染”。更新方法 (Update Method) 是它的搭档：世界维护一组对象，每个对象实现一个模拟“一帧”行为的 update()，每帧依次调用。两者和组件模式一起常被视为游戏引擎的核心。游戏开发状态模式与有限状态机State Pattern & Finite State Machines状态模式 (State Pattern) 把对象“依赖状态的行为”分散到各个状态类中，对象只持有指向当前状态的指针并把调用委托给它，状态切换就是换指针。它是实现有限状态机 (Finite State Machine, FSM) 的一种方式。FSM 能用很强的结构约束理清一团乱麻的标志位代码；状态组合爆炸、需要复用和需要“回到之前状态”时，分别用并发状态机、分层状态机和下推自动机来扩展。游戏开发空间分区Spatial Partition空间分区 (Spatial Partition) 把对象按位置存进空间数据结构，使“找出某位置附近的对象”这类查询不必遍历所有对象，把 O(n) 或 O(n^2) 的操作降下来。最简单的是固定网格；还可以选层次结构（四叉树、BSP、k-d 树、BVH），以及边界固定或随对象自适应的划分方式。代价是对象移动时要更新结构，并且要额外占用内存。游戏开发类型对象Type Object类型对象 (Type Object) 用“一个类的不同实例”来表示不同的逻辑类型：例如不为每种怪物写一个子类，而是一个 Monster 类加一个 Breed（种族）类，每个 Breed 实例描述一种怪物，怪物只持有指向自己 Breed 的引用。这样新增或修改种类只需要改数据，不必重新编译；代价是要自己管理这些类型对象，而且给每种类型定义不同的“行为”会变难。游戏开发组件模式Component Pattern组件模式 (Component Pattern) 让一个实体横跨多个领域（输入、物理、图形、AI……），同时不让这些领域彼此耦合：每个领域的代码放进自己的组件类，实体本身退化为组件的容器。它是现代引擎实体模型的基础，代价是对象变成需要正确装配的一组对象，组件之间如何通信也成了要做的设计决策。游戏开发脏标记Dirty Flag脏标记 (Dirty Flag) 用一个布尔标记记录“派生数据是否已经过时”：原始数据变化时置位；需要派生数据时，如果标记已置位就重新计算并清除标记，否则直接用缓存的结果。场景图里由局部变换求世界变换是经典例子。它只在原始数据变化比派生数据被使用更频繁、而且难以增量更新时才划算，最大的风险是漏置标记导致使用过时数据。游戏开发观察者模式Observer Pattern观察者模式 (Observer Pattern) 让一段代码宣布“发生了某件事”，而不必关心谁会收到通知：主体 (Subject) 维护一个观察者列表，在事件发生时逐个同步调用它们。它适合连接彼此几乎无关的子系统（例如物理与成就），但要注意同步阻塞、观察者的注销，以及运行时才能确定的通信关系难以推理。游戏策划机制设计模式Mechanics Design PatternsAdams & Dormans 把游戏机制结构中反复出现的模式称为设计模式，用 Machinations 图描述，组成一套以"内部经济结构→涌现玩法"为质量观的模式语言 (Pattern Language)。第 7 章介绍历史与用法，附录 B 按 GoF 格式详述 16 个模式：引擎 (Engines) 4 个、摩擦 (Friction) 4 个、升级 (Escalation) 3 个、杂项 5 个。模式之间存在细化 (Elaboration) 关系：所有引擎都是源的细化、所有摩擦都是泄的细化，可借细化/简化调整设计的复杂度与焦点。综合游戏编程模式选型：解耦与性能Choosing Game Programming Patterns本页把《Game Programming Patterns》里的 19 个模式放到同一张取舍图上：大多数模式要么为了解耦（降低改代码时需要装进脑子里的知识量），要么为了性能（利用对数据和硬件的具体假设），而这两个目标经常互相拉扯。下面先讲全书的定位和 Nystrom 的架构观，再给出按问题选模式的路线和与 UE 的对照。