Download

Examples of when to use Blueprints vs C++

Community General Discussion
#1

Hi, I’ve read that for the base gameplay C++ should be used and then Blueprints to extend the gameplay. Can you mention some practical examples on when C++ should be used and when Blueprints? I don’t really know what can be understood like the base or the extension.

Thanks

#2

I’d recommend checking out one of the beginner UE4 C++ series out there to really get your hands on this and understand it better but I’ll give you a brief example.

In C++ you would edit your ACharacter and add a cool dodge ability for the character. Then in BP you create an instance of your ACharacter class and set it’s values. For example, if you want to tweak the “dodge speed” variable you can play with it in the BP (much faster than changing the C++ value and recompiling). BP’s are also good for adding references. For example, if you want to add a skeletal mesh to your character so they actually look like something you would do that in BP. This way you don’t need to hardcode asset locations in C++. You could change the name of the mesh or move what folder it’s in and the reference won’t break.

Other than all this BP is good for some light scripting in certain scenarios like for GUI and animation. I’d generally stay away from thinking you can build the bulk of your game in BP. Do most of the logic in C++ and use BP to tweak variables and references and such as I described.

#3

so basically it’s doing almost everything in C++ and then setting some parameters with BP?

#4

It’s really a matter of preference. C++ is faster, and it’s also easier to merge in changes. Blueprints is easier to work with in many ways though. I’ve been using C++ for 25 years but the convenience of blueprints finds me writing a lot of code in blueprints these days.

I tend to do like TacoShank noted, build a core in C++ as you can easily access those variables or components from blueprints, but the same does not work in reverse. I then use blueprints for most of the basic logic, and C++ for the more intense operations. It is also possible though to create a game entirely in blueprints though.

#5

To quote the amazing Allar

https://youtube.com/watch?v=flEtQBPtBTc

#6

How much BP vs C++ is used in your project is really subjective. It depends on one’s mastery with C++ (Unreal C++ really). The guidelines such as base class in C++ remains as general guideline, but the more important thing is to start get your hands dirty now with Blueprint first, and over the time you will slowly know how much C++ is needed.

#7

Here’s a simple effect practical example:

#8

That’s how I do it (with some BP scripting where it makes sense) but I also come from a pretty strong programming background. As J.C. Smith, Luos, and Syed pointed out it really does come down to personally preference in the end, at least at the solo hobbyist/indie level. I certainly spent my time learning UE4 with BP only but shifted to C++ over time. For me non-trivial code is much easier to write and read in a text format.

There are some major advantages to text:

  • For example, you can comment and un-comment a piece of code very quickly. The equivalent in BP sees you detaching nodes but often times you can’t have multiple of certain node types. So then you need to delete parts to get your BP to compile and there’s no quick visual separation like in text. It quickly becomes a mess if you are trying to test two different algorithms and you forget to reattach your code the right way or add back in what you needed to take out to get it to compile.
  • Then there’s the fact that if you want your BP to look nice and not be literal spaghetti code you need to put a significant amount of time into moving things around visually and rerouting connections. I often felt like I spent too large of a percentage of my time changing the aesthetic of my BP instead of actually getting work done. Then when you need to add something to your nicely formatted code you worked on cleaning up for a couple minutes you will need to add some large chunk to the middle of it and do all that work over again. It gets old fast. With text Visual Studio automatically formats your C++ to look nice. With text you hit enter and start typing a new line to add a large check of code to the middle. You spend your time solving the problem. Sometimes I have lost my train of though and forgot how I was going to solve a problem because cleaning up BP takes so much fiddling.
  • Obviously version control (which everyone should use) is made a lot easier with C++. Because BP’s are treated as binary files if you ever have multiple people coding on your project you will be limited to one person “checking out” and working on a BP at a time. This is a major problem for collaboration. Text-based languages are a god-send here.
  • Although UE4 is open-source, let’s be honest, most are not going to spend the time to understand how BP is compiled. I’ve had several times where my BP decides to break for no particular reason. I’ve had to do weird things like rename BP variables to get them to work again. When my C++ doesn’t work it’s because it’s my fault not because of bugs in the language.
  • Your text-based code won’t randomly change on you, where as BP’s will decide to break links and do other things without telling you. This is fairly frustrating when it happens.
  • You can copy and paste C++ easily from and to the internet. If you look around you’ll see people posting screenshots to share their BP. They vary in resolution and readability. This to me is a major downside. Of course there are a couple resources to copy paste BP to the web but they don’t seem to be used often.
  • Maybe this is a personal issue but my pointer finger gets murdered from clicking so much when I work exclusively in BP for too long. With text all or most of my fingers are engaged so there is less strain on just one of them.
  • You can open Visual Studio without opening the UE4 editor. This is useful because if you crash your game and the editor crashes when you reopen it you can debug the problem. With pure BP your only real option (if you don’t know C++) is reverting to an old version with version control and possibly losing work.
  • If you are familiar with other text-based programming languages they will help you understand C++ and vice versa. BP is actually quite a different programming experience from traditional languages. I do enjoy it, but transferring logic from BP to text-based languages can be really tough. It’s hard to explain exactly why unless you have a lot of experience working in BP. If you try both BP and another language like C# or C++ out you will see what I mean. You simply think differently in a visual programming language.
  • There are also the famed performance benefits to C++, but really you can nativize BP now so this is mostly a moot point for all but the most computationally expensive code. This is the argument for C++ I find the least compelling.
  • Edit: How could I forget? With BP you need to zoom in and out of your code to be able to read it. The zoom level you need to be at to comfortably read BP’s is high enough that it’s hard to fit much logic on screen. This leads to a lot of panning back and forth to understand what the code is doing. With C++ I can usually fit the entirety of the chunk of code I’m working with (e.g. a function) on screen and read it easily.

For me performance is absolutely not the reason why I prefer to work in C++. You really shouldn’t be worried about performance as a one man hobbyist/indie anyway. I would not use that as the reason why you chose BP over C++. I choose C++ because for me it’s a lot easier to work with and text-based programming works better with my brain. Try out both and see what works better for your brain. However, I do think there are objectively some major advantages for text-based programming as I mentioned above.

#9

[quote=“TacoShank, post:7, topic:106719”]

[li]For example, you can comment and un-comment a piece of code very quickly. The equivalent in BP sees you detaching nodes but often times you can’t have multiple of certain node types. So then you need to delete parts to get your BP to compile and there’s no quick visual separation like in text. It quickly becomes a mess if you are trying to test two different algorithms and you forget to reattach your code the right way or add back in what you needed to take out to get it to compile.[/li][/QUOTE]

BP has a Node disabling option. Its still experimental (Right-Click disable Node from Compile). It works better in Kismet (UDK) tbh. But its also easy to make up for any limitations by just adding a dedicated Bool and leveraging color-coding for branch / sections that are optional / duplicate. A kind of Blueprints #IfDef etc… Taking advantage of color-coding is one of BP’s biggest strengths in visual programming, because you can use different colors for sections with duplicate paths / minor differences. Then the human eye can quickly differentiate and skip over those sections…

Overall, the ability to use color customization in Comments + Nodes + Wires is huge… But not all devs make full use of it. The brain works better with visual stimuli. So for example you can plan-out a color-coded strategy for all your calc / logging / debugging code that’s different from UI / Menus which in turn is different from the more active nodes that push the gameplay forward etc. There’s no way to do that in text based languages to my knowledge. There’s no real way to ‘promote’ text code that’s more critical or important etc short of using a lot of // or /…/ etc. In addition you get to play around with shape and shaping code sections. which is also positive for the way the brain naturally responds. Personally I find I remember what BP code does faster than working with the equivalent in text, when both haven’t been looked at in a while.

[quote=“TacoShank, post:7, topic:106719”]

[li]Then there’s the fact that if you want your BP to look nice and not be literal spaghetti code you need to put a significant amount of time into moving things around visually and rerouting connections. I often felt like I spent too large of a percentage of my time changing the aesthetic of my BP instead of actually getting work done. Then when you need to add something to your nicely formatted code you worked on cleaning up for a couple minutes you will need to add some large chunk to the middle of it and do all that work over again. It gets old fast. With text Visual Studio automatically formats your C++ to look nice. With text you hit enter and start typing a new line to add a large check of code to the middle. You spend your time solving the problem. Sometimes I have lost my train of though and forgot how I was going to solve a problem because cleaning up BP takes so much fiddling.[/li][/QUOTE]

Lowering ‘wire’ spline curve settings or even using straight lines instead of the default settings, means you don’t have to keep moving as much BP code around. But there’s a few points to consider. If you rely on ForLoops with 5-10 lines stretching out from the index, or Array-Get with 5-10 lines carrying the same actor, that can be pretty hard to follow and force lots of rearranging and unnecessary Reroute nodes as well. Personally I favor using temporary Array-Actor variables and ForLoop-Index variables to cut down on a lot of re-org. Duplicating variables too is better than dragging multiple wires off them, as it helps clarify things. I trust Nativization to compile out all this extra node-bloat…

[quote=“TacoShank, post:7, topic:106719”]

[li]Obviously version control (which everyone should use) is made a lot easier with C++. Because BP’s are treated as binary files if you ever have multiple people coding on your project you will be limited to one person “checking out” and working on a BP at a time. This is a major problem for collaboration. Text-based languages are a god-send here.[/li][/QUOTE]

Agree. The BP diff tool is more a gimmick than an everyday gem too… Devs like TheJamsh have suggested offering a BP text input tool. Epic seemed to like the idea too, but that was a while ago. But it would allow devs to use text to input BP sequences. That would obviously help with diffing and presumably cut-out BP corruption permanently. Presumably it would also help with Collaboration, as it could allow merging of changes into the same binary BP…

[quote=“TacoShank, post:7, topic:106719”]

[li]If you are familiar with other text-based programming languages they will help you understand C++ and vice versa. BP is actually quite a different programming experience from traditional languages. I do enjoy it, but transferring logic from BP to text-based languages can be really tough. It’s hard to explain exactly why unless you have a lot of experience working in BP. If you try both BP and another language like C# or C++ out you will see what I mean. You simply think differently in a visual programming language.[/li][/QUOTE]

You do encounter some peculiar / surprising ‘oh, that’s how it must be done moments’ in BP. Flow control in BP feels odd.
Your instincts might be to add an inline delay to a For-Loop. But the loop will be already finished before the delay kicks in.
Whereas if you use a Multigate node, with a delay off each branch etc, that works to delay ForLoops as you would expect.

#10

As the others have hinted, use whatever you’re strongest at… But best to get used to using C++ and BP together. Chances of completing a full game using only BP are limited. So you’ll probably need plugins. While that’s someone else’s problem, if the developer disappears, it’ll quickly become yours! Personally I wish BP was further along, as it still feels very young, as its missing some relatively simple functionality like split-screen helper funcs + Datatable saves to CSV etc. But hopefully Epic will get there or shelve Fortnite like they did Paragon, and free-up more time for the engine… :stuck_out_tongue:

What I loath the most is the reliance on Visual Studio / VAX. There’s always some extra prerequisites / dependencies that MS forces onto your dev rigs. The build system also has MS dependencies that Epic promised to bin, but that didn’t happen. Overall, I miss the integrated environments of UDK / Unity. I also miss the ability Kismet had to Mod the underlying engine. For example re-enabling Bloom for split-screen should be a simple INI tweak, not a whole build from source. Anyway extending the engine is obviously C++ territory, so check out some of the older threads to see where you might run into issues sooner than later… 1 2 3 4

#11

As the others have hinted, use whatever you’re strongest at… But best to get used to using C++ and BP together. Chances of completing a full game using only BP are limited anyway, so you’ll probably need plugins. While that might seem like someone else’s problem, if the plugin-dev disappears, it’ll quickly become yours! Personally I wish BP was further along, as it still feels very young, and its missing some relatively simple functionality like split-screen helper funcs + Datatable saves to CSV etc. But hopefully Epic will get there or shelve Fortnite like they did Paragon, and free-up more time for things like this… :stuck_out_tongue:

What I loath the most is the reliance on Visual Studio / VAX. There’s always some extra prerequisites / dependencies that get forced onto your rig threatening stability. The build system also has MS dependencies that Epic promised to bin, but that didn’t happen. Overall, I miss the integrated environments of UDK / Unity. I also miss the ability Kismet had to Mod the underlying engine. For example re-enabling Bloom for split-screen should be a simple INI tweak, not a whole build from source. Anyway extending the engine is obviously C++ territory, so check out some of these older threads to see where you might run into issues sooner than later… 1 2 3 4

#12

Fortnite is making a fortune selling skins and battle passes… I wouldn’t hold my breath waiting for them to shelve it like they did to Paragon lol
Fortnite has potential of generating over a $billion in revenue. Tencent and Disney must be proud.

#13

Thank you for all the awesome answers guys, now I got it a bit clearer ^^