游戏UI框架设计(6)
--消息传递中心
最近一直忙于一个益智类游戏的研发工作,所以博客有段时间没有更新了。经过朋友的督促,决定这两天立刻完成最后的两篇博客讲解(UI框架)。
说起“消息传递中心”,或者是“消息中心”,熟悉一些客户端架构设计的朋友一定不陌生。这种技术的来源就是为了解决脚本、类之间紧耦合的问题,而诞生的一种开发思想。目前基于Unity技术的游戏与项目研发,目前官方提供的消息传递方式种类少,且耦合性很高。
例如以下三种常用数据传递方式:
eg: GetComponnet
这种方式是Unity提供初学者最简单,易用的方式,但是缺点很明显。
1> 写法麻烦,效率低。
2> 脚本之间存在强耦合性。
使用“单例模式”做脚本(类)之间的数据传递,例如本UI框架中的UIMaskMgr.cs ResourcesMgr.cs 脚本都应用了单例。此种模式优劣分析如下:
1> 突出优点:脚本(类)之间可以非常简单方便的进行数据互相调用,且效率高。
2> 缺点: 脚本之间的强耦合性。
本数据传递方式,一般大家都在设计框架的内部应用,一般不会应用在实战项目中。(因为框架内部相对稳定,而实战项目需求经常变化)
SendMessage 是Unity 官方推荐的一种数据低耦合方式,但用过的朋友知道这种方式使用麻烦、适用范围狭小、且存在一定耦合性。
所以开发一种低耦合性,无需考虑脚本(类)内部差异(脚本名称、组件名称)的技术非常有价值。于是笔者基于观察者设计模式,利用委托与事件的基本机制原理,进一步封装重构了一个 MessageCenter.cs 的核心类。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 |
|
以上核心原理解释如下:
public static Dictionary
为了进一步简化与方便消息传递的使用,笔者又对MessageCenter 类中的部分核心方法,做了进一步封装:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
|
以上的代码被定义在“BaseUIForm”脚本中,前面介绍过这个脚本。 具体的“消息中心”应用示例如下:
本项目中当玩家点击“商城系统”中的最左边道具,系统会弹窗显示“神杖”道具,如果点击左边第2个道具图标,则系统显示“战靴”道具,具体见下图:
以上功能的实现代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 |
|