Unity有什么框选插件

似乎在国内游戏行业所有的新技术出来，都会被首先问到这个问题。这也难怪，在国内做游戏开发就等于做网游开发，这是我们现在的主流。然而这些新技术的发源地恰巧又是以consolegame为主流，它们或多或少都带有为consolegame服务的色彩。这个矛盾一直存在着，就像这个问题一直存在一样。从大的方面看，Unity，UE这些引擎都属于泛用型游戏引擎，基本的设计思想和架构都是大同小异。我们可以看一下这些泛用型引擎都可以解决什么问题。图形渲染至少在现阶段，图形渲染仍然是最重要的部分，也是唯一能够看到的部分，所以大家都会拿这个来衡量引擎的优劣。引擎厂商也最喜欢拿这个部分来夸耀它们的引擎如何如何的NB。现在已经不是quake的时代了，图形渲染技术方面已经没有什么秘密，使用的理论性的东西大部分还是以前的理论，只是为了使用显卡硬件加速和现在的图形接口(D3D,OpenGL)而做一些特殊的调整。在GPUGems和ShaderX系列讲的都是这些细节的技术。场景的管理和可见性判断还是那些octree，bsp/pvs，bsp/portal或者它们的变种，顶多加入了硬件支持的occlusionquery（有些更专业一些，嵌入了第三方的可见性判断方案)。基本的动画系统都是skeleton+morph，加上各种动画融合方法和IK支持。粒子系统各个引擎几乎一样（能有什么本质区别呢）。渲染效率的优化上除了与可见性判断有关系，就是那些通用的优化方法：尽量减少渲染状态的切换，按照shader排序渲染，多线程渲染支持。都支持后期处理(hdr,ssao)。灯光和材质系统，在表现上可能是差别最大的。Unity的材质系统需要自己手写shader，而UE是通过连接图形化的shader表达式节点自动生成shader。这似乎很高级，但是如果会连接这些节点，我想已经距离会写shader不远了，怎么能指望我们的美术同志们会用呢。效率方面，这些引擎都不会有什么本质的区别，包括作为纯图形引擎的Ogre也不例外。真正担负大量计算工作的是显卡，引擎所做的工作无非就是让显卡尽量不做无用功。也不要认为一个很好的视觉效果和引擎有多么大的关系，也许他就是一个shader的工作而已。真正好的视觉效果是靠好的美术做出来的。物理模拟PhysX最早想推自己的PPU，也就是物理加速卡，将物理计算硬件化，但后来没有成功。被NVidia收购后，就将物理加速的重心移到了GPU上。现在PhysX与GPU结合的很紧密，可以真正实现大规模的物理效果。这也使得它成为所有商业引擎，乃至自己开发游戏引擎的不二之选。物理模拟的各种效果，比如刚体铰接，布料运算，流体运动学等等，都是物理引擎支持的功能，游戏引擎只是将这些功能整合到自己的架构中而已。所以对于物理模拟这方面，所有的引擎应该也都支持的差不多，不会有什么本质区别。游戏基础架构和脚本扩展在这些引擎上面制作游戏，主要方法就是依靠引擎提供的基础游戏架构(场景，游戏对象，资源对象)，使用脚本加入自定义的游戏逻辑功能。这个基础架构的思想都是从最早的quake引擎来的，功能上都是大同小异，只是实现上有所差别。Unity使用的是.net平台，UE使用的是私有的UnrealScript。网络通信都有为局域网多人游戏设计的网络通信功能。在实现上，基本上都是基于UDP，建立自己的一套网络协议，支持保证和非保证消息，支持游戏对象的状态复制和RPC调用。虽然称其为局域网通信，并不代表不能通过internet连线。一般可以通过外部的配对服务器或者dedicateserver实现internet互联。这种网络模式与MMO游戏有着很大的区别。首先，这种模式虽然在概念上也是C/S结构，但是并没有像MMO这样明确的区分client和server。在这种网络模式上一般构建的都是联机游戏，就是其中一个人建立游戏服务器(自己也是client)，其他人连进来开始游戏。其次，这种网络模式没有为大规模在线提供任何的专门的支持，一般支持人数都在64个以下。如果使用这种网络通信功能来做单机+连线游戏，还是非常的方便的。如果要用来做MMO游戏，这种网络通信功能不可能有任何的帮助，需要完全自己重新建立。所以一般都会拿这些引擎来制作MMO的客户端。这点就是我所说的最具有consolegame色彩的部分。综上所述，泛用型引擎如果用来做consolegame，那基本上可以满足所有技术上的要求了。如果用来做MMO，除了作为客户端引擎，来满足客户端的通用技术需求外，别指望更多了。MMO是一个比较庞大的工程，除了客户端，还有很多技术工作需要自己去完成。回到题目，Unity在MMO制作上相对于其他引擎到底有哪些优势呢？DotNetMMO客户端经常需要添加一些额外的功能，比如自定义的与gameserver的socket通信，网络消息的整编解编，web访问，xml解析等等。对于UE来说，由于整个开发环境都是构建在自己引擎的基础上并使用私有的脚本开发，除非引擎自己支持这些功能(C++支持)，否则没有办法仅从脚本层进行扩展。而Unity不同，它整个构建在.net平台上，可以极大地从.net平台的各种支持库中获得帮助。需要的功能基本上用.net都可以直接搞定。UnrealScript再强大，也没有办法和一个成熟的.net平台媲美。资源管理资源管理可能是MMO客户端最特殊的需求了。MMO客户端所使用的资源数量与传统的游戏不在一个数量级上，并且随着更新和维护，资源数量还会不断的上涨。为了不使你的客户端因为没有可用的内存或显存而挂掉，动态的资源调度和管理是必须的。Unity和UE在资源管理的基本概念上都是一致的，就是基于一个场景进行资源管理，场景作为资源引用的根节点，所有被引用到的资源都会在场景加载时被加载，切换场景是使用垃圾回收机制，释放没有被引用到的资源。对于单机游戏，这个方法很适合，开发者甚至都感受不到资源是如何被装载和卸载的。而对于MMO来说就不行了，可能需要根据游戏逻辑细粒度的进行资源装载卸载工作。Unity提供了场景和资源包(AssetBundle)的动态加载和卸载功能，为高层的手动资源管理提供了可能性。编辑器扩展在刚开始接触Unity时，它的这种奇怪的IMGUI模式令我很困惑。后来慢慢发现，虽然这套gui并不是非常适合作为游戏界面框架，但是用它来开发自定义编辑器真是再方便不过了。Unity本身的Editor也是全部构建在这套GUI之上的，在Unity中制作一个自定义编辑器几乎可以是1~2个小时的工作。多平台支持这个似乎不用多说了，是Unity主打的优点。支持的平台非常广泛，各个平台的构建工作流非常顺畅，还可以自定义构建脚本。