Could we get a block-based Blueprint? And a cheezeburger?

General Feedback & Requests
1

There are two problems I have with the current node based visual programming.

First is, the manual lay-outing that is always needed and may even break (one node overlaps another). It’s always a click and drag fest. The layout can break when I remove one pin, at times the node can get larger because of that. Or when I add more elements to a struct/enum. Every other node placed below could get overlapped by the bigger switch node. And then another click and drag is required to fix the layout again. And of course, any name change of a variable or function/macro, could cause the same problem all over again.

Second is, the wired connections. It can leave a harder to read mess. Especially with the entry node of a function. Where the parameter variables wires may go through the entire graph and to the last node at the far right. It’s not always a problem, but node wires can get covered behind another node still far too often.

Bottom line seem to me, that the current node-based visual programming in Blueprint is a bit of a mess if I needed to make a bigger graph. The solution to the node-based system could be the block-based system! It seem to fix both of the mentioned problems.

The screenshots below are not a good example of the problems in Blueprint. But I still show it for some comparison with the blocked based system.

nodeSystemBlueprint.png
nodeSystemBlueprint.png1431×502 135 KB

Here is the blocked based node system done with MIT App Inventor 2. Of course it’s not functional and a bit improvised since it even doesn’t support structs and enums.

blockSystemAppInventor2.png
blockSystemAppInventor2.png871×590 38.1 KB

The block based node system’s appearance does look familiar, doesn’t it? Yes it does! Unlike Blueprint, it isn’t like spaghetti, but more packed like a cheezeburger.

nodeSystemBlueprint.png
nodeSystemBlueprint.png1431×502 135 KB

The code above is C#. Yes it possible to use local variables to avoid having to cramp everything into one line. But this also would require additional steps. And that’s where the block based system seem to have no problem with. Text based programming languages get usually all of their functions parameters in one line. The Block based system puts all parameters below each other like a list.

Unlike the node based visual programming, the block based system auto layouts itself. Just like a text based programming language where all is pushed automatically to the side or into the next line.

Regarding lay-outing, the block based system makes good use of both worlds, taking aspects from the text based programming languages and the visual based programming languages. The block graph I made with MIT App Inventor 2, takes a bit less space than Blueprint. And I think it still would be same if it actually was functional. Not to mention the that the font size of the block graph is bigger than the one in crude C# example. So, the block graph could get even more compact. It’s almost as slick as a C# code, but still being a visual programming language, not a text bases programming language for scripting in the Unreal Engine 4.

I would take this cheezburger! :smiley:

UPDATE

I guess, it is time to quote myself:

Obviously I’m silently crying for C# support here. By the way, a blocked system would also remove the “hacking” aspect of a text based source (I’m not so font of hacking). Yet still being quite like a text based source after all.

No, I don’t struggle to comprehend C++. Yes, it is sorta “slick” inside UE4. Epic Games actually did a good job here. But there are still problems and hiccups with C++ that make me my head shake, and make me wonder how primitive humanity actually is. (Because “legendary” means “perfection” and not “fail”)

This is not a high priority suggestion, obviously. But also a thought about how one cold avoid that stitched monster called C++ (stitched literally). The other reason is that although visual programming ain’t new. Now there is an actual good way of applying visual programming. So even as a programmer myself, actually, especially since I’m a programmer, I’m very curios to see what a visual programming language really could do.

I think that Blox Visual Scripting for Unity is kinda silly. Because Unity does have C# already. Unreal though, doesn’t have a C#.

I don’t want to replace the current node system of Blueprints. But I would love see a block based addition to it. A block based system could already run on the code Blueprint nodes are based on. It should only be a matter of showing the graphs in a block based fashion?!

I was wondering if a blocked system could serve as an alternative to actual C# in UE4. That could do as a visual programming language a lot more than now Bluerpint could do with its fat nodes.

Maybe this could be a compromise for actual C# support?

2

The block based style looks extremely confusing for me. If Blueprints would look like this, I would do everything in C++. The node based system is not trying to look like code. It allows a different way to explore your logic.

3

The block based style looks extremely confusing for me. If Blueprints would look like this, I would do everything in C++. The node based system is not trying to look like code. It allows a different way to explore your logic.
[/QUOTE]

It sounds like you didn’t do much programming with C# or even C++. But the thing is, if you searched the internet for this blocked system. You would find many projects and activities that actually use this to teach children to learn programming. Yes, I’m not kidding. It ain’t that complex.

I guess the function calls do confuse you? Well, the execution order goes from the right to the left, and from top to bottom. This order is the same as in C# or C++.

You have to try it for yourself. Then you will see, it ain’t complex. It just showing things a bit different. Blueprint ain’t simpler just because it doesn’t look like code. The blocked system only looks like code in its layout. There are still no headers, and no other genuine pain in the *** C++ syntax rules. Plus, unlike in the node system, even the lay-outing is much better, because it is totally automatic. It can’t get even simpler than this!

4

This has nothing to do with my programming experience. I’m programming for nearly a decade now (C# for my job and C++ as a hobby). Almost one year ago, I’ve acquired some experience with block style programming, since I’ve taught teenagers in programming and as you said it’s good for beginners to start with.

For me it has no advantages compared to normal C++ or node based blueprints. The automated layout is maybe an advantage, but in C++ it’s done by VS and in blueprint you can quickly organize it by hand. I mean as a programmer (and now I don’t know how much programming experience you have) you spend most of the time in creating / optimizing your logic and that’s independent of the language you are using. As soon as this is done you can quickly drag and drop the stuff you need and reorganize if you need to.

5

Block based BP would be the worst thing UE4 could have :confused: Good thing they went with nodes.

6

I mean as a programmer (and now I don’t know how much programming experience you have) you spend most of the time in creating / optimizing your logic and that’s independent of the language you are using. As soon as this is done you can quickly drag and drop the stuff you need and reorganize if you need to.
[/QUOTE]

No lay-outing is quicker than “quick” lay-outing. And there is no such thing as “quick” lay-outing. -.-

Structs makes/breaks as well as enum switches somewhere else in the Blueprints, can’t be lay-outed that quickly. Because they have to be found first.

Any new function/node that I wanted between another node, would require moving around. If I wanted to change the execution order, I would have to reconnect the pins instead just one single drag and drop to where I want the functions or nodes to be.

Wires clutter the graph, too. Instead of just reading where the data is coming from, your eyes have to follow the wires. This makes a block based system, just like the text base code, more readable. Because the variable is right there.

I intend to replace node based Blueprints, not C++. -.-

The block based style looks extremely confusing for me.
[/QUOTE]

Why does it look extremely confusing, so being a disadvantage? You have only explained why it “may” not be an advantage.

Why?

Guys, girls. Talk to me. Reason is the only thing that can protect your feelings from me. :slight_smile:

7

It’s not intuitive. I am an artist / designer and I find nodes (the way they are done in UE4 at least) easy to work with, quite intuitive so far. Bare code (cleanly written) follows the nodes. But that blocky contraption doesn’t help in any way. It doesn’t make it easier to understand code, and it’s pretty horrible from visual point of view.

8

[FONT=Arial Black]This is for people ahead of their time!

bffcc2dd96176b6fdd8c1a854a3cc226.jpg
bffcc2dd96176b6fdd8c1a854a3cc226.jpg736×552 70.5 KB

9

NO.

11

Yea I know, but it feels like the block based system removes the advantage of the node based system in order to act more like normal c++.

In my opinion the node base system allows an extremely creative way to actually write code. You can drag and drop you stuff around like you are sorting your ideas. The block based system isn’t that creative in order to act more like ‘normal’ coding.

12

Yep, that was exactly my thought when I had another closer look at my finished block graph. :smiley:

13

I feel like the spaghetti system, while messier, helps beginners identify individual pieces of their code easier than the block based system does, so that they can more easily learn what order certain steps for certain scripts should go in. That’s not to say that they couldn’t learn that from the block based coding system, but to me, blueprints in their current form really help people like me who are primarily artists individualize pieces of their scripts to better organize and build their systems. I’m not a programmer by trade, but I’ve accomplished a fair amount with blueprints and have found them to be very intuitive and helpful.

14

I’m an artist, gamer design, and programmer myself. Well, the programmer part is probably the part why I actually do like the block based thing. Because it is compact and direct. E.g., no spaghetti wires to bother with but the variables are right there.

Yeah, I have to admit my programmer instinct is probably far too strong with this. So I’m not going to argue much further.

Bu the way, there is this blocked based system for the Unity engine. And it looks a bit different than that App Inventor 2. It is called Blox Visual Scripting. The parameters aren’t placed vertically, but like in text based source, horizontally.

15

That block based looks an awful lot like actual code, but with fancy boxes around the elements and visible parameters names. While I do agree that Blueprint could use less layouting (a mix of keyboard interaction and procedural layout could help a lot), that block system seems to be unable to replicate some of the flow shenaningans Blueprints are capable of without resorting to creating multiple functions and whatnot. The example blueprint you picked is the thing BP is worst at: plain old linear functions. How would you bind event listeners, execute delays and such things with blocks?

16

Events shouldn’t be a problem. But regarding the delays, I was asking myself the same question. Isn’t a delay nothing more than a frozen tick? I think a delay should be part of an actual finite state machine (like PlayMaker or NodeCanvas) and not be used inside a Blueprint, though.

It’s not a secret that a visual finite state machine can help a lot to keep things clean. I wonder when, or if Epic Game will attach such a FSM to the Blueprint system itself. When I was still with the Unity engine, I used NodeCanvas and even PlayMaker. No, I didn’t use PlayMaker trying to “replace coding”, that’s such a dumb idea. But I preferred PlayMaker over NodeCanvas, because NodeCanvas 2.0 was so unstable and buggy, and its state node are quite too fat and not so slick as those of PlayMaker in the first place.

17

A delay schedules the execution of whatever is connected to it’s exit node to the future, it doesn’t pause execution. It’s basically a massive shortcut to creating a timer, but without having to declare a custom event or function to execute later.

Think is, blueprints’ strengths aren’t inside functions, they are in the graphs, where you can use all execution flow tools and perform highly asynchronous coding.

18

I am a developer, but I think blueprints are awesome.

Just my two cents - but I like the node approach alot - I find myslef using it quite extensively on several large projects.

For me, developing in Blueprints is very unobtrusive - gets out of the way and lets me focus on what I am trying to do instead of on semantics and language syntax.

I think Epic did an Epic job with them :wink:

19

It’s unlikely at best that Epic would add a third “language” to the engine. We’d sooner see official C# support than a second visual scripting tool.

Personally, I find the BP nodes much more user friendly at first glance, and I prefer C++ to BP anyway.

20

the 's approach seems for me, a non programer, more friendly!
For me, at least as I understand, reading the block code,this is more like how the code works in most programming languages that I have ever seen: C#; C++; Fortran, Basic, Java, old Unreal Script…

Why not makes a native C++ instead C# for Unreal4 using this approach?
As I am not a programmer I do not understand the limitations involved in such proposal. But it seems quite exotic.

But anyway the C# or C++ Visual Block could be collapsed-compiled to be used as a conventional node inside a same Blueprint Spaghetti!!!

21

The automated layout is maybe an advantage, but in C++ it’s done by VS
[/QUOTE]

Yes, but not entirely. VS doesn’t have to because of the nature of text itself. If I typed something before another word, that word after the word I’m typing down gets automatically pushed back. The same with the lines. If I add a new line, all the code/text below the new line would get pushed down automatically. This is not the case with nodes at all.

We still could haz get a cheezeburger, though. And that without ditching the node system.

The graph should view a node that does have an execution pin on it, as its own group of nodes. All nodes that don’t have their own execution pin, and are connect to that node that do have an execution pin, they do all form a group. One group never would overlap another group. I could moved the “group root”, the node with the execution pin, and all other nodes would move as well without even having to do a click-selection-drag.

And the editor itself can make use of this, too. Any new node with an execution pin, would automatically place itself next to the right of the previous node. This way the user even could place such nodes between two nodes. And that without having to reconnect the execution pins, or even having to drag around anything. All node on the “first level” of the execution line, would place themselves in line automatically. And since each node with an execution pin knows what its member nodes are, it also knows how much space it needs, can push back, just like a text based word would, all the other node groups after it.

Eventually I will make a separated thread for this idea. It may require a bit more explanation. Also, the member nodes, so the nodes without an execution pin, they should be layout automatically if the user wants to, since auto lay-outing can break the member node’s readability. I already have such a bunch of nodes without execution pins, in one of my BP graphs, that require manual placing or it would be too hard to understand them.