Reading blueprints as a coder

Development Programming & Scripting Blueprint
1

I’m starting to read blueprints with lots of interesting game mechanics.

I find that reading blueprints from right to left helps turning a blueprint into a single line of code quicker.

This example BP calculates the ray (impact) distance from one component in the direction of other component.

bp.png
bp.png980×380 82.1 KB

It translates into:

Distance = GetWorldPos(StartPos) - SingleLineTrace( from: GetWorldPos(StartPos) to: GetWorldPos(EndPos) ).hit.location
A few points are missing like onEventTick or makeArray. But the most important pseudo - code is there.

Is it possible to export now the blueprint graphs as SVG? That way i could store the SVG + pseudo code as snippets.

Thank you, hope this is useful too.

2

I’m not usually the one to ask this, but wouldn’t it just be easier to read the Bluprint? I don’t understand what will be gained by turning it into pseudo code.
Also, by SVG do you mean Scalable Vector Graphic? If so, you are looking at a lot of work transforming something rendered in the editor to a vector graphic.

3

Ummm, i may be wrong since i don’t have that much experience with blueprints.

It seems to me that a single line of code is much easier to read, write and work with than a bunch of nodes and lines connecting it.

Blueprints have the advantage over c++ that you can compile them and test them really fast, no need to compile and re-open ue4 for example, c++ workflow is a bit crappy in that sense.

Thats a problem with ue4, it has a great graphical way to create scripts, really useful for ppl who never programmed, however a scripting language exposing the same API is 100 times more productive for normal ppl (aka coders).

Any idea about progress on scripting languages alternative to BP? (going to research that soon)

The BP to SVG would be a very nice way to share blueprints with other ppl, or save diagrams in your computer.

1 Like
4

[=TiagoLr;78433]
Ummm, i may be wrong since i don’t have that much experience with blueprints.

It seems to me that a single line of code is much easier to read, write and work with than a bunch of nodes and lines connecting it.

Blueprints have the advantage over c++ that you can compile them and test them really fast, no need to compile and re-open ue4 for example, c++ workflow is a bit crappy in that sense.

Thats a problem with ue4, it has a great graphical way to create scripts, really useful for ppl who never programmed, however a scripting language exposing the same API is 100 times more productive for normal ppl (aka coders).

Any idea about progress on scripting languages alternative to BP? (going to research that soon)

The BP to SVG would be a very nice way to share blueprints with other ppl, or save diagrams in your computer.
[/]

I’m pretty sure C++ has the same(or more) options as Blueprint. And for you, a coder, a Blueprint might be hard to read, but that’s just until you learn it. I’m a coder, but I have never touched C++, so I’m just working in Blueprint.
It is really easy to read and understand.

5

That sounds strange you prefer graphical scripting over typing scripting (or blueprints over scripting language)

Not that i like unity for a couple of reasons, but have you tried their workflow? Their c# scripting feels a bless compared to blueprints, if you notice that a big blueprint can be converted to a couple lines of code, and that you take a few seconds to read some lines compared to several minutes following blueprint diagrams, then you will understand how much more productive and easy a scripting language is.

C++ is good for great control over UE, but its workflow is not nearly as good compared to blueprints (compile, wait, reopen editor etc…)

What i would like to see would be a scripting language (UScript, C#, JS, don’t care) exposing the same API as blueprints and working in the same way (almost no compile and well integrated).

1 Like
6

[=TiagoLr;78473]
That sounds strange you prefer graphical scripting over typing scripting (or blueprints over scripting language)

Not that i like unity for a couple of reasons, but have you tried their workflow? Their c# scripting feels a bless compared to blueprints, if you notice that a big blueprint can be converted to a couple lines of code, and that you take a few seconds to read some lines compared to several minutes following blueprint diagrams, then you will understand how much more productive and easy a scripting language is.

C++ is good for great control over UE, but its workflow is not nearly as good compared to blueprints (compile, wait, reopen editor etc…)

What i would like to see would be a scripting language (UScript, C#, JS, don’t care) exposing the same API as blueprints and working in the same way (almost no compile and well integrated).
[/]

Well.

The general problem with the scripting languages(both in UE4, Unity etc) is that there is a performance loss. And with UE4 you have the ability to make fast efficient code in C++, because it is really compiled, not just translated into some pseudo code thingie.

You can argue that a “real” scripting language is better, but it is also narrower. Blueprint has about the same performance as Kismet I would think… but it is much more available. Artists don’t need to understand scope, syntax, references etc etc to make something work. They just drag and drop.

I agree that it can get out of hand easily with Blueprints… I’ve made some pretty nasty stuff myself.
But as I have gained experience, I have learned to divide and conquer, just like real programming. You split stuff up into smaller parts, use functions, pass variables… Just like when you write code.
I like Blueprint. But I also understand taste is different between people.
Maybe Epic will expose what is behind Blueprint and make Kismet2. I’m for it, more is better. But I don’t think so.

7

Yeap, using a language to control what blueprint does seems totally possible, after all the blueprint nodes get turned into commands.

No need to worry about performance lost with scripting language vs blueprints, that is nonsense, both call game engine API commands that are exposed.

On a perfect world there would be a way to create blueprints from code and code from blueprints, its also very possible but takes some work and seems a bit far away. But that would benefit both artists/non-coders and coders a lot, a scripting language that translates into blueprints (and vice-versa).

Last thing, blueprints are a bit over-hyped, they attract ppl with few experience writing scripts, but they also cloud the advantages of using a scripting language to do the same thing. With all those videos saying “blueprints are really powerful” etc… it takes a bit of insight to realize that all those pretty/polished graphics and a very well made graphical system to create game logic (props for that) are no match to create logic using words.

Edit -> Graphics are a maybe a good compliment to written logic to quickly understand how data flows and get the big picture (thats why blueprints with a matching script would be terrifying)

8

[=TiagoLr;78548]

No need to worry about performance lost with scripting language vs blueprints, that is nonsense, both call game engine API commands that are exposed.

[/]

There should be close to no difference between scripting and Blueprint. Not what I’m saying… but between scripting/Blueprint and C++ there is performance lost.

9

I dunno about storing them as SVGs at all, but if you Ctrl+C copy any Blueprint node, it actually just sticks a text representation into the clipboard.

Stick it on pastebin, and it’s really easy to share.

Some of the nodes of course won’t be very easy to share, but you can always unhook those and just place a comment describing what type of node needs to be there, and its connections, and copy that instead (i.e., cases where you’re casting or something and the names may be different).

10

I’m not here to defend Epic or something, but I do value how they approach this from design perspective.

First, almost all people, regardless if your are programmer or game designer with no coding experience, when you tackle a complex problem, you are more or less starting from a flow chart.
This is essentially what people spend most of time to begin with, either on paper or with some charting program, doesn’t really matter. The simplicity of flow chart means that you don’t have to know what’s the implementation detail in a task block, you just need to know how things are , what’s the input/output, in a graphical way that makes people communicate easier. Imagine you try to explain a certain system without a flow chart, now compare doodling for a minute, and writing in words to explain those details. Flow chart obviously win by a large margin, thus it was invented and refined and still being used till today.

Second, for scripting comparison, blueprint’s disadvantage is on smaller scale of things, like doing some simple math expression or multiple statement condition brance looks ugly compare to some few lines of code. BUT, blueprint’s major advantage is to hide the following and thus simplify work flow in a long run:

  1. automatic scoping, if you can’t do something, you can’t. you either wait Epic to update the engine or do it yourself, but whoever use BP won’t just get a compile error that something is not available, they can’t even create a node that does not belong in current context.

  2. naming/typing simplified, no typo. this will save A TON of time, don’t lie that you never mistype a variable name with script that does not have strict declare/use, and scratching your head try to hunt down where your logic goes wrong. blueprint’s graphical approach solved this problem. novice/veteran coder alike, imagine the time saved for non-coder. all the “syntax” burden is then relieved from designer/coder and just spend most of their time doing actual work.(note, logical error happens no matter what. but blueprint save you from all the rest.)

  3. very good graphic debug system, let you debug even in a multi-threads situation that you focus on a per-instance level. now imagine doing this with a scripting based system, you’d need a whole new editor UI for debugger.(like set break point, stepping, watch value list, etc.)

  4. very easy “migration”, partly because of 2., you can migrate/copy your asset and others that gets it can use them right away(given same engine version). if you try to do this with multiple scripts, you are less likely to drag and drop unless you do it the prefab way like in unity. UE4 can certainly use some of those idea to make migration/copy even better.

  5. node system hides API migration better than script, as in any node based application, it is much easier to just load the node, do the recompile/re-interpret, and hides all those details from user. For script you must have a deprecation period, you need to force your code base to maintain backward compatible for a certain time, and lost work hours to create those deprecation warnings. with script you have to hunt down all those invocations and change all of them. But with node based it is far easier as input/output/actual code are generated on the fly, thus you can deprecate old stuff procedurally. open and recompile, .

  6. colored nodes are better than syntax highlight in script. I don’t even have to zoom in to know what things are doing from a zoomed out scope, imagining doing this for scripts. If you are familiar with graph system, you can pin point where you want to go really quickly even if it’s someone else’s creation. Maybe not the detail part like rotation value is wrong, it’s hard for both script/graph. But to identify starting points(red nodes), execution(white) or data(colored) flow, what was , function/cast/timeline/macro, they all have distinctive color that you can see without actually zoom in. plus node comment you can home in to the nodes you want even faster, now try see the comments from multiple scripts at the same time.

So yeah, blueprint is not actually over-hyped, and in some other post I did before, it is actually a good way for old programmer to start learning how things are in a multi-core/simultaneous execution era. Even better, once you finished prototyping, you can always port those parts with performance issue back to C++, and they are pretty straight forward(except for those pesky macro declaration). Now that math expression is actively tested, I’d assume that scripting would lost yet another advantage. Which leaves very few things worthy before blueprint tackle them.

11

Agree with you Penguin on what you said, still it will take time to find if overall blueprints are more practical to use than a scripting language, i doubt it, nonetheless i can go with blueprints + cpp, its still good to keep an eye on what could be better instead of just praising things just because they’re there, also wanted to show that.

thanks n002342355, very useful tip to store the blueprints, have to open unrealed to visualize them but sounds good.

12

As someone in VFX industry(and start coding from around age 11~12 with BASICA), I can tell you node based system is the way, plus expression based node you can cover basically 99% of things you want to do.
If scripting alone can be more efficient, why isn’t editor just a viewport and some text editing panel on the side? Why is visual programming making huge stride in both efficiency and popularity outside of programmer circle?
I didn’t just praising things as is, visual scripting come a long way with multiple iterations through years, and thus saying what it could achieve while a scripting based system can’t is covered in my above post.
And certainly the entire UE4 community is pushing hard to make this system even better, major update every month, what kind of crazy company do that? Not only Epic did, and as of now no major break if you load from previously built projects.

All major 2d/3d softwares is more or less node based, from one extreme like say Max that really doesn’t have visible nodes but “modifier”(which Blender borrow from heavily), to Houdini that is almost entirely node based.
And all comp software is node based, if you would want to argue which is more efficient in a long run, that’s the true testament because 2D comp goes far longer than 3D softwares, and yet all surviving comp software are all node based.
Mind you, comp is basically math expression for pixels, plus other paint/hand tweak stuff, if expression along or script show any significant advantage over node based editing, it would be main stream by now.
The single most hard to deal with problem for any human interface with computer is input error, and scripting provides a perfect environment to mess things up just by one typo.

With proper design and solid foundation(building blocks like lego) I can even say in the future even programming would be node based plus expression, take for example OSL(OpenShadingLanguage), their postmortem from like 2 years ago already seeing their byte code based compiler with runtime optimization already surpass hand tweaked C shader. If you then see the examples of those shaders,(for example Vray’s OSL support pages: http://docs.chaosgroup.com/display/VRAY3/OSL+Support+in+V-Ray), it’s so dead simple that even the most complex ones can be in a visual scripting way. It’s just a matter of time.

Now with those being said, it’s not like text editing for programming is bad, it’s still needed, but at framework, hard and sweating ground level of works.
If you doubt it, show some solid argument and counter points.

13

If you want to code, then code. The C++ source is ready for you to play with all day long.

You keep saying normal people referring to coders, but I see it the other way around. With Blueprints, normal people are now able to perform and learn scripting in a way that actually meshes with their brain, visually.

14

Some posts are missing after forums went down, thats a shame, any idea why?

15

Hi ,

Please have a look at this post, it will explain what happened. Thank you!