请问UE感觉相对Unity来说很"难用"？
unity的好多设计是对开发者很友好的。架构设计比较灵活拓展。c#也是语法糖很优雅的编程语言。虚幻是epic团队做他们自己的游戏再把引擎分离出来卖挂了很多的gameplay逻辑在里面。但是UE可以让美术和策划没有很好的编程功底都能做成很棒的原型。而开发c++要兼容很多硬件平台，所以通常用宏或者typedef重新统一类型兼容跨平台。而c#有mono虚拟机帮你做了这一切。但是开发的轻松程度不是单纯对比编程语言的上手难度。虽然客观讲c++对开发者有一定要求但是真正的难题不是看编程语言的复杂度。而是好多硬件兼容性问题导致的crash，基于虚拟机的脚步反而会比用c++更加难以定位问题。因为你用的不是源码版本的mono哪怕告诉你某个底层报错的符号你也很难定位，定位到了也改不了只能想办法绕开。
用虚拟机的编程语言难的是这种问题。因为虚拟机代码你改不了。但是如果是虚幻引擎因为底层源码都是用c++写的崩溃能追到符号表反而相对容易找到问题和解决。 unity的好多设计是对开发者很友好的。架构设计比较灵活拓展。c#也是语法糖很优雅的编程语言。虚幻是epic团队做他们自己的游戏再把引擎分离出来卖挂了很多的gameplay逻辑在里面。但是UE可以让美术和策划没有很好的编程功底都能做成很棒的原型。而开发c++要兼容很多硬件平台，所以通常用宏或者typedef重新统一类型兼容跨平台。而c#有mono虚拟机帮你做了这一切。
但是开发的轻松程度不是单纯对比编程语言的上手难度。虽然客观讲c++对开发者有一定要求但是真正的难题不是看编程语言的复杂度。而是好多硬件兼容性问题导致的crash，基于虚拟机的脚步反而会比用c++更加难以定位问题。因为你用的不是源码版本的mono哪怕告诉你某个底层报错的符号你也很难定位，定位到了也改不了只能想办法绕开。
用虚拟机的编程语言难的是这种问题。因为虚拟机代码你改不了。但是如果是虚幻引擎因为底层源码都是用c++写的崩溃能追到符号表反而相对容易找到问题和解决。 USTRUCT和UCLASS核心解决的问题还是一个gc的问题，这些问题Anders Hejlsberg都帮我们解决了，UE的傲慢在于他觉得自己跟海尔斯伯格水平差不多，甚至还高明一些，所以才会选择C++作为【脚本语言】，注意，其实行业内的嘲讽是U++。
UE对于很多问题的理解都是菜鸟级别的，典型的就是他们理解的“数据驱动”，实际上在游戏行业内被戏称为“Excel驱动”，UE对于“数据驱动”的解说，你网上一搜一大段，我就不贴了，找到自己信服的看就是了。
但是Unity用的是真正的数据驱动模式（当然和ECS是不同的），他的Component的概念就是及其标准的data driven了——因为我有这个component所以我有这个功能，而不是我本来就有，填了数据才能正常运作。
data driven的本质并不是说我填了表，让已经固有的逻辑运转起来——本质上，UE的蓝图也是一种填表，蓝图只不过换了个Excel的UI而已，最终蓝图能组织的逻辑也是非常简陋的，核心功能你还是得用U++甚至C++去开发，比如一个很常见的功能“根据策划配置在json的脚本函数名运行一段脚本函数（或者一个蓝图）”。
data drive的本质是将逻辑数据化、模块化、可插拔化。比如我有个MovementComponent，他的工作就是管理GameObject（UE的Actor）坐标变化的，装上以后GameObject的Transform.position或者localPosition就能变化了，no side effect。但是UE里这层抽象就非常狗屎，还不知所云的分了PlayerController和AIController。
而游戏的程序开发，本质就是一系列的系统去驱动一系列的数据（这里的“数据”你也可以理解为Struct，和Data driven的数据Data之间没有直接关系）发生变化——角色是数据、子弹是数据、地图是数据，然后比如角色的移动系统，就是根据游戏规则去改变角色数据中的Transform数据。当理解了这个之后，你会发现进一步抽象，一个数据（特指Struct）被抽象为更多个Data，被更没有side effect的系统所依赖（因此才有了Data驱动了System的效果），才是更好的抽象，最后发现ECS是最好的架构，并且ECS还解决了网络同步问题——每个客户端逻辑(system)单独运行，只要同步Data（也就是Component）即可。
当然Unity的思路和ECS还是略有不同的，尽管她自己也给了ECS的方案，但是同样作为Data Driven的结构，他本身的框架也非常适合游戏开发了。但是UE则不同，UE的OOP思路历来就不太适合游戏开发，即使古早的传奇(delphi5开发，delphi可是提倡OOP的泰斗级软件了，毕竟Object Pascal)，也不会像UE4框架写出来的游戏那样，最后一个角色，连自己的老子（Parent）是谁都分不清。事实上本质问题还是，OOP是不适合游戏开发的，这个就一言难尽了。
所以如果觉得UE4比Unity难用，作为游戏开发者，是【至少】入门了的表现，如果还觉得UE更好开发游戏，必然都是外行，顶多用蓝图做个demo秀一下（事实上你在b站看到的所谓大佬们的demo，99.999%都是做不成正式游戏的）。不是资本市场的商业原因，相信没有团队会去选择用UE，除非团队的技术官水到极点（或者是不做游戏的，比如你让阿里系的P9 P10来选择，他们连游戏是什么都不一定知道，当然就……） UE外面人看着光鲜，内行人都懂，太多的历史包袱，祖传代码。UE比较重继承，设计上反而不如unity组件设计。所以要摸明白整体的架构才能有所作为
页:
[1]