I have read much of people saying that C++ is more powerful than Blueprints. But there’s just one thing that still makes me wonder. At what situations / circumstances that C++ is more preferable than Blueprints and vice versa ? Can anyone tell me what is it ?
I want to make game that almost open world, but the gameplay is simple. It’s like story mode but with some minigames. The only reason I want to use unreal is to take it’s capabilities making realistic graphics. I will appreciate any answers
We are very proud of how far Blueprints has come. C++ is capable of a little bit more as of this moment, but you can use a small amount of C++ to make a new blueprint node instead of writing the entire game in it.
Sometimes there is a little extra bloat in the code that you don’t see with Blueprint, but it’s negligible on anything that isn’t very high-end and in need of optimization. For your purposes, based on your description of the game, Blueprint will serve you well
Most people saying stuff like this are just parroting something they heard somebody else say. I wouldn’t put very much stock in it.
You’ll have little trouble at all making a viable game with 100% visual scripting. Simple or complicated is a subjective term - I think it may be safe to say you’ll need c++ for a multiplayer game but that’s as much as I’d feel safe to say with certainty.
If you are already a professional programmer, of course you’ll find some cases where the ergonomics of visual scripting isn’t as good as what you are used to.
But likewise, if you are used to visual scripting, plenty of cases where text code feels unwieldy and slow as well.
The way I do it is like this:
I use blueprints because its fast and easy. If I can measure some performance problem somewhere on the CPU, then I get some help to move code to c++. So far, I haven’t had to do that.
Some people have suggested that there is a “more correct” way I can do some things, but the proposed solutions are something that require an expert to work for a couple weeks. Whereas my working solution (made by a novice) took a few hours. So ya know, think strategically about time and don’t take people too seriously that think there is “correct” ways to make a game.
C++ is indeed more poweful but it is like sportscar - you dont need it to buy groceries.
But there are times when you definitely can use C++… cases that I can think of:-
When the game is getting slow and certain bp operations are slow (by profiling), then you may want to convert that portion only to C++.
There are UE functions that are not available in blueprint - I would estimate BP only covers about 90-95%…
When you want to integrate external libraries as many of them are written in C++/C.
A rule of thumb (which can be broken at times) is that when your blueprint function covers more than four screenfuls of nodes, you’ll probably want to port it to C++.
Another rule of thumb is that if it contains loops over arrays or sets of objects, that have to run every tick (or at least, very frequently,) then it’s likely a good idea to port it to C++.
There’s also the case of computationally intensive work – if you want to build a custom fluid dynamics simulator, or a new kind of audio synth plugin, or a new rigid body kind, then you’ll want to use C++, because the overhead of doing “heavy lifting” in Blueprint will quickly add up.
Finally, there are some subsystems that can’t be customized using only Blueprints. For example, parts of Chaos physics, and the fundaments of the Gameplay Ability System, need some C++ to get started.
To be fair, even when moving to C++, the typical workflow is something like this:
I have BP_MyThing that derives from, for example, the engine class AActor.
I create a new subclass of AActor in C++, call it something like AMyThing. This new subclass may not even do anything additional yet.
I re-parent BP_MyThing to use AMyThing as the parent.
I can no incrementally move pieces of BP_MyThing into AMyThing – although the first such increment will likely be moving most properties and event dispatchers into the C++ .h file, because the C++ code will want to read these.
You will probably never actually stop using BP_MyThing – even with a fully C++ class, the blueprint on top of it, will let you easily customize specific instances: Swapping out sound effects and meshes, adding flourishes like animation footstep particle systems, and changing things like strength or speed or hitpoints.
Even when using full C++ from the start, it’s a good idea to make a blueprint of that class that you can place, for this customization reason. In fact, you might even make multiple blueprints out of the same custom C++ class, for things like “fast vs slow enemy” or “solid versus hollow rock” or whatever. It really isn’t “either/or,” and it is possible to move between the systems somewhat incrementally.
If I’m doing something new in the project I’m working on, that isn’t highly dependent on an already existing native/blueprint structure, what i will generally do, if something is reasonably complex, is put it together in blueprint so i can get it to flow correctly, get the thing working, and then write it in native, and leave hooks in it for blueprint, so people don’t have to mess with the code to make changes quite so much in the future.
However, most of what i work with these days is already existing blueprint, which i’m not in a position to wholesale turn to native, especially when you’ve got a tree of blueprints that are linked together. So I do a fair amount of stuff just in blueprint too.
