What to do in C++ and What in Blueprint?

Development Programming & Scripting Blueprint
, , , , , ,
1

Hello guys,
i currently focus myself on doing stuff in unreal with c++
for this i purchased UE4 c++ tutorials on Udemy
but what i see is that they still make use of blueprint, and when they use they say because it is easier to do it in blueprint.

What i wonder now is, in which scenario i should use c++ and and which scenario blueprint

I want to have full performance so i dont know can someone help me out,
does someone have a clear quideline when to use which.

2

If you want full performance, you would do everything 100% in C++. Blueprints are useful when dealing with things that are difficult to put into code, like linear algebra, calculus, Physics, Animations, ect. Assuming your C++ knowledge is strong and you know how to optimize your code, C++ will be faster in almost all cases. There are some situations where blueprints are not practical, like an inventory system or anything dealing with recursion.

3

I prefer to create custom classes with custom methods and call them using BPs.
It’s like creating bricks and building something using them.

4

i like this too , but i wondered what to script in blueprint and what in c++ and if i understand right i should do as much in c++ if possible everything

with script i mean something like : Fire,Jump,Sprint,Teleport etc. just game stuff xD

5

I prefer use BPs mostly. But it’s not always comfortable to create complicate methods using them.
Because nodes are getting large and you rather get confused with them. In this case I use C++ classes. Create custom methods (500+ rows) then inherit them by BPs and call their methods like nodes. It’s my faster to compile BPs than C++ classes. But C++ compiled code works faster.

I hope you find this information helpful.

6

This question has been asked multiple times.

The short answer is - It is totally up to you!

Making games is very hard and time consuming as it is. However I have some tips for you:

  1. Go whit whatever you (and your team)
    are most comfortable/fastest with;
  2. The editor works with blueprints. Whatever you do, if you want to design in the editor, you will have to make a derived blueprint class out of your C++ code. This begs the question “Is writing it in C++ would yield any benefit”.
  3. Don’t waste time in unnecessary optimizations. Most of the time it is not your blueprints that slow your game down but your approach; (e.g. checking the whole level instead of registering the thing you are looking for)
  4. Avoid putting large chunks of logic in Tick() and manage your Tick() intervals. You can make your game lighter if you check for surrounding objects every second instead of every frame for instance; (Speed x 30)
  5. Use as much as you can of the provided systems like characters, AI components, physics and networking. You can always go and modify only the pieces that you need later in development;
  6. Blueprints are great way for checking your logic. If they look “like spaghetti” there is probably a problem within your design. (the same goes for ugly C++ code however very few people can actually recognize it)
  7. Blueprints are great for keeping the programmer in check. If you can’t use a particular approach in blueprints, you are probably not supposed to do it this way. Think of a different way for solving your problem;
  8. NEVER, EVER circumvent the engine garbage collector and memory management!

I hope these are useful.

Happy coding :slight_smile:

7

I disagree on 7, there many things you can’t do in blueprints due to limitations of it’s system, limitations of reflection system, not whole API stack avable to it (not because it’s not ready, but it’s simply not exposed), doesn ot support all the features of C++ and as well as security concern of running perticilar code on blueprint virtual machine. If something does not work in blueprint that means you need to look in to C++ solution.

8

I thought that many might disagree on a few of these tips but this is, in the end, my personal opinion.

I am sure all of these have exceptions and I’m sure I have missed something important. I would just suggest that you should have a strong enough reason for your approach and good enough understanding of what the implications of your design might be.

About point 7:

I still strongly stand by my suggestion that you must at least first TRY to change your approach. Problems, in my humble experience, have multiple solutions and usually at least one can be done in blueprint :wink:

You will not believe how many projects end up with memory leaks, critical bugs and delays because someone did not see the obvious solution and “hacked” his way through the engine.

I would go so far as intentionally avoid writing C++ code until I have a working prototype and then try to identify the parts of the game where I want C++. With experience you can start making those decisions on the spot but I still do prototypes in BP only.

As for security - You can have fully exposed client and still maintain reasonable level of security on your server with or without VM. It again boils down to designing your systems.