在unity项目开发中,ui模块的开发往往占据了很大一部分工作,部分游戏甚至绝大部分的工作都是在ui上,如何高效管理各种界面,这里分享一套高效易用的UI框架. 首先,我们定义一个PanelBase类,作为所有panel的父类,在这个类里,我们可以给panel定义一套生命周期     //初始化     public virtual void Init(){}     //开始面板前     public virtual void OnShowing() { }     //显示面板后     p

约定 还记得上版本的第二十四篇的约定嘛?现在出来履行啦~ 为什么要重制? 之前写的专栏都是按照心情写的,在最初的时候笔者什么都不懂,而且文章的发布是按照很随性的一个顺序.结果就是说,大家都看完了,都还对框架没有一个感觉,感觉很乱.而现在,经过两年多的摸索,笔者已经对框架的体系有了一个了解,所以希望再版一次此系列的专栏. 为什么不在原来的文章里直接修改呢? 在上一轮的专栏第二十四篇里有讲过过:虽然以前的内容过时了,但是这些专栏对笔者有很重要的意义,它们记录了笔者成长的一个经历,在评论区有着大家的支

背景: 前段时间用Xamarin.OSX开发一些工具,遇到了两个问题. QFramework的大部分的类耦合了Unity的API,这样导致不能在其他CLR平台使用QFramework. QFramework定义了太多了命名空间,如果使用vs for mac或者MonoDevelop开发项目很不方便,每次都要先using命名空间IDE才会提供代码提示,当然用Rider就没有这个问题. 基于以上几点进行了一次架构调整. 目前架构: 为了提升开发效率,命名空间全部统一为QFramework,而不是像以

从框架搭建系列的第一篇文章开始到现在有四个多月时间了,这段时间对自己来说有很多的收获,好多小伙伴和前辈不管是在评论区还是私下里给出的建议非常有参考性,在此先谢过各位. 说到是一篇小节,先列出框架的概要图. 目前,图中除了UI模块和未支持的部分,都有相应的文章来介绍. 设计模式: Unity 游戏框架搭建 (二) 单例的模板Unity 游戏框架搭建 (三) MonoBehaviour单例的模板 事件: Unity 游戏框架搭建 (五) 简易消息机制 AI: Unity 游戏框架搭建 (四) 简易有

此篇文章准备了将近两周的时间,写了改,改了删.之前有朋友反馈,上一个文章太冗长了,影响阅读体验,这一讲就走个精简路线.所以只要不是很重要的内容就都删减掉了. 文章分两个部分,第一部分是原理,第二部分是实战. 原理部分,初学者尽量去理解就好,不用跟着敲,列出的代码都是示意代码. 实战部分是留给初学者的,希望敲完代码,这样有助于理解前边的原理. 当然原理不是很难. 第一部分:原理 ResKit 中值得一说的 Feature 如下: 引用计数器 可以不传 BundleName 当然也有很多不值得一提的

Unity StrangeIoC框架  http://blog.csdn.net/y1196645376/article/details/52746251    

今天研究Unity Ioc 框架,被自己坑了两个多小时. 运行就报错,反反复复检查了很多次,配置文件,代码都没有问题,也从新写了好几遍. 最后仔细看报错消息才知道,config文件没有生成到目录…………  -_- 各路大神,引以为鉴呀!

之前的文章中介绍的Unity 游戏框架搭建 (二) 单例的模板和Unity 游戏框架搭建 (三) MonoBehaviour单例的模板有一些问题. 存在的问题: 只要继承了单例的模板就无法再继承其他的类. 虽然单例继承其他类是比较脏的设计,但是难免会遇到不得不继承的时候.没有最好的设计,只有最合适的设计. 解决方案: 首先实现单例的类从使用方式上应该不变,还是 XXX.Instance.ABCFunc() 之前的单利的模板代码如下所示: ``` using System; using Syste

一 项目概述1.1 角色1.2 业务术语1.3 项目效果展示二 项目需求三 项目概要3.1 项目技术架构3.2 项目目录结构3.3 项目技术选型3.4 项目整体集群规划3.5 创建项目工程四 APP 数据生成模块4.1 创建公共模块工程4.1.1 创建 Java 工程,导入 pom 文件4.1.2 创建 AppBaseLog 基类4.1.3 创建 AppErrorLog 错误日志类4.1.4 创建 AppEventLog 事件日志类4.1.5 创建 AppPageLog 页面日志类4.1.6 创

关于基于python 2.7的unity自动化测试框架GAutomator测试环境的搭建 百度云盘链接(思维图学习资料):https://pan.baidu.com/s/1dFWExMD 准备工作(具体操作步骤度娘知道): 1. 安装java jdk 2. 配置java jdk环境变量 3. 安装Android jdk(嫌麻烦直接下载:Android Studio安装,大约1.8g) 4. 配置Android jdk环境变量 5. 安装和配置好python开发环境 框架搭建(建议使用pychar

  为了重构手头的一款项目,翻出来当时未接触Unity时候收藏的视频<Unity项目架构设计与开发管理>,对于我这种初学者来说全是干货.简单的总结了一下,以后慢慢提炼. 关于Unity的架构有如下几种常用的方式. 1.EmptyGO:   在Hierarchy上创建一个空的GameObject,然后挂上所有与GameObject无关的逻辑控制的脚本.使用GameObject.Find()访问对象数据. 缺点:逻辑代码散落在各处,不适合大型项目. 2.Simple GameManager:   

什么是消息机制? 23333333,让我先笑一会. 为什么用消息机制?   三个字,解!!!!耦!!!!合!!!!. 我的框架中的消息机制用例: 1.接收者 ``` using UnityEngine; using System.Collections; using QFramework; /// /// 1.接收者需要实现IMsgReceiver接口. /// 2.使用this.RegisterLogicMsg注册消息和回调函数. /// public class Receiver : Mon

  在进行项目架构阶段,游戏框架可以解决一部分问题.剩下的架构问题还需要根据不同的项目解决.总之游戏框架是游戏架构的一部分. 关于锤子和钉子:   最近又拿起了<代码大全>和<暗时间>,想起来<暗时间>的作者维护了一个个人博客,就去逛一逛.   这几天一直琢磨一句话:手里拿着锤子看什么都像钉子.于是翻到了博客锤子和钉子.我的这个行为很好的阐述了什么叫:手里拿着锤子看什么都想钉子- -.   看完之后深度自省了一下- -   文章很有趣,推荐大家读下.   对于框架,用锤

本来这周想介绍一些框架中自认为比较好用的小工具的,但是发现很多小工具都依赖一个类----App. App类的职责: 1.接收Unity的生命周期事件. 2.做为游戏的入口. 3.一些框架级别的组件初始化. 本文只介绍App的职责2:做为游戏的入口. Why? 在我小时候做项目的时候,每次改一点点代码(或者不止一点点),要看下结果就要启动游戏->Loading界面->点击各种按钮->跳转到目标界面看结果或者Log之类的.一天如果10次这种行为会浪费很多时间,如果按照时薪算的话那就是....

  好久不见 !之前想着让各位直接用QFramework,但是后来想想,如果正在进行的项目直接使用QFramework,这样风险太高了,要改的代码太多,所以打算陆续独立出来一些工具和模块,允许各位一个模块一个模块的进行更换,减少更换带来的风险. QSingleton:   之前有几篇文章介绍过单例模板在Unity中的几种实现.之后又参考了其他的单例库的实现,借鉴(chao)了它们的优点,借鉴了哪里有声明原作者. 快速开始:   实现一个继承MonoBehaviour的单例类 namespace

为毛要实现这个工具? 在我小时候,每当游戏到了测试阶段,交给QA测试,QA测试了一会儿拿着设备过来说游戏闪退了....当我拿到设备后测了好久Bug也没有复现,排查了好久也没有头绪,就算接了Bugly拿到的也只是闪退的异常信息,或者干脆拿不到.很抓狂,因为这个我是没少加班.所以当时想着解决下这个小小的痛点... 现在框架中的QLog: 怎么用呢?在初始化的地方调用这句话就够了. QLog.Instance (); 其实做成单例也没有必要.... 日志获取方法: PC端或者Mac端,日志存放在工程的

前言 架构和框架这些概念听起来很遥远,让很多初学者不明觉厉.会产生"等自己技术牛逼了再去做架构或者搭建框架"这样的想法.在这里笔者可以很肯定地告诉大家,初学者是完全可以去做这些事情的. 初识架构和框架 架构和框架是非常接地气的,离我们其实并不遥远. 什么是架构? 架构是一个约定,一个规则,一个大家都懂得遵守的共识.那这是什么样的约定.什么样的规则.什么样的共识呢? 我以包为例,我经常出差,双肩背包里装了不少东西.笔记本电脑.电源.2 个上网卡.鼠标.USB 线.一盒大的名片.一盒小的名

UI Kit 快速入门 首先我们来进行 UI Kit 的快速入门 制作一个界面的,步骤如下: 准备 生成代码 逻辑编写 运行 1. 准备 先创建一个场景 TestUIHomePanel. 删除 Hierarchy 其他的 GameObject. 搜索 UIRoot.prefab,拖入 Hierarchy. 在 UIRoot / Design GameObject 下创建 Panel ( 右击 Design -> UI -> Panel ). 将该 Panel 改名为 UIHomePanel.

在上一篇,我们完成了一个定时功能,并且接触了 Action 和委托.lambda 表达式这些概念. 到目前为止,我们的库作为知识收录这个功能来说,已经非常好用了,由于使用了 partial 关键字,所以重复的代码少了很多.而作为一个可复用的工具库来说,勉强能够应付. 通过 partial 关键字,理论上可以对已有了类,进行无限地增加示例.而我们的示例的类型呢,主要是写可独立使用的方法和 MenuItem 示例.什么叫独立使用的方法?到目前为止我们写的所有静态方法都是可以独立使用的,这些方法并不需

在上一篇,我们接触了单例,使用单例解决了我们脚本之间访问的问题. 脚本之间访问其实有更好的方式. 我们先分下脚本访问脚本的几种形式. 第一种,A GameObject 是 B GameObject 的 Parent,或者是中间隔着几个层级的 Parent. 那这种情况下,如果 A 脚本想调用 B 脚本的方法,直接通过 transform.Find("XXX/YYY/ZZZ").GetComponent<B>().DoSomething() 就可以了. 但是如果是 B 脚本想

我们花了 5 篇文章学习了消息机制的方方面面.并且完成了一个简易消息机制,之后集成到了我们的 MonoBehaviourSimplify 里. 现在 MonoBehaviourSimplify 有一点框架的感觉了.因为 MonoBehaviourSimplify 在提供消息功能的同时,决定了项目脚本中的交互方式.而目前的这套结构,足够用它来完成一个比较小的项目了. 消息机制是笔者在接触单例之后,第二次被震撼到的设计模式(观察者模式/发布者订阅者模式).而笔者在初学的时候,还不太敢去设计 Mono