Mixing Blueprint and C++

Don’t add C++ because you think you need C++. Remember that a lot of people giving advice in the forums may be in a very different situation from you. The needs of a large AAA studio are different from the needs of a mid-size contract shot, which are different from the needs of a small indie team, which is different from the needs of a 1-3 person studio. There is no one-size-fits-all “best”.

For us, we do almost always create a C++ class and then descend our Blueprints from that custom class instead of from engine classes. That gives us the ability to move complicated, slow, or troublesome blueprints into code without having to deal with reparenting the blueprint. But, we’re a contract programming shop. All of our programmers know multiple languages and most have been doing text-based OO languages for a decade or more. For us, we’re not going outside of our comfort zone when we use C++. Also, we do mostly mobile work, and a lot of times, we’re pushing pretty hard on the limits of what current mobile devices are capable of. For us, it can be really helpful to get processor intensive stuff out of BP and into C++.

But, if you don’t already know C++, don’t force yourself to use it because you think it’s the “right” way, or the “serious” way, or because somebody told you it’s “best”. If you’re comfortable with Blueprint, there’s no reason not to use Blueprint, at least until and unless you have a problem that can’t be solved with BP. There’s a very good chance you never will such a problem. Epic isn’t pushing Blueprint as a gateway drug to C++… they fully intend it to be a first class citizen capable of doing full, complete, professional games.