游戏开发入门（二）游戏中的设计模式

Admin

视频链接：游戏开发入门（二）游戏中的设计模式（3节课 时常：约2小时40分钟）
该视频主要围绕游戏中常见的设计模式展开讲解并实践，需要大家多多实践与理解

---

笔记与总结（请先学习视频内容）：

1.有必要深刻的认识到设计模式的意义
游戏开发是一个软件工程，他的特点是需求极易变化。对于任何一个软件工程，我们要从代码的组织方式上来提高其可读性（别人也很容易理解），安全性（不能经常出bug），易用性（逻辑复杂，思路太偏，使用上各种麻烦），健壮性（要能良好的处理意外情况），可维护性（是否容易修复与修改），可拓展性（是否容易添加功能），封装和复用性（一段代码不要到处拷贝粘贴）

2.游戏项目的特点
对于游戏项目来说，除了上面的问题，我们更要注意其可拓展性，因为游戏的需求每天都可能发生变化，所以在写游戏逻辑的时候一定要尽可能的考虑多种情况，考虑到以后的修改是否方便等。因此，我们需要尽可能降低代码的耦合性，做到不同的功能尽可能不要互相影响。不过，这里的降低耦合不仅仅是指自己写的模块间的耦合，还有考虑与别人写的模块的耦合，尽可能做到不要过分依赖别人的模块，这样别人代码的一点修改不至于造成我们代码的大规模修改。

3.不要过度设计
因为需求变化太过频繁，很可能你针对当前需求设计的是否完美的一个方案在第二天需求变更时就完全失效了。另外，对一个需求的设计是需要时间成本的，也许花费一个星期才思考一个近乎完美的解决方案，但第二个星期需求就改了，这一个星期的时间几乎完全浪费。这一点几乎无法完全掌握，但是可以通过经验积累尽量避免问题。

4.游戏性能是一项非常重要的指标
游戏与其他软件不同的是，很多游戏逻辑不是消息驱动，需要每帧都去调用。所以，我们在向Tick()函数里面添加方法时，都要去思考能不能换一种方式驱动来减小函数执行的开销。

5.工厂模式：简单工厂，普通工厂，抽象工厂
所谓工厂，目的就是生产产品。所以，我们至少封装一个工厂类和一个产品类。一般来说呢，一个工厂又不会只生产一种产品。所以呢，我们把产品抽象一下，可以基于这个产品派生出多种类似的产品。这样就是一种简单工厂了，该工厂可以生产一个类型不同系列的多种产品。举例来说，一个制造厂生产民用飞机，战斗机，无人机。那么这三种飞机就是同一个类型（都是飞机），不过系列不同（应用场景不同）。

当然呢，有的时候为了分工明确，我不想一个工厂生产所有类型的产品，所以我把工厂抽象一下，不同类型的工厂生产相同类型不同系列的产品。这也是一种工厂模式，我们就称他为普通工厂吧。举例：我不能让战斗机与民用飞机在同一个厂子生产，所以呢，再弄一个新的战斗机制造厂专门生产战斗机，而民用机弄一个新的民用制造厂来制作。

那么什么是抽象工厂？
上面简单工厂不管怎么抽象，一个具体的工厂只生产一种特定的产品。抽象工厂的每个具体的工厂可以生产多种产品。举例：制造厂发现平时生产飞机多出来很多材料，扔了太浪费了，所以研究一下生产点小型汽车。这样，一个民用飞机制造厂又可以生产汽车了，然后改名为民用制造厂。战斗机工厂生产防弹车，改名叫军用制造厂。

对比一下简单工厂，普通工厂与抽象工厂：
简单工厂只有一种工厂，负责生产同一类型的所有产品，所以可以简单的都在一个工厂处理，工厂不需要抽象，但是由于产品可能有多种，所以产品有必要抽象。
普通工厂有多种工厂但是每个工厂只生产同一类型同一系列的一种产品，考虑到同一类型的产品可能有多种而且一个系列的产品对应一个工厂，所以产品与工厂都有必要抽象。
抽象工厂有多种工厂，每种工厂都可能生产多种类型的产品。考虑到同一类型的产品可能有多种，所以也有必要抽象。

游戏设计中的工厂模式： 游戏GamePlay逻辑游戏世界里面需要频繁生成与创建的对象都可以通过工厂模式来管理。如刷怪，然后可以根据怪的种类再进一步抽象成普通工厂。

6.Builder模式：
细分一个对象的构造细节并拆分，达到可以自由调整构造顺序以及构造内容的效果。

游戏设计中的Builder模式：使用不多，个人觉得可以通过这个创建不同类型的组装武器，可以拆分零件等。总之，可以重复利用同一个资源实现表现的多样性。

7.原型模式：
复制一个对象的实例，简单来说就是克隆。一般用在根据对象自己本身创建一个新的对象，隐藏对象创建细节。

游戏设计中的原型模式：一般编辑器里面拖拽进去的对象都是用类似的方法实现对象创建的，如Unity中的Prefab。首先玩家从资源文件拖拽一个对象到编辑器场景里面，这时候就创建了一个对象。随后，玩家点击play，新的世界就会clone一个完全一样的对象。

8.单例/单件：
整个程序运行中只存在唯一的一个全局对象。

游戏设计中的单例：比如一个全局的NPC管理，事件记录器，控制台管理等等。

9.观察者Observer模式/发布订阅模式：
当一个对象的状态发生改变时, 所有依赖于它的对象都得到通知并被自动更新。目标对象可以自由的绑定N个观察者，他不在乎订阅者都是谁，反正每次自己发生变化的时候就通知所有观察者，达到了降低耦合的目的。
发布订阅模式与观察者模式有区别，发布有一个统一的调度中心，订阅者（类比观察者）可以随意从调度中心订阅内容，发布者（类比目标对象）可以随时发布消息到调度中心，然后调度中心根据订阅者是否订阅来处理消息的发布。

游戏设计中的观察者模式：
比如任务系统中，所有接收同一个全局任务的玩家会收到任务的更新信息。该模式与C++语言中的多播代理的实现思路极为相似。

10.Adaptor适配器：
把完成同样的一个功能但是接口不能兼容的类桥接在一起使之可以在一起工作,主要处理旧的接口不兼容的问题。

游戏设计中的适配器模式：一般在项目或引擎代码更新后与原来接口不兼容，或者在一个新的游戏里面套用老项目代码的情况下使用。比如旧项目使用新引擎的功能，调用新引擎的底层接口。可以新建一个适配器继承旧的类，然后保存一个新引擎对应类类型的属性，调用旧的接口的时候覆盖原来的旧的逻辑改为新引擎对应类的接口，也可以为旧的类增加新引擎才有的新的接口。

11.Bridge桥接模式：
假如一个对象有两个维度的变化因素，那么可以通过继承抽象实现一个维度变化，通过在抽象类里面聚合另一个维度变化的因素（这里面也通过继承来抽象，而且还可以继续聚合抽象），这就是桥接模式。

游戏设计中的桥接模式：暂时还没有使用过。

12.Decorator装饰器：
就是对已经存在的某些类进行装饰，以此来扩展一些功能，装饰器的价值在于装饰，他并不影响被装饰类本身的核心功能。通常在一个继承的体系中，子类通常是互斥的，而有一些功能却是通用的，为了给不同的子类动态添加不同功能，就可以使用装饰器来达到这样的效果。

游戏设计中的桥接模式：暂时还没有使用过。