C++ versus Blueprints


I was wondering what the trade-off would be when choosing to program C++ as opposed to Blueprints in UE4.
It seems that mostly a combination is used, and even though I’m more of an artist. I fear that blueprints might leave poor habits due to its visual simplicity.
Then again that is a personal opinion and i wonder what the experience of other artist/programmers are!

Well, I currently do not use C++ as I don’t want to learn all of the special C++ things that are specific to UE4, but I would use C++ for all of the heavy lifting, world generation algorithms, etc… You are correct to say that a combination is used, I’ve come to find out that many things are simply a waste of time to do in C++ rather than blueprint.

Fair enough, seems like the logical approach. However, don’t you notice a difference between C++ or Blueprints in your approach. It seems to me Blueprints gravitate towards a short term solution. Hard to get a definite answer.

The big problem for me with visual programming, is it is very difficult to read. So I would only use BP to call more complex C++ functions, in response to game events.

Hello, I’d like to ask about the performance. Is there a difference if you make a specific task on C++ and the same task with Blueprints?
At what point the Blueprints are getting heavier than C++?

If your more of an artist you want to do BP imo. Even if you were planning on doing C++ you would still want to know and understand BP. I mean there just like C++ functions called in like a flow chart layout. If your comfortable with C++ you will pick up BP in the matter of a couple of the first tutorial videos. Then you can decide. If you dont feel like your are an expert at C++ then the learning curve will go up exponentially v.s. BP which are alot easier to learn. With BP there is no syntax to worry about, You can create them in the UE4 editor and do not need visual studio installed and configured to compile your UE4. Those 2 things if you dont know what your doing will cause alot of headaches.

As of now where I’m at with my project I’ve been able to do it all with BP and haven’t had to write one line of code yet.

I would recommend blue prints to anyone getting involved with UE4 even if you are a C++ programmer with game design experience.

C++ has been stated to be about 10-15 times faster than Blueprint, which is on par with or better than Unrealscript used to be. This performance difference really only matters for very performance intensive functions. Most applications blueprint can be used without you being able to notice the difference. The more you can do in fewer actual nodes the less of a problem this will be. The devs said something about blueprint existing in some layer that has to be traversed each time a node is called. I want to say this was discussed in depth in one of the recent twitch streams regarding performance optimization.

Personally I much prefer the node based blueprint scripting to C++ coding- it feels so much more unified with the editor, and makes scripting a whole lot more “fun”. If you have a project in mind- look at what you will need to do in order for it to work- many games can be extremely effective without needing a lot of code- high quality art assets/sound/visuals make up for a large portion of the experience- so unless your game involves really heavy or complex tasks, you won’t notice at all. I’m always bound by my render thread, and I only start seeing BP performance issues arise when I have very heavy chains of nodes acting on tick, which is a bad thing to do in the first place. I wouldn’t say Blueprints are a “short term solution” at all- they really are extremely powerful, and I have yet to say “wait I can’t do this in Blueprints- better go back to C++”. If you forget about the performance issues (which aren’t really issues)- to me, it feels like a big step forward to coding in general- more accessible, more visually engaging, and fully integrated into the editor- no need for Visual Studio. I think the learning curve for C++ or any other language was so high that for many people it stopped them trying to create their dream projects (myself included)- Blueprint bridges this gap, without nerfing functionality, and giving you all the tools you’ll need. If I ever was unsure of how to do something- dragging a pin out from the node I wanted to add function to gave a list of available options- almost 100% sure this isn’t present using C++, but so many times it has helped me get from “hmm, how can I do this?” to “oh yeah- of course- thanks context sensitive node creation” :slight_smile:

Developers have said that C++ is around 10x faster than blueprints, but this doesn’t really matter if those playing the game are bound by GPU.

Use Both C++ and Blueprints

Both Blueprints and C++ have their advantages!

I really think its a misconception to think that either C++ or Blueprints can exist independent of each other in full commercial game!

Blueprints and C++ are designed to work together :slight_smile:

C++ is better for math and intensive calculations that you want to run at highest possible speed, the kind of speed people used to have to pay $1000’s of dollars for prior to UE4 (we are all quite beyond-lucky that Epic is giving us C++ for for free!).

C++ is the only way to add new code to the Engine and do things UE4 has never done before, bringing in third party code libraries to add whole new features to the render code path of the engine or any other low-level aspect of the Unreal Engine.

Blueprints is the ideal way to handle asset references, and spawn particles and play sounds, and any thing that you’d want to tweak over time and iterate over quickly. So all core C++ variables should be exposed to Blueprints for fast-editing / iteration. Blueprints is also involved any time you want to use UMG for your game UI! Yay for UMG!

Blueprints is also required to involve the maximum number of people in your project so everyone can participate in building the game simultaneously. Blueprints offers unparalleled gameplay iterative testing speed via PIE and all the C++ variables that you exposed to be tweaked in the Editor!

**Asset Referencing**

Asset referencing simply must be handled in Blueprints because hard coding asset paths in C++ can break during packaging and simply break the game. You can't even rename a single asset if you are referencing it via a hardcoded path in c++, let alone move folders around and expect the game to sitll work!

This means every C++ base class should a have a Blueprinted version that fills in all of the asset references created as UPROPERTY in the C++.

Gameplay Coding Summary:

C++ ~ Core engine that performs calculations at highest speed and then tells Blueprints when to spawn particles/effects/sounds that can then be easily tweaked in the Editor.

Blueprints ~ Asset referencing and fast iteration of test code and all C++ variable tweaking to fine tune the core C++ engine.

This way you get the best of both worlds, and can really enjoy using both C++ and Blueprints!



Agreed - especially when it comes to materials. While I’ve written custom shaders on the Unity side of the house, creating and manipulating shader logic via the material blueprint editor is like HEAVEN!!

Er? Actually I find the opposite to be semi-true…the inability for effective revision control on blueprints is actually a deterrent in this area - simultaneous edits and merging issues makes this a pain point.

If you’ve ever been burned by trying to migrate an assert (for example - a blueprint based on a C++ class), you would disagree with this statement. It is a nightmare. The editor/blueprint based wiring can be brittle at times and re-configuring all those values from scratch can be a just brutal chore. I’ve taken to referencing assets (for creating instances of materials for example) in code more and more to prevent this sort of brittle binding. Yes - renaming things can be a cause for concern - but having a documented process and keeping all of your asset names in a single common place can help mitigate it.

As always - find the workflow that works for YOU!