育才学习网unity中框架怎么写
1.我就是不明白unity的框架结构到底是怎么回
字符串做参数找方法可以通过c#的反射实现；monobehaviour没有抽象或虚拟update方法，因为抽象方法必须实现，这样太繁琐，我们平时只需要实现很少的方法；虚拟方法默认空函数体，虽然什么都不做但还是会调用，这样会消耗性能；所以最后unity的做法是，你需要什么方法写什么方法，如果你想可以被继承那么也可以写成virtual的，unity会调用最后一个实现的版本，这和继承的行为是一致的。
那些没有写的方法在初始化时不会加入调用列表，这样就不会消耗性能。unity的c#是标准的c#，只是其运行在mono上而不是.net上。
2.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：游戏管理。
3.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再强大，也没有办法和一个成熟。
4.unity ui 为什么要框架
界面搭载好后，开始开发游戏内容，这下问题开始来了：
1.如何实现界面间的沟通？例如点击返回按钮，知返回上一个界面，点击背包道系统，弹出背包。
2.如何实现界面与游戏数据的沟通？例如点击排行榜，能列出最新的排名，点击购买车辆，能扣钱内并买入新的车辆。
一开始我的做法（我相信也是大部分新手最喜欢的做法）就是为每个要触发功能的UI添加一容个脚本，然后添加一个public gameobject,
然后拖入触发UI时要控制的object。在脚本的OnClick等函数里实现逻辑功能。
转载请注明出处育才学习网 » unity属性怎么写