先列出上一篇的总结: 要做的事情: 备份:导出文件,并取一个合理的名字. 遗留问题: 第八个示例与之前的示例代码重复,功能重复. 约定和规则: 每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能 每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法. 每写一个示例进行一次导出,导出的文件名后边加上日期和时间,这个功能已经在导出功能里内置了. 示例分类: 知识学习&收集 API 收集 C# 语法实践 库本身的功能 规则实现 使用流程提供及…

整理前的准备 到目前为止,我们积攒了很多示例了,并且每个示例也都贯彻了最的约定和规则. 在上一篇的小结也说了一个比较新的东西:编程体验优化. 在之前我们还积攒了一个问题:代码重复问题. 我们可是忍住整理的冲动忍了好久了. 所以现在也是时候准备着手整理了. 知识点和问题总结 遗留问题 我们写列出来之前记录的第一个问题: 第八个示例与之前的示例代码重复,功能重复. 这个问题想想就很好解决,只要删除掉第八个示例之前的示例就好了.但是怎么删和删完是否会破坏原来的功能?这两问题要具体看了代码才会知道.现在…

昨天呢我们把第八个示例整理完了.整理之后学习了类的第一作用:方法的集合,还有 Obselete 这个 API.并且在进行整理的时候贯彻了我们新的约定和规则:先确保功能有效,再去做变更和删除. 今天我们在往下接着整理第九个示例 第九个示例 using UnityEngine; #if UNITY_EDITOR using UnityEditor; #endif namespace QFramework { public class ResolutionCheck { #if UNITY_EDITO…

在前两篇,我们把所有的示例重头到尾整理了一遍. 当前的状态如下: 要做的事情: (完成) 备份:导出文件,并取一个合理的名字. 遗留问题: (完成) 第八个示例与之前的示例代码重复,功能重复. (完成) 方法所在类的命名有问题. 菜单栏显示顺序问题. 弃用的代码警告 约定和规则: 每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能 每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法. 每写一个示例进行一次导出,导出的文件名后边加上日期…

在上一篇我们整理到了第七个示例,我们今天再接着往下整理.我们来看第八个示例: #if UNITY_EDITOR using UnityEditor; #endif using UnityEngine; using System; using System.IO; namespace QFramework { public class PreviousFunctions : MonoBehaviour { public static string GenerateUnityPackageName(…

在前两篇,我们把所有的示例重头到尾整理了一遍. 当前的状态如下: 要做的事情: (完成) 备份:导出文件,并取一个合理的名字. 遗留问题: (完成) 第八个示例与之前的示例代码重复,功能重复. (完成) 方法所在类的命名有问题. 菜单栏显示顺序问题. 弃用的代码警告 约定和规则: 每个示例在 QFramework 目录下创建一个文件夹,文件夹的格式是: 数字.示例的功能 每个示例写一个脚本,脚本中包含可复用的静态方法和 MenuItem 方法. 每写一个示例进行一次导出,导出的文件名后边加上日期…

我们在整理阶段解决了一些意外的问题.但是这些问题仅仅只是被解决而已,我们并没有去思考过这些问题是为什么产生的?以及在以后我们如何去避免这些问题的产生? 方法所在类的命名问题,最后我们通过方法分类解决了,并且学习了类的第一作用:方法的集合. 解决之后导致了大量的弃用代码,为了标记弃用代码,我们又简单学习了 System.Obselete 这个 API. 这样的意外问题真是好啊,可以让我们一下学习很多东西.不过如果在工作中或者做项目中全是意外问题,而身边又没人知道这么解决,那么每天肯定都会过得非常辛…

昨天我们完成了第八个示例的第二个 MenuItem 菜单顺序的调整. 我们今天再往下接着调整. 我们来看下接下来的 MenuItem 代码如下: [MenuItem("QFramework/8.总结之前的方法/3.生成文件名到剪切板")] private static void MenuClicked3() { CommonUtil.CopyText(Exporter.GenerateUnityPackageName()); } CommonUtil 已经提取成第二个示例了. Expo…

MonoBehaviour 简化 在前两篇,我们完成了第九个示例.为了完善第九个示例,我们复习了类的继承,又学习了泛型和 params 关键字. 我们已经接触了类的继承了.接触继承之前,把类仅仅当做是方法的集合,接触了继承之后,我们的类还可以使用继承来解决一些问题. 第十个示例 在 Unity 中,我们的脚本都往往继承自 MonoBehaviour,继承了之后我们就可以在脚本内编写很多功能.比如访问 transform/gameObject,再比如控制动画接收碰撞事件等等.另外我们继承了 Mon…

第一章小结 为了强化教程的重点,会在合适的时候进行总结与快速复习. 第二章 简介 在第一章我们做了知识库的准备,从而让我们更高效地收集示例. 在第二章,我们就用准备好的导出工具试着收集几个示例,这些示例中有的是我们后续库的基础工具,也有的是在项目中非常实用的小工具,还有一些示例是实践了在框架搭建方向上非常重要的 C# 语法知识. 第二章大纲如下. 第八个示例(一) 在之前,我们完成了一个导出的功能.但是在完成这个功能的过程中,我们也遇到了一些问题.我们回忆一下,在<MenuItem 复用>的这…

在之前的两篇中,我们使用 public 静态方法对之前的内容进行了一个抽取,有了 public 静态方法这个工具,我们的学习行为也发生了一点变化. 在没使用 public 关键字之前呢,每一个示例仅仅是一个知识的记录作用.而我们用了 public 关键字之后,我们可以把知识作为一个可以复用的方法.但是呢,这样就有了一个顺序的问题. 我们是先写方法在写 MenuItem?还是先写 MenuItem 还是在写方法? 笔者给出的答案是,在学习新的 API 或者新的知识点的时候建议先写 MenuItem…

在笔者刚做项目的时候,遇到了一个需求.第一个项目是一个跑酷游戏,而跑酷游戏是需要一条一条跑道拼接成的.每个跑道的长度是固定的,而怪物的出现位置也是在跑道上固定好的.那么怪物出现的概率决定一部分关卡的难度. 以上有点绕,其实就是,到某一个时刻,怪物是否要出现.而是否要出现是根据概率来决定的.如果一个怪物出现的概率是 100%,那么每次到达跑道固定的位置时候都要生成怪物.如果是 80% 那么就有百分之二十的几率不生成怪物. 那么如何去写这个逻辑呢? 我们先分析一下,我们要输入的是一个概率,而得出的结…

在上一篇,我们对框架和架构进行了一点探讨.我们在这一篇再接着探讨. 什么是库呢? 来自同一位大神的解释: 库, 插到 既有 架构 中, 补充 特定 功能. 很形象,库就是搞这个的.我们的库最初存在的目的,就是收集知识,而收集知识是一般的架构(项目)中是没有的,那么我们为了补充特定功能(收集知识),就要把我们的库导进来,然后收集一两个示例,再导出去,然后删除掉项目中库的文件,消除痕迹以免被其他人发现:) ,而这个库补充的收集知识这个功能是对于大家有用的,而不是对项目有用的,虽然对大家有用到最后也会…

第九个示例 目前代码如下: using UnityEngine; #if UNITY_EDITOR using UnityEditor; #endif namespace QFramework { public class ResolutionCheck { #if UNITY_EDITOR [MenuItem("QFramework/9.屏幕宽高比判断")] #endif private static void MenuClicked() { Debug.Log(IsPadResol…

导出 UnityPackage 功能到这里要告一段落了,相信认真看的童鞋都有收获.笔者在写教程之前纠结了很久.到底是先给出一坨工具代码,然后再逐个讲解比较好,还是一篇一个知识点比较好.后来想通了.工具和知识点都要同时写.也就诞生了这个系列的教程,这对笔者来说是一个挑战. 在 框架搭建 2017 年版本,采用的就是一篇文章一个小工具.而到了 2018 年版本,自己的内容变多了,所以一篇文章会讲好多东西.大家读起来内容会比较深一点,一篇文章大概要读个半个小时.再后来觉得一篇文章读半个小时这件事对笔者…

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

Unity 游戏框架搭建 2018 (二) 单例的模板与最佳实践 背景 很多开发者或者有经验的老手都会建议尽量不要用单例模式,这是有原因的. 单例模式是设计模式中最简单的也是大家通常最先接触的一种设计模式.在框架的设计中一些管理类或者系统类多多少少都会用到单例模式,比如 QFramework 中的 UIMgr,ResMgr 都是单例.当然在平时的游戏开发过程中也会用到单例模式,比如数据管理类,角色管理类等等,以上这些都是非常常见的使用单例的应用场景. 那么今天笔者想好好聊聊单例的使用上要注意的问…

在上一篇,我们把菜单的顺序从头到尾整理了一遍.在整理菜单顺序的过程中,记录了一个要做的事情. 要做的事情: (完成) 备份:导出文件,并取一个合理的名字. 整理完菜单顺序后,学习新的知识,解决随着示例增多,可能出现类需要合并的问题. 我们要学习新的知识,试着解决类的合并问题.首先我们来看下要合并的类是什么,在我们的示例中是 TransformSimplify,这个 TransformSimplify 是对 Transform API 的简化,而 Transform 有非常多的 API,那么以后肯…

MonoBehaviourSimplify 中的消息策略完善 在上一篇,笔者说,MonoBehaviourSimplify 中的消息策略还有一些小问题.我们在这篇试着解决一下. 先贴出来代码: using System; using System.Collections.Generic; namespace QFramework { public abstract partial class MonoBehaviourSimplify { Dictionary<string, Action<o…

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

我们的项目开始立项的时候,最常见的一个情况就是:几个人的小团队,一开始什么也不做,就开始写代码,验证逻辑,游戏就开始写起来了.而公司的一些所谓的领导层面一开始就把游戏定义为我们要做一个大作.这个事情本身就是一个笑话,因为没有任何的规划和设计,我们就妄图写出一个杰出的作品出来是不现实的.Unity 在好用,那么以这个心态去做游戏,一定会写不出来好的游戏来.- 刘钢<Unity 项目架构设计与开发管理> 以上这段话说得很清楚了,就是做一个项目的时候一定要做规划和设计,当然这是从整个项目的角度来看,…

上篇文章中实现了基本的打包功能,在这篇我们来解决不同平台打AB包的问题. 本篇文章的核心api还是: BuildPipeline.BuildAssetBundles (outPath, 0, EditorUserBuildSettings.activeBuildTarget); 在第三个参数中,只要传入不同平台 BuildTarget就可以了.目前只考虑Android和iOS平台. 区分iOS.Android平台 很简单,只要在上篇文章的QABEditor类中将原来的BuildAssetBund…

在上一篇我们收集了一个 屏幕分辨率检测的一个小工具.今天呢再往下接着探索. 问题 我们今天在接着探索.不管是写 UI 还是写 GamePlay,多多少少都需要操作 Transform. 而在笔者刚接触 Unity 的时候有一个非常不习惯的地方.就是对 transform 的位置.角度.缩放进行赋值. 比如,如果仅仅是对 transform.localPosition.x 进行赋值. 代码要这样写. var localPosition = transform.localPosition; loca…

在上一篇,我们得出了两个核心的学习思路: 根据问题去学习,并收集. 主动学习,并思考适用场景. 我们今天解决 MenuItem 显示顺序问题. 目前 MenuItem 显示如图所示: 我们来看下 MenuItem 这个属性构造的定义. 第二个参数是,是否是验证方法,目前不用理解,官网上默认是 false. 第三个参数,意思是优先级,表示 MenuItem 所在的显示顺序,数值越大越在底部. 我们先给第七个示例试一下.将代码改成如下: using System.IO; #if UNITY_EDIT…

第四章 简介 方法的结构重复问题 我们在上一篇正式整理完毕,从这一篇开始,我们要再次进入学习收集示例阶段了. 那么我们学什么呢?当然是学习设计工具,也就是在上篇中提到的关键知识点.这些关键知识点,大部分来自于 C# 语法. 不过在此之前,我们先实现一个功能,这个功能是,传入几个数字,随机取出其中一个数字. 比如传入 1,3,5,7 从这四个数字中随机取出一个数字出来. 其实现很简单 代码如下: using UnityEngine; namespace QFramework { public pa…

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

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

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

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

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