Unity使用中对组件与对象引发的思考 VR开发心得

2017-05-11 17:40:55

 开始本文的主题之前,我们先来阐述一个问题为什么在游戏设计中要使用面向对象,有必要嘛?实际上这个问题大家都知道,面向面向过程的c语言,也有一个struct的东西。数据和行为必须有一定的组织形式,才能适应复杂的业务需求(繁化简,大化小的方法论),像游戏设计这样有复杂业务逻辑的系统,也必须有很好的数据组织系统 。语言有点晦涩我们通过几张图来说明下问题,

传统游戏

传统游戏中的基本类继承体系

传统游戏2

传统游戏系统中的类继承体系,全部展开太多了,我们可以看到我们熟悉的一些系统装备系统,角色系统,魔法系统等等。

魔法的继承关系

魔法系统细节

 

装备系统的类图

UGUI插件 InventroryPro这个是的装备格子数据类继承体系,我们看到继承体系有装备(格子数据)基类,背包子类,可消耗子类,钱币子类,装备格子类,不可使用子类等等。

     关于OOP和CBD的编程接合和实践,国内圈子对于基础研究的文章不多,这也是让我困惑的地方,但国外主流的引擎如基本已经是基于组件开发了,也就是传说中的MonoBehaviour,一切皆是组件。可能是我比较笨,实在掌握不了组件与传统类继承关系的有机结合的真谛(在我看来组件更像一种行为或者方法的切面)。无奈没有理论基础,只能通过实践考察来思考一下这个问题,看了下 InventroryPro框架中的继承体系结构,由于GameObject 本身不能继承,造成其扩展只能通过MonoBehaviour动态来添加(我同事认为实际这种形式是破化面向对象的封装的),也许是我太看重MonoBehaviour的行为特性,实际看了下例子他们使用的时候也只是将MonoBehaviour看作一种类,很多还会继承接口来规范化行为,但是GameObject不能继承,通过工厂模式来创建也是可以,但是InventroryPro的做法是直接做成 prefab预设实际上也是一种封装的变相实现。但引申出来的问题就是,即使实例化创建了prefabs其也一定是GameObject,本身还是需要通过GetComponent系列方法获取的具有业务逻辑的MonoBehaviour进行单独实例化保存(这里指的是实例化成类属性),进行逻辑控制。这也就需要对于MonoBehaviour类和GameObject做两套生命周期的管理,特别是GameObject在很多时候需要做对象池的管理。

     经过一套心路历程,思想还不是那么明确,我们用反证法想想,实际如果只是将MonoBehaviour看作一种行为(或者叫做游戏心跳逻辑Update)是不合理的,如果仅是行为那么其实就退化成面向过程了(也就是说是一个函数),这样就有必要将MonoBehaviour看作一种具有属性和行为(数据和方法)的类组件,才是合理的,而GameObject感觉就像一个共生的宿主,实际是只是一种具有层级UI的类,也是符合单一原则的。如果我们仔细观察传统游戏游戏引擎的设计者的类图,往往会将UI类和逻辑类放在一起形成类继承体系,而Unity3d将UI类GameObject和MonoBehaviour做了硬解耦,世间万物有利就有弊,理解其本质即可。

最后

    由于本人能力有限,也不敢定论什么“关于Unity面向组件和面向对象基础继承体系”,只是接合实践,学习现有插件的设计系统,记录一下自己的思考过程。各位同学如果有很好的想法,总结和收藏,也勿怜惜留言,指点迷津。

99VR视界二维码
热门推荐
Hot Recommended
在线客服