C++ vs Blueprints UE4

by on

I've been working with C++ for a while now, and I like the conciseness of C++. However, Blueprints have a role in the game making process.

I'll start with some things about the Unreal Engine's C++ that I don't like.

 

The "Hot Reload" sometimes it works, and sometimes it does not, and it seems to be completely random. I know it is not.

However, I haven't been able to pin down exactly what triggers the "Hot Reload" not to work.

Sometimes "Hot Reload" doesn't work even if it appears successful aside from things not working as they should.

You could get compiled successfully and still have randomness, having to restart the editor.

When adding components to classes, sometimes the existing blueprints do not update, and you have to recreate them even if you delete intermediate files and binaries.

We have to delete intermediate files and binaries to fix issues.

 

I read a couple of blog posts by Allar recently, which had a few sentences that were very enlightening in it.

"If you don't like spaghetti, then stop making spaghetti" and "I heard C++ is faster than blueprints, use the profiler!".

Or something along those lines, it seems a lot of people are using blueprints, and so I figured I would give them a second chance. 

After all, it was my fault that they looked like spaghetti and I think I'm starting to like them.

 

You can iterate much faster, in C++ compiling, crashes and other randomness take valuable time.

You CAN make them readable as it turns out.

 

I've found that when I got craziness starting to creep up, it's time to make a function.

It's the same refactoring that we do in C++, and when you apply that same concept to blueprints, they become very readable.

I would still make base classes in C++ and convert the blueprints to C++ as soon as performance becomes an issue, and only if it becomes an issue.

 

With performance being a concern, you can always try the blueprint nativization.

 

Nativization can lead to some mysterious error messages under the following conditions:

  • If you decide to access the private variables of another class.
  • If you have a loop that it thinks will be infinite.

 

These only show up after packaging, something about a cycle error when launching the game.

So if you try to use it for your games, watch out for that.

You can manually exclude the culprit in the project settings or only include blueprints that need the performance boost that does not hit either of those conditions.

 

To conclude, iterate with Blueprints, profile, and then optimize with C++ if necessary is my view on the matter.

 


Comments 0
No comments have been left yet.