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支持 。粒子系统各个引擎几乎一样(能有什么本质区别呢) 。