I was just wondering ..the people who are using c++, are you doing everything in c++ or are you mixing it up whith blueprints. And how do you decide wich parts are in c++ and wich parts you keep in blueprint.
I do c++ base classes with BP Children.
I mostly only code the concrete things that wont change in c++ or things that need to be highly efficient and then let BP call them.
but structs/enums i do exclusively in c++ they’re easy to do for anyone and much better
1 Like
I do almost exclusively Blueprints. I just HATE compile times. (and compile issues)
The only exceptions I make are:
- Heavy math - it looks too complicated in BPs as soon as you get more than 10 operations;
- Collection handling - looping through and modifying arrays - it looks awful;
I usually make a BP function library that gradually transfer to a C++ function library and base empty (with no overrides) C++ classes to later use if needed. (rarely needed though)
This is the time to note that I work mostly on prototypes, RnD and personal projects so I’m yet to reach proper production phase in any Unreal Engine project.
I’m guessing I’ll need to transfer some stuff to C++ when optimizing but I wouldn’t do that before profiling extensively.
I would take @Auran131 advice for structs and enums and remember:
You can expose anything from C++ to BP but you can’t expose anything from BP back to C++ so act accordingly - base classes on C++ game-play on BP.
1 Like
Any successful C++ project is going to be a mix. You may be able to make a game 100% in blueprint without too many problems (depending on scope), but doing the same thing as pure C++ is just madness.
I agree with Auran’s suggestion for structs and enums being in C++ almost 100%. Migrating them can be a real pain. There are also some issues with making changes to blueprint structs that seem to cause blueprint issues not caused by similar changes to C++ structs.
UI’s a huge case where you do yourself a disservice trying to avoid blueprint, the Designer is too useful in setting those up. It’s not terrible to have a C++ class between UserWidget and your blueprint, but it’s not always needed and it’s easy to insert later.
Content hookups are another really important thing to setup through the creation of blueprints. Asset references should never be coming from code. Content or ini files. That way when files are deleted or moved, the Editor can help you keep your project in a working state by making sure the references continue to work (or warning you about ones it can’t do anything about like ini’s).
For building actual systems, it often depends on the who the user is or what sort of behavior I want. I will often do mission scripts in blueprint because I want the iteration wins of not shutting down the Editor. Or if the logic is unique to the gameplay I’ll do that in blueprint.
Something like: Systems in C++, Content in Blueprint.
The trick is recognizing which category what you’re building actually falls into.