When people ask what’s the best way of programming in UE4, what people often say is to mix the two. So can anyone explain to me what is c++ best for and what are blueprints best for? Like, when should you use blueprints, and when should you use c++? What do AAA teams usually do?
Thanks.
Blueprints are used as an end point by designers and level designers to stitch together the many systems developed by C++ programmers…
Blueprints are to invoke AI custom code within a behavior tree, to setup animation rules, to control generic triggers, to direct real-time cinematics, to script world events, to put together complex character locomotion systems that are built on split C++ functions, etc.
Anything performance critical must be developed on C++ if your game is considerably complex;
However most indie titles are small projects they won’t need the optimizations C++ achieve and can be developed 100% blueprints just fine.
Going full blueprint the project is developed much faster; going mixed the project can be optimized to specific platforms… Going full C++ it’s still same runtime performance of a mixed project so isn’t really worth it because development will take much longer time to complete on a project without BP scripts.
If you reach a point anything other than graphics is affecting framerate than that’s when you need C++, most indie projects never go that far tho.
I think of it like legos. C++ creates the lego piece, blueprints decide where the lego pieces are placed and used. I create 80% of my functionality in C++ and use blueprints sparingly, mostly to stitch together the C++ functionality. After using both blueprints and C++ extensively, I much prefer C++ because it’s easier and faster to use. The visual studio debugger is far better than anything UE4 has to offer. I can easily copy/move functions from classes. Code is much more compact. I don’t have to manage wire connections. Comments are far easier to edit in C++. If you know C++, I encourage using it over blueprints, whenever possible.
I do most of my base classes in C++ and scripting type stuff, including visuals in BP. So my character with all functionality and movement will be in C++, but I subclass that in BP to assign the character mesh, etc.
As Duke mentioned, creating the full class setups in C++ is usually our approach to, as you can even create the components in the constructors:
USceneComponent* SomeComp = CreateDefaultSubobject<USceneComponent>(TEXT("Some Comp"));
You can do this with things like static meshes, and also set thier properties in the constructor too, which then show in the blueprint editors as the default values. We tend to do this and then allow designers to fill in the meshes with those created and do any positioning and things in the Blueprint viewports.
There are many ways to go and different teams use different approaches. As a rule of thumb, C++ is for programmers so use it to implement everything your programmers should be responsible for. And blueprints are for designers so use them for everything your designers should take control of. If you are a single developer or you are prototyping then use whatever you prefer more.
tl;dr: BP and C++ are not specifically designed for different tasks they are designed for people with different skills and/or roles
If you are making any sort of game you plan to release into the world than C++ is for your CORE game play systems and Blueprint is for Designers to build out your worlds. You build an Inventory system in C++, but each item is created and defined in Blueprint. You can even do some basic enhancements or elaborations to systems such as altering your inventory system to also be an Equipment system in Blueprint, they share similar functionality and code but still quite different. User Widgets I like to implement functionality in C++ and then re parent the Blueprint Widget to it so my functionality remains the same but I can have several different appearances to the same object the widget represents. So you could have one Inventory Widget that is a list, while another can utilize the exact same C++ functionality but appear as a grid.
If you are building out a portfolio of games to show to prospective employers, than building out game play in Blueprints is fine. But there are a slue of issues in trying to use pure blueprints to build out a game you are trying to sell or distribute. Overtime your Primary Blueprint classes WILL become bloated and take longer and longer to compile, transferring them to C++ will drastically improve that compile time. Blueprints will also LOAD EVERYTHING you have associated with them unless you are VERY careful to use Soft Object References and Interfaces wisely other wise it is very easy to accidentally load every asset of your game into memory on start up simply because you have a property reference to another class that references some assets and that class then references some other class that has some other assets etc etc. Finally C++ is so much easier to debug so long as you are running in “DebugGame Editor” Mode which is unoptimized and allows you to step through nearly every function and view most properties; While blueprint can do some debugging it is no where near as powerful as good old fashioned code debugging, and you will become very frustrated at the phrase “variable out of scope” when you try to break on a blueprint node to inspect the value coming out of it.
We do military simulation stuff and its all C++ with nothing in blueprints if it doesn’t have to be. We even try to minimize setting stuff up in maps.
There’s no good way to diff maps or blueprints is the main reason. Also we have plenty of coders.