往往一个游戏公司中,一个大型的项目都是很多人共同配合完成的,每个人都分工明确而又互不干涉,相互独立而又密切合作。这就需要主程的框架了。在游戏行业,一般情况下,程序就只做和代码相关的事情就好,建模师就弄模型就可以了。策划就只写和游戏策划相关的。这样事情就简单多了。如果你让一个建模师去给你的一个UI组件挂一个脚本,那不是很尴尬吗?别人压根不会啊,再或者你每次都喜欢把脚本手动挂载在UI控件上,如果建模师不小心把它删掉了,那么久会出现各种问题,找起来也要半天。所以如果有框架能动态的自动挂脚本。这样就能免去我们很多的麻烦。这里我做了一个这样的小demo,实现了程序,模型的分离,很好的达到我们想要的效果。其实像这样的思路,我们也是有这样的框架或者模式的,而且比较成熟了,在很多领域都可以用,不只是游戏领域,那就是MVC模式。先看下效果吧:
需要拿demo,点击下面链接即可
至于MVC模式是什么意思,这个我就不多说了,百度下就可以了解到了。那我们就开始制作这个demo吧。
首先我们需要用到编辑器扩展,来写一个方法,就是要生成那个UI的属性,这里的属性是任意的,可以是组件,也可以是它上面的脚本。编辑器扩展代码如下:
这是最简单的编辑器扩展代码了,然后我们的重点来了,我们需要知道的是选择的那个UI的名称,位置等信息。OK,所以我们需要写一个脚本,专门用来获得选择的UI的这些信息。代码如下:
这样就可以得到用户选择的UI的这些信息了,当然你也可以扩展,我这里就写了这么多,仅做演示。然后值得注意的一个点,就是我们的类用partial关键字修饰了,这样的话,就表示这个类是拆分类/合并类。因为这个关键字的作用是把类或者结构体局部化了,这样的话,只要同样拥有这个关键字的类,都可以归为一个类,前提是类名要一样。然后我们就可以再写一个局部类来测试我们的理论和实际是不是一样的了,上最后的测试代码:
然后我们把这个测试类挂载在UI控件上,然后运行就可以测试了。至于UI的制作,简单,就没说了。以上就是这个案例的demo制作流程了。看不懂的可以找我拿demo。
不喜勿喷哦!