Unreal Engine 5 = Game Changer

This is an incredibly relative statement and you know it.

 

I looked up devops repository size limits, and found a reddit message telling that their 30 gigabyte repo got rejected for upload.

https://developercommunity.visualst...push-30gb-git-repository-into-azure-devo.html

 

Relative to what?

You already know how to type formulas like a + b from school mathematics course. And because typically game engines offer simplified wrapper around underlying mechanics, you won't need to reach software engineer level in programming.

The way I see it, if you were using visual scripting for 1 year, then you burned through all the initial benefits it offered compared to normal programming. That was enough time to become skilled at a relatively simple scripting language.

If you were using it for 5 years, then it was enough time to become skilled in a complex high level, like C++, C#, or Java.

In the long term, disadvantages pile up and turn into months and then years of wasted time. And that's why I'm not a fan of it. Because the time wasted rearranging connectors could be spent programming.
--------

It is possible that at some point a truly efficient visual tool will appear, then I'll adopt it. But the way I see it right now we are not there. Even Epic Games with its massive investment into blueprints didn't get to this point. What I call efficient tool is approach where you would not need to ever move a connector arround and would be able to create program rapidly preferably without touching mouse. Instead, current tools insist on wasting your time on tasks unrelated to code, and largely are focused on teaching you cable management.

 

I'm starting to think you don't understand that the ability to visualize information, especially formulaic information, can vary from person to person in substantial ways.

 

This debate (visual vs text programming) is the exact same people had when Grace Hopper invented cobol as a high level language that abstracted away hardware implementation, and which echo lasted into the assembly vs high "level level" language like C++ ...

The truth is that we didn't stay at cobol, we evolved the language until it reach the plateau of productivity.

In some way, it's true visual language is limited, but that's because it hasn't been iterated enough like text language was into its plateau of productivity.

Most visual language designer AVOID thinking too hard about those aspects, and generally have a narrow view of programming in general, I know because when I introduce excel (ie tableur in french, I use excel because I can't remember the agnostic translation in english ) as a language paradigm, they think i'm crazy (which is basically the mirror of node base visual scripting, ie node link command by data, excel paradigm is to link data by command) and the discussion end.

Like Grace Hopper says "high priest" are going to gatekeep their church.

 

A LOT of people falls out math due to how school teach it, literary course I full of allergic people to mathematical notation, fun facts they are clearly able to solve complex math problem when you express it as far as possible as math lingo.

 

BTW there is this great post in the dots visual scripting threads

https://forum.unity.com/threads/dots-visual-scripting-experimental-drop-9.890302/#post-5879603

 

There is a 1 gigabyte limit per push that's all, it used to be 5 gigs per push but they changed it a while back

 

I think what the man with the cat logo is saying, overall github is better. even if you not using web platform, you can log changes locally and you won't need to allocate many GBs of storage for different revisions.

You can also create something called 'branches' which we are just learning today.

This is when you wish to test something new. I hope you do find the chance to try it.

BTW i love you cyclotronica game!! It looks so cool and i love the psychedelic graphics and it is such a cool topic for the kids.

 

I'm a bit of an outsider looking in when it comes to visual scripting so i'm very confused when people say "visual scripting has limitations". I've been teaching myself to code in a bubble and it's so incredibly frustrating how there seems to be this universal "you have to learn it like I did by reading over cold boring documentation." The entire pipeline absolutely feels gate kept, and the idea that "You have to put in the effort yourself." is a testament to the overarching gatekeeping mentality of coding from what I can see. It's a self fulfilling culture of mental dick measurers on a grand scale.

Why does it have limitations? Why can't a visual code system be developed that does the exact same thing that bare code does?

Why can't it simply be a modified IDE that modifies how we see the underlying code so that it doesn't become this dumbed down, pain in the ass secondary level of functionality that constantly fights with the underlying code?

People generally see visual coding as this stale, safe environment where you don't have access to writing lines of impactful functionality. That it's these safe, rounded building blocks that can't choke the user if they accidently swallow it.

Why can't we simply modify the way we interact with code to be a bit more compartmentalized in regards to its scope so that they call into easily displayed containers of nodes?

Imagine if within any node you could dive deeper down into each of the sub structures of the code to the binary bits and pieces that make up the core architecture. and then pan back out to the top level node systems that now perform very user friendly functionality.

A system that artfuly displays the noob level stuff all the way down to the atomic level functionality with the exact same structure, but displayed in a more digestible form for noobs as well as top tier coders alike.

Why is an archaic, text based solution, prone to user error and without any modern conventions for displaying new methods and librarires just out of your reach for you to learn when you are ready the standard?

Can any of you guys explain to me why this is impossible? It doesn't seem like it would be impossible to me. I see visual scripting as a potential to create a container, that does not modify the underlying code, it simply holds it in a visual space and displays inputs in a visual manner.

What am I missing?

 

Sir visual scripting comes undone very quickly, for simple comparisons you can compare line of code for simple 'for' loop with relevant noodles needed to make same thing. I would recommend to learn basic script and nodes for everything else.

 

I do. However, visualizing information is a learnable skill, and people overestimate its importance, while treating it as some sort of unsurpassable limit or a mental disability.

Not everyone can become Bjarne Stroustroup or Salvador Dali.

However, anyone can learn program or paint at mediocre level. And that's all that currently is required to make a game with a modern engine. Mediocre level.

Instead, people convince themselves that something that is perfectly achievable for them is utterly impossible, that they have some sort of disability that prevents them from ever learning programming, and that programming is some sort of dark art mastering which requires revelations from Elder Gods.

And in doign that, they scare themselves into using inefficient tools, which waste years of their time.

----------

Your visualizing difference argument would have a point, if in order to become proficient programmer you had to start studying at the age of 2. But that's not the case. People start at 14, 15, 18, 20, 25, and sometimes in their 50s or 60s and still learn it.

For majority of games, you only need to learn to script. And prerequesite for learning to script is literacy and being able to use a written human language.

I personally think that the whole "I am an artist, I can't program" and likewise "I am a programmer, I can't draw/model" thing is largely a purely mental barrier which need to be overcome.

Hell, at one of the places that taught programming I saw a guy in a wheel chair learning Delphi. I think he had a cerebral palsy, could barely speak and had awful cordination (which didn't help him with form editor). That didn't stop him. And that's the right attitude more people need to adopt.

At least that's how I see it.

 

That's how you see it, but how you see it does not match the lived experiences of many many people.

 

This doesn't answer the question, why does the visual scripting 'for' loop have to be intrinsically more complex or different from a traditional 'for' loop. Why does the code differ at all? Why isn't the visual scripting for loop a standard for loop just in a node form?

 

It isn't different, but the readability is greatly reduced, and this is a basic need in most games. where it is useful is when language is too difficult to use and only option is visual scripting (e.g unreal and cryengine.) if you can, it is advised to learning scripting, we started 2 months ago, is very nice, especially if u follow youtube videos.

 

Here you go. This plugin greatly improves editing graphs a lot, reducing constant keyboard-mouse schizophrenia. Epic should definitely incorporate some of this functionality right into the engine.
https://www.unrealengine.com/marketplace/en-US/product/blueprint-assist

I do understand your doubts. I was initially too much focused on blueprints while it was introduced, trying to do everything in it. After some time I felt limits of it, also annoyed by spending too much time operating on the graph. Also, you can't do any editor customization with blueprints, that's often a bigger disadvantage than actual runtime performance. Designers more often trash performance by bad/lazy practices and they would gladly move these bad practices into code if nobody would correct them

One bad about blueprints in UE4 is actually Epic promoting it with words "making a game with no coding". They didn't prepare any education path for blueprint people, so they don't even think about learning programming concepts. In this regard, blueprint documentation sucks as well as C++ documentation (it assumes you already know C++, so WTF?).

However, I'm far from agreeing that blueprint isn't already "truly efficient visual tool". It is.
- Already beats any kind of programming or scripting language for prototyping. Especially for a person who isn't a "fluent programmer" yet. And most of the designers are not. Artists mostly will never be fluent in traditional programming. Unless they follow path of the technical artists.
- Scripting small things with visual scripting and internal behavior of specific actors? Well, I wouldn't ever do in a hypothetical scripting language, C# or C++. The difference is blueprint is a unique fusion of actor definition (its structure, visuals and properties) with a simple code. Not only much easier and faster, but it also provides a self-contained package. It's impossible to break it, if you would remove component from the actor, the blueprint wouldn't compile or even automatically save - it would notify about code missing this component. That basically solves part of the old problem of script not working because someone removed/changed related data in the editor.
- It's a mistake if somebody refuses to learn any other thing than visual scripting and tries to implement every system, every single thing with this. Well, it's a problem with people. Not a tool. There are experienced programmers who also push their programmer-specific agendas like "better to write system from scratch than simply fix someone's else code".
- If there is any programmer in the team, visual scripting should be mixed with code. Always picking up proper tool for a job. The designer shouldn't try to implement everything in nodes and complain "oh no, you're hiding something in code again". Or programmer shouldn't try to put the simple script in code where it using visual scripting would be fast and better for teamwork.

What we're missing here is proper documentation. And training non-programmers in the team.
So often I hear programmers complaining on designers or artists implementing some horrific things into a game, but when I asked "OK, but did you explained to them why this wrong instead of just silently fixing it and laughing about with other programmers?" and surprisingly often answer is "nah, I don't care about explaining, I just fix what designer/artist has done badly".

 

How can the visibility be reduced? It's literally visible.

Like imagine you create a node, you assign it the code "if (x>y)" It dynamically generates the 2 variable inputs of x and y to the side. You visually see those, you clearly see the "x>y" in the node quite clearly. How is readability an issue?

For me collapsing and uncollapsing code in script is such a pain in the ass, there is no reference for scope, you don't see things in 2 dimensions, it all just cascades downwards. you have collapsibles inside collapsibles and it's a generic hodgepodge with no frame of reference. When you have nodes with various colors and visual ques within them you very quickly remember see their framework and architecture. The functionality has a tangible form.

I realize this is a complex issue, and if you open up visual scripting to have parity with the freedom of written code suddenly the easy of use starts to evaporate and the form of the nodes and architecture starts to fall apart and the infinite possibilities kinda tear it apart. But that's what's so exciting about the possibility of this. It has so much untapped potential and it's frustrating to hear people talk about visual code as a quick cash grab to nickle and dime people in the asset store, or as (as others have called it) baby's first gamedev tools. They don't seem to "get it".

Our coding IDE's are archaic and they gate keep. Is improving them to be more powerful and better going to be easier as the past frameworks have evolved and been entrenched for decades? Not even close. But the potential for an exponentially better system that would reinvent our entire reality is there as this obviously has far reaching implications into realms beyond gaming.

 

You do realize that my position is based on life experience, right? You will not be able to convince me that someone is incapable of learning to script, unless they have an actual mental impairment.

I remember trying to improve my drawing skills years after I was no longer a teen.

The main issue is immense psychological pressure from yourself and self-doubt. Because there's someone who is better at it than you because they started 20 years earlier. However, as long as you keep practicing and ignore that, you will eventually improve. And once you improve enough, the inner voice of self-doubt shuts up.

As far as I know programming is the same. If you convince yourself that "this is impossible to me", you will have a perfect "reason" to bail.

 

I agree, I'd much rather do most of my game work at a high level as well and let Unity, UE, Godot, etc. handle the engine. But for Unity there are times I may want/need to peek into the black box, and I know this goes for others. Maybe your games don't fall into this space, it's possible and that's fine. Unity can handle a wide variety of games and it has some nice aspects to it. But as someone who sometimes runs into walls trying to do something new or creative (not just trying to fix bugs), it is difficult or sometimes impossible without the source.

 

It is based on yours, but your experiences are not universal.

 

Well, let us take example, so I played your game on feedback friday( very enjoyable by the way) and you played my car game.

If you were to compare the lines of code, to represent same inside visual scripting the difference would be huge. it is very difficult to explain but when you try to translate what you have always done in visual scripting to code you realise it only small effort to learn and why you did not start this way from begin.

 

Very true, i feel he sometimes gets confused between what is known as 'subjective opinion' and 'irrefutable facts.'

it happens a lot on here i feel.

 

Yes, many are "mentally incapable" in this regard. Not everyone is able to think in a very abstract way, grasp multiple levels of abstractions. Or simply feel satisfaction after solving yet another engineering problem. I love it, I'm fueled by problem-solving.

On the other hand, I'm practically incapable of memorizing things that I can't find actual use. I never spent even an evening on memorizing things to pass the exam. I also can't learn abstract math since if I don't understand where/how I would use it.

There are few people that could master many disciplines

 

That kind of marketing spiel is a lie, and it is unfortunate that Epic uses it too. Blueprints are coding.

That requires something on the level of Python or Lua. Not C++ or C#. Preferably with assistance from the editor. You know, code completion, function name list, documentation. A lot of people are proficient in Oblivion or Skyrim scripting, for example. They can't program normally.

Epic used to have Unreal Script, they sacrificed it in the name of blueprints. Wasn't the best idea.

This is largely correct.

 

Oh I knew your handle was familiar! Thanks again for trying the game out.

But back to the point and this is the core question I have... You keep saying "If you look at visual coding it is different and worse".

Why? What can't it be simply a container, like switching from an IDE. Forget the notion that visual scripting is different, imagine if your functions and code and everything were displayed in a node based format. Imagine a visual scripting environment that could open literally any script and wasn't some sort of derivative of standard code. Imagine visual scripting as ONE IN THE SAME as core code, just displayed differently.

Why isn't visual coding simply a new IDE that displays root code within a node based container?

 

it is and you are definitely correct, except a few things i do not like. the overall logic to create say a 'trigger state' with noodles is so much more involved than a few line of code. And a lot of visual coding requires knowledge of unity api anyway. This is why i feel moving forward it always better to slowly try scripting.

Maybe you can try and you will be surprise how quickly to pick it up

 

Now you only need to prove that I'm so far removed from the rest of mankind that my experience do not apply to the rest of the human race. I haven't transcended humanity, last time I checked.

They are not universal, but I already covered mental disabilities. I'm fairly sure you can't program in a vegetative state, for example.

You don't NEED any of that to make a game in a modern engine. You're describing wrong level of proficiency. This level of proficinecy is necessary to WRITE an engine. Which is not the same thing as making a game in existing product.

Can you describe, in english or your native language, what a part of the game is supposed to do?
If you can do that, then you can program.

This:
"If a player has a quest item, make a villain appear and attack player after giving the speech".
Is a program.

P.S. Don't schools have basic computer courses these days?

 

That syntax is pretty close to specflow which is a super nice QA tool

 

It's not worth discussing because every time this topic comes up you act in a ridiculously reductive matter and just assume that, despite the fact there are plenty of people who have exclusively worked in visual scripting who have even tried learning traditionally typed script who have talked about their experiences. You are trying to go "oh you just need to try," but many have. You can find these people all over, even on the UE4 forums. You can find them on tigsource. You can find them in the support forums of the various visual scripting assets.

What you do constantly, however, is just ignore the fact that these people exist and assume they're all just like you. This doesn't even have to be a disability thing, just a way that people learn and perceive information.

 

What happens if lightmap is > 5gb?

 

I'm currently writing in C# and finding myself pretty decent at it, I have a ton to learn, but I no longer run into road blocks I feel pretty empowered working on my project. I also have extensively used node based systems like amplify shader and unreal's shader systems so i'm very aware of the strengths of both systems.

You say triggers can be done in just a few lines of code. Imagine a visual scripting system that you just punch those 3 lines of code into a node. THAT is what visual scripting COULD be. Not premade, sub par setups. Actual limitless code.

Again I don't know why current visual scripting can't allow for this and this is also why that prior unreal pic was so groundbreaking to see...


Does this image better illustrate the concept? There shouldn't be a "visual scripting environment", it should simply be code displayed in a new manner that isn't raw text. which is again very prone to user error and is not easily categorized, or displayed in an optimal manner. The potential for learning this code, commenting it, organizing it, revamping it, leaves modern code in the dust. It gives code an actual form.

Working in modern code is like living in a house made of seran wrap on mars and the wrong sudden movement causes the entire structure to implode. A revamped visual system has the potential for the best of both worlds, power and structure/ resilience.

Don't like a node? Clone it, change it, add or remove the functionality you want it to have, just as you would copy and paste a function.

 

The way I see it, if they aren't dead, they haven't failed to learn to program yet.

If they had initial roadblock, while learning traditional script. (which is possible, as bad teachers and bad learning resources exist), then managed to overcome the roadblock and produce results in visual scripting tool, then they're currently at the point where they acquired sufficient knowledge to switch to traditional programming and are capable of doing that. Because flowcharts has been frequently used as a stepping stone while training traditional programming, and that's what they effecitvley used visual scripting tools for. So they used visual scripting tools as a crutch - which is what I've been always describing them as.

And if I expected others to be like me, then I would say that the best thing to do is to start with a programmable calculator (something like that, maybe? https://en.wikipedia.org/wiki/HP-16C), then move onto Z80 assembly, before touching high-level languages, as that would give you a solid understanding of close to metal fundamentals modern machines do behind the scenes.

 

i see what u are saying but the trouble is when you have a feedback loop, it becomes less readable than plain code. but i appreciate why such tools would be useful for sure.

 

You have to push each file separate, those should be LFS anyway

 

And that is something I would call efficient.

 

I still don't know how you can say this. When you have a loop in visual coding, you literally see the loop, it is very readable and I know it's obvious to those who have coded for a long time the mental structure of how it works, but to those getting into coding the visuals of the following very much better visualize what exactly is happening with loops:

 

why don't we take this into private messages so as not to detract from main thread if u so wish?

 

i did not know you are working with friend joe strout, he first showed me miniscript when i started. I like your mortal kombat game by the way, it looks so cool.

 

Given that it took 30 seconds for me to figure out what's going on, then more time to realize that this seems to be actually spread across multiple frames, then another period of time to realize that "my int" is actually the same variable.... and then at a second glance I noticed that ++actually does not follow "input on the left, output on the right" paradigm and instead of modifying left argument in place....

The readability of this compared to normal loop is rock bottom.

Unreal engine has ForLoop construct.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/FlowControl/index.html

Readability of that one is higher.

 

At that point, chances are you would probably be better off copying and pasting a function. Nothing stops anyone from designing and implementing a visual scripting system that allows you to do anything that could be done in a traditional language, but the question is: would it be comparable to (or beat) traditional languages when it comes to development speed, clarity, efficiency, and overall practicality?

I don't think text-based programming languages are archaic, just like written human language isn't. They hit a good compromise between human- and computer- comprehensible language.

Personally, it's not that I don't like visual scripting languages. I used GameMaker ages ago, and learnt a lot using their visual system. They're great at what they can do well. But I think it's good to be able to choose, because visual scripting as of today is not quite there yet in many aspects.

 

Maybe I'm crazy, but in this picture what's being provided other than flow or directionality? Is that really what trips people up with coding?

You're quoting the wrong person.

 

Agree, both sides seem to get frustrated. Truthfully, visual scripting is a tool that makes for an easier introduction to programming, but has limitations. I'm not against it, but I don't use it.

One could maybe be developed, but they probably never are around long enough to reach maturity.

The limitations
- Tons of tools already exist for text (lexers, parsers, formatters, IDE's, unit tests, etc.), so it is easier to take advantage of these things in text. Granted visual tools could probably use these things, but it would probably be a lot of work.
- Source control makes it easier to see changes. I can easily see changes between lines of text. Would be harder to write a diff tool for visual scripting (not saying it's not possible).
- Unit tests. I can easily write test cases for text code. Again not saying it's not possible for visual scripting, but tooling would have to support it.
- Find. I can easily do a grep (search for text) in file. Could be implemented in visual tool, but in text I can easily jump from one place to another to see different uses, harder for visual tool.
- Refactor. I can easily copy and paste text out of a method into another file when refactoring code, as general code progression is write, refactor, test, repeat. Additionally I can easily change the name of a method/class/variable and an IDE will replace every known occurrence. A visual tool could probably do this, but again it would be hard to move nodes from one place to another easily and it would be harder to review changes.

That's just off the top of my head. There are probably more.

Probably could be done, but it wouldn't be as efficient and would take up a lot of time to engineer. So why take the time to build it. Most people that need that functionality know how to code in text, and it's more efficient. I'm not saying visual scripting isn't useful to some people. It would also depend on how complex the scripting language is. Take C#, how would you handle Attributes? Or handle out or ref in a method call? Not saying it can't be done, but is it worth the effort.

Could probably be done, but it's not as efficient. Using visual tools is nice when you're learning a system, but when you know a system text based processes are so much easier, quicker and more adaptable.

Probably not impossible, but is it worth it? Maybe for some? There are cool visual tools for SQL, but every time I always end up going to a text editor because I can do it faster and easier (the tool gets in my way). Text to me isn't archaic, it's efficient. Just like the language I'm writing in now.

I'm not saying visual tools aren't good or shouldn't be built. They have uses and people can get things done. But visual tools are always inefficient compared to the language itself.

 

It's more like a hack than loop

Actually try loop nested inside of a loop (even using proper ForLoop macro), that's where the current setup becomes inconvenient. And no local params per loop (you can only have local variables for function. There's certainly room for improvement here.

Or implementing scripting language designed to integrate small scripts into graphs. Skookum Script is a very interesting thing, I wonder if Skookum guys actually working on something even better after being purchased by Epic. Many people are curious about that

 

This is why I don't like VS as currently implemented. Little work, much entangled mess. And this is someone who is closely familiar with the engine and the internals of it and with BP. Imagine how it would look when those people do it who have no clue how it works? For example those designers and artists, who don't care.

ps: I have no problem providing this tool to anyone, who needs it as long as I don't have to work with it or with the people who only wants to use these.
I have a couple things where I see real value in node-based visual scripting: setting up state-machines, application flow-control (which is more or less the same as state machine). But pretty much it.
psps: starts around 3:50 if YT doesn't jump there.

 

Unreal BP doesn't allow time based operations like delays in its flowcontrol nodes like forloops etc

 

I wasn't arguing that this was perfect, just that at a glance you can see that this is a loop, and this was all I was able to find through google images.

Edit: misread your post, thought you were saying readability of visual scripting as a whole was rock bottom

 

Im not sure what it is, but writing shader code is a nightmare to me. All the various concepts within an a typical shader language file is often very confusing.

I’ve written many fancy shaders in Unity using hlsl, shaderlab, and surface shader but just nothing beats a good visual editor for me. Making fancy shaders in UDK, UE4, Amplify, and now Shader Graph is so much more a breeze compared to doing it in code

This is not to say im more efficient than some engineer who’s spent their time making visual treats in shadertoy, but I - personally - am able to work more efficiently and understand shader concept easier when presented in a graph. Especially so because graphs tend to intelligently encapsulate a lot of complexity in easily accessible and searchable boxes and criteria.

 

that is because some facets of game dev lend itself very nicely to visual aids, shader code is one such example i feel.

 

I agree, and i must admit I am new to C# and working in a bubble so a lot of my perspective is skewed from the frustrations of not knowing higher end code. But I really do think that the potential to marry the existing standardized IDE environment with some new higher end modern conventions wouldn't JUST aide people into getting into coding, I think it would have tangible benefits for seasoned coders too like reducing user error and better scaling up and down of how you want to view your code.

This is all hypothetical though, none of this functionality currently exists, visual code in all modern aspects are bare bones versions of other code and very hard to modify by the end user which very much leads to the stigma that visual code is training wheel trash because as it stands, it is.

One of the greatest benefits if there were a feature rich visual environment is people would be able to learn much faster in that environment. And if the nuts and bolts were exposed it could evolve into something better organically by the user base.

 

Knowing "it is a loop" is not good enough, it is important to know at a glance, what the loop condition and body is.

I think it is bad because it deceptive.
It is not a loop, it is a loop spread across multiple frames, apparently with 1 second(?) delay between iterations. And that detail is something you can only notice when you squint at a tiny little number.

Not quite.

All imperative programming languages have same basic building blocks.
Those are variable, function, class, closure (aka block), loop, branch. (... statement, expression). There is also syntaxic sugar for more complex concepts.
To get rough idea of what is going on in any language, you only need to learn which syntax is used to denote which element which is very quick. The time I spent looking at your example, is on par of what could take for, say, Pascal programmer to figure out whats' goign on in Javascript code after seeing it for the first time.

There are outliers, of course, for example, Common Lisp, APL, and non-imperative languages follow different paradigms (for example, there's ML family of languages for functional programming).

This does not apply to visual scripting. Because there is no indication of which node corresponds to which imperative block, and where lies distinction between data and statement, and no common paradigms. There's "node", but no agreement of what "node" is, conventions are not standard and vary across software.

The closest paradigm to visual scripting is electronic circuit schematic. And when Visual tools follow that idea, they become far more usable. In circuitry, there's only signal which flows in parallel through the whole diagram at once. This concept is applicable for signal processing and highly parallel processes.

Spoiler

However, Unreal Blueprints mix two different paradigms, and in addition to signal/data, there's also "execution point", which throws the wrench into readability.

In your example. I have to stop multiple times to investigate SMALL details to make sure it does what I think it does. And in the end, it turns out it does not what I expect, because rather than immediately performing in a single frame, the diagram appears to pause execution for 1 second upon hitting the delay node.

By the way, neither behavior trees nor material editor have this issue.

I used it developing materials for unreal tools. However, compared to standard programming, I believe the loop in your example is rock bottom.

Spoiler

This is better:

Spoiler

This is also better:

Spoiler