5 ms·

> I heard Blueprint sucks! > Blueprint actually rules. Look, I get it - why would a visual scripting thing be good? They're all shit! I agree. > Blueprint is

> I heard Blueprint sucks! > Blueprint actually rules. Look, I get it - why would a visual scripting thing be good? They're all shit! I agree. > Blueprint is the only one that's any good. It's amazing. It will also help you learn the engine. Everything you do there will be applicable to C++. No matter who you are, you should start in Blueprint. It's 100% true that you can build an entire game in Blueprint. Yeah, with multiplayer. Yeah, performantly. Yeah, maintainably. It's not just for rapid prototyping. > Be a snob about Blueprint at your peril. I've helped a lot of people get good at Unreal and get hired for it, and Blueprint-related recalcitrance is the number one way people screw themselves - without realising, they sentence themselves to months of wasted time and frustration only to mould themselves into the type of Unreal user who sabotages any team they're on. Swallow your pride and look at some nodes. Best advice in this page. Blueprints are excellent. They make the engine API extremely discoverable. You naturally gain a deep understanding of the classes and components and how they interact. They are performant. They can do 95% of what you want. The C++ engine API is fine but it doesn't lend itself to learning the engine. I don't recommend using it unless you identify a specific need.

LanceH 3y ago
I had this same scepticism but kept seeing tutorials doing real with with it until I was convinced.
aschearer 3y ago
How do people using Blueprints deal with: - Find and replace a variable - Change a variables type - Merging changes from multiple commits - Refactoring - Finding all references I'm a fan of visual coding and use it extensively in YWDHT but have found the above challenging. I'm curious how Blueprints solves these issues, especially for larger teams.
- russdpale 3y ago
  A colleague and myself were just discussing similar issues with SSIS packages compared to just running the queries in a stored procedure on the server.
  - Pxtl 3y ago
    Yes but the difference is that Blueprint is actually a good language while SSIS is a dumpster-fire.
- andybak 3y ago
  This is an extremely good list of the potential issues with most current node-based tools and Is be very keen to see a detailed reply.
- timeagain 3y ago
  I think you missed the point. Yeah it isn’t code and it has downsides, but it is a GUI for discovering and learning to intuit the API. To not use it would be tantamount to refusing to read the documentation. When entire teams are using visual programming tools through the entire dev lifecycle (incl. refactoring and maintenance), wake me from my cryogenic freezer!
  - andybak 3y ago
    But the original article and the post we're all replying to isn't arguing for using it for "discovering and learning to intuit the API" - they are arguing for using it for the bulk of coding tasks.
    - spywaregorilla 3y ago
      No I don't think so. You can. I do about 80/20 bp, gradually shifting some content to cpp as I need more specific network replication capabilities. But they're definitely referring to learning by doing stuff in blueprints. I would agree with this. Figuring out how something ought to be done with the engine in blueprint and then re-implementing it in cpp is the more pleasant experience imo.
- spywaregorilla 3y ago
  Not sure why this is downvoted. > - Find and replace a variable > - Finding all references I think the basic search tools are pretty good. I can't say I expect find and replace to be super common. I would prefer to do such things one at a time. > - Change a variables type I would say you really shouldn't be doing this too often. It's compiling to statically typed code under the hood so this will frequently cause a lot of breaks. You can do it, and it will highlight all the areas where this breaks things (maybe more easily than c++ might tbh). And if the types are compatible, that might mean you have to do the annoying step of redrawing lines to the same var with a new "node" representing the proper type. > - Merging changes from multiple commits This is hard and not good. The most difficult part about blueprints. > - Refactoring I tend to think this is pretty easy. Maybe easier than in code. I'm a big fan of collapsing all nodes into subnodes. So every individual step becomes one high level node. You can also "collapse nodes" into a function itself. You want to minimize the number of nodes you're looking at any given time so it kind of encourages good practices on itself if you're competent.
  - andybak 3y ago
    > I can't say I expect find and replace to be super common. I would prefer to do such things one at a time. This seems like a very strange thing to say. I presume you do text-based coding as well? Multiple cursors, search/replace, bulk refactors and other semi-global operations are a huge part of my normal workflow and I can't quite fathom how visual coding would change the need for that. Regarding refactoring - I'm not sure what you describe really is "refactoring".
    - spywaregorilla 3y ago
      I'm a data scientist day to day, which is a very different feel from coding up game systems. The latter is a lot more intricate and intertwined. The text coding I do in c++ for unreal is probably more involved. I can't say what you're saying resonates with me as familiar. I've always been confused at why people ever feel multiple cursors is useful if not just begging for disaster. You can, for example, rename a property in a blueprint class, and that will flow through to all references to that property in other blueprints, if that's closer to what you mean. When I think about refactoring I think about taking some logic and making it into a more reusable function; or abstracting it into a shared component. I would say the former is what I was saying, and the latter is more of a capability offered by the engine than the tooling. Reparenting classes to compatible alternative parents and moving properties and logic to component classes is relatively comfortable in my opinion.
- deleted 3y ago
  [deleted]
- crustaceansoup 3y ago
  I've only been on medium-small teams, but I'll give it a shot: Merging is essentially as banned as we can make it; we use Perforce, and set all .uasset files (Blueprints and other UE assets) as Exclusive Checkout so only one person can edit them at a time. This is recommended by Epic. When we do need to merge things, it's mostly a manual process of opening the Editor on two branches and duplicating all of the changes. All of the refactoring-related questions, again, mostly manual effort. There are some constructs that can help keep things DRY which reduces the problem, like BP function and macro libraries. You also get inheritance and interfaces. UE also lets you redirect property, class, and function names to new names using "Core Redirects"; you can do that and then resave all packages to effect a bulk change. Finding all references: Search All in UE will find a string anywhere; that means in property details, BP function calls, variable names, comments, anything. There's not exactly a "find references" as you might expect from a normal IDE though. Really, the ultimate solution to dealing with these and the general "visual scripting spaghetti" problem if they're on the verge of becoming acute is to stop using Blueprint. We try not to use Blueprint for any complicated systems. It's nice for simple presentation-related things (e.g. "play x sound when y happens"), or places where we want designers to have some control for tuning or prototyping, but even for something that seems "straight-forward" like GUI code it can very easily end up spiraling out of control. Blueprint also has a performance cost and it's hard to profile. UE5 dropped UE4's main attempt to fix this with "nativized" Blueprints, i.e. Blueprints that got compiled into C++. There are ways to improve Blueprint performance, but you really shouldn't even get yourself into a place where you're leaning on it so heavily that you can even worry about that.
  - yAak 3y ago
    Sounds very similar to the problems of using XIBs/Storyboards in iOS dev. (aside from the perf. cost you mention)
- dbrueck 3y ago
  Earlier this year we completed a huge refactor that involved, among other things, getting us almost 100% off blueprints (now we use them just for little bits of presentation logic in UIs). BPs are amazing for discovering how to use the engine - they provide a sort of guided exploration of things, especially when you don't know what you don't know. For us they really, really, really broke down when it came to version control, multiple people working on the same BP, code reuse, and refactoring. Arguably, at least some of this was our fault - I think you're "supposed" to do the major coding not in BP and then use BP mostly for really high level stuff, and we didn't always do that. Anyway, it's been wonderful not having those issues anymore. Gone are the days of changing one thing and then git saying that 100 files have uncommitted changes!
  - doctorpangloss 3y ago
    It's nice to hear from someone with real experience. Blueprints clearly delivered negative ROI. In general they probably do. This is the worst time to be advocating for visual programming, considering the first truly groundbreaking application of AI is going to be in writing code. The real question is, did C++ give you any real ROI either? Probably not, it probably only got in the way compared to the way Unity is architected. > Gone are the days of changing one thing and then git saying that 100 files have uncommitted changes! You're using Unreal, but not with Perforce? Get back into the time machine buddy! People's expectations about this extremely clunky engine are way too high.
    - dbrueck 3y ago
      > The real question is, did C++ give you any real ROI either? We actually moved most of everything that was in BP (and a good bit of what was in C++) to Python, so it addressed all of our issues while also speeding up development and, somewhat surprisingly, giving us a decent performance boost too. > You're using Unreal, but not with Perforce? Yeah, definitely not going to use Perforce, haha - might as well be using SourceSafe! > People's expectations about this extremely clunky engine are way too high. Unreal absolutely does have its warts, an almost overwhelming amount of complexity, and we've run into our share of issues. Sometimes you're amazed at how quickly a feature can be implemented, and then other times you spend days on something you thought was going to be trivial. We replaced the replication system with something better suited to our needs, for example. That said, on the whole we're pretty happy with Unreal (both the renderer and the materials system are very impressive).
brundolf 3y ago
My hangup with blueprints has always just literally been: I'd like to type them out with my keyboard instead of using a mouse I wish they offered like a "Bluescript" language or something, that just maps 1:1 with blueprints but lets you write them out as code
- andybak 3y ago
  I think lossless roundtripping with a textual representation is essential if node-based tools want to escape the local minima they all seem to get trapped in. Either that or the ability to use 3rd party editors so competion and innovation can happen in the same way it has for textual code editors.
pfisch 3y ago
Blueprints have terrible performance. They just do. Even trying to compile them into c++ doesn't work well. Blueprints run at least 100x-1000x slower than equivalent c++. This isn't even discussing working with multiple coders and version control, which is also a disaster. If you are making a simple game then they can work. If you aren't then they are not great.
- peterashford 3y ago
  1000x slower? No. Just no.
  - pfisch 3y ago
    Do some kind of looping math operation and benchmark it. https://youtu.be/8gVixDglpQ4?t=75 https://youtu.be/8gVixDglpQ4?t=75 Blueprints are extremely slow vs C++
- johnnyanmac 3y ago
  >Blueprints run at least 100x-1000x slower than equivalent c++. they are slower but unless you are doing literal math in the blueprints this is a huge exaggeration... which is exactly what one AAA game I worked on did. sigh. And they wondered why we couldn't hit 60fps (tho, that wasn't even the biggest detractor to performance). Now, BP's in general usage when you're not doing literally everything in them is about 10x slower. But when you properly use blueprints, you can mitigate this a lot. BP's in a large project work best when you expose existing c++ code to BP and make sure any designer code is piped through c++ first. The main exception tends to be UI code, but UI is rarely a performance bottleneck in large 3D games to begin with. >This isn't even discussing working with multiple coders and version control, which is also a disaster. yup, that's my 2nd biggest gripe. Nothing worse than trying to submit code and the BP you changed one node in is locked, with the owner of the lock being out for the day.
  - pfisch 3y ago
    Even calling BP code from C++ goes through an interop layer and is still much slower vs the equivalent C++. I'm not saying never use BP, but everyone should realize the performance cost of using BPs is quite high.
jarsin 3y ago
Don't forget to use base classes in c++ though. It's massive performance hit to cast to bp only classes. The base class will help you move nasty bp stuff like complex calculations once you run into them.
andersa 3y ago
Blueprints are not performant, they are potentially the slowest scripting language to ever be used in a significant way, worse than python even. If you don't believe this, try implementing some basic number crunching routines in pure blueprints and see how long they take to execute. Though if you're just using them to configure and glue together C++ classes, like most gameplay code is doing, then it's usually fine. Reading other people's blueprints and understanding them is much harder than doing this with the equivalent code - having to follow the wires everywhere is a nightmare with all visual noise. I often jokingly call it a write-only language. Not to mention the part where you must have compiled the project and be running Unreal Editor with all the assets loaded to do this in the first place. And then you can't even properly diff or merge them without using some special tool that doesn't properly integrate with your version control and only works reliably half the time. Blueprints are fantastic for familiarizing yourself with the engine, since you can quickly discover all the things to do from the context sensitive search. They're also great for people to get started with their projects and prototyping. They're not at all suited for production work in a large team. I really wish Unreal Engine supported a proper scripting language so the choice isn't between noisy node graphs hidden in binary asset files and raw C++ code. People keep shooting themselves in the foot with both of these.
- johnnyanmac 3y ago
  >I really wish Unreal Engine supported a proper scripting language so the choice isn't between noisy node graphs hidden in binary asset files and raw C++ code. People keep shooting themselves in the foot with both of these. That's apparently what UE's new Scheme based language, Verse[0], is aiming to do. But this is very new tech and currently used in the Fortnite editor part of UE. It's not quite something to use in the main engine yet. [0]: https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference https://dev.epicgames.com/documentation/en-us/uefn/verse-lan...
  - brundolf 3y ago
    Oh I didn't know about this, this sounds great Have they said explicitly that it has ambitions beyond fortnite?
johnnyanmac 3y ago
>They make the engine API extremely discoverable. yeah, because the UE documentation is absolutely horrid (and it's not like Unity is better at this). I have lots of gripes, but I think the meta issues involve how BPs cause so much community knowledge about the c++ API to be buried. Absolutely fatal if your game cares about performance. >They are performant They are performant... IF you know how to weave between them and c++. Shame that courses don't really seem to emphasize that and you simply hit that wall once you're working on a project.

LanceH 3y ago

I had this same scepticism but kept seeing tutorials doing real with with it until I was convinced.

aschearer 3y ago

How do people using Blueprints deal with: - Find and replace a variable - Change a variables type - Merging changes from multiple commits - Refactoring - Finding all references I'm a fan of visual coding and use it extensively in YWDHT but have found the above challenging. I'm curious how Blueprints solves these issues, especially for larger teams.

russdpale 3y ago
A colleague and myself were just discussing similar issues with SSIS packages compared to just running the queries in a stored procedure on the server.
- Pxtl 3y ago
  Yes but the difference is that Blueprint is actually a good language while SSIS is a dumpster-fire.
andybak 3y ago
This is an extremely good list of the potential issues with most current node-based tools and Is be very keen to see a detailed reply.
timeagain 3y ago
I think you missed the point. Yeah it isn’t code and it has downsides, but it is a GUI for discovering and learning to intuit the API. To not use it would be tantamount to refusing to read the documentation. When entire teams are using visual programming tools through the entire dev lifecycle (incl. refactoring and maintenance), wake me from my cryogenic freezer!
- andybak 3y ago
  But the original article and the post we're all replying to isn't arguing for using it for "discovering and learning to intuit the API" - they are arguing for using it for the bulk of coding tasks.
  - spywaregorilla 3y ago
    No I don't think so. You can. I do about 80/20 bp, gradually shifting some content to cpp as I need more specific network replication capabilities. But they're definitely referring to learning by doing stuff in blueprints. I would agree with this. Figuring out how something ought to be done with the engine in blueprint and then re-implementing it in cpp is the more pleasant experience imo.
spywaregorilla 3y ago
Not sure why this is downvoted. > - Find and replace a variable > - Finding all references I think the basic search tools are pretty good. I can't say I expect find and replace to be super common. I would prefer to do such things one at a time. > - Change a variables type I would say you really shouldn't be doing this too often. It's compiling to statically typed code under the hood so this will frequently cause a lot of breaks. You can do it, and it will highlight all the areas where this breaks things (maybe more easily than c++ might tbh). And if the types are compatible, that might mean you have to do the annoying step of redrawing lines to the same var with a new "node" representing the proper type. > - Merging changes from multiple commits This is hard and not good. The most difficult part about blueprints. > - Refactoring I tend to think this is pretty easy. Maybe easier than in code. I'm a big fan of collapsing all nodes into subnodes. So every individual step becomes one high level node. You can also "collapse nodes" into a function itself. You want to minimize the number of nodes you're looking at any given time so it kind of encourages good practices on itself if you're competent.
- andybak 3y ago
  > I can't say I expect find and replace to be super common. I would prefer to do such things one at a time. This seems like a very strange thing to say. I presume you do text-based coding as well? Multiple cursors, search/replace, bulk refactors and other semi-global operations are a huge part of my normal workflow and I can't quite fathom how visual coding would change the need for that. Regarding refactoring - I'm not sure what you describe really is "refactoring".
  - spywaregorilla 3y ago
    I'm a data scientist day to day, which is a very different feel from coding up game systems. The latter is a lot more intricate and intertwined. The text coding I do in c++ for unreal is probably more involved. I can't say what you're saying resonates with me as familiar. I've always been confused at why people ever feel multiple cursors is useful if not just begging for disaster. You can, for example, rename a property in a blueprint class, and that will flow through to all references to that property in other blueprints, if that's closer to what you mean. When I think about refactoring I think about taking some logic and making it into a more reusable function; or abstracting it into a shared component. I would say the former is what I was saying, and the latter is more of a capability offered by the engine than the tooling. Reparenting classes to compatible alternative parents and moving properties and logic to component classes is relatively comfortable in my opinion.
deleted 3y ago
[deleted]
crustaceansoup 3y ago
I've only been on medium-small teams, but I'll give it a shot: Merging is essentially as banned as we can make it; we use Perforce, and set all .uasset files (Blueprints and other UE assets) as Exclusive Checkout so only one person can edit them at a time. This is recommended by Epic. When we do need to merge things, it's mostly a manual process of opening the Editor on two branches and duplicating all of the changes. All of the refactoring-related questions, again, mostly manual effort. There are some constructs that can help keep things DRY which reduces the problem, like BP function and macro libraries. You also get inheritance and interfaces. UE also lets you redirect property, class, and function names to new names using "Core Redirects"; you can do that and then resave all packages to effect a bulk change. Finding all references: Search All in UE will find a string anywhere; that means in property details, BP function calls, variable names, comments, anything. There's not exactly a "find references" as you might expect from a normal IDE though. Really, the ultimate solution to dealing with these and the general "visual scripting spaghetti" problem if they're on the verge of becoming acute is to stop using Blueprint. We try not to use Blueprint for any complicated systems. It's nice for simple presentation-related things (e.g. "play x sound when y happens"), or places where we want designers to have some control for tuning or prototyping, but even for something that seems "straight-forward" like GUI code it can very easily end up spiraling out of control. Blueprint also has a performance cost and it's hard to profile. UE5 dropped UE4's main attempt to fix this with "nativized" Blueprints, i.e. Blueprints that got compiled into C++. There are ways to improve Blueprint performance, but you really shouldn't even get yourself into a place where you're leaning on it so heavily that you can even worry about that.
- yAak 3y ago
  Sounds very similar to the problems of using XIBs/Storyboards in iOS dev. (aside from the perf. cost you mention)
dbrueck 3y ago
Earlier this year we completed a huge refactor that involved, among other things, getting us almost 100% off blueprints (now we use them just for little bits of presentation logic in UIs). BPs are amazing for discovering how to use the engine - they provide a sort of guided exploration of things, especially when you don't know what you don't know. For us they really, really, really broke down when it came to version control, multiple people working on the same BP, code reuse, and refactoring. Arguably, at least some of this was our fault - I think you're "supposed" to do the major coding not in BP and then use BP mostly for really high level stuff, and we didn't always do that. Anyway, it's been wonderful not having those issues anymore. Gone are the days of changing one thing and then git saying that 100 files have uncommitted changes!
- doctorpangloss 3y ago
  It's nice to hear from someone with real experience. Blueprints clearly delivered negative ROI. In general they probably do. This is the worst time to be advocating for visual programming, considering the first truly groundbreaking application of AI is going to be in writing code. The real question is, did C++ give you any real ROI either? Probably not, it probably only got in the way compared to the way Unity is architected. > Gone are the days of changing one thing and then git saying that 100 files have uncommitted changes! You're using Unreal, but not with Perforce? Get back into the time machine buddy! People's expectations about this extremely clunky engine are way too high.
  - dbrueck 3y ago
    > The real question is, did C++ give you any real ROI either? We actually moved most of everything that was in BP (and a good bit of what was in C++) to Python, so it addressed all of our issues while also speeding up development and, somewhat surprisingly, giving us a decent performance boost too. > You're using Unreal, but not with Perforce? Yeah, definitely not going to use Perforce, haha - might as well be using SourceSafe! > People's expectations about this extremely clunky engine are way too high. Unreal absolutely does have its warts, an almost overwhelming amount of complexity, and we've run into our share of issues. Sometimes you're amazed at how quickly a feature can be implemented, and then other times you spend days on something you thought was going to be trivial. We replaced the replication system with something better suited to our needs, for example. That said, on the whole we're pretty happy with Unreal (both the renderer and the materials system are very impressive).

brundolf 3y ago

My hangup with blueprints has always just literally been: I'd like to type them out with my keyboard instead of using a mouse I wish they offered like a "Bluescript" language or something, that just maps 1:1 with blueprints but lets you write them out as code

andybak 3y ago
I think lossless roundtripping with a textual representation is essential if node-based tools want to escape the local minima they all seem to get trapped in. Either that or the ability to use 3rd party editors so competion and innovation can happen in the same way it has for textual code editors.

pfisch 3y ago

Blueprints have terrible performance. They just do. Even trying to compile them into c++ doesn't work well. Blueprints run at least 100x-1000x slower than equivalent c++. This isn't even discussing working with multiple coders and version control, which is also a disaster. If you are making a simple game then they can work. If you aren't then they are not great.

peterashford 3y ago
1000x slower? No. Just no.
- pfisch 3y ago
  Do some kind of looping math operation and benchmark it. https://youtu.be/8gVixDglpQ4?t=75 https://youtu.be/8gVixDglpQ4?t=75 Blueprints are extremely slow vs C++
johnnyanmac 3y ago
>Blueprints run at least 100x-1000x slower than equivalent c++. they are slower but unless you are doing literal math in the blueprints this is a huge exaggeration... which is exactly what one AAA game I worked on did. sigh. And they wondered why we couldn't hit 60fps (tho, that wasn't even the biggest detractor to performance). Now, BP's in general usage when you're not doing literally everything in them is about 10x slower. But when you properly use blueprints, you can mitigate this a lot. BP's in a large project work best when you expose existing c++ code to BP and make sure any designer code is piped through c++ first. The main exception tends to be UI code, but UI is rarely a performance bottleneck in large 3D games to begin with. >This isn't even discussing working with multiple coders and version control, which is also a disaster. yup, that's my 2nd biggest gripe. Nothing worse than trying to submit code and the BP you changed one node in is locked, with the owner of the lock being out for the day.
- pfisch 3y ago
  Even calling BP code from C++ goes through an interop layer and is still much slower vs the equivalent C++. I'm not saying never use BP, but everyone should realize the performance cost of using BPs is quite high.

jarsin 3y ago

Don't forget to use base classes in c++ though. It's massive performance hit to cast to bp only classes. The base class will help you move nasty bp stuff like complex calculations once you run into them.

andersa 3y ago

Blueprints are not performant, they are potentially the slowest scripting language to ever be used in a significant way, worse than python even. If you don't believe this, try implementing some basic number crunching routines in pure blueprints and see how long they take to execute. Though if you're just using them to configure and glue together C++ classes, like most gameplay code is doing, then it's usually fine. Reading other people's blueprints and understanding them is much harder than doing this with the equivalent code - having to follow the wires everywhere is a nightmare with all visual noise. I often jokingly call it a write-only language. Not to mention the part where you must have compiled the project and be running Unreal Editor with all the assets loaded to do this in the first place. And then you can't even properly diff or merge them without using some special tool that doesn't properly integrate with your version control and only works reliably half the time. Blueprints are fantastic for familiarizing yourself with the engine, since you can quickly discover all the things to do from the context sensitive search. They're also great for people to get started with their projects and prototyping. They're not at all suited for production work in a large team. I really wish Unreal Engine supported a proper scripting language so the choice isn't between noisy node graphs hidden in binary asset files and raw C++ code. People keep shooting themselves in the foot with both of these.

johnnyanmac 3y ago
>I really wish Unreal Engine supported a proper scripting language so the choice isn't between noisy node graphs hidden in binary asset files and raw C++ code. People keep shooting themselves in the foot with both of these. That's apparently what UE's new Scheme based language, Verse[0], is aiming to do. But this is very new tech and currently used in the Fortnite editor part of UE. It's not quite something to use in the main engine yet. [0]: https://dev.epicgames.com/documentation/en-us/uefn/verse-language-reference https://dev.epicgames.com/documentation/en-us/uefn/verse-lan...
- brundolf 3y ago
  Oh I didn't know about this, this sounds great Have they said explicitly that it has ambitions beyond fortnite?

johnnyanmac 3y ago

>They make the engine API extremely discoverable. yeah, because the UE documentation is absolutely horrid (and it's not like Unity is better at this). I have lots of gripes, but I think the meta issues involve how BPs cause so much community knowledge about the c++ API to be buried. Absolutely fatal if your game cares about performance. >They are performant They are performant... IF you know how to weave between them and c++. Shame that courses don't really seem to emphasize that and you simply hit that wall once you're working on a project.