Unity3D如何有效地组织代码
发表于2017-12-12
准确地说，代码作为Unity项目里的一种资源，此问题应该扩展到如何组织Unity资源。简单说说我们的经验：
所以我们自己的代码，一般目录名会以下划线开头，譬如 "_Scripts", "_Prefabs"等。
- 对于场景，文档等目录，用两条下划线，以便他们能排在最顶部。
- 代码用C#，别用JS。必要的话用namespace将自己的代码括起来。我们是用namespace把自己积攒的公用库包住。
- C#的注释要认真写，打///就能帮你补全了，没理由偷懒。
- 每个程序文件开头要用一段注释写修改Log，谁改过什么简单留一条说明。就算用了Unity的版本管理或者Git，那些log终究会丢失，只有认真把log写在代码里，才会有意识去认真优化它。
更多的是脚本里与其它的脚本进行交互。Unity里提供了一种万金油的方法是SendMessage, 这种方法性能略差，如果你调用的频率不高，随便用也无妨。另一种方法是直接通过对象的实例去调用。
来自：http://blog.csdn.net/zhaoguanghui2012/article/details/50535786
我们的做法是写几个公用的控制器，让它们各司其职，负责各自的事情：
- 写一个一个GlobalManager.cs来控制游戏的全局变量及全局方法。静态类模式。譬如当前玩到第几大关第几小关，玩家的金币数量等。
- 写一个GameController.cs来控制当前关的游戏进程。单实例模式。游戏的主循环也是用它控制。初始化，胜利、失败判定等等。
- 写一个InputController.cs来控制所有的用户输入。单实例模式。鼠标、键盘、触摸屏，我们做游戏是保证同时支持这三种输入的，因为大部分时间是在PC上测试。
关于GameController与InputController的联系，有点让人纠结。一般来讲是在InputContoller里调用GameController.Instance.Foo()执行方法。或者直接对Input写成Listener的模式，让GameController去监听。
- 其它的类似菜单控制器，声音控制器，成就控制器，IAP虚拟道具控制器等等，也是采用类似的方法管理。
- 关于PlayerPref的操作，统一写成静态类的get/set模式，程序中哪里要用则直接读写。
- 如果你的项目里场景的数量少(<5)，那么拖入场景的资源可以很随意。如果场景数量很多（几十个，有的解谜游戏每个关卡就是一个场景），那么拖入场景的prefab数量一定要少。
- 设计你的prefab资源里，你要想像当其他人拿到这些资源，是否直接拖入一个空场景里就能run，顶多再简单设置几下。如果你设计的资源不能做到这些，那么得好好重新想想。
写了这些，感觉写不下去了。
想吃透Unity，起码得真做出几款产品放上线才行。真正做产品的过程中会碰到各种各样意想不到的问题，代码不断地被重构和妥协，不存在什么最佳的方案。
我们的做法是写几个公用的控制器，让它们各司其职，负责各自的事情：
- 写一个一个GlobalManager.cs来控制游戏的全局变量及全局方法。静态类模式。譬如当前玩到第几大关第几小关，玩家的金币数量等。
- 写一个GameController.cs来控制当前关的游戏进程。单实例模式。游戏的主循环也是用它控制。初始化，胜利、失败判定等等。
- 写一个InputController.cs来控制所有的用户输入。单实例模式。鼠标、键盘、触摸屏，我们做游戏是保证同时支持这三种输入的，因为大部分时间是在PC上测试。
关于GameController与InputController的联系，有点让人纠结。一般来讲是在InputContoller里调用GameController.Instance.Foo()执行方法。或者直接对Input写成Listener的模式，让GameController去监听。
- 其它的类似菜单控制器，声音控制器，成就控制器，IAP虚拟道具控制器等等，也是采用类似的方法管理。
- 关于PlayerPref的操作，统一写成静态类的get/set模式，程序中哪里要用则直接读写。
- 如果你的项目里场景的数量少(<5)，那么拖入场景的资源可以很随意。如果场景数量很多（几十个，有的解谜游戏每个关卡就是一个场景），那么拖入场景的prefab数量一定要少。
- 设计你的prefab资源里，你要想像当其他人拿到这些资源，是否直接拖入一个空场景里就能run，顶多再简单设置几下。如果你设计的资源不能做到这些，那么得好好重新想想。
写了这些，感觉写不下去了。
想吃透Unity，起码得真做出几款产品放上线才行。真正做产品的过程中会碰到各种各样意想不到的问题，代码不断地被重构和妥协，不存在什么最佳的方案。