RT。受官方那个c++的shootgame影响比较深吧，觉得FPS达到那样的效果还不错。如果用蓝图实现和c同样的FPS游戏功能，那两个效率之比，蓝图如何？

vs崩溃好久，从高二到现在一直都没用过c++的功能。shootgame那个demo的代码也没打开过。也不知ue4的c++是什么机能，和UDK的ucscript有啥区别。目前看来做一些简单的FPS，蓝图可以胜任并做一些常见的像机瞄跑步弹药的内容。但是用c++的话是否要敲很多行代码呢？

蓝图不原生花，效率 帧率几乎是c+的十分之一

@-STPEAK 大佬怎么看

蓝图效率没那么垃圾,说效率低的80%都是根本就不会用就乱喷,其次蓝图在打包好的游戏中,才能体现出真正的效率,在编辑器里运行和打包出来效率是不一样的,就好像c++ 的debug模式和release效率完全不一样,差了好几倍.
用蓝图来做的话,基本感觉不到两者效率上的差别,蓝图效率低只体现在那种需要好几万次的大循环上,其他的感受不出来,在说了蓝图写游戏也基本不会出现需要进行好几万次的大循环的情况
但是,蓝图的一个非常大的问题就是如果项目做大了极其容易发生灾难性的文件损坏!导致工程无法打开,轻则找到那个损坏的蓝图替换掉就行了,重则连锁反应坏了一片蓝图
还有最坑的是蓝图有时候会"埋炸弹"比如看上去这个蓝图没任何错误,不一定什么时候你只要添加一个新的组件或者添加一个Cast,只要一保存,这个蓝图就废了
总之,蓝图的效率问题不需要担心,除非你要做那种需要好几万次的大循环,这还得看情况,看循环体里是什么东西,真正需要担心的问题是蓝图的稳定性

如果是想用代码写游戏,推荐先学透蓝图,因为蓝图所需要的编程思维,和其他所有面向对象的编程语言是一样的,当你蓝图学透了后你会惊奇的发现,C++你只需要稍微的看看语法,你就会用了

蓝图就是C++封装成的脚本语言，不过是可视化脚本，蓝图即是C++，通过蓝图运行程序的时候的确没有C++那么原生，（毕竟是从一个一个的结构包里使用资源），打包后就不一样了，UE引擎会对蓝图进行智能编译，把一个一个使用到方块，在还原成基本的代码API方法，进行打包，最后效率逼近原生但有差距，这个差距仅对千万级对象的科研开发有影响，对普通民用软件来说觉对够用，包括大型MMORPG或堡垒之夜这类多人射击游戏。（很多人说虚幻引擎优化差，多半是美术模型贴图面数高，程序对象池不合理导致，比如XX求生，和编程方式没多大原因的....）英配自家的很多游戏都是C++搭建整体框架，蓝图做具体的单位逻辑和动效表现，可视化节点加智能化编译构成的模拟化脚本，这块随着硬件越来越高，智能编译越来越趋近原生，在3D制作领域越来越能代替原生编程了，这是个趋势，毕竟原生编程仅是一小撮人的红利，模拟化脚本可以让引擎成为各类行业通用工具，不仅服务于游戏产业！

商店的MagicNode Plugin可以在蓝图里写cpp了

要看你怎么做了，常规情况下 BP 效率并没有 C++ 那么高，但是也不至于低的这么夸张。
一般开发者主要遇到的问题是图形优化压力，Drawcall 压力，真正算到代码层面的不多。
一般建议 C++ 做功能，BP 做数据连接和传递，这个应该效率不错

简单的说就是，蓝图把一个功能的C++代码整合成了一个可视化操作节点，但是这个节点里的内容数据有时候包含了你不想要的资源属性，必然在调用或静态运行中浪费性能资源，反之C++虽然没有蓝图操作简单方便，但是你写的什么功能属性就是什么代码的可读性一目了然。
总结：如果想优化代码什么的肯定首选C++了
如果想快速入门，就选蓝图
（但是注意为什么现在市面上的UE4总被人批优化差，虽然引擎的光影什么的确实消耗资源，其次是模型的优化。但是还有一方面就是蓝图制作的造成资源浪费）

用了这么久，感觉蓝图带来的那点cpu上的损耗几乎可以不计，不管是蓝图还是c++。
项目做到最后瓶颈基本都在gpu图形渲染上。
蓝图唯一的缺点就是，一旦坏了就比较麻烦。你需要把蓝图文件复制到新项目，然后删除导致损坏的部分，再移回去。
或者想将项目的引擎版本降低，蓝图就彻底没辙了。
c++完全没这烦恼。

机器压制和手工打磨的区别

关键是C++可以开发大型网络游戏，你开发fps游戏总不是想自己局域网自嗨吧，蓝图做不了，偶尔有蓝图的websoket插件，可能更新个版本就用不了了。