序
1、一个Unity框架需要满足的条件:
(1)对于程序、策划、美术可以一起流畅的工作;
(2)代码维护便捷、维护成本低;
(3)降低开发的难度;
(4)有较好的游戏更新机制与版本管理;
(5)打包发布方便;
(6)打空包;
(7)制作工具:路径编辑工具 + 地图编辑器 + Excel表格解析 …
…
2、Unity开发框架的一些基本原则:
原则1:程序做程序,美术做美术,策划做数据;
—>程序逻辑与美术视图(地图、角色、UI、特效…)分开;
即:程序—>拼逻辑,美术—>做资源
—>程序逻辑与策划数据(Excel表格、行为树、状态机…)分开;
原则2:方便代码维护;
Q:Unity哪些编写习惯是不好维护的?
A:代码挂到节点(资源)上,这样在寻找代码在哪调用时,就需要依次将视图翻开,去寻找这个节点有没有挂脚本。
抛弃在视图上直接手动挂脚本,只有文本可搜索的代码,才是好维护的。
原则3:要求游戏场景不要放任何逻辑相关的内容节点,也就是说要让场景是空的。场景只是一个运行时的载体和容器;
这样更新资源会更方便,代码维护会更方便。
原则4:代码加载资源;
尽量不用Resources.load。
Q:代码加载资源,为什么不使用Resources.load?
A:Resources里的资源,不管用了还是没用,都要被打到包里去,这样会导致打空包不方便。其次,Resources资源加载,不方便做资源更新(热更新)。
使用纯Assetsbundle来做资源更新 + 资源加载 + 资源管理;
资源加载流程:
step1:加载ab包到内存;
step2:从ab包里面加载资源给游戏使用;
step3:做好资源管理,不用的资源及时释放掉;
优点:
(1)方便打空包(空场景,没有Resources)
(2)方便更新,Assetsbundle机制,天然就可以更新资源
(3)ab包会压缩资源,如果把资源放到安装包里面,包体会小
只要在StreamingAssets/ 文件夹下,就可以加载到这个ab包。
缺点:
(1)不想Resources.load非常直接的加载到资源,需要先打ab包,然后再加载ab包,再从ab包读取资源
所以,在开发的时候,一般使用两种模式,第一种是发布模式,就从ab包中加载资源;第二种是调试模式,使用Editor编辑器模式下使用AssetsDatabase加载资源。
这两种模式都使用同一个接口,GetAssets(路径):{调试模式->AssetsDatabase,发布模式->ab包}
资源管理
常用的项目文件夹结构:
在导入资源包后根据现有的文件夹结构,自行调整资源路径。
单例模式
一般常用两种单例模式,一种是普通的单例,另一种是继承unity的Monobehaviour的单例。
普通单例:
Unity单例:
主体流程
因为要保证场景中尽量不放置任何资源,所以在主场景中创建GameLanch对象并挂载名称相同的脚本,用来做游戏启动脚本。将此脚本继承Unity单例作为唯一的启动脚本。
再编写一个名为Game的脚本,也继承Unity单例。
之后在游戏启动脚本中引入游戏脚本。
加载资源(发布模式和调试模式)
然后初始化框架
这样在项目运行时,就可以发现游戏启动的对象有相应的实例。
UI框架
1、UI界面视图的制作 (美术 + 初级程序员 + 高级程序员)
(1)Q:哪些东西是能做成UI视图?
A:把完成特定功能的UI,做成一个视图。主游戏操作UI,例如:游戏商城、游戏背包、排行榜、结算视图…
反例:按钮做成一个视图(X)—>Button组件
(2)各个视图之间一定要独立,不要交叉引用;
单独适配,每个UI视图都要单独适配。
2、UI逻辑控制
一个UI视图,只能对应一个UI控制的代码;
一个UI视图,有且只有一个UI Ctrl 来作为他的代码控制
规定:视图名字 + Ctrl(Controller) 作为脚本名称
可以编写一个编辑功能 —>根据UI视图,自动生成代码;
(1)方便的接收输入;
千万不要在UI代码里,来写游戏逻辑,与UI无关的游戏逻辑;
通过派送事件来触发游戏逻辑;
(2)方便的显示结果;