edit date: 2019-12-04 14:59:39
新坑《游戏编程模式》(作者 Robert Nystrom)。
在 Unity 下,用 C# 做了简单的实现,传送门:
链接:https://pan.baidu.com/s/1q2j5er-NrxQqJKYSc4TM2w
提取码:8eq2
其他模式传送门:
命令模式
本来是考虑用学到的每一个模式作为框架来做成游戏原型,现在这个计划还没有搁浅,只是觉得先做一些小练习循序渐进吧。
“在对象间定义一种一对多的依赖关系,以便当某对象的状态改变时,与它存在依赖关系的所有对象都能收到通知并自动进行更新。”
在这里发生改变的对象就是被观察者(或称为观察目标,被观察对象,Subject),被通知的对象即为观察者。观察者之间没有相互之间的联系,被观察者只负责发出通知,可以随时根据需要增加或移除观察者(模式动机)。
观察者模式还有很多名字,发布-订阅(Publish/Subscribe)模式、模型-视图(Model/View)模式、源-监听器(Source/Listener)模式、从属者(Dependents)模式。
来,类图:
听到『观察者模式』,很多人会想到“事件”,“消息”,甚至“数据绑定”,但其实并不是一回事。
观察者模式非常适合处理不相关的模块之间的通信问题。在单独的模块中并不适合使用观察者模式。
一个非常适合的例子就是游戏中很常见的成就系统了。
通常在达成成就时,会有一系列的条件的判断,可能会同时涉及到多个模块,比如物理系统,游戏逻辑等等。如果要在各个模块中静态的处理成就,不仅成就系统会分散在众多模块当中,同时也像胶水一样将所有模块粘在了一起,修改这种耦合严重的代码就会变得异常困难了。
比如:“不使用飞行秘笈,脚不着地地完成一关”的成就很可能涉及了物理系统,技能模块和游戏循环三个部分的判断。如果静态编码我们可能会使用这样一个逻辑:在物理相关的模块中,提供一个检测是否落地的方法,并保持一个是否曾经落地的状态变量;在技能模块中类似,检查是否使用过飞行秘笈;最后在游戏循环中,在一关结束时,过关了并且没有达成此成就(可能是由成就系统提供的方法,某成就是否达成的检查),便对上述两个条件的状态进行查询,最后来判断是解锁成就(也应该是成就系统提供的方法吧,解锁某个成就,并进行一些 UI 的视效),或者清空上述的状态。怎么样,在这个例子中成就系统并没有深入到物理和技能模块中(只是类似实现最后判断的位置),但和游戏循环耦合在一起,甚至如果要修改 UI,声效等等,最终会在游戏循环的逻辑中形成一张复杂的静态调用网(调用了上面所有的系统模块中提供的方法)。
观察者模式就可以解决类似这种本来不相关的模块之间的通信,当在其他模块中达成了某种我们所关心的状态变化时,观察这些变化的观察者就会收到这个变化的信息,从而进行接下来的操作。
观察者模式的典型应用有前面说的“成就系统”以及 UI 系统。
如果用观察者模式实现前面所说的“不适用飞行秘笈,脚不着地地完成一关”的成就,那么首先要明确的是,所有和成就相关的解锁,判断都是在成就系统模块内部完成的,而物理模块中“没落地”,以及技能模块中“没使用”的判断时机较难提供(所以在上面的例子中是在成就达成的位置,一关结束进行判断的),因此首先减少耦合最严重的部分,游戏循环在一关完成时,通知成就系统,而成就系统可以自己保存其他需要观察的模块的状态,并判断是否解锁相关的成就。相应的,成就模块作为被观察对象在成就达成时通知 UI 模块与音频模块,执行可能需要执行的,成就系统并不关心的操作即可。
这样,当我们要修改成就系统,或删除整个成就系统时,甚至可以不去修改这些相关的模块,因为这些模块只是发出了通知,开销也只是对所有观察者的一次遍历而已(看一看类图中的描述)。当然,如果删除了观察者,而被观察对象还保留着观察者的引用这种情况,是要进行处理的啊。
我很容易陷入,为什么这样,究竟好在哪里这种刨根问底的细节中,真的是因为笨,所以一定要想出一个场景,再按照自己所想推论一番,可能我是经验学习的类型吧。