Hacker News Reader

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.

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.

Yes but the difference is that Blueprint is actually a good language while SSIS is a dumpster-fire.

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.

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!

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.

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.

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.

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

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.

Would you be down to chat a little about your Blueprint experience and take a look at a tool I've been working on? Check my homepage (on my profile) for contact info if so, I'd be very thankful :)

I'd prefer to just reply to comments but I'd take a look. You might find better perspectives asking the folks who sound like they've finished shipping a complete game though.

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.

Sounds very similar to the problems of using XIBs/Storyboards in iOS dev. (aside from the perf. cost you mention)

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!

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.

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

Blueprints are extremely useful in prototyping at the very least, not just in the initial stages of development but for adding new systems. There is nothing wrong with them and the idea that LLM’s are going to replace blueprints is ridiculous. Sure, you will be able to have them write a block of collision code, but gamedev is one of the most complicated fields in terms of having an understanding of what your state is and what references what.

LLM’s can spit out code without understanding the problem, but understanding the problem is 99% of gamedev

Hey, I've been working on something I think is pretty cool to address some of the shortcomings mentioned here. If you're up for chatting about your experience and offering some feedback, mind hitting my profile and shooting me an email (on my homepage)?

ua6oxa! Is this like an unreal engine blueprint alternative you are working on?

hey Chris :) I'll email you!

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.

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

Oh I didn't know about this, this sounds great

Have they said explicitly that it has ambitions beyond fortnite?

It'll come eventually to the main engine

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

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.

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.

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

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.

1000x slower? No. Just no.

Do some kind of looping math operation and benchmark it.

https://youtu.be/8gVixDglpQ4?t=75

Blueprints are extremely slow vs C++

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

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

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.