unity脚本框架
㈠ unity 大游戏使用什么框架
关于Unity的架构有如下几种常用的方式。1.EmptyGO在Hierarchy上创建一个空的GameObject,然后挂上所有与GameObject无关的逻辑控制的脚本。使用GameObject.Find()访问对象数据。缺点:逻辑代码散落在各处,不适合大型项目。2.SimpleGameManager所有与GameObject无关的逻辑都放在一个单例中。缺点:单一文件过于庞大。3.ManagerOfManagers。将不同的功能单独管理。如下:MainManager:作为入口管理器。EventManager:消息管理。GUIManager:图形视图管理。AudioManager:音效管理。*PoolManager:go管理（减少动态开辟内存消耗,减少GC）。缺点:(1)不能管理prefabs。(2)没有进行分类。更好的实现方式是将一个PoolManager分成:若干个SpawnPool。每个SpawnPool分成PrefabPool和PoolManager。PrefabPool负责Prefab的加载和卸载。PoolManager与之前的PoolMananger功能一样,负责GameObject的Spawn、Despawn和Trim。要注意的是:(1)每个SpawnPool是EmeptyGO。(2)每个PoolManager管理两个List(Active,Deactive)。讲了一堆,最后告诉有一个NB的插件叫PoolManager--。*LevelManager:关卡管理。推荐插件:MadLevelManager。GameManager:游戏管理。
㈡ unity3d 做项目用不用框架 比如 C#中有MVC结构 还有三大框架 这些 用不用啊
mvc是普遍采用的结构，在做unity3d项目中，建议用这样的结构来。但是又有别于一般的mvc框架，总之就是要规划好各层的关系。比如说一个做一个界面，就分成显示脚本、控制脚本、以及数据存储脚本等。
unity是非常灵活的引擎，采用树状层次关系结构，也也导致不能完全照搬传统的框架结构
㈢ Unity UI框架（一 窗口层级管理）
多个场景会反复出现相同的UI窗体，多个场景反复加载(复用)
各个UI脚本之间的传值，容易交错，耦合度高(UI之间不相互联系，通过消息传递)
要手工控制窗体中间的层级关系(使用栈结构保持控制当前所有需要显示的UI窗体)
多个UI窗体之间相互叠加，容易出现误操作(对当前窗体遮挡处理)
窗体自动加载管理
语言的国际化
尽量让框架本身完成与具体业务无关的事务性工作，让开发人员只需要专注游戏的业务逻辑
开发最简版
1.窗体自动加载管理
2.缓存UI窗体
3.窗体生命周期管理
UI框架的核心类设计
1.BaseUIForms基础UI窗体
2.UIManagerUI窗体管理
3.UIType窗体类型
4.SysDefine系统定义类
链接：https://pan..com/s/1-PomcmeBh2Up1S3iHWTHqQ
提取码：41cf
创建一些文件夹把贴图素材导入MyAtlas
把脚本素材分别放到
然后定义一个UI基类
还有一个UI管理类先列举出字段
然后搭设场景
几个空节点还有UICamera
Canvans设置为按相机照射UIScaleMode调整为宽高比例缩放match一般是0.5或者按高度适配
相机处理设置为正交模式照射层级只有UI还有记得把相机往后拉一点点不然没有图片
然后再Nomal下创建这样的界面记得定好锚点
在Resources保存为预制体到时候动态加载
然后记得把UI相机的这个去掉
然后添加常量名字
在UIManager添加UI创建方法
创建一个
挂给我们的LoginUI预制体
创一个空节点挂上脚本
因为没设置窗口激活所以是隐藏的
然后UI层级管理的话要用到栈“先进后出”
Stack<T>
类似于收盘子洗盘子羽毛球筒放进去拿出来
还有类似于枪的弹夹
然后UIManager添加方法有些判断写反了又改了改
然后是把常量提取出来定义
我又把他的监听类添加Transform也可以传递语法糖改为C#6
UI基类封装常用方法
提供一个方法类FindAdd的封装
然后拿去测试
这里定义一些窗口的常量定义
登录逻辑
人物选择界面逻辑
㈣ 现实的unity3d开发使用什么框架
Unity3D引擎采用“添加组件”开发方式，符合人类思维方法。初学者能够快速理解并掌握开发原理、流程，是最适合学习的开发模式。
①工程(Project)，一个游戏便是一个工程。开发阶段对应一个工程目录(文件夹)，发布后则对应一个可执行文件。工程是游戏资源、逻辑、玩法的集于一身的综合项目。
②场景(Scene)。通俗的讲场景是游戏中的“关卡”。多数情况下，每个关卡都是单独的场景。例如游戏中的副本、主城、野外都可以是独立制作的场景;FC红白机中的《超级玛丽》等等。
场景可以是功能性的。这种场景不涉及游戏玩法，但可以在其中执行初始化、热更新等操作。例如很多手游启动后，会进入“读条”、“下载资源”状态，这便是功能性场景。
场景组成了游戏工程。游戏启动后，必然会进入到某个场景，游戏至少包含一个游戏场景，可有无限多个场景。
③游戏对象(GameObject)。游戏对象只能存在于场景中，只要出现在Scene视图中的物体都是游戏对象。场景提供了空间，游戏对象是其中的基本元素。例如花草树木、子弹手雷、人物Boss、按钮图片、爆炸特效等等。游戏对象可以表现出千差万别的样貌和功能，形态、体积、功能可以完全不同。
④组件(Component)。游戏对象之所以表现出不同的性状，是因为其身上挂载的组件不同。组件负责游戏对象的具体和细节体现，是游戏对象最基本的功能粒度。例如场景中的“相机”对象，之所以能够拍摄场景并呈现到Game视图上，是因为“相机”身上挂载了“Camera”组。“Camera”组件提供了这个过程的全部功能，功能来自组件而非游戏对象。“Camera”组件挂载到任意其它游戏对象上后，该游戏对象同样会具备“拍摄”功能。
游戏对象可以看作是很多个组件的“容器”。从Inspector面板中，查看挂载了那些组件。
组件本质是类，必须挂载到游戏对象身上才能工作。游戏运行后，由Unity编辑器负责实例化，无需、也不能手动实例化。并非所有类都可以称之为组件，例如开发者写的脚本类，必须继承于MonoBehaviour类，才能挂载到游戏对象身上；Unity自带的组件，继承于Component类才能挂载到游戏对象身上。
这样，就形成了“游戏”->“场景”->“游戏对象”->“组件”的逻辑链条，最终，我们通过“组件”来驱动游戏中的物体，组成千千万万的逻辑关系，最终实现我们的游戏。
㈤ Unity教程：Unity开发框架
1.什么是游戏工程？
工程：Project，工程文件是组织项目的基本方式，基本通过文件夹分类来达到合理整合、分类、维护所需要的资源，另外工程只能被开启在编辑模式下，因此它面向的是编辑者。
2.如何打开与创建工程？
如果是首次安装Unity3D引擎，通过点击 Unity3D图标将会打开一个默认的工程，通过点击菜单栏的文件（File）下拉菜单框中的New Project、Open Project、Save Project 来新建，打开及保存一个工程。
12.什么是脚本？
脚本：Script，脚本简单的地说就是一条条的文字命令，这些文字命令是可以看到的，可 以使用文本编辑器打开查看、编辑，脚本程序在执行时，是由系统的一个编译器将一条条的翻译成计算机可识别的指令，并按程序顺序执行。
Unity3D引擎所支持的脚本语言有三种，分别是 JavaScript、C#、Boo。这三种语言都简单 易用，在开源.NET平台、Mono上运行，编译迅速。
13.简述场景、资源、游戏对象、组件间的关系
一个游戏工程可以由一个或数个场景组成，场景是由许许多多的游戏对象组成，这其中包括有我们可见的游戏对象，如角色，建筑等，以及那些不可见的游戏对象，例如声音，而组件 正是通过组织相关的资源来赋于这些游戏对象以不同的功能及属性。
本教程由中国AR网原创，更多基础教程请关注！
㈥ unity 大游戏使用什么框架
关于Unity的架构有如下几种常用的方式。
1.EmptyGO
在Hierarchy上创建一个空的GameObject,然后挂上所有与GameObject无关的逻辑控制的脚本。使用GameObject.Find()访问对象数据。
缺点:逻辑代码散落在各处,不适合大型项目。
2.Simple GameManager
所有与GameObject无关的逻辑都放在一个单例中。
缺点:单一文件过于庞大。
3.Manager Of Managers。
将不同的功能单独管理。如下:
MainManager: 作为入口管理器。
EventManager: 消息管理。
GUIManager: 图形视图管理。
AudioManager: 音效管理。
*PoolManager: go管理（减少动态开辟内存消耗,减少GC）。
缺点:
(1)不能管理prefabs。
(2)没有进行分类。
更好的实现方式是将一个PoolManager分成:
若干个 SpawnPool。
每个SpawnPool分成PrefabPool和PoolManager。
PrefabPool负责Prefab的加载和卸载。
PoolManager与之前的PoolMananger功能一样,负责GameObject的Spawn、Despawn和Trim。
要注意的是:
(1)每个SpawnPool是EmeptyGO。
(2)每个PoolManager管理两个List (Active,Deactive)。
讲了一堆,最后告诉有一个NB的插件叫Pool Manager- -。
*LevelManager: 关卡管理。
推荐插件:MadLevelManager。
GameManager: 游戏管理。
㈦ unity如何架构一个游戏
似乎在国内游戏行业所有的新技术出来，都会被首先问到这个问题。这也难怪，在国内做游戏开发就等于做网游开发，这是我们现在的主流。然而这些新技术的发源地恰巧又是以console game为主流，它们或多或少都带有为console game服务的色彩。这个矛盾一直存在着，就像这个问题一直存在一样。从大的方面看，Unity，UE这些引擎都属于泛用型游戏引擎，基本的设计思想和架构都是大同小异。我们可以看一下这些泛用型引擎都可以解决什么问题。图形渲染至少在现阶段，图形渲染仍然是最重要的部分，也是唯一能够看到的部分，所以大家都会拿这个来衡量引擎的优劣。引擎厂商也最喜欢拿这个部分来夸耀它们的引擎如何如何的NB。现在已经不是quake的时代了，图形渲染技术方面已经没有什么秘密，使用的理论性的东西大部分还是以前的理论，只是为了使用显卡硬件加速和现在的图形接口(D3D,OpenGL)而做一些特殊的调整。在GPU Gems和Shader X系列讲的都是这些细节的技术。场景的管理和可见性判断还是那些octree，bsp/pvs，bsp/portal或者它们的变种，顶多加入了硬件支持的occlusion query（有些更专业一些，嵌入了第三方的可见性判断方案)。基本的动画系统都是skeleton+morph，加上各种动画融合方法和IK支持。粒子系统各个引擎几乎一样（能有什么本质区别呢）。渲染效率的优化上除了与可见性判断有关系，就是那些通用的优化方法：尽量减少渲染状态的切换，按照shader排序渲染，多线程渲染支持。都支持后期处理(hdr, ssao...)。灯光和材质系统，在表现上可能是差别最大的。Unity的材质系统需要自己手写shader，而UE是通过连接图形化的shader表达式节点自动生成shader。这似乎很高级，但是如果会连接这些节点，我想已经距离会写shader不远了，怎么能指望我们的美术同志们会用呢。效率方面，这些引擎都不会有什么本质的区别，包括作为纯图形引擎的Ogre也不例外。真正担负大量计算工作的是显卡，引擎所做的工作无非就是让显卡尽量不做无用功。也不要认为一个很好的视觉效果和引擎有多么大的关系，也许他就是一个shader的工作而已。真正好的视觉效果是靠好的美术做出来的。物理模拟PhysX最早想推自己的PPU，也就是物理加速卡，将物理计算硬件化，但后来没有成功。被NVidia收购后，就将物理加速的重心移到了GPU上。现在PhysX与GPU结合的很紧密，可以真正实现大规模的物理效果。这也使得它成为所有商业引擎，乃至自己开发游戏引擎的不二之选。物理模拟的各种效果，比如刚体铰接，布料运算，流体运动学等等，都是物理引擎支持的功能，游戏引擎只是将这些功能整合到自己的架构中而已。所以对于物理模拟这方面，所有的引擎应该也都支持的差不多，不会有什么本质区别。游戏基础架构和脚本扩展在这些引擎上面制作游戏，主要方法就是依靠引擎提供的基础游戏架构(场景，游戏对象，资源对象...)，使用脚本加入自定义的游戏逻辑功能。这个基础架构的思想都是从最早的quake引擎来的，功能上都是大同小异，只是实现上有所差别。Unity使用的是.net平台，UE使用的是私有的UnrealScript。网络通信都有为局域网多人游戏设计的网络通信功能。在实现上，基本上都是基于UDP，建立自己的一套网络协议，支持保证和非保证消息，支持游戏对象的状态复制和RPC调用。虽然称其为局域网通信，并不代表不能通过internet连线。一般可以通过外部的配对服务器或者dedicate server实现internet互联。这种网络模式与MMO游戏有着很大的区别。首先，这种模式虽然在概念上也是C/S结构，但是并没有像MMO这样明确的区分client和server。在这种网络模式上一般构建的都是联机游戏，就是其中一个人建立游戏服务器(自己也是client)，其他人连进来开始游戏。其次，这种网络模式没有为大规模在线提供任何的专门的支持，一般支持人数都在64个以下。如果使用这种网络通信功能来做单机+连线游戏，还是非常的方便的。如果要用来做MMO游戏，这种网络通信功能不可能有任何的帮助，需要完全自己重新建立。所以一般都会拿这些引擎来制作MMO的客户端。这点就是我所说的最具有console game色彩的部分。综上所述，泛用型引擎如果用来做console game，那基本上可以满足所有技术上的要求了。如果用来做MMO，除了作为客户端引擎，来满足客户端的通用技术需求外，别指望更多了。MMO是一个比较庞大的工程，除了客户端，还有很多技术工作需要自己去完成。回到题目，Unity在MMO制作上相对于其他引擎到底有哪些优势呢？Dot NetMMO客户端经常需要添加一些额外的功能，比如自定义的与game server的socket通信，网络消息的整编解编，web访问，xml解析等等。对于UE来说，由于整个开发环境都是构建在自己引擎的基础上并使用私有的脚本开发，除非引擎自己支持这些功能(C++支持)，否则没有办法仅从脚本层进行扩展。而Unity不同，它整个构建在.net平台上，可以极大地从.net平台的各种支持库中获得帮助。需要的功能基本上用.net都可以直接搞定。UnrealScript再强大，也没有办法和一个成熟的.net平台媲美。资源管理资源管理可能是MMO客户端最特殊的需求了。MMO客户端所使用的资源数量与传统的游戏不在一个数量级上，并且随着更新和维护，资源数量还会不断的上涨。为了不使你的客户端因为没有可用的内存或显存而挂掉，动态的资源调度和管理是必须的。Unity和UE在资源管理的基本概念上都是一致的，就是基于一个场景进行资源管理，场景作为资源引用的根节点，所有被引用到的资源都会在场景加载时被加载，切换场景是使用垃圾回收机制，释放没有被引用到的资源。对于单机游戏，这个方法很适合，开发者甚至都感受不到资源是如何被装载和卸载的。而对于MMO来说就不行了，可能需要根据游戏逻辑细粒度的进行资源装载卸载工作。Unity提供了场景和资源包(AssetBundle)的动态加载和卸载功能，为高层的手动资源管理提供了可能性。编辑器扩展在刚开始接触Unity时，它的这种奇怪的IMGUI模式令我很困惑。后来慢慢发现，虽然这套gui并不是非常适合作为游戏界面框架，但是用它来开发自定义编辑器真是再方便不过了。Unity本身的Editor也是全部构建在这套GUI之上的，在Unity中制作一个自定义编辑器几乎可以是1~2个小时的工作。多平台支持这个似乎不用多说了，是Unity主打的优点。支持的平台非常广泛，各个平台的构建工作流非常顺畅，还可以自定义构建脚本。
㈧ unity 4.x 和 5.x 的c#脚本有差别吗如果有，差别大吗
框架改了些，4.0x上的c#脚本可以用在5.0x上，但是有些函数、属性、方法 会提示你已过时，让你用其它方法替代，不过即使你不修改 大多数情况还是能直接用的。
㈨ unity3D里面的脚本编写是什么样的原理运行起来是怎么样的呢
非常好的问题，这个涉及到引擎的脚本系统，我自己都没有完全弄清楚。你只需要知道unity脚本是基于组件的，引擎负责管理组件对象的生命周期，因此你在unity脚本中看到的Awake，Start，Update等方法都会由引擎所调用。
而脚本虽然是C#写的，但是会被mono编译成IL，然后目前unity可以选择IL2CPP，也就是说最终代码被编译为C++。这样的好处是mono的runtime是有缺点的，而且JIT本身是影响性能的。而且还有一个很重要的原因是unity本身是C++写的，直接编译成C++比较方便的调用引擎内部的函数。
㈩ Unity教程：Unity脚本程序基础(三）
中国AR网（www.chinaar.com）连续分享了Unity教程，获得了火热的反响,今天再次分享教程《Unity教程：Unity脚本程序基础》
Unity脚本语言：
Unity3D 目前支持三种语言的脚本程序，包括C#、JavaScript、 Boo,在一个游戏中开发者可以使用一种或者同时使用多种语言来实现脚本的控制。
教程由中国AR网资源教程（http://www.chinaar.com/ZYJC/）分享，更多教程进入中国AR网可以看到，有相关问题也可以在文章后面进行评论。