如何评价腾讯开源 Unreal Engine 的 Lua 解决方案 sluaunreal？
如何评价腾讯开源 Unreal Engine 的 Lua 解决方案 sluaunreal？ 可喜可贺。这无疑是对unreal社区的巨大推动。据我所知，这应该是目前第一个开源且达到产品级实用水平（对，这个是重点）的lua整合方案。有腾讯带的这个头，unreal的使用门槛又下降了一波。要知道目前Unreal不普及的其中一个大障碍就是推动团队适应蓝图 + c++开发并不容易。有了这波助推，再加上腾讯最近在UE4上的开发动向（大胆预测未来3年腾讯的头部自研项目会以采用UE4为主），unreal有望迎来一波小春天。
顺便 @庞巍伟 ，这波操作确实亮。
但是，同时也顺便说一下，蓝图是不是真的那么不堪，以及蓝图跟lua相比各有什么优劣。也给准备入坑Unreal的各位一个参考。
至少在国内的客户端圈子，多数程序对蓝图是比较抗拒的（包括以前的我）。今年年初我为我们项目（注，是pc游戏，不是手机游戏，有些细节考虑会不同）做unreal脚本语言选型的时候，花了一段时间认真的评估了几个方案：lua、mono、haxe、蓝图。
是的，因为有unity + lua的实践，所以第一个想到的就是lua（当然那时还没有slua-unreal）。
但是经过一轮实践之后，我们却最终选择回归蓝图，因为我们发现蓝图有非常多的可取之处，平衡下来反而更适合我们的项目情况。
所以为什么还是来给大家做一下分析，因为蓝图有缺点，也有亮点，接下来请看：
蓝图的锅
初次接触蓝图的时候，确实给人感觉这像一个给非程序使用的工具，而不是一种可以大规模工程化的东西，原因很多人都分析过，这里我再不厌其烦的说一下：
1.天然的文化抗拒，尽管蓝图是不折不扣的编程语言，但天然给习惯编码的程序员一种不适应的感觉。
2.写蓝图很容易，但写出高质量的蓝图却不容易，不加控制很容易搞出一些蜘蛛网图。这对程序团队有一定的要求。
3.代码冲突进行merge非常麻烦，必须要尽量拆分蓝图的粒度避免merge，甚至考虑使用代码库的lock来避免一个文件多人编辑。
4.蓝图的性能并不给力，我们做了一些粗略测试，比lua慢个10倍是常有的。这大大限制了蓝图的使用广度，在手游中可能更加严重。
5.在写计算密集的代码时，难以避免地会显得比较乱。
蓝图是不是根本没有作为主要开发语言的意义？
当然不可能，epic自己是做游戏的公司，他们肯定不会自己坑自己。事实上epic也证明了这个体系能做出非常优秀的工程质量。比如他们开源的gameplay ability，可以用蓝图清晰地组装出非常丰富的技能系统。
而我们经过一轮实践也是慢慢发现蓝图的优势比我们想象得要多。
1.蓝图是一个强类型语言，且不容易写出语法错误
1.用lua的同学应该很清楚写错变量名要在运行时才发现这个事情有多痛苦，往往这产生的时间消耗比c++编译还要命。
2.不容易产生语法错误的好处就是你可以交一部分逻辑给策划、美术去定制，不用担心他们天天问语法问题。2.蓝图跟编辑器的结合非常完美
1.你可以很方便地添加蓝图组件，直接在地图上编辑组件的数据
2.可以精确地筛选地图内单个角色的逻辑进行单步调试，这对rpg游戏调角色逻辑超级的爽
3.ui控件自动生成变量，省掉lua一个一个手工获取控件的工作，并且不用担心写错名字
4.unreal官方提供的大量方案都对蓝图支持比较完善，可以节省很多二次开发
5.可以直接定制变量的默认值、变量的一些编辑体验（变量分类、提示中文化），这对提升策划编辑关卡的体验很有帮助
6.用蓝图比较容易做出可以在编辑器内直接预览的内容3.蓝图与unreal c++的对象系统结合很完美
1.使用一致的数据类型，不用担心夸语言传参的时候做类型转换带来性能消耗，尤其是传递array和map的时候
2.蓝图和c++使用统一的GC机制，不用担心lua强引用某个对象产生内存泄露，当然这个在lua上也有很多方法可以规避，这个比较考验框架的设计。3.虽然蓝图慢，但幸运的是大部分情况下它不会带来致命的后果
1.很多cpu消耗大户（移动、寻路、AI、动画），unreal都用c++做好并且可以直接用。
2.由于蓝图和c++对象系统结合得很完美，所以你可以很容易把蓝图的一部分代码移到c++，这方面lua会相对痛苦一些，因为要处理很多数据类型不一致、数据放c++还是脚本的问题，很多时候不得不大规模重写。
3.lua虽然比蓝图快，但lua重度在战斗逻辑上使用还是有很多限制，并没有想象中那么自由。
4.前面也提到，蓝图和c++在数据访问结合上比较紧密，这在数据密集夸语言传递的情况反而产生了一些性能优势。4.蓝图非常擅长写流程相关的东西
AI、状态机、技能流程配置、关卡事件脚本、ui交互流程，使用蓝图做非常完美
蓝图对延时机制的支持非常完善，很容易就可以写出先做A，等会再做B的逻辑。5.蓝图可以编写construction脚本，这意味着可以写一些程序化生成逻辑并且在编辑器预览。
像smart spline（藤蔓绳索制作）、river tool（河流附着地形）这样的插件，lua写起来会需要一点绕（需要在editor运行时跑一个lua实例）。6.只用蓝图可以避免lua蓝图c++三通的一些问题，比如调试的不方便、各种复杂耦合导致代码质量下降。当然这可以通过程序的架构避免。
7.由于蓝图是官方支持的语言，所以很容易可以复用网上流通的蓝图插件，不需要考虑太多夸语言处理的麻烦。
8.最后，弱弱的说一下，c++好好搞的话（主要是include隔离），编译其实没那么慢~（笑）
说了那么多，简单说一下选择的大致思路：
1.如果你是一个小团队，个人更建议蓝图，减少一些二次开发的折腾。
2.如果你是一个中型团队，那么根据团队的实际经验进行选择，选择熟悉的方案。
3.如果是一个大型网络游戏工程，有比较频繁的上线迭代需求，那么lua是首选，在大程序团队代码质量控制上比较容易。
4.如果是一个大型的单机游戏工程，强调关卡和复杂的策划逻辑定制，那么蓝图依然是首选，通过细致的架构可以将大量的工作交给策划，更细致地做游戏性的内容，同时紧密地利用UE4编辑器的特性提高游戏性内容的制作效率。
最后，小小的可怜一下没人理的MonoUE，在我心目中最佳的游戏逻辑开发语言还是C#。23333 为什么不是mono + unreal.不明白 UE4的蓝图有几个弊端：
1、给程序员用的话，非常不友好。而UE4自身又没有其他脚本可用。
2、遇到冲突无法对比合并（不要跟我说UE4自带的blueprint compare）
基于上面的原因，UE4非常急需一门脚本语言来加速开发效率。
本人曾经是Unity slua的重度使用者。Unreal slua虽然没有详细去了解，但是猜测它基本思路跟Unity下的是一致的。
得益于cpp的反射，所以它能够很方便的帮忙把cpp或者蓝图借口导出来，不再像以前都要手工或者使用lua bind之类的工具（还是要手工写绑定代码）导出lua接口。
最后我想说的是，slua（的思路）真的很赞！
@庞巍伟 我这么夸你，大神要不要点个赞！？ 这种自问自答（描述中已经自答了）是打广告的姿势咯，同学~ 首先上面那个自问自答看的有些尴尬，这彩虹屁拍的。
作为sluaunreal使用者来正经回答一下。
目前的slua做商业游戏开发没有太大问题，我们项目绝大部分逻辑都已经放在lua了。实际使用中可能会遇到一些lua访问c++产生的性能坑，不过都是可以解决的。另外profile还有很大调优空间。
如果现在起新项目的话可能会考虑隔壁方案，隔壁方案在性能优化上比目前版本的slua好一些，而且还有代码自动补全能期待期待。 大规模使用slua的话，会不会破坏UE引擎中数据驱动的开发方式，导致程序员依然负担起项目中最繁重的开发任务，把程序员的瓶颈再一次强化。
个人感觉蓝图其实是比较好的开发方式（问题是国内策划美术的接受程度不高，比较抗拒开发蓝图） 很期待其Lua方案。
其实项目资源规划好，蓝图和C++配合使用，蓝图实现UI和事件等简单处理，具体实现都在C++，其函数声明都蓝图可重载，所有其C++派生蓝图，这些蓝图根据实际情况分类打插件包DLC，需要C++代码频繁热更，在其派生类蓝图重载该实现，然后打包DLC热更。前提做好蓝图管理. unreal不就是c++么，蓝图也是基于c++吧，这难道不还是cpp + lua的模式 和unlua相比怎么样？
页:
[1]
2