Why blueprint and C++ projects?

Newbie - Most all tutorials start with a Blueprint project. But after reading some material, the author mentioned ‘If you start with a Blueprint project it’s harder to incorporate C++ whereas if you start your project as a C++ project, incorporating Blueprints is much easier. So start with a C++ project.’ I don’t know if that’s one man’s opinion or what but the real question is Why do you have to decide if you want a Blueprint Project or a C++ Project? Why isn’t a project just a project?

You don’t really have to choose one or the other. You can add a C++ class to a project by clicking File -> New C++ Class, and then selecting which parent class you want to base the new class of of.

@jnbbender Those are just project templates to quick setup a project of those types. While the blank blueprint projects just open an empty level, the blank C++ project creates a Visual Studio structure (if in Windows) ready to be compiled and with a basic skeleton of necessary code.

Those templates exist for a simple reason: there are people not familiar with C++ and want to work on features that does not rely on it, so they can stick with all offered by blueprints and go as far as possible (this is very true for artists not familiar with coding in professional languages) and there are people who wants to develop complex things which to be efficient need low level resource access for full control (this is very true for very skilled software developers, not necessarily game developers), so they will start with C++ and interface with the Editor exposing their code to blueprints, so artists can have access to their optimized code or features.

If you are newbie as you say, stick with blueprints and learn the most of what is possible to achieve on it, and only them start your adventures on C++ (if you don’t care, you don’t need to).

Thanks all. After looking at the detail you must go into a Blueprint ( creating loops, assigning variables, etc.) it seems things would just be faster on my fingers to write it in C++. Thanks for the input.

This is quite a complex discussion topic that universities usually cover under a “Software Architecture” course. To try and make it simple, you can’t make a large house on bad foundations. There are a couple of core principles:

  1. C++ -> Blueprint communication is a-ok, but Blueprint -> C++ is ugly, difficult and usually means you did something wrong. For example, you don’t want to create a function in BP and then try and call it from C++. If you need that, you want to create a BlueprintImplementableEvent in C++ and override it in BP.
  2. If you create a system of any complexity in BP, injecting code into it is usually exponentially more complicated than the initial system. You always want to have code in your base, then build up to BP.
  3. Code should not know about your “game”. Your code are your systems, your Blueprints are your game. The code should know about “a spell does damage using this formula” but Blueprints do “if I come close to this rock it will turn into a fish and start spitting spells randomly at a 500-radius around the player”
  4. You are not creating the code nor Blueprints for yourself, but your designers. You know, the people who don’t know the difference between a website and a word document in most cases. Your variables need to be categorized, properly named, everything needs to be baby-proofed. We had designers do silly things like scale a landscape actor (boy could I tell stories about that one). Which brings me to my next point…
  5. Data validation should be everywhere. This is a huge point for code-based projects. Adding data validation is unfortunately only possible through C++ now but it will have your assets hook up into the map check functionality and spit out big huge red text if something is wrong (like a landscape actor being scaled).
  6. Blueprints might seem easier and simpler but as complexity increases the maintainability and readability of graphs drops exponentially. A gigantic code class is far easier to read and understand than a gigantic Blueprint.
  7. UE4’s flavor of C++ isn’t as scary as most people think. Through the crutches, UPROPERTIES etc. it’s more akin to C# than “raw” C++

I got sidetracked there a bit and it probably seems more like random rambling than a coherent “list” but I hope it might help with some common BP vs C++ concerns.