原文链接：http://gameprogrammingpatterns.com/type-object.html
允许用一个类去创建一些新“类”，每一个新“类”产生的实例都代表了一种对象。
假如我们在做一个牛逼的角色扮演游戏。我们的任务是用代码实现一群邪恶的怪物，它们试图干掉我们的英雄。怪兽们有很多属性：血量，攻击，外观，声音等等。但我们只以前两个为例。
每个怪兽都有一个记录当前血量的值。开始是满的，每次受到伤害，就会减少。另外，怪兽还有一个代表攻击的字符串，每一次怪兽攻击英雄，这些文字就会以某种形式显示出来（先不用关心怎么显示）。
用基类提供的操作集合，去定义子类的行为。
每个孩子都有一个当超级英雄的梦，但是地球上并没有那么多宇宙射线（可以让人变异的射线）。但是，游戏能让你成为虚拟的英雄。因为在我们游戏设计师的字典里，没有”不行”，我们的目标是为超级英雄提供几十甚至上百种超能力，供英雄们选择。
我们的计划是先定义一个Superpower基类。然后，我们将会有子类去继承它，每一个子类实现一种超能力。我们会写一个设计文档，分发给团队中的程序员去编码。完成后，我们会的到100个超能力类。
原文链接：http://gameprogrammingpatterns.com/bytecode.html
通过将数据编码成虚拟机的指令，为行为带来数据适应性。
做游戏很有意思，但是不容易。现代游戏需要大量复杂的代码。主机厂商和App市场的审核人员有一套很严格的质量标准，可能一个小小的崩溃bug就会让你的游戏上不了线。
同时，我们确实希望压榨平台的性能。游戏推动着硬件的发展，我们必须通过变态的优化来保持竞争力。
原文连接：http://gameprogrammingpatterns.com/update-method.html
模拟一批相互独立的物体，让他们每次只进行一帧的动作。
玩家控制着强大的瓦尔基里(北欧神话中奥丁神的婢女之一)，去偷巫王遗留的稀世珍宝。她试探着接近巫王宏伟的藏宝室，然后…没有遇到任何阻击。没有被诅咒的雕像向她射击。没有不死的骷髅兵在入口巡逻。她只是径直走过去用连锁勾起战利品。游戏结束，你赢了。
原文连接：http://gameprogrammingpatterns.com/game-loop.html
将游戏时间的进度从玩家输入和处理器速度中分离出来。
如果让我选一个本书最不能少的模式，那就是这个。游戏循环是游戏编程模式中最精髓的一个例子。几乎所有的游戏都会有它，再也没有第二个应用如此广泛的。但是在游戏之外有很少用到。
要看它是如何起作用的，让我们把记忆拉回到过去。在哪个编程跟洗碗工一样的青葱岁月。你需要把一堆代码塞进机器，按下按钮，等待，然后出结果。这就是批次模式的编程——一旦工作完成，程序就停止运行了。
原文链接：http://gameprogrammingpatterns.com/double-buffer.html
使一系列操作看起来像瞬间或者同时发生的。
计算机的心脏在不停地跳动着。他们的力量体现在，能够把一个很大的任务拆分成能够一个个完成的小步骤。通常我们的用户希望看到一个任务能够瞬间完成，或者很多任务能够同时进行。
一个典型的例子，渲染是每个游戏引擎都应该具备的功能。当游戏绘制玩家所见的世界时，它在一小片时间内画了——远处的大山，起伏的山丘，树木，一个接一个的画。如果用户能够看到这个渐进的绘制过程，会产生山河破碎的感觉。所以，场景必须能够平滑快速的更新，迅速显示一连串渲染完成的帧。
原文链接：http://gameprogrammingpatterns.com/state.html
认错时刻：在这一章里，我有的包装和修饰有点过分了。看起来是在讲状态模式，但是我发现如果不讲有限状态机的基本概念，我几乎没法讨论状态模式和游戏。但是一旦我讲了，感觉就像是在介绍分层状态机和下推自动机。
这样牵扯的太多了，所以为了尽量保持简洁，实例代码留下了一些细节需要你自己去填写。我希望他们仍然能够表达清楚大体意思。
http://gameprogrammingpatterns.com/singleton.html
本章是个奇葩。本书的其他章节都是告诉你怎么用一个设计模式。这一章告诉你怎么不用。
除了崇高的理想，GOF在书中对Singleton模式的描述，弊大于利。他们强调这种模式应该保守地使用，但这一条在游戏工业中并不奏效。
像其他模式一样，在不适当的地方使用Singleton，就像用夹板处理子弹伤口一样。由于它被大量地滥用，这章的大部分内容将告诉你避免使用Singleton，但是一开始，我们还是要先从Singleton本身开始。
原文链接：http://gameprogrammingpatterns.com/prototype.html
我第一次听说“Prototype”这个词是在设计模式中。今天我发现大家都在说这个词，但是已经不是在谈设计模式了。我们会在这里展开讨论，但是我也会给你介绍一些别的有趣的地方，以及一些其他的衍生概念。但让我们先领略一遍经典的内容。
假设我们在做一款类似《圣铠传奇》的游戏。在英雄的周围会产生很多生物和魔鬼，企图分享他的肉。这些恶心的晚餐伙伴是通过“卵”进入场景的，并且不同的敌人用的是不同的卵。 在这个例子中，我们为每一种怪物创建一个类-Ghost，Demon，Sorcerer等等，像这样：
|
1 2 3 4 5 6 7 8 |
class Monster { // Stuff... }; class Ghost : public Monster {}; class Demon : public Monster {}; class Sorcerer : public Monster {}; |
一个卵的构造函数实例化一个特定的怪物类型。为了支持游戏中所有的怪物，我们简单粗暴得为每一种怪物写一个卵类，构成了这个并行的类结构。
像这样实现他们：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
class Spawner { public: virtual ~Spawner() {} virtual Monster* spawnMonster() = 0; }; class GhostSpawner : public Spawner { public: virtual Monster* spawnMonster() { return new Ghost(); } }; class DemonSpawner : public Spawner { public: virtual Monster* spawnMonster() { return new Demon(); } }; |
除非你是按代码行数付费的，否则堆砌这么多垃圾可不时间令人预约的事。大量的类，大量的冗余代码，大量的副本，大量的复制，大量的重复…
原型模式提供了一个解决方案。主要思想是一个对象可以产生其他跟他相似的对象。如果你有一个Ghost，你可以用它产生更多的Ghost。如果你有一个Demon，你可以产生其他Demon。任何一个怪物都可以被当作一个原型怪物，用来产生其他的分身。
为了实现这个，我们提供一个基类，Monster，和一个虚函数clone()：
|
1 2 3 4 5 6 7 8 |
class Monster { public: virtual ~Monster() {} virtual Monster* clone() = 0; // Other stuff... }; |
每一个怪物的子类都可以实现一个方法，返回一个跟自己类型状态一模一样的新对象。例如：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
class Ghost : public Monster { public: Ghost(int health, int speed) : health_(health), speed_(speed) {} virtual Monster* clone() { return new Ghost(health_, speed_); } private: int health_; int speed_; }; |
原文连接：http://gameprogrammingpatterns.com/observer.html
你再也找不出一台电脑，里面没有用MVC架构构建的软件。MVC的底层就是Observer 模式。Observer模式应用如此之广泛，以至于java将其纳入核心库（java.util.Observer），C#甚至已经把它固化到语言中（event 关键词）。
Observer是经典GOF设计模式中，最被广泛使用和熟知的模式之一。但是游戏开发界却被诡异地隔绝了，所以对你来说，可能比较陌生。如果你还没有染指过，让我来带你看一个激动人心的例子。
原文连接: http://gameprogrammingpatterns.com/flyweight.html
雾气散去，壮观的原始森林展现在我们面前。古老的铁杉，不尽其数。像一座塔尖林立的绿色教堂。在巨大的树干之间，你只有拉开一定距离才能辨认出这是一个巨大的森林。
这是作为游戏开发者梦想的世外桃源般的设计，而这种场景往往因为一个设计模式的运用而变为现实。这个模式的名字就是再低调不过的：Flyweight（被很多书根据意思翻译为享元）。
原文连接：http://gameprogrammingpatterns.com/command.html
Command模式是我最喜欢的模式之一。在我写过的大多数大型的程序，游戏和其他代码中，随处可见。正确地使用它，可以让一些丑陋的代码变得整洁。这样一个漂亮的模式，“Gof”(《设计模式-设计模式:可复用面向对象软件的基础》的四个作者)给出了一个极其抽象晦涩的描述：
将一个请求封装成一个对象，从而可以让用户使用不同的请求，队列或者日志请求去参数化客户端，并且支持撤销操作。