I’m not a great programmer by any means, I’m a game designer, some 3d art, and writer if anything when it comes to game development.
I can do C++ pretty well and have successfully made my own small horror game with just C++ but everytime I try blueprints which is suppose to be easier for artist or non-programmers, I can’t do it. It’s so messy and too clunky imo. I get overwhelmed by the amount of nodes. Am I the only one like this?
no.
i’ve been using ue for several years and i find blueprints are much slower and annoying to work with. and i know a few devs that have said the same.
i also find them very very clunky.
i had to buy a trackball due to the sheer pain it was causing on my wrist due to all that pointing and dragging. (though tbh i love my trackball and not going back).
the time and physical pain spent in aiming a friking node, and ue fails to connect… is really bad. considering i can type way faster.
they also allow you to shoot your foot very easily with concepts that are either advanced or not recommended. which imnsho it goes against the same concept of “bps are easier”.
(with things like events, macros, asynch-able code, etc, which are totally unnecessary (i’ve been working without them for quite some time)). specially when defaulting to events instead of functions when creating definitions.
the ability to position them individually (as opposed to, let say, scratch) makes it much more harder to read at a glance, and the usage of space is pretty bad. you spend 50% of the time just jiggling the nodes (and yes i have a lot of hotkeys to align them but still). and then it becomes a contentious argument with teammates that have nothing better to do than arguing about how you align your nodes.
i also prefer scratch in the sense that nodes are top to bottom, which is much more natural and space efficient and easy to manipulate. nodes themselves are quite wide, and more if you add variables. and having them going horizontally is pretty bad for me. is a constant zooming and panning and you’re never able to have the code at a glance.
e.g. the spagettification is usually because blueprints allows you to connect the execution pin from multiple places to the same node, this is effectively a goto. and breaks encapsulation of functions.
the other problem is that variables are not really a 1st class citizen, and can again be connected randomly to multiple places and across multiples boundaries (events), even across multiple “goto” execution points. makes them untrackable, hard to read and unintuitive. and super hard to maintain.
again, sounds silly, but i think scratch is much better at this, where variables are embedded in the sentence.
i actually believe that bps are much more harmful than helpful. since people who aren’t coders will just throw stuff and see what sticks. i’ve read too many questions here in the forum of people who do not know how a for loop or a variable works. No shame in not knowing, but the system creates poor habits, since is used by people who doesn’t know the basics, and allows them to do dangerous things (like connecting stuff from two different if branches or events).
and it makes it harder to learn the fundamentals. when you have a proper function, you quickly learn about encapsulation and local variables. and this is just an example it happens with all other things.
non-jokingly, i think that scratch, as a design, is far far superior to ue’s blueprints.
and then there’s the issue of them being binaries. which makes them impossible to diff without ue, which is really time consuming and if the build is broken, good luck.
can get corrupted.
are really hard to version.
really hard to merge.
can’t work on git branches.
refactoring… there’s just no comparison. it’s really bad on bps. changed the name of a parameter in a function and BOOM your bp doesn’t compile anymore.
etc.
locking bps on git is soooo slow. and working with bps you kinda need to.
this is a known AND open issue File locks are extremely slow and basically unusable · Issue #2978 · git-lfs/git-lfs · GitHub
also hotreload/livecoding could corrupt your bps Hot reload on native actor component can lead to Blueprint corruption and data loss | Knowledge base
edit: point from jansenSensei about versions.
bps are tied to an engine version. you can’t go back a version.
let’s say a new engine version comes out, you rush and upgrade (typical) then you find a functionality breaks (typical) now you can’t roll back without loosing a week, month, or maybe more of work.
i’ve seen this happen in projects before and it’s a risk some people don’t plan for.
unfortunately epic breaking functionality on new releases is far too common. https://forums.unrealengine.com/t/request-for-lts-versions-of-ue-and-marketplace-assets
also if you were to, let’s say, want to move from the vanilla branch to the oculus branch, and it turns out it’s a version behind, you’re in trouble.
another problem is that it’s really hard to make libraries, functions, etc.; that you can share with other projects, by using bps. the version is one problem, but also copying bps from one project to another is a pain. you can use plugins but still the issue with versioning remains.
i have several other complaints about them. but they do have their place. there are certain things that are easier with them. but coding per se, it’s always faster to be done in text with a good ide.
i have been working on my own game for a few years, and i’ve made it a point to work with cpp as much as possible and i think it was very wise.
there are cases where i do use bps, usually to set default values (eg data assets, data tables, instances, and such). or when i need some visual adjustment very quickly (a material, transform, etc).
in the end, is up to you. programming is a much much more personal thing than some people like to claim.
if you find it more suitable for you to use code, just go ahead with that.
pd: i don’t think that gotos are inherently bad. but i don’t think the language should allow for it indiscriminately since it’s targeted for non-devs and meant to be easier.
It’s visual vs practical.
That’s all there is to it.
But also consider that c++ is native and runs faster, while BP gets converted to cpp by asinine functions written by edjits that do all sorts of mental gymnastics. This means that anything in BP will take double the time to run if not worse.
Where BP can shine is visual logic debugging: Simply because you can pause the editor and see the flow of things to determine where you shot your foot. This is much faster than debugging code, where you have to actually know what you are doing and keep a good head on your shoulders all the way through.
Realistically, if you are good a logic BP or C++ both achieve the same goal. One visually in a spaghetti mess, one by writing code.
That said, It’s a lot easier to pull up a BP and prototype than it is to get .net to open up and pull the correct file you want to prototype on, so many people attempt small things in BP and convert them later (or never in many cases, because look at the s*it people release!)…
If I am crafting the blueprint, I am generally super clean, organised and tidy with them. I am comfortable with reading Nodes or C++.
On the other hand, I regularly struggle with reading other dev’s bp’s more than reading another code block in some language.
I also noticed that when those bp systems go bigger, it’s also getting harder for me to understand what is going on to where. I also find it BP’s open room for bugs more than tradional code, but this is what I personally felt about it. I use hybrid generally. Prototype, refactor to C, expose in BP minimal functions and so on. Even just refactoring, migrating same code block from BP to C is generally huge game feeling changer, interms of consistency, flexibility, debugability. I also respect BP and how fast to do things with it. So I try to mix both worlds with correct amount imo.
So I don’t think you are alone. They are clunky, harder to debug, get messy in no time, slow, opens more room for error than normal for some devs.
I also use ElectricNodes plugin and I cannot work anymore without that since my OCD get triggered most of the time 
If you know CPP it will probably be much easier to read and maintain than BPs.
Right, and also, if you don’t understand the code. You can easily look it up to summarize or explain the code where with blueprints it’s a bit harder. Another issue is that most unreal tutorials uses blueprints which doesn’t help me when I want to do it in C++ but I guess I can always try to convert the logic but it’s a time waster in between.
Just a note. Most professional editors allows for step by step debugging with variable inspection.
even conditional breakpoints, and expression evaluation, something that bps doesn’t have (afaik).
i use rider and the debugger there works fine. Step through code | JetBrains Rider Documentation
also by the visual stuff. maybe i’ve been coding for a while, but i can see the shape of the code and recognize it visually too. after all text is visual too.
i can easily see the flow of the text at a glance (ifs, fors, etc) whereas with bps even if visual, i personally struggle to get the idea at a glance and have to follow the nodes. specially when placed kinda randomly.
there’s this thing people talk about that we don’t read text letter by letter but by shape (e.g. that trick where the text only keeps the first and last letter then reorder the rest).
so i can quickly see a full header, variables, names, public/protected, and uproperties tags just at a glance without actually having to actually read it.
whereas in bp, if i want to know if a variable is transient, i have to click on it, expand the panel (because it uses too much space) scroll, find the transient checkbox and see it.
i think the only advantage is that ue’s hotreload/livecoding is not good enough. which is an utter shame in 2026. you can’t really trust it (warning it can corrupt your bps), so you have to reload the entire editor for every meager change. so i think bps help to tweak values fast.
what i usually do, is to have all the code and logic in cpp, then expose variables or config to bps, and tweak the values there if need to.
but again this is a problem from epic, hotreload/livecoding should work reliably now. i would exchange nanite and lumen for proper hotreload without a doubt.
i agree with grimnir, i tend to do the same. if i have to prototype something quickly and if i’m not sure of the systems and return values, i use bps. and then port the bp code to cpp when it gets messy.
but then again, is double the work. most companies don’t do it ever.
so nowadays i can prototype much faster on cpp, given i type much faster than drag (plus all the hotkeys for multiline editing).
so i just do it in cpp knowing that i’m just avoiding creating tech debt that i will have to pay for in the future. only exception would be things that require many iterations. but again, that usually boils down to parameters (variables).
btw for people considering trying cpp, i have some ideas:
whether you choose bp or cpp it’s fine. but it’s cool to be skilled enough to use any of the tools.
chances are your usage will greatly vary depending on which company and project you work on.
That’s because you don’t actually work in consulting. IF you did, you’d be reading other people’s code and code style which isn’t going to match what you are used to.
Additionally, I never had a BP corrupted or not work after creating things in C++ properly. This plus the other message about git, really makes me think you may be neglecting your work machine. Try a defrag. check your SMART. make sure your storage is in order…
I’ve been coding for decades now so I know my way around code. I’m completely new to unreal and think blueprint will help me convert to it and start using the engine. I am wrong. I struggle a lot. A lot!
I do a course on cpp for unreal and learn that blueprints are essential for dynamically setting values like walk speed or fire rates etc and for some UMG work and basically nothing else. Cpp all the way for everything else. I am happy now. Work moves along at a steady pace and I can honestly say I enjoy the engine now.
or to tell that story in a shorter way: I almost gave up on learning ue due to blueprints but then cpp showed me the way. Thank goodness.
My workflow now consists out of thinking “I need this” followed by creating a cpp class then a bp of my base class. I do all my work in cpp but expose everything to bp and set all my vars in the bps I created. There you go. Everything in its place and all is well with the world. Even UMG, I use meta=bindwidget to auto link my widgets to vars in my code so I can visually set my widget appearance but I can keep my UMG widgets clear of any nodes, everything is auto linked to my code back end so no need for messing around with coding in two systems in two places…
TLDR: blueprints almost made me give up on learning unreal but cpp made me stay… even though I had never touched cpp for a day in my life before unreal. Cpp all the way. Nuff said
not really. i work for many different companies. some of those companies work for other companies. i’m constantly working with other people’s code and codestyles. and have to learn them fast.
i once worked on a 15 yo project with 5 to 6 different coding styles. my teammates were complaining about that all the time.
some projects i have to work are all in bps zero cpp. some are the opposite.
the bp corruption happens on hotreload/livecoding.
try modifying the structure of the base class then do hotreload. i can’t remember precisely, also it doesn’t happen every single time.
maybe it was adding properties, or changing their type, or changing a function definition. can’t remember. just google for hotreload bp curruption online and you’ll see it. any person with experience on it recommends not to use it. this is not a “me” problem, is fairly well known. it has an article even Hot reload on native actor component can lead to Blueprint corruption and data loss | Knowledge base
try renaming a component, that surely brings issues.
thanks for the suggestion. i do try to keep my machine well cared for. i have a smart notification program and i work on multiple operative systems (on different disks and different filesystems) and they all suffer from bps corruption on hotreload.
that reminds me, locking bps on git is soooo slow. and working with bps you kinda need to.
this is a known AND open issue File locks are extremely slow and basically unusable · Issue #2978 · git-lfs/git-lfs · GitHub
forgot that. umg are usually easier done in bps. i tend to do umg mostly in bp. though nowadays i do the logic code in cpp, and bind the widgets with meta=(BindWidget) and works well.
I think this could be a setup issue. Normally, for the past year and a half anyway the unreal s*it I’m forced to touch has been on a custom engine build that is literally just running the engine off the compiler before you run the project off another compiler etc.
But at the same time I can’t go changing component names on the teams, so what the hell do I know 
I can say this though - before corrupting anything the debugger on the the engine should fire up and stop the process for my specific setups… It should mean it prevents actual file writing and therefore corruption. Not really willing to test it out.
Either way, this is where GIT is useful. you just restore the file and you are Ok…
unfortunately is not.
renaming things is a basic thing. i’m sad you’re not allowed to.
feel free to use livecoding all you want. i’m not gonna stop you.
it’s ok if you take responsibility of the risks, and know exactly how to avoid them.
but in general i don’t recommend it to other people. it’s unreliable, regardless of our opinion.
Exactly. I used to use bp for my umg work but now I moved over to cpp and do all my visual design in umg and that’s that.
Just to contradict myself for a second, I tried to create my first ever blueprint only project last month. I did it in the source version so I was effectively using 5.8 and each time I hit play in Rider it launched 5.8 and all was well with the world. Whenever I started my project by double clicking the project, though, it would for some reason load in 5.7.2 which was installed afterwards via the launcher. Whenever I opened the project and didn’t realize the change in editor versions I was shocked out of my mind to discover all my blueprint work was simply gone. Gone!
Luckily, going back to 5.8 fixed the issue and restored everything but it highlighted something for me: in blueprints it is possible for all your work to simply be deleted. In cpp you won’t find ue simply deleting your source. Just another win for me. So I deleted the entire project and started again in cpp and noticed I redid the project in record time in cpp
nah, blueprints and I are not friends 
I mean, the whole engine is highly unreliable… regardless of our usage of it and opinions… Doesn’t mean the people asking aren’t going to be interested in our opinions on these technical bs (or they wouldn’t have asked)
As you probably know, I don’t recommend using the engine at all - and i generally say that if you really “MUST” you should build an Nvidia branch from source…
yeah i agree, opinions are fine. i was just stating a fact and wanted to say it as such.
it depends how much one tolerates a system’s fault, i guess.
ahh good note. i forgot about this.
with bps you can’t go back a version.
let’s say a new engine version comes out, you rush and upgrade (typical) then you find a functionality breaks (typical) now you can’t roll back without loosing a week, month, or maybe more of work.
i’ve seen this happen in projects before and it’s a risk some people don’t plan for.
unfortunately epic breaking functionality on new releases is far too common. https://forums.unrealengine.com/t/request-for-lts-versions-of-ue-and-marketplace-assets
also if you were to, let’s say, want to move from the vanilla branch to the oculus branch, and it turns out it’s a version behind, you’re in trouble.
another problem is that it’s really hard to make libraries and functions that you can share with other projects with bps. the version is one problem, but also copying bps from one project to another is a pain. you can use plugins but still the issue with versioning remains.
btw, just an opinion, running the main branch (5.8) sounds risky, it’s meant to be unstable.
Agreed. Main is meant to be risky, its for devs who accept the nature of development and contribute or atleast interested in what is going on. It’s not a stable branch to make continuous development of a project.
Maybe you can get a version max and branch your own engine if that’s necessary.
Also
Using C++ for core inherited classes will provide stronger refactor safety and version resilience. Using C++ only UMG architecture would not guarantee things won’t break. A method can be depracated or deprecating, a dependency is modified maybe with HLSL and UMG visually breaks. Many things can happen. The trick is UMG and in any interface development is architecture, who talks with who, listens how, who authors what.
Those things can be sometimes harder but totally doable with blueprints in UMG too. If you are into custom panel classes, data driven ui design, global procedural animations, or a grift map AAA, chat interface and so on ofcourse cpp is a must but not because it cannot be done, its because it would be better, more flexible and truly reflect the design.
BP or CPP doesn’t matter, things will change we can only say BP more sensitive to structural changes than C++ source files.
“C++ = safe forever” is not a realistic assumption in any continuously evolving engine ecosystem.
For me it was sorta the reverse, I’m generally more of a traditional programmer and wasn’t convinced I’d like blueprints, but I ended up loving it.
If you get along with C++ better than BP, then just use C++, the only downside is that you have to compile your code everytime yo make a change because unreal does not have a c++ interpreter of any kind, everything else is just upsides all the way through.
But visual scripting like BP isn’t really different than normal programming, in almost any way except that at the end of the day it’s more limited and the end results will be orders of magnitude slower than C++ code (this is not a limitation of visual scripting, it’s a limitation of the blueprints interpreter).
The main benefit of BP is human readability, a node graph is easier to understand than a raw text document hwere functions may end up being executed in any order, with the connections between nodes you can clearly see how the code flows in BP, this simplifies code sharing too, e.g. if you copy paste someone else’s blueprints, one glance and you will understand it. If you copy paste someone else’s C++ code you have to read it front to back several times to understand it, or maybe ask an ai to explain it for you and pray that it didn’t screw it up lol.
If you think blueprints is harder, then you’re probably just not using it right, the real magic imo is this:
You right click, and you open this context menu, you see the context sensitive button up in the right corner? it narrows things down to nodes it thinks you might want (but in a relatively permissive way) if you untick it, it will show you ALL the nodes instead.
Combine this with the convenient search function, it has allowed me to stumble my way through scripting in UE usually without needing to refer to documentation at all, being able to search for functions like this is amazing.
Then you just pop it down, drag the connectors where they need to go, edit the necessary values and move on to the next one until you think you’re done.
In C++ it’s much the same but you will ont have as convenient of a search function and instead of dragging any connectors you have to use function calls to declare how the code will flow, and modifying the code ‘feels’ more involved even if you’re technically doing just about exactly the same things.
If you’re getting overwhelmed by the amount of nodes, you must do the same thing you do when you get overwhelmed by the amount of code in C++
Reduce code duplication by creating functions, or dividing your code across multiple files.
It’s all literally the same thing in the end.
