Unity3D使用经验总结 缺点篇

Unity3D使用经验总结 缺点篇

不论是从官方手册,还是各种第三方教程,几乎涉及到的,都是讲如何使用U3D,以及U3D的优点。

虽然我是用的一个让步语气,但请不要否认U3D的这些优点,它们的确存在。 但对于一个引擎的特性来说,优点与缺点总是共存的。

你可以从网上了解到所有优点,但是,你很难真正体会到U3D的缺点,除非你自己被坑过。 今天,我就来细数一下U3D的缺点。 这些缺点,仅针对大中型项目。 小型项目,U3D的优点可以充分利用。

 

是不是猛的一看,全是缺点。 不要怕,想看优点的朋友,走这里  Unity3D使用经验总结 优点篇

 

一、环境

U3D的环境可以说是非常OK的。一体式的感受,让所有工作都无缝地进行。 真要说它有什么缺点,还很难找到。 但有几个地方,不得不说。

1、U3D默认不支持多项目,每次打开场景,则会关掉当前场景,再打开下一个场景。 而双击U3D的启动图标,又会自动打开最近一个项目。 想要解决这个也还好办  在快捷方式后面加上 --project即可。 加上后,每次编译时会有一个提示,这个无关紧要。

再试试双击U3D的快捷方式,是不是会让你选择项目啦。

 

2、多个U3D版本不易共存,网上也有人提供了解决方案。但是,这始终不是太爽的一件事。

3、编辑器未和执行环境分离,若要DEBUG,必须启动U3D编辑器。 而很多时候,对于程序员来说,是不需要的。 它们只是想改改代码,然后编译,执行。 或许,U3D可以通过命令行提供一个较轻量的启动环境。

4、如果代码中出现了死循环,那就只有强行结束U3D,然后再开。 中间如果忘了保存,那刚刚做的场景编辑工作,就洗白了。

 

二、开销

基于Mono的运行环境,导致引擎起步价就比别人高。初始化时间过长。 这对于中高端机来说,是感觉不到的。但低端机,相比之下,就显得尴尬了。 而这一情况,对3D的影响还好。但对于一个小型的2D游戏来说,就会被人误认为,游戏做得不够好。

U3D虽然提供了原生的2D支持,但是其本质仅仅是在运行期锁定了相机,集成了BOX2D物理和2D碰撞生成器等东西。 运行时期的起步价开销,与3D是等同的。

 

三、代码驱动的开发模式

不管是官方示例,还是一些入门教程,都是以代码驱动的方式来引导大家熟悉U3D。 当然,代码驱动方式也确实很方便,同时更能章显U3D的强大。

对于一个小项目来说,代码驱动无疑是最便捷的操作方式。

但是,对于一个大型项目来说,代码驱动的结果则是BUG频繁,且很难逐一解决。 同时,对策划要求较高,策划需要知道不同对象应该挂什么样的脚本。 而对于代码驱动的开发方式来说,编码的人,最好就是策划。为不同的对象,使用脚本定制特定的功能。

因此,使用U3D做大型项目的话,还是得需要退回到经典的数据驱动模式。 数据驱动模式则正好没有代码驱动模式面临的问题。同时,数据驱动才能更好地做出网络游戏。

关于这个问题,我想等有时间了,专门弄一篇文章,向大家表达一下我心中所想。

在这里,简单地提一下脚本挂接需要注意的地方

 

U3D的组件思路是要一直沿用的,如果脚本不挂在对象上,那就失去了这个NB的特性,现在,我们要决定怎么样挂。我的思路是,对于一个对象来说,如果是对其能力进行扩展的,那就可以将这样的特性挂在对象身上。 反之,如果是决定游戏流程的,那这就应该是普普通通的代码,不能挂到对象身上。

下面,举一个简单的例子。  玩家走到一个触发器上,触发器触发,然后,玩家移到新地图。

首先,触发器本身是一个对象,它会检测是否有对象进入它,如果对象 玩家,那将会被传送。

对于一个普通的gameobject来说,是没有检查对象进入和触发能力的。 那,我们可以将它的COLLIDER弄成TRIGGER。 但是,一个对象的RIGGER触发的检测,只能是在挂在它的对象脚本里做。

按我们上面说的原则,那当脚本里检查触发后,我们就不能直接操作玩家。 而是应该将这个事件抛出,由逻辑来处理。

于是,我们可以写一个事件类,这个事件类负责管理所有事件,然后感兴趣的对象,可以来对里面的事件进行接收和处理。

我们还需要一个TrigerDetector来做所有触发器的挂接。 剩下的事情,就是真正的游戏逻辑来做了。 

 

上面是单机的情况,那网络的情况,又怎么做呢。 这就是数据驱动的魅力了。

对于这个触发器,我们可以挂接一个teleport的脚本,这个脚本什么功能都没有,只有一些变量,如目标地图ID等。另外,我们还需要将这个对象标记为SERVER对象。

然后,我们需要扩展编辑器,将场景导出。标记为SERVER对象的,则导出到SERVER使用的数据文件,没有标记为SERVER的,则导出到客户端的数据文件里。

然后,前后两端进行加载和操作。至于如何导出,下面有简单说明。

 

四、所见即所得

咦,这不明明是优点么。为毛又成缺点了。

其实,这确实是优点,而缺点其实不是因为它,而是因为U3D采用二进制存储场景文件。那多人协作的时候,SVN冲突可是一桩接着一桩的。 

解决这个的办法也挺简单,我们扩展一下编辑器,将对象导出成非二进制格式不就成了么。然后再在游戏里面,重新加载。

思路是这样,要实现这个中细节,其实也挺麻烦的。我们公司的编辑器虽然功能不多,界面不美,但是却优雅地解决了这个问题。

这套方案也不是一两句话能说清楚。 总之,记住,这里是个坑。

既然提到这里了,如果不说点具体解决办法,可能有人说我是装B了。 那我说一个能够一定程度上解决冲突的办法。

1、场景中所有对象,使用prefab。 不能有非prefab出现,且不能修改prefab的任何属性

不能修改属性的原因是为了保存的时候简单,如果大家属性都一样的话,那我们只需要存它的缩放,旋转,平移以及对应的prefab名字就可以了。 遇上需要不同属性的东西,那新建一个PREFAB

2、扩展一个编辑器功能,将场景导出为XML或者JSON什么的文本格式

这个文本格式,保存了所有的对象信息,每个对象信息包含缩放,旋转,平移以及对应的prefab名字。 当然,这不是死的,如果有其它需求,可自行添加。比如,对象的初始active状态

3、新建一个真正的场景,里面只有一个GameObject对象,这个对象只挂接了一个脚本,这个脚本的初始化,就是调用游戏逻辑的初始化,这个脚本的UPDATE,就是调用逻辑的UPDATE。

这其实就是一个MAIN入口。 你的游戏逻辑应该是与具体场景无关的。 你只需要加载你先前导出的文件,然后对所有对象进行实例化即可。

 

这个是解决SVN冲突的第一步,同时也是数据驱动实现的第一步。

 

 

关于游戏的增量更新之类的坑,并不是U3D特有的,通常只有两个解决方案,一个是数据和代码分离,以减少更新压力。 另一个是纯脚本,实现所有功能,包括资源的加载什么的。 不管采用何种方案来应对这个问题,数据驱动是必然的。

这也是我入手U3D的原因,因为通过编辑器扩展,我找到了数据驱动的解决办法。

 

其实,最想说的两个问题都说了,一是数据驱动,二是SVN冲突解决。但U3D肯定不只这些坑。 但那些坑,都是很具体的,通过具体需求才能解决的。

上面讲到的,是所有项目都适合的坑。希望对大家有帮助。

 

 

 

posted @ 2014-05-28 09:05 麒麟子(Alex) 阅读( ...) 评论( ...) 编辑 收藏

你可能感兴趣的:(Unity3D使用经验总结 缺点篇)