unreal engine4 中c++与blueprint如何取舍，两者是什么样的关系？

sasasa0604 · 发表于 2020-11-25 12:59

blueuranus · 发表于 2020-11-25 13:00

蓝图有个硬伤，没法merge…这就决定了多人协作开发是件很不方便的事情。
所以我们在实际开发过程中都是用C++定义逻辑基类，蓝图里继承一下用于配置参数和资源引用，因为很多参数是可视化调节比较方便，资源引用写C++里对于更改和Cook扫描都不是很友好。这样做导致蓝图对C++有依赖，就会出现C++里改名后蓝图就废掉的问题，可以通过在Engine.ini里配置命名的Redirectors，能避免重新把蓝图拖一遍。
当然一些特定化的逻辑，如动画蓝图、关卡蓝图、AI、UMG什么的，该用蓝图还是用，C++搞这些还是不够方便。
最后还是希望Epic尽早解决蓝图merge的问题，要不然版本管理多分支的开发就很难推行下去，做大项目还是有些麻烦的。

tutushetou · 发表于 2020-11-25 13:00

无脑选C++或其他动态语言如Mono VM等等。
首先UE C++压根就不是普通的C++，官方已经保护住不少可能出现的大坑了，甚至编辑器也是魔改的，写起来就和高级语言差不多。带来的副作用可能性能有一点点损耗，而且对于非UE的C++程序员看起来有些……奇怪，不过问题并不是很大，做逻辑上架构也算比较明亮。
Mono VM这类虚拟机写起来更舒服了，不需要等编译，写一些对性能没什么苛求的逻辑是非常舒服的，开发阶段也比较有快感。
至于蓝图。。emmmmm。。之前有一项性能测试:
Unreal C++: 1.1ms
Mono VM: 1.9ms
Blue Print: 47ms
而且蓝图连出来一旦复杂了可读性真的是极差。
早日放弃蓝图，早日获得新生……

kili48 · 发表于 2020-11-25 13:00

其实都不矛盾的，两个都是工具，蓝图的优点是容易学，一个团队在项目初期脑洞时间，所有人都可以通过蓝图来快速实现自己的想法，大家讨论的时候可以相互展示，避免我想的和我说的自己你认为你听到我说的不是一个东西，。按照传统方法，大家都在描述自己脑子里的东西，现在所有人都可以参与进来。最后由程序员定型这个功能，玩法怎么实现。

很多时候蓝图的结构让它容易被看懂流程。联系学习蓝图也学c++ 你适应那个就用那个，反正新版本已经可以互转了。

乔明888 · 发表于 2020-11-25 13:01

两者可以并存，不是取舍关系。
根据以前我的开发经验，蓝图的好处在于方便实现，方便想法的验证。
这样一来策划花一点时间就能够通过蓝图构建一个玩法关卡，从而进行验证。
你知道这是多么大的进步吗！！！！！
对于开发团队而言，除非是天打雷劈的合拍，否则交流成本往往高到吓人。但是通过蓝图能够节省很多很多很多的交流成本！！！
性能低？不要紧，后期优化或者转C++就行了，更不用说蓝图->C++的功能已经在路上了……

qzuser · 发表于 2020-11-25 13:02

蓝图不是程序，而是包含游戏逻辑的一种数据类型
C++决定了蓝图能干什么，蓝图来控制怎么干
任何一个稍微复杂点的项目，这种数据类型都是必不可少的，如果没有蓝图，一个庞大点的类家族可能要有上千个子类，而且都是写死的，写死的！这种感觉像是你把所有三维模型的顶点索引转成数组保存在.h文件中。
当然如果只用蓝图，你的游戏类型和功能会严重受限，UE4就退化成了一个豪华版的RPGMaker。

nicyooh · 发表于 2020-11-25 13:02

反对一切说蓝图好学，团队都可用的。

一方面，大工程开发，蓝图对设计模式的要求非常严格，cast to实在太方便了，用蓝图很容易就写成一团麻。不只是形容连线，更多的是蓝图间互相耦合太紧密了。2017OpenDay看到某大神的蓝图，真的是太烂了。当然，大家喜欢他的作品是因为画面做的太太太棒了。

另一方面，蓝图也是编程，我所在的小工作室40多人，35+美术策划没一个愿意学蓝图的。

蓝图真的是看着无限美好，用起来一堆坑。

说几个常见的，蓝图体结构，写好了，发现缺东西，加个变量，然后，结构体坏了，蓝图里编译运行一切正常，cook就失败。这时你需要重命名结构体。于是我见过AIDataNewNewNew。
outermost depracated，还是那样，运行编译都正常，cook就失败。因为改了c艹代码，蓝图库懵逼了。于是，删除了整个工程里50多个节点，再重新加回去。
至于什么reparent后各种警告报错，蓝图类出错需要打开修复然而打开就崩，我都无所谓了，习惯了。。。
还有，蓝图本身依赖于编译好的模块，而跨平台很多模块不能用。所以跨平台要放到c艹里去。然后，我要吐槽某游戏硬件，插件写的真烂，我竟然不能用c艹编译通过。

稍微大一点的工程，还是用c艹吧，做好逻辑层和表现的通信，表现用蓝图。

a544797017 · 发表于 2020-11-25 13:03

什么？我居然被邀请了？！

我曾经在重庆一个VR公司做技术美术，一直用的UE4，但说实话我使用的经历也就半年。
说到这里会不会有很多人就不看我下面的回答了额(°_°)…

我一直觉得c++和蓝图就是相辅相成的东西。
是的，蓝图真的很简单，只要你逻辑清晰，开发一个小游戏不成问题。

● 复杂性
blueprint和c++都有一个程度的问题
如果你做一个简单的互动，例如：点到点之间运动的某物体。
蓝图咋做的？选中目标点拖到蓝图里，右键蓝图空白选择simple move to 然后各种连接目标等等，地图放上导航区，完成
然而c++呢？

摔！（╯‵□′）╯︵┴─┴ 老子文科生你问我c++？！

好吧，勉强凭借所学知识猜测一下。依稀记得我看过u3d里面的编程代码，虽然我看不懂....感觉编辑了蛮多东西，一大串一大串的。blueprint中的“simple move to”这么一个小的程序块就能代替那么多语言。
用蓝图这么几下就能做出效果的东西，用c++做会不会降低工作效率？

蓝图能做到的东西，c++也一样能。然而反过来呢？就不一定了！
蓝图的逻辑制作完全依靠里面已有的编辑好的程序块，如果需要达到的效果没有，虽然也可以自己制作函数内容。

不过复杂到蓝图功能无法实现呢？自然是需要自己去编啦！！！

以上为猜测....( ) 不对不要打我

● 困难性
16年8月刚入行，9月我就已经开始自己研究蓝图了，实在难的就去找当时的技术总监来一起讨论。
我是无任何编程基础的人，在使用蓝图之后可以满足项目的需求。但如果我去学编程然后再去应用到ue4当中去满足项目呢？
我觉得不一定会有我使用蓝图的效果好。
因为我没有编程语言的经验累积，但幸好我是有一定逻辑基础的人。
学会蓝图再去学c++会感觉很难，然而先学会c++再去看蓝图呢？

大概的意思就是c++比蓝图要难，可变化性也多，所以它要难得多。

● 相通性
蓝图也好 c语言也好，这些都是我们要达到目标的工具，重点是在实现目标过程中的思路最重要。怎样最省时间？不产生冲突bug？逻辑严谨？简化程序运行？提升速度？不管你拿什么做，都是要考虑的。
就像是“My name is xx”和“My name&#39;s xx”一样。怎么排列，怎么制作，怎么做到你想要的结果，完全取决于你在想什么。

你还问取舍？看效率！！！
别人会问你怎么做的吗？只会讲这个做的好不好而已！

如果有大神看到我这不成熟的回答请忽略
我没那么厉害，但是我有好学和研究的心。
(ˇˇ) 严肃脸

（是我的话，不会放弃任何一种可能实现的途径，有时候写蓝图往往看似不可能的地方却给了我可能实现的路）

liddx000 · 发表于 2020-11-25 13:03

要看你对自己的定位。
假如你是程序的话，C++是必须学会的，否则你会受制于还未提供给蓝图的功能。
而假如你是美术或者策划的话，只需要学习下蓝图就可以做到丰富的效果。
然后说下问题的答案:虚幻C++可通过UFUNCTION宏将函数暴露给蓝图，所以说C++代码是完全可以写出蓝图的功能的，只是编译速度太慢了要有取舍。但假如你希望用到一些虚幻C++已经封装好的而还未暴露给或无法暴露给蓝图的功能，那么，C++就必须是你要经历的一道坎。

高翔 · 发表于 2020-11-25 13:03

很多游戏引擎都是两个语言混合开发的，在我眼里，虚幻引擎就是c++混合一个脚本语言的一个引擎而已，使用原理和其他引擎一模一样，就是游戏大多数内容都用脚本语言实现，脚本语言一般都有易学易用的特点，脚本语言实现不了或者实现有难度的，才用引擎的底层语言。。。虚幻也是这个道理，蓝图，其实在我眼里就是一个脚本语言，只不过这个脚本语言逆了天，跨时代地先进过其他脚本语言几十年！彻底地实现思维导图式的设计思想和逻辑思想！！所以，游戏内容当然是全部用这个逆了天的脚本语言--------蓝图，来实现。当你发现蓝图有些功能实现困难或者无法实现，才用c＋＋！！！所以，这里面根本不需要做选择！大型游戏一定会是这么做的！小游戏也同理！

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