同时看过 unreal4 和 Unity 源代码的人觉得哪个引擎架构更好？
同时看过 unreal4 和 Unity 源代码的人觉得哪个引擎架构更好？ 其他的不说，就说说你觉得不值得一提的blueprint ，或者node based 的可视化编辑器，却开启了西方开发管线的新道路。西方workflow相信游戏机制的质量与迭代次数正相关，所以特别重视Prototyping 和Greyboxing 。与其让设计师写策划程序员实现或者自学脚本，还不如给他们更方便的方式去验证玩法，提高迭代效率。
所以现在西方3A的开发流程其实是让程序员写底层代码，或者实现计算量很高的方法并包装成node，再由gameplay designer 通过可视化编辑器去实现和打磨玩法。UE官方也是推荐用blueprint去开发，不像你说用来玩玩而已。
建议了解下他们的workflow，与国内是特别不同的。当然也不说个是与非，毕竟没有完美的引擎，题主说的也不是不无道理的，但是Unreal比Unity优秀的地方的确在于他们自己有开发游戏，他们的引擎结构自然是在开发过程根据自己的需求演变过来的（包括你觉得臃肿的Actor，我也认同），自然也经得起3A规模的开发需求。不像隔壁Unity，今天想弄个Runtime Navmesh这种0202年该有的基础功能都弄的我一肚子火，UE2013年已经支持了好吗？ unreal4...没得说
更新1：
- blueprint我觉得是神器啊，可以给策划拿来用（可视化编程），程序员也可以用的很开心~这个比你随便写几行，就要重新编译运行一遍强多了~
- FVector这个确实有union更方便，不过我觉得没有也可以接受~
- Actor里有很多业务逻辑接口，按照你的观点怎么设计更合适呢？ 我理解的是这样更多的是为了性能考虑。至于你说为什么不用支持反射的js/lua/mono，可以看下这个 https://forums.unrealengine.com/showthread.php?2574-Why-C-for-Unreal-4
我觉得到ue这种工程的代码，有时候不得不做一些tricky的写法了……而且有一个很有意思的区别就是，UE之前是做过游戏，而Unity是纯卖引擎的……
更新2：
我想确认下，题主说的“ 从结构上分析下那个引擎更好, 不考虑渲染质量啥的.”是指不考虑引擎效果、功能，单纯从代码质量分析么？ 两个引擎思路设计是不一样的:
Unreal注重的是工业化流程, 强调整体性, 官方性. 所以你会发现Unreal很少会有那么多的插件和扩展(普及程度是最大原因, 但还是和设计有关系).
Unity3D的思路就是全脚本化, 让大家来给它做各种Mod, 可以说是用互联网思想来做引擎. 有了流量和用户, 普及就不是啥问题, 更可以说自己的哲学是正确的
题主所说的, 用带反射的语言来做. Unity3D就是这么完成的编辑器. 可以说, 编辑器本身完完全全都是用引擎本体写出来的. 但引擎本体本没有编辑器支持.
而虚幻呢, 由于老的一些架构和思想下, 还是使用引擎本体糅合编辑器的功能, 通过宏控制来制作. 但多年的编写经验证明这么做其实也还好. 这是用C++做脚本这点. 我也感觉不大好, 至少来说, 开发效率和普及就受到很严重的牵制.
另外我觉得, Unreal这种整合方式的思想和Unity3D这种MOD开发的思想肯定会长期存在的, 各有各的好处.有的人喜欢完善, 有的人喜欢自定义. 就像Windows和Linux一样
萝卜白菜而已, 不必纠结 都好又都不好。个人感觉，到了这种程度的引擎已经不是靠一两个漂亮的写法或者实现取胜的了。我还没到看引擎代码的地步，但是最近客户端框架看了不少。我发现无论多么火爆的游戏他们的框架和实现都有蹩脚甚至丑陋的地方。我可以写出比它们更加优雅的实现。然而这并没有什么卵用。 看过unity源码。包括老的一套渲染，资产管理，对象模型，构建，以及ECS的资产管理和对象模型，渲染和构建还没细看。
于是，前两天改Unity源码崩了，默默打开UE4看UE4怎么搞定的。
“原来mac的cpuid直接写汇编了”
默默扒过来塞进unity
编译
....
编不过，淦!什么垃圾引擎。 ce3 2点几还是3点几有个版本源码里有注释是，我知道这里有问题，他会影响到xx，但是我不知道怎么解决，先备注一下。
题主看了ce岂不是要崩。 没看过unity源码。了解只限于接口层面。两者特点就不说了，大家都能数出出一堆。我只说些实际开发的问题。
十多年前那会儿，商业引擎稀少且昂贵。和很多公司一样，当时所在公司主张自研引擎，以掌握“核心竞争力”。
想法没错，但自研的成本太高了。特别对于中小公司。没有技术支持，没有现成的模式。连可以讨论的社区都不会有。策划和美术就是小白鼠，根据他们的反馈总结工作模式。然后改进工具。一做就是五六年。这期间加班熬夜不少，弯路也走了不少(最大受益者可能是程序员们，起码算是有意思的实践)。商业引擎的意义就是直接让你进入到量产阶段，帮你省了几年年自研一切的时间。
但商业引擎也有不靠谱的。我用过一个高价的烂货。名字不提了，免得被删，只说感受。编辑器极不稳定，缺少资源、甚至点错按钮(某按钮在编辑时不能按，一按就崩。。。)都能直接崩溃，且不显示原因；早期prefab设计的有缺陷，后来加新prefab方式打补丁，最终有N种prefab并存；不同平台接口/库差异巨大，一份代码无法在不同发布设置下通过编译；资源默认不打包，安装极慢；导出过程繁琐且全人工，需要手工挑选文件，为这事配了4个专人；第三方库多得夸张，引擎目录50多G，同一个第三方库在引擎里有好几份(第三方库用到同个库的不同方言版本。。。)；语言多到眼花，不算移动端的java与oc，全平台通用的有cpp引擎和逻辑代码，c第三方库，c#编辑器，py发布工具，as的界面，lua的策划脚本；不稳定又不开源，查到某处蹦了只能骂娘；没有自己的性能分析工具，官方让自己找；最后一击：官方宣布不提供技术支持了。。。
所以要么如unity那样没有大坑，稳定性好；要么完全开源，有问题你自己上。最怕这种半吊子的。当然谁让你用了它呢。立项时技术选型很关键。
像例子中的FVector，其实怎么写又能有多大区别？只要不对项目进展有可观查的影响，或有影响但不难改进，其实都不算问题。充其量能说代码不够美观。
站在程序员角度，自然会对代码的整洁程度在意。但别的工种未必这样看。比如我周围的美术就觉得unreal的编辑器用着更爽。他们更关注工作流是否顺畅。只要能按部就班的操作，把人力投入转化为等量产出，开销可控，效果一致，中间没天坑、没绊子，就是好引擎了。
所以不必纠结具体实现。先看你自己团队的人员情况和任务目标。有多大的锅，就配多大的铲。若缺少合格的Ｃ＋＋程序员或做几个月就出货的手游项目，明显unity更适合；团队人员素质够，或要做ＶＲ Ｄemo，那还是选Ｕnreal好。 占个坑位Mark一下这个问题，现在看的还不够全面，虽然发现了许多疑似性质的缺陷但是还没法下定论，等以后看全了再来详细理性的喷（划掉）讨论。 各有各的优势和特点，不能一概而论，准确的说谁也不可能替代谁。因为设计的出发点不一样，应对的场景也不尽相同，所以不能简单的放在一起做比较。unity固然是简单明了，但是框架设计上没有太多的利用c++新的语言特性，毕竟它的主力开发语言并不是c++，c++只是用来构建引擎的底层功能(不过很快c#就要取代它了，于是开源也指日可待)，所以你会看到很多旧时代的设计风格，其实整体阅读起来不是那么的流畅，回调函数满天飞，面向对象的方法论运用得不够彻底。反观unreal它就站在了unity的相反面，大量c++新增的语法糖充斥其中，让人眼花缭乱。看到那些类的继承层级和变态的模板泛化技巧，你估计会倒吸一口凉气。但正因为unreal忠实贯彻了面向对象的设计哲学，极尽所能的做到了程序高度的抽象和复用，所以理解起来还是非常直觉的，当然这也与代码的阅读习惯有关。关于代码的风格问题，我觉得epic被crytek严重带偏了，现在引擎中的代码整洁度远远不如unity那样漂亮(个人对代码格式和布局有洁癖)。深以为unity的团队执行着更加严格的编码审查过程，每行语句的缩进和关键字间隔，以及函数名和变量名都遵循着统一的规范，一丝不苟，像似专门有人反复校对过一样。unreal早前的代码还算标准，但后来估计加入开发的人员太多，又有社区的掺和，所以越来越乱了，很多嵌套的条件分支都没有合理的缩进和对齐，就像踩在泥里，一脚深一脚浅的，阅读起来非常难受。不过从引擎的代码数和功能量上说，unreal确实遥遥领先于unity，所以有那么多代码质量的问题，应该是可以体谅的，但还是希望epic后面有时间的时候好好把代码整理一番。
最后补充一点，unity反射给c#的c++函数是需要手动做binding的，而unreal却能自动完成，利用特殊的指示符宏和uht工具。这就看出unreal架构上的先进性了，因为反射binding会被外部开发者频繁使用，但unity只是内部引擎开发人员会偶尔遇到，所以不需要把它设计得那么自动化。