Unity3D使用经验总结 缺点篇

不管是从官方手册，仍是各类第三方教程，几乎涉及到的，都是讲如何使用U3D，以及U3D的优势。

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

你能够从网上了解到全部优势，可是，你很难真正体会到U3D的缺点，除非你本身被坑过。 今天，我就来细数一下U3D的缺点。 这些缺点，仅针对大中型项目。 小型项目，U3D的优势能够充分利用。

 

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

 

1、环境

U3D的环境能够说是很是OK的。一体式的感觉，让全部工做都无缝地进行。 真要说它有什么缺点，还很难找到。 但有几个地方，不得不说。

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

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

 

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

三、编辑器未和执行环境分离，若要DEBUG，必须启动U3D编辑器。 而不少时候，对于程序员来讲，是不须要的。 它们只是想改改代码，而后编译，执行。 或许，U3D能够经过命令行提供一个较轻量的启动环境。

四、若是代码中出现了死循环，那就只有强行结束U3D，而后再开。 中间若是忘了保存，那刚刚作的场景编辑工做，就洗白了。

 

2、开销

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

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

 

3、代码驱动的开发模式

不论是官方示例，仍是一些入门教程，都是以代码驱动的方式来引导你们熟悉U3D。 固然，代码驱动方式也确实很方便，同时更能章显U3D的强大。

对于一个小项目来讲，代码驱动无疑是最便捷的操做方式。

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

所以，使用U3D作大型项目的话，仍是得须要退回到经典的数据驱动模式。 数据驱动模式则正好没有代码驱动模式面临的问题。同时，数据驱动才能更好地作出网络游戏。

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

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

 

U3D的组件思路是要一直沿用的，若是脚本不挂在对象上，那就失去了这个NB的特性，如今，咱们要决定怎么样挂。个人思路是，对于一个对象来讲，若是是对其能力进行扩展的，那就能够将这样的特性挂在对象身上。 反之，若是是决定游戏流程的，那这就应该是普普统统的代码，不能挂到对象身上。

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

首先，触发器自己是一个对象，它会检测是否有对象进入它，若是对象 玩家，那将会被传送。

对于一个普通的gameobject来讲，是没有检查对象进入和触发能力的。 那，咱们能够将它的COLLIDER弄成TRIGGER。 可是，一个对象的RIGGER触发的检测，只能是在挂在它的对象脚本里作。

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

因而，咱们能够写一个事件类，这个事件类负责管理全部事件，而后感兴趣的对象，能够来对里面的事件进行接收和处理。

咱们还须要一个TrigerDetector来作全部触发器的挂接。 剩下的事情，就是真正的游戏逻辑来作了。 

 

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

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

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

而后，先后两端进行加载和操做。至于如何导出，下面有简单说明。

 

4、所见即所得

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

其实，这确实是优势，而缺点其实不是由于它，而是由于U3D采用二进制存储场景文件。那多人协做的时候，SVN冲突但是一桩接着一桩的。 

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

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

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

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

一、场景中全部对象，使用prefab。 不能有非prefab出现，且不能修改prefab的任何属性

不能修改属性的缘由是为了保存的时候简单，若是你们属性都同样的话，那咱们只须要存它的缩放，旋转，平移以及对应的prefab名字就能够了。 赶上须要不一样属性的东西，那新建一个PREFAB

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

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

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

这其实就是一个MAIN入口。 你的游戏逻辑应该是与具体场景无关的。 你只须要加载你先前导出的文件，而后对全部对象进行实例化便可。

 

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

 

 

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

这也是我入手U3D的缘由，由于经过编辑器扩展，我找到了数据驱动的解决办法。

 

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

上面讲到的，是全部项目都适合的坑。但愿对你们有帮助。