Cocos2d-x项目的MVC框架

上一节,我们主要的了解了Cocos2d-x都有哪些小伙伴,我想熟练并已经精通的同学们,已经开始了测试,或者已经拿它们做项目了,那么请初学的小伙伴继续努力的去了解它们、掌握它们。而已经有项目或者正在写项目的同学,请听听我对Cocos2d-x的进一步了解。

Cocos2d-x项目的MVC框架

与其说Cocos2d-x项目的MVC框架,还不如说是我个人对MVC框架在Cocos2d-x项目上的理解,因为我也算是半个野生的,运用的并不是很好,请各位看官见谅。

本篇所用的Cocos2d-x版本为:Cocos2d-x 3.2

当我们已经开始搭建好项目,着手开始写代码的时候,我想同学们肯定会遇到这样的一个问题:

某些UI类在加载到父级上之后,经常毫无原由的造成崩溃现象。或者代码写了好几千行,难以进行维护及其他人帮助处理等。这是为什么呢?

其实,就是因为2点:

你对Cocos2d-x还是不够了解

你没有框架的概念

其实,这种问题往往是因为,你子级元素在父级addchild之前,就开始调用到了父级元素。或者说你就一直埋头去写,根本没有去想到底该怎么写。

我以前在交流群里经常对遇到这种问题的同学这么说:“你孩子还在母亲肚子里没生出来呢,你让它去打酱油可能吗?”

“你的孩子应该有无限的未来,为什么你不给它好好的去规划未来,而直接就开始给它戴上紧箍咒,让它束手束脚?”

我以前初学Cocos2d-x的时候经常会遇到的一个误区。那就是 在init函数里添加了显示UI或需要父级的数据等。

其实在init里面添加显示UI的代码,并没有问题,但是对于我的编程经历上来讲,这并不好,我个人认为你初始化就应该做初始化的事,你的UI就应该在UI的函数里进行加载,逻辑就应该在逻辑函数内,而不是哪地方都是。

我想了解MVC框架的同学们,都清楚MVC到底是什么了,那么我引用一下度娘对MVC的定义:

MVC全名是Model View Controller,是模型(model)-视图(view)-控制器(controller)的缩写,一种软件设计典范,用一种业务逻辑、数据、界面显示分离的方法组织代码,将业务逻辑*****到一个部件里面,在改进和个性化定制界面及用户交互的同时,不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。

在我一开始得知MVC框架的时候,我也纠结了很久,对于小项目来说这种框架非常的消耗时间,往往在一个类里面就可以搞定的东西,非要分成4份,管理器、业务、UI、逻辑。在这里我只能说是仁者见仁,智者见智了。

我先说说这种框架的好处:

1、你可以很轻松的将以前的业务拿到任何的新项目中。

2、你可以在策划变更逻辑、美术改变UI后,不用重新对逻辑和业务做过多的修改。

3、你可以很轻松的找到问题的所在,代码鲜明、整洁、规范。

坏处:就是你会觉得很烦,明明一个非常简单的业务,非要写这么复杂。

那么将MVC框架运用到Cocos2d-x上,是什么样子呢?

首先同学们看一下我写的基类BaseLayer

根据我的个人经验,我赋予了BaseLayer这几个简单的函数:

1、初始化及数据读取

2、显示及加载UI

3、加载逻辑与返回逻辑

……

就像上述,inti()就只是负责初始化,而showUI()就只是负责显示及加载UI,加载与返回逻辑就负责逻辑处理。

那么我们对比MVC架构和BaseLayer来看:

模型(model)————BaseLayer数据的初始化及本身业务

视图(view)————BaseLayerUI的初始化及加载

控制器(controller)————BaseLayer的逻辑处理及返回

那么BaseLayer的实现一般就是这样的步骤:

1、inti();

2、GetReadData();

3、LoadUILogic();

4、showUI();

5、ReturnLogic();

以实际功能业务为例:装备升级功能

我现在有个需求,需要实现对装备的升级功能。

我们以BaseLayer为基类,派生出业务类Equipment_LvUp (请原谅我小学英语毕业)。

1

2

3

4

5

Equipment_LvUp* m_pEquip = Equipment_LvUp::create();

this->addchild(m_pEquip);

m_pEquip->GetReadData(…);

m_pEquip->LoadUILogic (…);

m_pEquip->showUI ();

从顺序上,我们不难看出,先初始化数据、然后获取业务必要数据、加载业务逻辑、显示业务视图UI我们这么做之后,如果发生问题可以轻松的去判断问题的所在,是因为数据、显示、还是逻辑。而后,当我们的业务逻辑变更后,可以根据需求去调整代码,既鲜明,又直观。而且你可以把业务扔在不同的管理器下随时调用,可谓是相当的方便。

而且我们还可以根据不同的需求,对它进步一再重构及功能提升。像资源的异步加载、业务算法优化等等这些功能就可以逐步的完善。也可以分写4个类,就像之前提到的管理器、业务、UI、逻辑分类写。这些方法用哪个都可以,这只是给你提供一个思想、一个方式而已。

MVC框架我的理解,通俗点讲,就好比你玩英雄联盟,你的事件是通过鼠标及键盘进行响应的,也可以说是你的直观逻辑处理,QWER每次点击都会通过键盘映射到相应的逻辑进行处理,逻辑处理完之后通知相关UI进行动画或者渲染等,然后UI再给你提供新的界面,以供你进行新的选择。

那么从Cocos2d-x的demo也不难看出这种框架模式

逻辑分离

根据逻辑引用计数的增加和减少采用不同的类进行处理

每个类只负责自身的显示及动画效果。

好了,简单的MVC架构模式就讲到这里了,下一期准备讲讲整个游戏工程的架构。