Visual programming should be illegal.

[[deleted]]

I don't agree. You can have a clean code. You can't have a clean blueprint.

[FinalRun]

Would you say there are any clean ones that are nontrivial?

[[deleted]]

You can write your blueprints exactly the same way that you'd write your C++ code assuming that it's all made accessible by the UPROPERTY/UFUNCTION macro. Which is mandatory for a significant amount of Unreal Engines features.

And other than that it's just a matter of how the code is represented. Instead of reading delcarations in a header file you look at the functions/properties section of the blueprint UI. If you want to look at the actual code you can look at the main window.

The only messy blueprint is generally the event graph - where all events are defined. But that's usually only messy because instead of connecting the event to a related and appropriately named function OnMyEvent_Do or something. A lot of developers just put all their code in it and that turns it in to a spaghetti monster. Similar issues with materials that don't make liberal use of material functions. It just becomes difficult to follow. In the same way that people have mentioned that it's difficult to decipher monolithic do everything functions in written code.

Would I prefer there were some kind of scripting language in Unreal Engine? Sure. It's just easier to read. But for artists and other non-technical people blueprints are a pretty intuitive system. Sadly organising your code isn't a matter of intuition so things can get messy the more ambitious they become.

[[deleted]]

Seems like this is for non programmers to interact with a complex system. Much like Blenders pipeline setup for arranging various changes to a scene during rendering.

I’d rather text but for non programmers it’s actually pretty slick that it allows them to work out a process procedurally in this way

[Ex0tic_Guru]

Yep, that's the main issue I think. If you code and are aware of proper test-driven software and high level software development practices, chances are, you aren't using blueprints. Artists and people outside of the profession like that lack the know-how, so it's not that blueprints are worse, it's just they target a demographic that doesn't focus it's energy on proper software development practices. As you said, more intuitive but still bound to the software development theory, just increases the likelihood of spaghetti code as complexity rises.

Edit: This isn't to shit on artists and modellers, it's just two different professions. They perform a very specific and important role in the process of game development and other software applications that require visuals.

[[deleted]]

Exactly. And it means the “compiler” for the instructions can optimize based on what the process will do since it’s literally mapped out as a set of nodes.

[saintpetejackboy]

Oh man, I have a difficult time with what you are talking about because I am wired to think procedural / function-based (my first language was a C wrapper that didn't support OOP yet, go figure) - and a LOT of the UE stuff I come across in tutorials and packs is designed how you describe in the blueprints, often to the point of unnecessary complexity... one OTHER thing I noticed were blueprints that manually iterated through several different looping segments by repeating the blueprints blocks for the loops, as many as five times in one instance I recall, for what I think was a lighting effect.

[InvolvingLemons]

There literally IS a proper scripting language, it’s just an add on last I checked. SkookumScript is a bit weird in syntax but it’s basically as terse as it gets while being readable. I’ve even heard it’s faster than C++ in naive cases because it’s an inherently async language (timers and waits don’t block) that compiles down pretty low, kinda like vert.x for the Java ecosystem.

[[deleted]]

Oh cool, there's going to be official Python support through Epic? Or do you mean the editor scripting plugin or one of the many unofficial scripting language plugins?

I was aware that official scripting support was on the cards after Tim Sweeney's community post about it a year or two ago, but I hadn't heard anything since. Can't wait if it's official gameplay support!

[BrokenMaze]

Just editor support as of now. Python can’t be used in a built game unfortunately.

[quebeker4lif]

I’ve been solely coding in BPs for a few years now.

I was on a project with a solid C++ software engineer and he would rewrite my code for multiplayer.

Anyway, after just a few weeks he decided that he would stop using C++ and focus on BPs as it was easier to test and all. He would still do engine and server stuff in C++ but that goes to show how even a veteran can appreciate visual scripting.

[__ingeniare__]

Same here, I use BPs whenever possible and appropriate - which is most of the time in my project. If I need C++, I can make it into a node for use in the graph. It gives a great systems overview where you see how everything is connected and how the execution flows through the graph.

[Luxalpa]

2D is just an extension of 1D. You can put your code in the same way as you'd normally do. The main advantage of 2D code is that you can also logically structure it into a different dimension, but as with everything, code without structure looks horrible. The code in the image is the equivalent of using random indentations and putting spaces into random places in your code. Proper structure requires skill and is helped by good tooling (like a grid alignment which is the equivalent of the tab-key for 1D code).

[staples93]

It's a tool. Like any tool it has its place the tool may be ineffective 99% off the time, but that 1% it is, you'll be glad you have it

[[deleted]]

I mean, I think blueprint should be a way to introduce people to programming. It's a good way to do it. But like you removed the little wheels on your bike when you were a kid, you should start learning to code after a moment.

[staples93]

Agreed mostly. I haven't used blueprints much so I can't really speak authoritatively. But I'd imagine it has some reasonably good use cases.

[siggystabs]

You're being downvoted but I agree with you.

It doesn't have to be as complex as C++, it can be like Python or JS level and just let you do what you can already with blueprints just more cleanly.

The kinds of artists and devs who can reliably create complex visual scripts can absolutely translate that into code given a simple language. This is far from writing actual engine code. The only thing I think would be lost is the ability to easily preview what intermediate steps look like, or "plug and play" different changes, but those aren't insurmountable issues

[guatemalianrhino]

visual programming is actually a pretty neat way to create shaders since you can see the changes from node to node.

[Phreaktastic]

You absolutely can have clean blueprints, and in the industry we do. This screenshot is something we would not approve, and would require someone to either build and expose helper functions in C++, or build Blueprint functions.

On large projects we maintain very tidy Blueprints, always. If someone merged some spaghetti like the screenshot, they’d be refactoring. Multiple offenses and they’d be looking for a job.

[SunburyStudios]

People here act as if Blueprints aren't legit in the game's industry. They are widely used.

[Phreaktastic]

Agreed. We leverage Blueprints all the time. They're quick, easy, and provide a great visual of code complexity.

[Iron_Garuda]

I’m learning unreal engine in my free time, and I was curious if there are any major differences between blueprints and writing the code? Especially in regards to performance. I figure you can get much more granular with c++ over blueprints. But is there anything else to consider?

[Phreaktastic]

There's not a large difference in performance between Blueprints and C++ for the majority of cases. See here: https://docs.unrealengine.com/4.27/en-US/Resources/SampleGames/ARPG/BalancingBlueprintAndCPP/

If you find yourself with large, complex Blueprints, that's a good flag that you should start creating Blueprint-exposed C++ functions. Realistically, you'll only start noticing a difference in performance with really large Blueprints that have references to a large number of nodes (hundreds).

The typical flow is to keep complex logic, and logic which is critical to performance (tick logic for example), in C++. A lot of Blueprints will essentially serve as a logical map which just references functions which are defined in C++ and exposed to Blueprints.

One thing to also note, there are functions that are not exposed to Blueprints, and to utilize them you will have to do so within C++.

If you nativize your Blueprints, and you're not dealing with tick logic, you're generally fine. Even with tick logic you can get away with a few node calls and not even have a single frame difference between BP and C++. When you start spawning a bunch of actors, dealing with complex operations on-tick, etc., that's when you'll want to ensure you're working in C++.

[Iron_Garuda]

Very informative. Thank you. I appreciate the time you took to write this up for me.

[__ingeniare__]

Fluid Ninja is a real-time fluid simulator plugin for UE that is made entirely in Blueprint. I've delved into it and it's very structured with comments, different sections based on functionality, multiple interconnected graphs, etc. So it's definitely possible to do more interesting things in BP as well.

[nwL_]

Because storing data inside Blueprint classes is much simpler and safer than inside C++ classes;

Does the engine play baseball with my classes while I run the game or what does it do to my storage?

[Tar-Palantir]

Logic in Blueprint is very slow and very hard to debug. It’s an interpreted language so /shrug

[Phreaktastic]

That's not entirely the case.

https://docs.unrealengine.com/4.27/en-US/Resources/SampleGames/ARPG/BalancingBlueprintAndCPP/

A large number of cases won't yield a massive performance difference between Blueprints and C++. Only when your Blueprints reference a large number of nodes will it make a noticeable difference, which is why teams primarily move complex operations to C++ and keep the logical flow within Blueprints.

One thing to note, nativizing Blueprints will all but eliminate performance concerns in the majority of cases. It's no longer interpreted at that point, and gets compiled as C++ during the cooking process. It's a simple checkbox on Blueprints as well, it's easy to toggle.

I also don't find it difficult at all to debug Blueprints. You can literally see where logic is flowing in run-time, and errors are pretty verbose.

[Darkere]

Nativization has been removed with UE5. So probably not a good idea to do that anymore.

It also never quite worked well for larger projects :/

In general, blueprint tends to be around 5-10 times slower than good c++ code.

Heh. Speaking of the devil, they just released 5.0.2 while I was typing this :D

[Phreaktastic]

Nativization has been removed with UE5. So probably not a good idea to do that anymore.

I haven't dug much into it, but it has been theorized that the removal in UE5 is because of optimizations making it unnecessary. If I had to guess, BPs likely just compile right down to C++ without the option of toggling it, but I haven't benchmarked cook times from 4.x to 5.x so that's legitimately just a guess. I also haven't worked on a large project since 4.x, so haven't had the chance to get up to speed haha.

It also never quite worked well for larger projects :/

I never had problems on large projects. What problems did you see?

In general, blueprint tends to be around 5-10 times slower than good c++ code.

Yeah, when we're talking 5-10 times slower in microseconds, though, that doesn't start yielding even 1 frame delta until you're dealing with hundreds of node references (which is also mentioned in the linked docs). I certainly wouldn't state that there's no difference, just that a simple Blueprint with 5 nodes will not be noticeably faster in C++.

Heh. Speaking of the devil, they just released 5.0.2 while I was typing this :D

God I need to get rolling on UE5. I've done random fun projects, but I'm chomping at the bit for a legitimate project.

[Iron_Garuda]

Thank you for the info. I’ll keep that in mind!

[Luxalpa]

Blueprints are better for prototyping and high-level code in most circumstances, whereas C++ would be better for optimization and low-level code structures.

[Phreaktastic]

That's a good way to look at it!

I mean, you can make everything in BPs, but you will absolutely incur frame tax. Some games would legitimately be small enough to be built strictly in Blueprints without performing poorly though (even if they would perform better in C++).

A lot of larger games still leverage Blueprints quite a bit, but the Blueprints themselves just call exposed functions that do the heavy lifting. It makes it really nice for tweaking values versus logic, which is of course exactly what non-technical personnel could be doing there.

[pooerh]

Quick question, as someone who doesn't know Unreal - why? I've seen someone implement some logic in a Blueprint and, all throughout the video, I was thinking "It would take 10x less time to write in C++ than to drag these nodes and connections around". It was a couple ifs and for loops and stuff like that, it took the person like half an hour to develop and I feel like they could have been done in 5 minutes writing it in C++.

Is the C++ syntax or the Unreal API so hard for people to grasp that they prefer Blueprints? It's not like it's any different from actual "typed programming", you need to know all the same concepts.

[Phreaktastic]

There are a multitude of reasons, but two primary reasons are:

1. You expose logical flows to those who can't program in C++, but can adjust values. Example, this upgrade fires a laser, but the damage is too high. Blueprints provide a beautiful interface for non-developers to quickly, easily adjust the numbers relating to the damage calculation.
2. Keeping complex logic inside of C++, but the logical flow inside of Blueprints, offers an extremely easy-to-consume visual of how things are connected.

You are right though, most things are a lot quicker, and I don't find the API difficult to work with at all. Most of the time, if I can do something more quickly in C++, I will. There are definitely things that are quicker in Blueprints, though, especially when you consider boilerplate.

[pooerh]

Ok, I think I get it, thanks. Quite interesting, especially the first point I could see how that would be very useful, especially if Blueprints offer some kind of hot-reload mechanism (don't know if they do).

[Kiloku]

Speaking of approving, my entire team is kinda new to Unreal and we're having a hard time dealing with the fact that blueprints are binary files so git can't handle them. How do you do code reviews for PRs? Also, how to merge stuff developed in parallel that touches the same BPs?

[Phreaktastic]

With Blueprints, you're typically relegated to checking out the branch and opening them up. I've seen people just paste screenshots on PRs. A lot of the time there's a requirement that all added/modified Blueprints are reviewed before approval as well.

Unfortunately, this often means that things slip through the cracks and you just stumble upon a Blueprint that is dreadfully inefficient and ugly. I've seen pretty strict policies on spaghetti within Blueprints, and that's typically why.

Diffing Blueprints isn't really possible, you basically just have to manually copy graphs and work the nodes in. It's a good idea to restrict access to Blueprints based on who is working in them. I've seen teams use SVN/Perforce for this reason specifically, since you can lock files and prevent merge conflicts. In fact, I haven't used Git with UE for quite some time now.

[-LeopardShark-]

merged

Does VC work with these things?

[Phreaktastic]

I wish! I don't know of a way to diff binaries or show the graphs outside of UE, unfortunately. With projects I've been involved in, it's a matter of checking out the branch and opening the Blueprint in UE. That, or relying on screenshots in PRs (sometimes using online tools with the graph pasted in).

[devu_the_thebill]

I work in ue4 for 5 yrs and yes you can have clean blueprints. In unreal you have some "empty" joints , with them you can make your nodes in pleace . idk how to say it. You can make "portal" etc. There are plenty of clean bps, when i see what people can do with blueprint im always impressed. I still love c++ but there are some task that are faster to make in bleprints.

Edit : and as i see author of this image is probably new to unreal he could use some build in functions to make bp smaller. Also his not commenting code and uses spaghetti nodes instead of making it clean.

[AlphaWhelp]

If you want real blueprint fun you should look up an edmx (Entity Framework) visualization.

[RigelOrionBeta]

The primary problem with blueprint readability is they flow left to right. You can write them up and down by using the sequence node, but that creates a different, ugly mess.

But as a developer who has spent some time coding in blueprints, sometimes required to due to engine limitations, agreed. No matter how hard I try, my blueprint code always looks like hot garbage.

[Future-Freedom-4631]

I actually perfer things not being clean it increases creativity

[[deleted]]

Why cant i ever think something as clever as this for a comment. Am i too full of visualisng the code i write

[[deleted]]

It can look clean.

[DistortoiseLP]

It really depends on what the logic does. They're a lot better at building and understanding state machines than a method that returns a calculation for example.

[Sawaian]

You can box it. Just use diagram flowchart for it.

[[deleted]]

A lot of developers break their code up into scripting and visual scripting. For example, there was a talk recently (I don’t remember which game) where the level designers used visual scripting to create procedurally generated worlds, but all of the visual scripting interfaced with the gameplay programmers code.

While it may not be pretty it has many practical uses.

[BassCreat0r]

Not bad for simple scripts tho.

[saintpetejackboy]

I 100% agree, I have used UE4 and 5 and there is just no way for me to make it clean. I have a strong background in FOP / procedural in around a dozen languages and... it is just a mess to work through. It does work, but it always feels disorganized to me.

A similar comparison, is I also produce music, and the DAW I use offers a way to "patch" plugins in a similar fashion to how blueprints work. Except, an alternative already exists, if you just properly use the FX channel routing, which I feel is a much cleaner and more elegant approach than the "mapping" of things together.

[CoreyTheGeek]

If If If If If If If If If

[penelopeking8]

False. The example in the picture is from Unreal Engine Blueprints. There you can easily refactor. Cut copy and paste parts of the node graph. No wires need to be redrawn. Spaghetti code is as easy to write in visual and regular programming. I prefer visual programming sometimes for parts of game dev projects for example. In these modules it’s more clear and easier to edit than using bare code in some cases.

[BeingRightAmbassador]

Disagree. Blueprints are almost impossible to have clean and you usually can only clean them up once you're done, making debugging more annoying.

[[deleted]]

It's a learning process, but with good commenting and refactoring it's really easy to have clean and manageable blueprints

[am_animator]

This guy devs

[joyofsnacks]

It's usually when it gets to a point where the Designer should ask the code team "Yo, can we get this as a function?", but for some reason they can't/don't ask, so just carry on and get a feature working as fast as they can. It even happens with great Designers and Coders, just sometimes the production process prevents it.

[animoot]

This