求教 塔防游戏,基础类框架,用逻辑类+UI控制类的方式,发现问题

把设计模式当圣经,不是每个程序员去看一遍,才能写好代码的。

好吧,稍微讲一下设计模式吧。
编程原本是没有所谓设计模式的,但是就像你这样,很早之前也有这么一个程序员遇到跟你一样的问题。在做项目的时候发现所有东西绑在一起不好,不灵活,后面的项目又要重头搞一遍,效率低,他就根据自己的经验,把代码重新梳理了一遍,解耦,分视图,逻辑,控制等模块,使得流程更加清晰,编程效率更高,这些都是根据经验来的。后来逐渐形成了一套理论,业内大牛把常用的一些模式总结成了一套理论,就是设计模式,23种设计模式不分语言不分环境,是一种编程思想。每一种语言又有比较经典的实现,比如JAVA里面讲设计模式,你直接看完之后再去实践,就会节省你大量摸索时间。同样creator里面到底适不适用设计模式,需要根据编程经验来自己判断,如果你经验不够,那就要去看看别人的,比如你先去熟读设计模式,为什么会有模式出现,不用模式行不行。当然你要自己摸索也没问题,本来这些东西也都是前人摸索出来的,你想自己搞一套,完全可以。

具体情况具体分析,首先都是为了解决问题。
相信有很多程序员最初并不知道设计模式是啥,然后在长久的码农生涯中,(看别人这么写,看老大这么写)稀里糊涂的学到了很多招式,后来又偶然听别人说设计模式,看了下百度的定义,咦,这些个设计模式不就是我之前用的某某方法吗

是的,都是为了解决问题来的

6666666原来如此

MVC模式大量用于WEB应用,难点在于状态管理。用来做游戏个人觉得也没任何问题,我们公司现在用的就是MVC模式。在状态管理部分,我们借用了react-redux封装了我们自己的creator-redux,单向数据流,状态决定游戏界面输出,每个模板,游戏区域都可以单独测试。只要上手了写起来就特别简单。

刚上班的时候,跟楼主一样,想着把逻辑ui完全分离,然后发现走入了一个死胡同,后来慢慢的就好了一点,感觉游戏 想要完全分分离逻辑和UI层,有时候反而很麻烦

楼主写的好诱人啊,搞得我也好想试试啊

好想认识楼主啊

哇 好久看不到有争论这么多的帖子了,楼主 ,咋写都能写,你这么写也没啥毛病,只不过你现在需要的是分解,分步去做。你感觉到的迷惑就是因为 想了一大堆 但是没有下手去写。其实下面评论的那些老哥们说的无论设计模式也好还是各种也好,都是好意,毕竟经过多年的总结出的模板都属于精华,但是我也同意说自己尝试的好处。说了这么多都是废话
其实,最重要的一环是数据的抽象,只有你把你要做的东西拆分到粒度很小的时候,然后根据一定的规则,你的经验来抽象成一个数据模型表示你要做的东西就好,然后剩下的ui以及逻辑,随你折腾。但是独立的数据抽象很重要,放到这里你的塔防游戏,塔就是你最重要的抽象,能把塔抽象好一个具体的数据model就好,同理适用于怪物,这里这两个最重要粒度也最合适的抽象好后,剩下的就是你怎么组织了,就是所谓的游戏逻辑。balbalbal等等,举个例子,你可以弄一个Game逻辑类,来把你的游戏主逻辑和控制放到这里,然后按照你想要的去写就好,也不需要一开始就把架构弄得太大 反而会让你迷惑,你就先把核心的数据和核心逻辑写好,然后去填充,填充的过程中你自然会有想法去优化之类的。自然而然就出来了,核心总结:数据的抽象,以及分解分布去做。

我觉得creator不用硬套MVC模式,在我看来脚本就是所谓的逻辑层控制界面上的UI,UI层不就用说了用编辑器拼出来,数据层自己定义的一个全局变量来管理就行了,不知道我这样理解对不对

元素模式了解下

ui 和logic之间的交互 是用消息通知还是状态监测啊

目前,游戏架构全部做完了,现在就是堆内容了。

跟你说的很类似,抽象了 一个 Game逻辑,和 塔 ,怪 和攻击方式 三个类, 通过组合 塔+攻击方式 /或者 怪+攻击方式 或者道具+攻击方式 组合出不同的逻辑状态 , 逻辑状态与 场景现存 元素进行交互, 逻辑大概就是这样。 UI 这一块,全部做成分布式的, 怪物创造,怪物移动,怪物攻击,怪物死亡,塔创造,塔攻击。。。等等
其中通过传参形式,传入绑定的精灵,位置信息,行动目标,然后根据调用的API 去进行game逻辑反馈,中间不可避免的在UI里面有一个或多个BOOL值 ,反馈逻辑类,UI执行情况, 是否出现错误,需要重新生成,或者执行完毕等状态,反馈逻辑值。 因为逻辑类脱离了UI,前期代码时,发现数据跟UI完全不同步,然后不得不在UI里面触发逻辑反馈值,这个地方很难完全剥离。 通信方式,试过单例,不太好用,重新生成关卡清理数据 和 同步 不太好。用过单例,要在一个单例里面,调来调去的,也不舒服。 在父层 里面做,跟单例差不多,也很不舒服 ,找到 eventDispatch,很好用,但是发现,其实对主循环的开销很大, 这个玩意最后全部塞到了 Director的循环里面了。所以又改进了一下,做了一个 事件状态机, 就是传过去事件后,UI只管响应、不响应和无法响应 。 响应的是什么,在UI里面判断。就是只用了一个listener ,减少开销。
OK,我最后有去看了下MVC,发现了,在COCOS里实现 MVC是非常容易的,因为人家已经帮你把View解决了大部分, 通信机制也帮你预制了, 数据与逻辑 就剩下是自己的事了。感觉写的过程还是很爽的。 目前准备干的是,不用cocos的消息,开个线程,在线程里面处理消息的传递过程。 实践过程中,发现大量的内存碎片化问题,感觉不太好解决,目前没有好方法,UI层用cocos的retain release还行,逻辑层 完全不继承ref ,无法享用这个东西了,可能方法是用 malloc 2片内存,再动态的检测,互相倒换内存空间,应该可以解决,不过检测追踪的点,有点拿不准位置,要研究研究。

creator,是很挺好的,很方便。全局变量 单例 父节点 消息 都可以用来沟通,不必局限到底用啥啊

好的,有时间会去看,暂时找了本game programming patterns在看

状态检测是啥? 在循环里面,遍历UI和LOGIC 数据么? 然后进行同步么?

啊,就是效率太低了

我现在逻辑和表现是写在一起的,sprite之类的 直接组合在了逻辑里面

你把逻辑块的东西,比如血量、攻击力、移动速度,这些东西抽离出来,放一个类。把精灵当图片和图片的表现形式,放一个类,就可分离了。 你逻辑运算出,一个怪物要攻击了。 逻辑告诉UI,播放对应怪的攻击图片运行。UI就去放这个动画。这个过程就分离了。