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.
