游戏开发(三) 之 cocos2dx-lua 的简易 mvc 框架

此篇文章,严禁转载!!!

此篇文章,严禁转载!!!

 

客户端环境搭建完成,现在开始做开发前关于客户端的准备,我觉得这也是一个项目主程需要解决的事情:

1. 一套mvc框架,用于规范流程,快速开发
2. UI适配
3. ios android 原生互调
4. 网络通讯(http + protobuf)
5. IO操作
6. lua热更策略
7. 想不起来了,反正后面我都会一一去实现,到时候在补齐

MVC

今天主要讲下这个mvc,如果想先看实现,请点击<<传送门>>,或者先看完这篇说明在看实现.

老样子,不多解读市面上mvc,可以翻阅其他资料,我的这个有些许不同:

XXView:

这里没有任何游戏的业务逻辑,整个类里面只做两件事

• 接收用户操作(点击,滑动等操作),相应操作去调用 对应的controller
• 根据 function XXView:modelUpdate(model) 接收到的不同model进行数据显示,以及UI逻辑

注意:view从来都不会直接去修改model的数值.一切修改通过controller

XXModel:

这里只有数据存储,和一些简单的数据换算,复杂以后可能看起来就是这个样子

local testM2Model = class("testM2Model",XXModel)

function testM2Model:init()
	self.a1 = "1"
	self.a2 = "2"
	self.a3 = "3"
	self.a4 = "4"
	self.a5 = "5"
	self.a6 = "6"
	self.a... = "..." 
end

function testM2Model:getA1A2()
	return self.a1 + self.a2
end

return testM2Model

怎么样,是不是一目了然,这里就可以划分出来各个模块的模型,如果这个规划的好,后期开发也会如鱼得水

这个 规划的好  ,我觉得真的是重点,你工作中会发现一些有着良好的编程习惯的人,在复杂的模块开发之前,一定会先做模型图.

把数据模型整理出来,规划好,模块划分也就确定下来了.

XXController:

这里也没必要说 主要就是做业务逻辑了,好处就是你只需要管你逻辑对应的model,你完全不用关心界面的事情,只需要把你逻辑处理好,对应的数据修改对应的model,然后调用model:update()

XXMVCManager:

这个类似于一个缓存类,负责缓存各个model ,controller. 

然后生成各个类.

这里有个我很喜欢的语法的使用,就是反射. 有反射的语言,写这个类是相当的简单.

核心代码:

这里是生成一个XXView类,根据模块名去生成,不需要每个都去写一些重复的东西(主要是为了少写代码)

这套mvc我一共实现过 c++ lua js c# 几个版本,其中实现最简单的就属lua了,非常灵活.最费劲的就是c++,当年写的时候因为他本身没有反射机制,最后是通过宏实现的,调用的时候写的代码 完全一样,唯一的缺点就是我需要在写调用代码的cpp里,引入对应类的头文件,这个是没办法一定需要手动去写的东西.

<<操作影响数据,数据驱动显示>>

整个MVC调用的过程可以总结为:

V->C->M->V 

整个过程其实是单向闭环的.

---------------------------------------------------------------------------------------------------

说下这个MVC的起源,我任职过很多家公司,有大公司,小公司,工作上发现了如下问题:

1.偷懒

      是因为公司没有一个完整的代码审核,评审机制,导致工作量不明确,无法把这个东西数据化,我觉得这个主要也是大部分公司996的原因

2.沟通

      在多人开发的项目中,包括前端与后端,前端和前端,我发现在沟通的事情上,花费了大量的时间和经历,也是由于沟通的问题,导致后续bug的出现

3.预期

      程序负责人,无法量化整个项目的工作量,导致任务分配不均,造成大家加班加点赶东西,效率又上不来.

4.bug

      前期如果测试不足,导致后期上线出现严重bug对于项目来说,影响非常大

5.成本

      如果你参与立项规划的话,要对这个成本有相当准确的掌握

6.人员流动

      期间核心功能模块的人离职,新来人接手,可能需要大量时间熟悉,严重影响整体进度

好来说下这套MVC的对于以上问题的解决方法:(前提是由你来搭建这套)

1.偷懒的问题:

由于可以对模块功能拆分的很开,而且也解决了各地方的调用,数据互通的问题,所以在编码过程中,可以专注逻辑开发,内容单一,可以轻松在版本控制上,看到工作内容以及质量

2.沟通的问题:

前后端的沟通,可以找一个人完全负责所有API的内容处理,而且这个人可以完全不管其他的东西,只去下面几个事情:

• 处理接收协议  整理接收的数据
• 处理发送协议  提供接口,按协议发送字段
• 维护Http相关事情

3.预期估算的问题:

根据框架,可以大概估算出各个模块的难度和内容多少,合理安排工作

4.bug的问题

虽然说谁也无法保证不出bug,但是对于流程单一的框架来说,对于查找bug来说,非常的简单,可以快速定位到问题所在

5.成本问题

既然可以掌握工作量,工作难度,可以根据不同模块不同内容合理分配给不同技术程度的人.

这里我有个实际经历:新项目,目前空出来的只有我一个人,时间赶不及,出于成本考虑,我完全可以招一个1年左右经验的来处理view层的UI拼接和UI逻辑部分,这部分难度很低,而且专注来做这个,速度一定会越来越快,我把这部分耗时的工作分出去,专心写逻辑,配合起来,整个进度真的是飞快.然后后面呢,这也可以当成一个培养方案,这个人接下来可以做部分逻辑的工作,你又可以开始招一个新人来接手他之前的内容.

6.人员流动问题

框架即规则,在你的规则下编写代码,会让你在查阅的时候,异常的明朗.我深有体会.就算有人离职,他的工作其他人来也可以很快接收过来,这里有个说法我觉得有点适用, 好的企业规章制度,会弱化每个员工对企业的影响.好的代码框架,会弱化每个程序对项目的影响.

 

2点多了,太晚了,白天还上班 ,先说这些.

今天晚上回来继续其他内容!!

有任何问题,可以给我留言,看到后会及时回复! 也欢迎大佬纠正,指错!

 

此篇文章,严禁转载!!!

此篇文章,严禁转载!!!