为什么有人用Unity引擎来做项目，却基本不用Unity里面的组件？

资源大湿 · 发表于 2020-11-23 19:06

NaNa公主 · 发表于 2020-11-23 19:06

不同类型的游戏用到的组件不同，还是要具体问题具体分析。题主的问题描述不详细，只能分类谈一谈。
1、某功能从零写起不难，自己完全可以做一个
比如常用的缓动动画插件DOTween，功能比较强大。但是很多游戏里并不需要用到它的全部功能。而研究一下Tween（缓动动画）的实现原理，你会发现很巧妙而且很简洁。
这种情况下不如自己动手写一个正好满足项目需求的简化版，好处是代码少且可控性强。
2、内置的组件不好用，不如自己写
Unity里确实有一些功能不强，无法应用于商业项目的组件，例如角色控制器Character Controller就是其中之一。它足以满足小型项目或者实验性项目的需要，但是一旦需求复杂就不得不自己实现一个更好的。
再比如一些UI组件。如果你不喜欢内置的进度条，或者和你的需求略有区别，那就可以实现一个自己的进度条。由于Unity已经提供了各种各样的图片显示方式，所以自己做一个也不难。
3、由于特殊原因，不能（或不必要）用内置组件
比如很多人会发现：用动画控制器做2D序列帧动画是大材小用。序列帧动画的本质就是改变图片，用脚本换图完全是一样的，如果封装得合适反而更直接。
还有很多成熟的2D角色插件用到了物理。如果因为游戏设计原因，不想用物理做运动，就可以做一个不借助物理的控制系统，包括模拟重力、检测碰撞等等都自己写代码实现。比如下文为了还原《空洞骑士》的手感，写了大量代码实现角色控制：
繁华如梦：用Unity重现《空洞骑士》的苦痛之路(2)——人物控制篇4、团队已经有了深厚技术积累，可以实现更好的组件
Unity底层开放的接口还是很多的，支持很大程度上的自定义。
比如多年前Valve为了用Unity做VR游戏，大幅改写了Unity的渲染管线。还有很多公司自己有一套历史悠久的粒子系统，使用更方便性能也更好一些。
5、某些组件很难被替代
如果你做的游戏正好需要在3D复杂空间中寻路，而且寻路的NPC也是人形角色。那么你会发现使用导航网格（NavMesh）或者新版导航网格是最好的选择。
复杂空间的寻路会涉及到三角形剖分、射线检测等问题，有很多细节问题需要处理，最好的办法还是借用成熟技术。

总之，用组件和插件好或不好，不能一概而论。我的观点是：

LNER · 发表于 2020-11-23 19:07

我也来说两句吧,其实我就是你说的那种人.
我最早在一家公司就用过一个月的unity,也没怎么熟悉,就知道一些基本操作和基本思想.
后来就去了另外一家,没有unity,所以就全是自己用c++手动写,从opengl的shader开始,一步一步往上搭,最终封装到顶层逻辑使用,也并没有什么不妥的地方,只是底层架构不算太好,渲染管线管理不好,添加一些基础功能时总是觉得找不到合适的位置,总之就是一开始就没有想好应该怎么去管理这些底层架构,虽然无论底层怎么改,上层也不用关心,反正就使用一些暴露出来的接口,只要接口不变,其他什么都不用改.
后来因为特效方面C++没有比较好的库来实现,公司就决定就转向unity开发.
所以就把底层代码去掉,接上unity的逻辑,然后上层架构也不用改,大部分结构也不用动,只需要unity提供一个update接口就可以.
所以就这样慢慢成型,到现在我也很少用unity的组件,经常看到其他人用一些什么组件做功能,我都好奇,你这到底是哪儿来的组件,怎么知道的这些组件.
我现在项目里很少有MonoBebaviour,有几个也是我用于面板显示调试信息用的.也有其他人写的MonoBehaviour,只是我觉得根本没什么必要,除了Start,Update,跟普通c#类没有任何区别.
这些的好处是什么.
1.代码风格统一.
2.能够100%掌控所有代码.不需要依赖于引擎的回调.
3.因为所有代码都是自己写的,所以需要实现功能时,不需要考虑有什么组件或者插件可以实现,而是专注于功能本身,去探究功能的本质.所以只要是做过的功能,从底层到表现细节都能够很好的掌握,印象也很深.
4.因为不依赖与MonoBehaviour的反射调用,所以任何地方打断点都能够看到完整的堆栈.查找bug更容易.
5.逻辑全部都集中在代码中,如果出现任何问题,只需要查找代码,而不需要去找那个物体上面的什么组件有没有添加或者启用.
6.代码全部都是自己的,所以有任何问题或者有任何的需求都可以随时添加.如果使用的其他插件或者unity内置的,则可能出现某些不满足功能,但是却无法修改,只能用一些歪门邪道进行处理.
等等的还有很多....
坏处嘛.
最大的坏处就是可视化功能弱化了,其实也影响不大,也可以像我一样添加一些用于显示调试信息的脚本,这些脚本也就只在编辑器环境下才会用到.
现在在我眼中,unity就是一个渲染引擎,最多还是一个物理引擎,至于项目代码结构,跟unity完全解耦最好.自己有了独立完善的代码结构,其实想要更换依赖的外部模块的时候也会很快.比如上个月我就把我项目从NGUI换成了UGUI,代码改动很小,预设上面的组件从Sprite换成Image,Texture换成RawImage,Label换成Text.大部分时间都消耗在了图集上.因为散图有几十万张....
其实我下个项目准备换成虚幻,代码整体结构基本也不用动,就只是把C#重新用C++写一遍.因为本身C#代码最初也是从C++重新写的,所以转换也不会花太多时间,改改数据类型,编译通过就好了,然后再测试测试.
即便换成虚幻我也只是使用虚幻提供一个更新接口,然后接入我的代码进行更新.也只是把虚幻当成一个渲染引擎和物理引擎.
unity也好,虚幻也好,cocos也好,都是只一个工具,也不要太依赖了,不然真的很难跳出来.

林洲91 · 发表于 2020-11-23 19:07

提示: 作者被禁止或删除内容自动屏蔽

killpause · 发表于 2020-11-23 19:08

谢邀。
很多人在用Unity之前就有了自己的一套开发模式，这套模式大部分时候会用得很顺手，开发效率很高，所以没必要强求使用Unity的那一套；但在面临复杂需求的时候，不如使用Unity的那套模式来得高效，而且也不算是融入了Unity的体系，所以这种路子并不值得学习。我本人也是类似的情况，现在越来越觉得这种模式不那么好了，正在改进中。
对于之前没有自己的积累的人来说，最好还是跟着Unity走，融入Unity，以Unity的那一套为基础开始自己的积累。

davidmr_001 · 发表于 2020-11-23 19:08

unity 提供的是通用功能，而且很多功能开发效率并不高。

unity组件提供的功能非常有限，但是扩展很方便。这就是为什么assetstore 那么火，很多其他引擎软件好用的功能基本都有移植。

对新入行和技术能力一般的人来说，使用默认和扩展功能是最方便可行的，而对一些技术实力强的公司和个人， unity提供的最大优点就是跨平台。

以前项目移植很麻烦，现在只要一份代码然后注意下平台差异就好了。所以unity才这么火。

其次是渲染模块，这个也是很麻烦的东西，要求数学和计算机图形学知识，这是国内很多码农不肯掌握的。导致现在unity里会写shader的人都不多。 unity现在版本渲染模块已经强了很多了，我入行那会基本还是要自己扩展的。 unity现在的渲染模块也是集成了很多其他公司改良后的功能。

unity的物理和寻路比较基础，复杂点的项目挺难用的。我现在的项目也是基本自己写物理效果。因为要做动态地图，寻路估计也要自己实现了。

unity网络功能一直挺迷的，现在的unet基本仿照 ue那套，不过用起来坑挺多。拿来做demo挺快，但是代码结构有点不合理。如果做成连连看无所谓，写代码服务端客户端混一起写，快是快，很难维护和更改。一般都是自己写的。

prefab component 那一套的话是挺好用的，不过只适合小型项目。项目复杂度一提高，改完代码还要修改prefab 之类的就很烦了。而且对热更新支持不好。如果你要最小化项目更新的话，一般都是写组装器，运行的时候组装模型动态添加组件。

不过要说效率的话 prefab 无论是开发还是加载效率都不错。

另外原始的prefab scene模式不太适合多人开发。尤其是需要非程序员参与的时候。

所以一般还要开发个项目编辑器，分离程序和美术。

最终功能肯定是跟项目需求走的。题主也不用着急，项目做多了自然就慢慢搞清楚了。

大部分同类型项目的功能都是差不多的。引擎只是工具，不能被引擎限制住。

MengAiLing · 发表于 2020-11-23 19:08

我来纠正几个概念
组件!=引擎
重复开发组件不等于重新开发引擎，我看有些回答问为啥还要用u3d，干嘛不自己做引擎，开发一个或者几个上层组件的工作量可能连完整引擎的1%都不到，你猜为什么不直接自己做个引擎？
其次某些功能不用u3d的组件以及自己重复开发组件很常见，因为u3d提供的组件大部分是不完备的，你开发个弱鸡小游戏可以，但是一旦业务复杂膨胀就歇菜了
而重复开发组件最大的坏处就是成本变高了
其次对人要求很高，要是你开发的组件还不如u3d原生的，那就算是瞎了

7759367 · 发表于 2020-11-23 19:09

学习做饭的捷径是看菜谱，买成品原料，买调料包。
如果你的目标就是做出来味道达到一般性标准，这样足够了。
但是如果你想随心所欲，遇到北方客人做咸点，遇到南方客人做甜点，控制软硬口感，调节香味，你会发现你必须理解食材，理解刀工，理解火候，理解调料包里面各种成分，恨不得糖盐花椒的顺序都要严格控制。然后你就不需要调料包了，甚至你自己都可以给别人做调料包了。
略微有点可悲的是，满足一般性味道，注意力集中在客流，成本上的人更适合当老板。喜欢做饭的人适合当厨子。

naya · 发表于 2020-11-23 19:09

大致可想到原因：
1、本身有成熟框架，Unity只作为一个渲染的环境。
2、Unity提供的插件功能，自己能够实现更加高效轻量的。
根据经验和自身能力选择合理的方式做项目即可。
当然如果想要更广的适应性，能够从0开始做东西的人必然可以获得更好的发展。

chu35177 · 发表于 2020-11-23 19:09

你应该跟着做。
不是应为组件优劣，而是因为你的领导既然决定了这个方向，那么好坏你只需要配合做。如果团队里面一半人喜欢这样，另一半人喜欢那样，项目最终会变得难以管理和维护。
既然你觉得现在的情况很容易看懂，很容易上手，那这样做就不是什么坏事。
至于优劣，就看项目的真实需要了和对引擎的依赖问题了。

		自动登录	找回密码
密码			立即注册

林洲91 林洲91 当前离线积分 118 窥视卡雷达卡	发表于 2020-11-23 19:07 \| 显示全部楼层提示: 作者被禁止或删除内容自动屏蔽
林洲91 林洲91 当前离线积分 118 窥视卡雷达卡
	回复推荐不推荐使用道具举报显身卡

为什么有人用Unity引擎来做项目，却基本不用Unity里面的组件？

本帖子中包含更多资源