Let's talk about increasing speed & productivity in Blueprint.

Vote on Issues

I wanted to start a new discussion on this topic, since existing threads on the subject are generally full or arguments or people being quite silly… In particular, I want to draw attention to an idea I’ve had for a while about improving the productivity and speed of Blueprinting - which I think benefits everybody while still staying in line with UE4’s existing practices.

Unless you’ve been living under a rock, you know that there have been plenty of discussions and cases for bringing a third programming language into Unreal. Most commonly, the go-to for this is C#. 99% of the time, the only argument for doing so is productivity.

Now, I don’t support the idea of bringing in a third language. I don’t think the solution to the problem is to ask Epic to essentially create and fully support a new first-class feature, which will ultimately only end up segregating the programming community and bring issues and caveats of it’s own. Even if this was possible, you still don’t get the flexibility and power of C++ - and you don’t get the visual interface of Blueprints. The solution isn’t to add a new tool, it’s to find a way to improve the existing ones.

I’m primarily a C++ enthusiast. I personally don’t struggle with or find the workflow frustrating and I’ve been doing it long enough to know where the caveats are. I started with Blueprint, Blueprint gave me enough knowledge of the underlying API that allowed me to start using C++ at all, so for that I’m grateful.

However - I’ve now reached a point in which I can actually prototype and test an idea faster in C++ than I can in Blueprint, which seems very backwards to me. Visual Scripting is fantastic for readability, but the process of creating and linking up nodes is extremely slow in the grand scheme of things. With Visual Assist installed, using C++ in Unreal is a blur of keyboard strokes. The best way to come up with and refine an idea IMO would be getting the best of both worlds, being able to type commands with minimal effort and have it displayed in both a text and node-based format - and have both of those things be coupled to each other.


This image should better explain what I mean. My suggestion is still just an early prototype idea, but I think there’s something to work with and I think it stays in line with what the engine already does, and should be far less complex than adding a new language.

The idea is to add a new window to the Blueprint editor, which displays a human-readable text interpretation of that Blueprint and whatever lies inside it. As you type, the nodes are actually created and linked up in the graph right in front of you.

This also works the other way, as you create nodes, the text editor fills up with the according text. Highlighting / clicking on nodes is also coupled together, and you get auto-complete in the text editor too, to speed up the workflow.

The key is that both the text editor and the visual graph are linked to one another. You can just create nodes like you usually would by clicking, dragging, connecting pins etc - or you can save hand movements and time by typing the ‘connections’ into the text editor, with auto-complete. The example image is an idea of what the Synxtax ‘could’ look like.

So, thoughts?

EDIT: Just a short one, I want to clarify that the extra window there would be optional, just like a details panel. It would be totally seamless with the existing editor and automatically fill as you create nodes, and vice-versa.

EDIT 2: Streamlined list of goals for this idea:

  • Reduce the time the user spends creating and linking BP nodes.
  • Keep the system contained in the BP editor, avoid creating new tools.
  • Stay in line and coupled with the existing tools.
  • VAX-Style auto-completion for fast prototyping speed.
  • Nodes and Text must be generated in tandem, no disjointed-ness between the two.
  • Text language should be basic enough to NOT require additional time spent learning it.
  • Text editor is completely optional and doesn’t become a requirement to create Blueprints.
2 Likes

I would say this is a good idea but probably will be better is the maps, shaders and Blueprints can be editable as that type of code, I mean when you edit in visual editor you edit at the same time the code and the code can be opened out of the engine to edit it.

I give a +1 to this, I want more clear work, probably slowdown the performance in the editor but I want this cause can help for script languages and help to corrupted files to edit it and figure where is the problem better.

This is an excellent idea and I believe one that Epic should strongly consider.
This would leave the advantage of visual code for blueprints but allow for not only text people to see things at a glance but possibly even build text parsing tools on top of blueprints.
We could see improvements in user made linters as a result of this.

[MENTION=8] [/MENTION]

Just to clarify on this subject too, I think the way to make this a succesful idea is to ensure that the text-based ‘language’ doesn’t need to be ‘learned’. You should be able to easily infer whats going on in the BP from the text and vice-versa, and within a few hours both methods should come as naturally as the other.

The idea at heart really is ‘Typing Out Visual Nodes’ - This is about improving the tools, NOT adding a new language.

Hey , great write-up for your request. I’ve forwarded it over to support to get a request put in the system, but I’m also bringing it up in my reports to the lead devs for consideration. Thanks!

[= ;581296]
Hey , great write-up for your request. I’ve forwarded it over to support to get a request put in the system, but I’m also bringing it up in my reports to the lead devs for consideration. Thanks!
[/]

Boss! I’ll be interested to hear what they say :slight_smile:

I actually suggested the same thing a few days ago … meant it as a joke, since it was about C#. But it seems very productive either way to have code not only inside UE, but also inside the specific blueprint :slight_smile:

Love this idea. I think if I had this, I could efficiently work on blueprints and learn C++ at the same time since it’s something that’s definitely on my schedule of things to do.

Exactly my thinking. ++ for seamless conversion between nodes and text

a script editor for BP could be interesting.
But to be honest I would prefer an improvement of the working flow with BP directely.

BP somehow remind me about mindmapping software, some have really tedious way of building the mindmap with ton of shiny visual list you need to scroll on and clic to select, open popup, forcing you to manually position every branch, note, etc…
while other just go straight with only keyboard solution, context shortcuts,dynamic hotkeys, personal favorite, custom snippet, default automatique positionning of every branch, node, with autorearanging.

Another idea of improvement, I’m thinking about how TheBrain handle the display of its nodes and how it can rearange the dispay of it dynamically, based on the active selected node.

Hey ,

Thanks for the suggestions and for providing a solid, detailed explanation.

I’ve gone ahead and entered a feature request for discussion by the developers: Unreal Engine Issues and Bug Tracker (UE-34684)

Have a great day!

I used to say somewhere back in 2014 that this is how Blueprints should work.
But after thinking more about it I understood that a gigantic amount of work on a very complex lexical parser is needed to make it possible.

Yeah I think this might be more difficult to do than first appears. But, it seems to me that just adding more keyboard control options and making the context sensitive menu a lot smarter could go a long way to giving the functionality you want.

Through a combination of typing node names and control keys/shortcuts, it should be possible to build up a series of nodes, with connections, without taking fingers from the keyboard. It would take some smart design to make it natural to use, but would probably be a lot easier than a full on editable text representation.

[=;581328]

I feel we need more visual control over Blueprints, such as user customization (optional user feature).
Add clarity to nodes by adding movable pins
[/]

Not to derail the thread but wanted to throw my support in for being able to customize the order/placement of pins, if for nothing else than OCD reasons.

[]
I’ve now reached a point in which I can actually prototype and test an idea faster in C++ than I can in Blueprint, which seems very backwards to me. Visual Scripting is fantastic for readability, but the process of creating and linking up nodes is extremely slow in the grand scheme of things.
[/]

Actually, there’s nothing surprising about that. Visual programming is slower than text typing, and is harder to get an overview of once complexity reaches a certain level.
This has been known in computer science since the first prototype systems in the '70s were tried on larger scales.
The kind of productivity you see with C++ is the same kind of productivity the other programmers want to get from C#. Which is why I think the “C# or nothing” demand isn’t that well founded; you can do that exact same thing in C++, so demanding C# just means “I already learned C# and would prefer that over having to learn C++.”

I like the idea of a scripting version of the node layout. I also don’t think it would actually be that hard to do, but it might be hard to do well.
Microsoft did something similar with XAML + graphical layout for their WPF applications in Visual .
Android also does a similar thing for UI layouts – type XML or move boxes around; your choice.

As a programmer that loves BP, I think this is a brilliant idea. Connecting nodes can get very tedious. Following node execution can also get tedious. As a programmer, I can usually make more sense of things when in text form (not always, though!) I like that this piggybacks on existing tech, and gives us programmers more familiar tools to work with. Like I said though, don’t get me wrong, I absolutely love BP! I love how easy it is to discover functionality using BP and this gives the best of both worlds.

I really like the idea. I don’t know how BP works, but wouldn’t it be a better idea to
get rid of “C++ or BP or both” and simply “fuse” C++ and BP?

What I mean is similar to your idea;
Using Visual Scripting with text, but the visual Scripting is equivalent(!) to the C++ Part.
I don’t know how this is possible(especially with multiple function outputs), but C++ Code that can be read as a visual graph and a visual graph than can be edited with C++ would be far superior.

Edit:

In other words:
Restructure BP Visual Scripting to a Visual Graph C++ IDE For Unreal.

Offtopic:
Really, whats the Point of C#? I never understood this.
What is so “productive” about C#?

[]
Really, whats the Point of C#? I never understood this.
What is so “productive” about C#?

[/]

The Visual support for C# is absolutely phenomenal. The “visual assist” type tools and re-factoring tools are better than any available for C++. If you rely on the IDE to tell you what you can do, especially if you are bad at memorizing function names or slow at typing, this is a time saver for the part of programming that’s “typing things and moving them around in source files.”
Additionally, C# is garbage collected, and thus, you can defer thinking about memory management, and when your object approach ends up causing random stalls every 30 seconds, you simply blame the runtime and tell the producer you won’t fix it.
Saves lots of time!

Also, if you already know C#, but don’t know C++, then clearly C# saves time, because you don’t have to learn a new language.

[=jwatte;581449]
The Visual support for C# is absolutely phenomenal. The “visual assist” type tools and re-factoring tools are better than any available for C++. If you rely on the IDE to tell you what you can do, especially if you are bad at memorizing function names or slow at typing, this is a time saver for the part of programming that’s “typing things and moving them around in source files.”
Additionally, C# is garbage collected, and thus, you can defer thinking about memory management, and when your object approach ends up causing random stalls every 30 seconds, you simply blame the runtime and tell the producer you won’t fix it.
Saves lots of time!

Also, if you already know C#, but don’t know C++, then clearly C# saves time, because you don’t have to learn a new language.
[/]

Visual does definitely support C# better, no doubt there.

UE4 C++ is also garbage collected.

Finally the time savings is absolutely minor. If you’re training a new dev and they have experience with neither C++ or C#, the situation is the same, 98% of their time will be learning the engine API, not the “language”.

Would I prefer C# to C++? If the tradeoffs were minor, of course. But let’s please stop pretending it’d be some gigantic time saver, because it isn’t. The engine API being different from the competition is orders of magnitude more time consuming than syntax and tooling differences. You ultimately have to master the API and documentation regardless of the language you use with the engine.

And I’ll repeat, if the goal is “engine accessibility” then go contribute or evangelize UnrealJS and Unreal Python, those are both more popular than C# and the market is bigger than former unity devs.

[=;581435]
Using Visual Scripting with text, but the visual Scripting is equivalent(!) to the C++ Part.

Restructure BP Visual Scripting to a Visual Graph C++ IDE For Unreal.
[/]

If that was possible, it would already be a thing and would have been an industry norm for years. If you can make a visual scripting system that is both as fast and powerful as regular old C++, you’ll be a billionaire in weeks.

Additionally, given that Visual already integrates perfectly fine with C++ and has more features than UE ever will, there’s absolutely no benefit in reinventing the wheel. There’s nothing wrong with the current workflow in either C++ or BP, it’s just that finding a way to make using BP faster is what people are really trying to say when they ask for a new language, in my opinion at least.

Again, these kind of major feature requests and invasive changes to workflow are what I’m trying to avoid. Although the OP idea isn’t exactly trivial to implement, it’s going in a more realistically achievable direction IMO.

[=VFe;581496]
UE4 C++ is also garbage collected.
[/]

This is also true, and people seem to forget how much is already done for you if you’re prepared to learn the API. I agree with pretty much everything you said. In terms of the C# debate, in my opinion there are only two valid arguments for it, which are:

A) They already know it coming from Unity or other engines - and somehow think the UE4 integration would be similar enough for them to get busy coding right away.
B) It’s ‘supposedly’ faster to iterate and work with - while I’ve not used C#, I really find this hard to believe - and again I think this is a tools/integration issue - not a language one.

I don’t really want to turn this thread into a C# vs C++ debate either way. The task at hand is to improve BLUEPRINT prototyping speed, not debate the finer points of text-based languages. The hope is that in doing so and providing some kind of common interface, prototyping / scripting productivity gets faster and circumvents the need for different languages.