《游戏设计模式》笔记 01 序章

我因为最近在学习游戏开发相关知识，然后意识到自己设计模式知识缺乏，所以就去寻找相关书籍，这时候《游戏设计模式》这本书就跳到了我的眼前。

github上有大佬将这本书翻译了，中文版阅读地址在这：架构，性能和游戏 · Introduction · 游戏设计模式 (tkchu.me)

序章：架构，性能和游戏

1.好的软件架构

对于作者而言，好的设计意味着改动轻松。

2.如何处理改动？

需要改动代码之前，你必须理解代码。而当你改动代码后，下个编写代码的人就需要重新理解代码。

这是编程中最耗时的部分，而解耦可以帮上忙。

3.解耦帮了什么忙。

作者认为如果两块代码是耦合的，那么无法只理解其中一个。如果解耦它们，就可以单独理解某一块，这样理解代码的时间就减少了。

对作者来说，软件架构的关键目标是：最小化在编写代码前需要了解的信息

当然，解耦后，可以单独修改其中某一块，这样波及的范围就会少。

4.解耦很好，那么代价是什么呢？

如果你足够熟练，也许能花少的力气写出最优雅的代码。

但事实上，我们大多数每次做出改动或是实现特性，都需要花费大量的努力去管理代码，使程序在千百次的变化中仍能保持它的结构。

所以，你得考虑程序的那部分需要解耦，再引入抽象。

但是，事情从这里开始变得棘手。每当你添加抽象或扩展支持，你就是赌以后这里需要灵活性，这些代码以后会被需要。如果赌对了，那么非常好，但是赌错了，你就得处理更多代码。

而当你过分关注这点时，代码库就失控了。因为接口和抽象无处不在，各种各样的扩展点，它们遍地都是。因此，你会消耗无尽的时间回溯所有的脚手架，去寻找真正做事的代码。

理论上解耦意味着改动需要理解的代码变少了，但抽象层本身也会填满大脑。

这样的代码库，会使得人们反对软件架构，特别是设计模式。

5.性能和速度

软件架构和抽象有时因损伤性能而被批评，而游戏开发尤甚。

让代码更灵活的许多模式依靠虚拟调度、接口、指针、消息和其他机制，它们都会加大运行时开销，因为知道运行时才知道调用的类。这更加灵活，但增加了运行时开销。

而写代码调用类中的具体方法时，你就是在写的时候指定类——硬编码了调用的是哪个类。这更快，但不灵活。

模板编程这是两级之间。在编译时初始化模板，决定调用哪些类。

要么损失一点点性能的前提下，让程序更加灵活以便更快地做出原型；要么优化性能，损失一些灵活性。

作者认为：让有趣的游戏变得高效比让高效的游戏变有趣简单得多。 一种折中的办法是保持代码灵活直到确定设计，再去除抽象层来提高性能。

6.糟糕代码的优势

编写构架良好的代码需要仔细地思考，这会消耗时间，而在项目的整个周期中保持良好的架构需要花费大量的努力。

而游戏设计需要很多实验和探索，特别是早期，写一些你知道将会扔掉的代码是很普遍的事情。

与此同时，你得让人们清楚，可抛弃的代码即使看上去能工作，也不能被维护，必须重写。

作者的小技巧：

一个小技巧能保证原型代码不会变成真正用的代码：使用和游戏实现不同的编程语言。 这样，在将其实际应用于游戏中之前必须重写。

7.保持平衡

有些因素在相互角力：

1. 为了在项目的整个生命周期保持其可读性，需要好的架构。 2. 需要更好的运行时性能。 3. 需要让现在想要的特性更快地实现。

好的架构长期来看提高了生产力， 也意味着每个改动都需要消耗更多努力保持代码整洁。

草就的代码很少是运行时最快的。 相反，提升性能需要很多的开发时间。 一旦完成，它就会污染代码库：高度优化的代码不灵活，很难改动

8.简单

作者认为：简化这些限制的办法就是——简单。努力去写最简单、最直接的解决方案。目标是正确获得数据结构和算法（大致），然后再从那里开始。

简而言之就是，蒸干代码，对于多种情况，我们想象最优雅的代码时，想的是通用的那个：只需要很少的逻辑就可以覆盖1整个用况。

9.作者建议：

• 抽象和解耦让扩展代码更快更容易，但除非确信需要灵活性，否则不要在这上面浪费时间。

• 在整个开发周期中为性能考虑并做好设计，但是尽可能推迟那些底层的，基于假设的优化，那会锁死代码

• 快速地探索游戏的设计空间，但不要跑得太快，在身后留下烂摊子。毕竟你总得回来打扫。

• 如果打算抛弃这段代码，就不要尝试将其写完美。摇滚明星将旅店房间弄得一团糟，因为他们知道明天就走人了。

• 但最重要的是，如果你想要做出让人享受的东西，那就享受做它的过程。