饭后温柔

汉堡与老干妈同嚼 有可乐味
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

unity的一些tips

Posted on 2016-06-15 12:30  饭后温柔  阅读(851)  评论(0编辑  收藏  举报

主要是我知乎上回答的一个关于unity的tip,备忘。


说说我所看到unity相关的,不好的习惯:

1 尽量不要在Awake(), start()等函数内加入业务逻辑的初始化代码。首先无法简便的直接启动调试查看。逻辑代码依赖太多,很多时候你只是希望检查界面编辑效果,在你不加入逻辑代码直接启动的话,基本会出来一大堆错误。另外,各个脚本start等函数的调用顺序很难控制,不要说可以调整脚本优先级,这个功能大致用用可以,不要依赖它。更何况很多人甚至不知道这个功能。初始化必须要显式调用,除非你知道自己在干什么(比如一些单纯的效果类脚本)。


2 不要public太多的变量到编辑器中,特别是逻辑变量。尽量减少脚本外部引用特别是对GameObject的引用。这对维护来说真的是一个梦魇,死的很难看。


3 一个Level内,要控制它的tree层级。你能想象一个MainMenu的level,直接包含了所有的UI,他们直接的脚本相互之间引用Level内GameObject。你能想象一个主脚本内有几十个引用到外部GameObject的变量吗? 单是要在编辑器内找到这些变量对应的GameObject眼睛都要瞎掉。有时在缺少信息的情况下只能靠猜的。应该把每个功能独立开来做成预制件,每个功能有管理自己的独自脚本组,然后再添加到主level内。这是基本的模块化而已,不能因为unity太好用就可以乱来。


4 有人似乎意识到了自己public出来的变量太多了,或者纯粹是懒得加了,于是当他确实需要引用某个外部GameObject时,通常都用someobject.getchild(i)来取得引用。 这绝对是值得捅一刀的行为,你的项目如果有人这么用,不要我说了吧。除非父节点之下是一个节点链表(如滑动框集合),否则谁知道getchild(i)得到什么意外?我就发现往某个节点增加了一张图片,然后整个模块的逻辑全乱掉了,这简直是谋杀未遂啊。


5 管理规划好你的NGUI的depth。2.7版本以下不要随意移动z轴和depth来达到显示效果,永远要有一个基本depth参照值。设计好atlas的划分,如果你不想遇到增加或减 少一张图片就会遇到奇怪的遮盖或消失问题。特别是你的level很庞大时,我发现无解。强烈建议升级到NGUI3.x,痛苦但值得。


6 coroutine是个好东西,但别滥用。实现一个状态机是有必要的。别的不说,至少不会在所有模块的各个角落里都添加上新手指引的代码了吧?建议仿照boost的statechart写一个简化版本,爽死你。


7 善用uigrid,uitable。当你写一个背包UI时,还要手动写每个格子的长宽,padding逻辑这是折磨自己,坑死别人,何苦。


8 规划好你的object的结构,这通常比你所写的脚本更重要。更一般的说,数据结构简单易懂,直接反映问题,这样你的逻辑代码才会清晰简洁。


9 设计不要超越或强迫程序。比如,要求一部分UI背景处在3D背景之后,其他UI的在3D背景之前,而这个3D场景是游戏主场景,忘了说你还要照顾在这之间穿插的粒子效果呢。我无法理解这种给自己下绊的尴尬决定是如何诞生的。可能2个原因吧,一是之前程序使用NGUI2.7,整个3d场景的layer被设成跟UI一致(无法想象),然后程序通过z轴和depth来达到这些效果。看到这我已经很凌乱了,而且居然无法说服他们这是不对的...


10 资源命名有待规范,目前资源包括预制件的命名混乱随意。这个是整个项目人员素质问题,或者说缺少个规划。


11 atlas的资源分布好好好规划。美术风格上尽量使用通用的控件,通用的控件使用的atlas限制一张之内。不要鬼扯什么设计不美观的问题,一张2048x2048的atlas大小,都容不下你惊人的设计能力?特殊的图片按照level或加载状态分好atlas。尽量做到动态创建销毁。不要包含过多的大图片,能从设计上避免就避免。


12 我真的不建议把UI直接跟level做在一起。如果是轻UI类型的项目可以。做uiniy要时常考虑一点就是,level,prefab,atlas等等都是个二进制文件,svn下不可比对,意味着你修改某个东西时,在这个level下的所有东西都要被锁定了,其他人只能等你。


13 SDK接入时,养成代码里就做好平台区分的习惯,用宏加上状态机。因为SDK是个巨坑,先保证己方代码不出错,才能自求多福啊。平台区分代码(宏),尽量都放在相同的代码段中。


14 c#的话,模板可能会是个问题。我会告诉你相同的模板代码,在andriod下build通过,在wp8和ios就不行呢。写的朴实点了。


15 资源方面,请试着封装一个resource manager。加载资源,prefab,level等时想着bundle。到处resource.load是不行的。这是个蛮头痛的问题,我还没真正开始做,异步加载估计有很多问题等着。

 

16 NGUIDebugTool里的接口有点用。

 

17 建议你的UI弹出子菜单能做到即时创建即时摧毁,多数情况下其实无须考虑加载时间,如果要可以尝试协程分步缓一缓。

 

18 NGUI的编辑器相关的代码可以借鉴下,反正我自定义的显示在inspector内的变量都是参考NGUI的,能显示的漂亮整洁些。


在可编辑性和代码控制间权衡好是使用unity的很重要的问题。


unity是个编辑器,意思是不只是程序员用它。请所有相关的开发人员熟悉基本的工作流程与概念。