在实际项目中,个人感觉,整个架构的核心(对我来说也是难点)就是数据的传递问题,尤其在unity中,跨脚本间的数据传递,首先要拿到脚本吧。有的架构思路呢,是建议少用或不用MonoBehaviour,就像非unity项目中的那样,有个主控逻辑驱动的类,里面进行update,这样抛弃了unity的组件优势,主要是因为不同脚本的初始化顺序、显隐控制是由MonoBehaviour自己控制的,不方便架构的驱动;另有思路是采用事件进行管理,通用的功能组件通过事件传递响应。实际应用很火的FSM有限状态机,我个人没有实际使用,但是我自己写的UIManager很像FSM,只不过我还是使用挂接脚本的方式,即UI呢是继承MonoBehavior的,具体优劣呢还是要分项目来说。unity架构中一些思想,我觉得有一些不错的,搜集整理一下。
- 设计的prefab,要考虑一下他人拿到后,拖入一个空场景里是否直接能够使用,顶多再简单设置几下。独立性。
- 代码结构要好好规划一下,包括文件夹组织、文件或组件命名规范等。
- 数据的抽离:静态的、动态的、全局的、本地配置文件的。
- 美术和策划的修改,提交后,其他人更新运行,能通过比较简单的方式或者说直接就能够看到效果。
- 状态这种思想有必要好好体会理解,在很多架构中应用,若设计得好,既方便修改扩展,也方便调试。
- 解耦,组件的独立性,说容易也容易,说不容易也不容易,不好细说,看具体情况。(可能我还没深入理解,因为我设计的不够好)
- 改动所牵连的修改尽可能的减少,牵一发而动全身的话,到了后期就完蛋了。如果过于复杂,还可以分层,分层的好处是专注,不同模块的开发干扰较少。
以上呢基本上包括通用的架构思路,但还是需要实际的项目磨炼,有时间,我自己打算尝试几套不同思路的框架,以项目的形式展现。