架构主要目的不是解决【计算机运算】性能，而是让【人脑】的性能更好

我喜欢这个描述，这应该也是瀑布流和敏捷开发的区别。瀑布流要先打好一整个架构，然后再继续做，直到最后一刻，可能代码才会运行起来——这适合有经验的高手。

对于游戏玩法来说，做原型是好的，因为大部分玩法都很烂不值得继续努力。我倾向于先做玩法验证，在知道代码范围后，再根据定好的范围重写代码。

这里也有两种不同的观点：程序员欢迎重写，甚至会着魔地反复修改某个简单的功能，但不喜欢在临时项目上拓展。但其他行业的工作人员期待一次制作完成品并不返工（只需要问问设计行业会出多少版设计案）

享元模式 · Design Patterns Revisited · 游戏设计模式

虽然中文翻译是享元，但是英文是flyweight，英文反而更难理解，从字面意思推断应该是类似于【瘦身，减肥】，意即把重复累赘的部分去掉，让数据更轻量级。

这个模式在渲染优化里非常常见，GPU Instance应该就属于享元模式。但是软件开发中，自己写的代码通常没有复杂到需要享元模式的地步。

或者说，比享元模式更底层一些的概念已经太普及了，不需要再专门强调享元概念了，程序员从第一天开始就在学抽象原则：一次实现，多次复用。

这个作者的每篇文章似乎都有这个毛病，写一些没有代表性的代码，让人看着一头雾水——本来是讨论享元模式，但最后 却纠结起了枚举和指针哪一个更好。

观察者模式 · Design Patterns Revisited · 游戏设计模式

我曾经很久都不知道什么是委托，然而在学了一周后我豁然开朗——这不就是函数指针吗？接着发现如果没有函数指针，我也可以通过很丑陋的方式实现，甚至这和面向对象和面向过程也无关，只要一个语言有数组，能调用函数，它就能实现观察者模式。

由于几乎在每个设计模式的文章里都有介绍观察者模式，这里我就很快略过了。

虽然观察者模式的好处是，被观察者不需要知道是哪个观察者在观察他，但是每个文章似乎都在避免谈论另一件事：观察者也得有有一个好的路径去知道自己该观察谁，如果这里写的不好，照样会将代码变成很静态不能随便修改的粘稠液体。这就需要更高级别的框架了。

接着文章谈论到，调用委托和静态调用之间的差别，还有不用担心性能差别，我觉得这里预测对了很多人，在游戏里，除非代码写的极差，那么总是GPU消耗大于CPU，然而真正了解GPU优化的人，已经度过了不知道如何优化CPU的新手期。

接下来，作者又写起了基本的数据结构——根据不要重复造轮子理念，在这里重构链式委托并试图节省性能是很愚蠢的。

最后，我很遗憾这篇没有提到观察者模式的另一个好处，那就是组合大于继承，根据观察者模式，可以为一个功能写出拓展组件，而不更改功能本体。

原型模式 · Design Patterns Revisited · 游戏设计模式

这个设计模式更加垃圾了，用非常复杂的逻辑解决了一个甚至不存在的问题。

不推荐阅读这个模式，我敢打赌，在遇到复制、批量生产对象时，绝对没有任何一个现代的游戏会使用这个模式的思想。

这篇的后面，作者又再一次恼人的开始设计编程语言（更加底层了，我相信下一次他会教我们汇编）

而后面讲述的同一个类但是导入不同数据——是一个非常狗屎的办法，又称换皮。

如果你确定好了游戏对象可能出现的数值情况，并且在整个游戏中给所有对象都使用这一个模式，那就会面对1级打普通小龙虾，10级打狂暴龙虾，100级打变异彩色龙虾的无聊情况。

单例模式 · Design Patterns Revisited · 游戏设计模式

我喜欢单例模式的点子，它让我既可以使用静态类的好处，又可以享受非静态类实例的好处。让类与类之间的沟通变得很顺利。

很多框架都会忽略的问题就是，怎么构建合适的结构，划分类之间的连接关系。

要摆脱单例模式，需要创建一个有条理的，清晰的类之间的依赖关系，最好有功能的类之间都有道路连接起来，并且可以轻松从一个类访问到另一个类。我有些喜欢这样，就像规划火车路线一样。

值得一提的是，由于作者主要在谈论C++，C#中的规则是不同的， 在C#中，静态类在第一次有其他类调用它时初始化，而非在Main()运行前初始化。

状态模式 · Design Patterns Revisited · 游戏设计模式

主要的精华是状态机这一概念。学起来稍微复杂，一个简单的状态可能需要写六七个类，快一千行代码。但是很有价值。

学完之后发现其实就是包装过后的If else

双缓冲模式 · Sequencing Patterns · 游戏设计模式

太基本了，开始教我们计算机原理了。任何一个现代引擎都替你代劳了这些事情。

后半段似乎想讨论预输入的事情，但是又浅尝辄止。

游戏循环 · Sequencing Patterns · 游戏设计模式

这一章很有价值，在我刚学习编程但不知道游戏引擎如何运作的时候，我经常被这个问题困扰。因为普通的代码是不会计算帧率的，它会等待输入，没有新的指示便不会轻举妄动，不会有待机动画在每帧播放。实际上，我保持这种困惑状态有一两年。始终感觉自己学到的编程知识和现代的计算机系统对应不上。

我很喜欢这一章内容，不过因为都是我已经看过的，就没有什么新东西了。

虽然对现代的游戏很基础，但是到199X年，这东西还很新。我一直记得暗黑出现前的那些回合制RPG。你不输入，游戏就会一直等待。能看到世界在我之外正常运转的感觉真是太好了。

更新方法 · Sequencing Patterns · 游戏设计模式

我意思是，你可以基础，但不能这么基础吧？？？为什么要教我们从头开始创建引擎？

字节码 · Behavioral Patterns · 游戏设计模式

我保证，在写上面的读后感时，我并没读后面的内容。这一章真的从汇编开始讲起了。

我认为这一章不仅没用， 还是副作用。为了保证可移植性，不能考虑容易变动的计算机底层结构。

子类沙箱 · Behavioral Patterns · 游戏设计模式

我的耐心在被消耗，我认为这一章只是把面向对象中的继承多态还有接口用另一种方式描述了一遍。

作者甚至描述了父类中protected函数的用法：给子类用。

类型对象 · Behavioral Patterns · 游戏设计模式

和其他设计模式一样不明所以。也许只是真的没用。

我思考了怎么在实际工作中使用这个类型，最终苦恼的发现很难用上而且没有解决问题。

而且我认为作者对游戏数据的存储有不同的认知，其实在游戏加载时读取表格，然后运行时根据ID查表就可以了，但作者一直在探索各种各样的获取数据的方式。（我认为作者的方式很难实现多语言本地化）

组件模式 · Decoupling Patterns · 游戏设计模式

很不错的组件模式，很多引擎都在提倡组件大于继承。但是我认为也不用提前设计太多组件，先写功能，直到代码足够复杂，以至于你可以看出哪些部分要分离出去成为组件，再思考这个问题也不迟。

服务定位器 · Decoupling Patterns · 游戏设计模式

等同于unity中的GetComponent()，差不多是另一种单例模式，我认为其中一个问题是：在构思出一个可靠的代码架构后，如果每个类都尽量只负责自己的那部分工作，真的需要全局寻找的东西真的很少。

c#还有一个巨大的问题：一个类不能限制自己的数据对具体哪个访客开放或封闭，在C++中这个问题有一个好一些的解决办法：友元类，友元函数。

优化模式 · 游戏设计模式

后面的优化模式我就不再看了，因为优化和使用的什么引擎有巨大关系，而且作者主要在讲述怎么在CPU层面优化代码。

很多时候，这真的不重要，对于游戏来说，玩家真的很难同时面对一千多个同时在运算的对象（除非是开放世界），即使如此，GPU压力也会比CPU压力更大，即使需要考虑CPU压力，也更多是物理引擎的计算压力，而这和自己写的代码如何无关。

而且，真的要优化代码，也应该是在游戏的后期进行，不要提前优化是所有代码课都会讲到的事情。