Unity项目架构设计与开发管理个人观看总结

常见的游戏架构有:

• EmptyGo
  就是最简单的创建一个空物体GameObject，把脚本挂在EmptyObject中，在使用的过程中经常会使用像GameObject.Find()这样的方法查找，是一个速度的很慢的方法，后期代码不容易维护，并且如果与与GameObject无关的东西一起的话会造成项目的混乱。
• SmpleGameManager
  在上面的基础上修改为一个可以随处访问的单例GameManager , 通过一个集中的地方来管理所有的东西，但项目大了也同样难以管理
• Manger Of Managers
  多个单例，Singletons，做成多个单例GameManager , 很实用，通常有一下几个Singleton:
  EventManager：管理所有UI之间的消息传递
  AudioManager：任何一个想要播放音频文件都可通过AudioManager.instance.play（）来访问，一般Sound类方法有
  
  GUIManager：GUI之间的点击事件
  PoolManager：（Create，Destroy）等耗时操作对象可以通过Pool起来，下一次用的时候可直接提取
  
  LevelManager：集中管理所有的关卡
  GameManager：除了这个，其他模块基本都是可以原封不动搬过来复用在其他项目中
  SaveManager：Load一些配置，暂停，保存是运用
  MenuManager：Menu上的动画，外观与GUI事件分离
  一般中型项目来说必须要有：LevelManager，PoolManager，SaveManager
  最好：GameManager，EventManager，MenuManager，GUIManager，AudioManager

LevelManager为什么要有？
比如Application.LoadLevel(“FirstLevel”)/(1)的时候，如果稍微需要改下Level的顺序或者复用场景希望传参的时候无法实现。
可以写一个配置表
自创一个API，LevelManager.LoadNext();
则以后只需直接修改配置表即可（assetStore上好用的插件：madLevel）
此外还可以集中管理场景加载时的：
transparency
Color
animation

• PoolManager
  RPG游戏中通常会频繁的创建角色NPC,由于会使得C# GC回收机制会很耗时，因此需要创建一个对象池

private List<GameObject>dorManObjects = new List<GameObject>();

典型操作有Spawn(),当要生成NPC的时候，就可以先要池里面看一下，有即可直接用，没有就创建一个
DeSpawn()用完NPC，暂时不用的时候放入池里
Trim（）最大容量 , 先进先出，后面如果满了还要放，则会把前面进入的object删除掉
为了能够管理所有的东西Active or DeActive 以及对Trim()里面的东西进行分类
可以对PoolManager设置层级

SpawnPool为一类的物体(Npc,掉落物体等)，可以设计为一个SpawnPool就是EmptyObject，PrefabPool只管理一个Prefab，则可以任意方便的Intance，对象池里的数量一次不难删大多，可以一帧删3-5个，否则会掉帧。

• SaveManager
  退游重进的保存功能等，有配置表，AssetStore上的优秀插件是LoadSave , 优点是全二进制存储读取，快，相对于json，xml，任何都可Serinlization,可加密
• MVCS:STRANGELOC
  一个SDK，一般来注册UI元素的事件时一般思路都是创建一个SingleTon，然后把所有的注册点击事件放里面，但是这样代码量一多的话，后期那个UI元素改了，就要去修改大量的函数代码，Strangeloc把UI与事件完全分开，只需要修改Mediator中介即可。
  思想：Bind方法，通过Key绑定Value ， 还可以通过取名字对同样的Key不同的Name也是不一样的东西

IBinder.Bind<Key>().To<value>().ToName(Name)

Key可以是event/interface/class对应的value是Callback/implementation/dependentClass

Event ->Callback
dispatcher出一个操作，Listener监听到绑定的操作，响应事件，观察者模式
interface->implementation

Context.injectionBinder.Bind<IWeapon>().To<Gun>()

缺点：依赖于C#比较慢的发射机制

• MVVM:UFRAME
  付费，框架，有可视化编辑界面
  
  总之就是要遵从一个最重要的原则，UI和逻辑层之间都要有一个分离层
  可有一个配置文件
  代码约束：
  逻辑文件夹尽量与GameObject的名称相同，如PoolManager下面的脚本最好也还是与PoolManager名称开头的
  0容忍warning与error,少用GetComponent<>()与GameObject.find()
  几个Unity Test Tools 免费测试框架

• Unittest

• Integration test
• Assertion Component