7 ms·

How do people using Blueprints deal with: - Find and replace a variable - Change a variables type - Merging changes from multiple commits - Refactoring - F

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).

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).