Ask HN: Why is visual programming so popular for game programming?
Why is visual programming so popular for game programming compared to other domains?
For example Unreal Blueprints
What is it about them that makes it so popular?
For example Unreal Blueprints
What is it about them that makes it so popular?
* makes the engine api very discoverable, which is huge. It’s a step above intellisense and auto complete. The api is likely the reason it’s so dominate in games. It’s the bulk of game programming. Visual programming isn’t very good for coding new things from scratch.
* let’s you read code and clearly follow execution from start to finish.
* let’s you visually document concepts with collapsed nodes, and colored containers and what not. Good blueprints are literally written as long form pseudo code, with double clicks to see actual implementation.
* concepts like const functions are just conceptually clearer. Const functions have no execution pin. They (should) have no side effects. Just a calculation. The engine doesn’t enforce this I don’t think but it’s close…
What it explicitly does not do is allow you to code games without knowing how to code. Countless beginners just die on the first steps. You still need to understand object oriented design and basic coding concepts to do well.
Everything you wrote is just as true for a well written text program, and untrue for badly written blueprint spaghetti!
The original claim was there are no alternative to blueprints, not scripting languages.
And, of course, c++ is an alternative. Maybe not the best, but an alternative to blueprints. In the Unreal documentation [1] we can find:
- Blueprints only
- C++ and Blueprints
- C++ Only
This is why I think it is common to mix and match them.
[1] https://docs.unrealengine.com/4.27/en-US/ProgrammingAndScrip...
Lua is great and I'm a huge proponent of it but different tools are meant for different use cases.
I say that as someone who's worked on both sides and shipped production Lua, Unreal script and C++ during that era. Visual scripting/programming tools are for your designers/artists/animators or as glue code between content that is under high iteration cycles. You can do things such as "find all references to this actor" or realtime visualization of states that just aren't as streamlined as text based languages.
The tradeoff is there's a level of complexity where text based languages are better at expressing abstractions and structure, you use them in different contexts and for different parts of a project.
I can understand why you might want to use it for shaders. (but not really)
And when it comes to placing volumes and marking up the scene I'll absolutely want visual gizmos.
I genuinely believe that if Epic had taken all the effort they put into blueprints, and put it into a text based programming environment, game designers would be more productive.
update: just watched Tim Tillosons twitch stream about it. I had not seen that before.
I think it'll be a massive game changer for unreal and am super excited for it.
Sure, that's pretty clear :). If you want to re-read my post above I wasn't saying that would be as good at game rules and there's a very real limitation as soon as you get away from scripted encounters and into anything more complex.
At the same time consider there may be people, teams and designers who it does work for. Very few things are in absolute and there are places where I've seen tools like this used effectively.
The only reason I commented at all was because the OP listed a bunch of stuff that was good in blueprints, but I believe all those things are good in text too.
Where blueprint shines is strictly limited to animation rigging (what animation to play when a character is doing what or response to user control) and visual effects (what the result would be if i mix certain elements, apply lighting, shader etc).
Outside of these two areas that are meant for content production, you won't find many studios employing professional blueprint programmers because it is far too slow and difficult to debug.
To illustrate this create a blueprint for a simple C++ loop with a dozen switch statements with conditionals inside each, that is a lot of mouse clicks, movements and typing. When you write code, you don't need to worry about how to organize nodes that is readable, there is no hand eye coordination of where to place your conditional node that will branch easily to a dozen or more wired connection.
In addition, for performance boosts and debugging, you are almost guaranteed to always use C++ and it is NOT the most user friendly experience especially for those who are not exposed to C++.
I just want to warn anybody from taking oneoff786's comment at face value without really realizing the full cost of using UE for its blueprint, you will be sorely disappointed and this is backed by up by many who have shipped games before.
Unity has visual programming, it isn't the the selling point of Unreal, and that isn't why large studios are using Unreal for. If you are an indie developer or a hobbyist interested in shipping games, Unreal will greatly delay and lead to frustrations.
I'm just warning anybody in case they think that blueprints are all that is needed to wire up a game in UE, that is NOT the case, you might be able to pull it off with purchased assets without much focus on novelty, but you could easily achieve the same far faster with Unity.
Game development is hard but its especially hard when relying on UE4's blueprint. Even more so when you are stuck with waiting for someone to reply to your forum questions and told to rely on Intellisense to figure out which API method to use because the document is out of date.
In fact I recall being told to just compile the UE engine to learn the inner workings, if I was a professional C++ developer at a game studio sure, but I'm a hobbyist shipping games on Steam, its a no go. C# is far far more accessible as many decisions are made for you as well as there are far bigger community and tutorials around Unity3d.
If you have the money and experience to use Unreal, go right ahead, you can absolutely make amazing games, but I guarantee you will end up using C++ and its 3rd party productivity tools since what's offered out of the box really is going to take ages for a shippable game compared to whats possible with Unity.
Finally consider the financial incentive of Epic, they need money from established studios that has a history of shipping games to cut them a royalty check, you can't do that by investing in hobbyists and indie game developers who are unlikely to ship a game ever!
> To illustrate this create a blueprint for a simple C++ loop with a dozen switch statements with conditionals inside each, that is a lot of mouse clicks, movements and typing. When you write code, you don't need to worry about how to organize nodes that is readable, there is no hand eye coordination of where to place your conditional node that will branch easily to a dozen or more wired connection.
For each node -> Switch nodes -> switch nodes.
Collapse the switch nodes so that you have only one master switch statement. Easy. And way way cleaner than code imo. And less time to code as you don’t need to manually specify each switch if it’s something nice like an enum?
I agree this is a shitty way to manage complexity, but at the same time it's super intuitive for lots of people. Maybe find ways to apply it conservatively and guide the non-hardcore emacs users down a path that won't drive you mad.
I haven't yet run across a lua integration that was actually reasonable to use. Every time it's a choice between "just hack in what I need to but there is no way to verify I've accounted for all the edge cases and it will be fragile as fuck" or "spend dozens of hours wrapping the exposed api in a safer and more usable OO or FP interface."
Oh also I hope you like implementing build systems virtually from scratch, and also dealing with every downside of C if you need anything more powerful than prototypical inheritance.
Six months of professional lua work has really, really drilled into me that a programming language isn't shit without its ecosystem, and it's meaningless to discuss one apart from it. I haven't used blueprints but it sounds a lot better than any lua system I've worked on.
The only really fun part is you'll often come across an undocumented function that someone obviously forgot to remove or didn't understand the implications of and you'll get DEEP system access through abusing it, or even just a straight root shell. No joke.
And I think it would be scary to have a team of programmers coming on and off a Lua project doing things all subtly differently, even rolling their own OO for example. You would have to be very disciplined as a team.
Also: Blueprints reload instantly and are easy to debug.
Its a frequently overlooked feature. Itd be great to have more accessible outside the editor.
|----||----||----()
X1 X3 Y1
Fun fact I learned: Many (all?) rail signal and control blocks are written in ladder with ALL valid states of that rail block predefined in ladder. The logic is simple but the task is incredibly critical. Supposedly it is much easier to visually verify/test the program using ladder vs a written language.
For example: a level designer might want a specific type of entity in their level (let's say a floating platform). A programmer can extend the engine to provide the logic for said entity, which accepts parameters like how quickly the platform should move, what should trigger the movement, in which direction it is moving, etc. The programmer implements all of this and the final result is a new entity type said level designer can drag and drop into their level in the editor, and configure to their heart's content.
Previous to that we also heavily leveraged Lua coroutines as a form of literate programming/game "script". Since the coroutines would execute in a linear manner(with yield() where it handed execution back to the engine) it was really powerful for scripted sequences.
Another interesting area is industrial/PLC programming. The parallels between what we did in gamedev and ladder programming was striking. Visual state representation, online edit-deploy-debug. I'm fairly confident you could give a designer a copy of a ladder editor connected to a game engine and they would have no problem scripting out a sequence.
There used to be junior programmer positions for people to listen to artists and modify/rebuild the source with different magic numbers. That's a waste of everyone's time.
Monobehaviours in Unity alone can't show logic, they contain them, they're just components that don't describe an inherent execution order among themselves.
1. He is comfortable tweaking parameters in a visual environment. This means he can iterate without me which is faster. He comes to me with a list of things he wants accomplish. I create a bunch of tools. He's off to the races.
2. For certain problems it's faster for me to whip together some visual code using re-usable code-building-blocks I've written. For example, sequencing through a series of states for some moment in the game or reacting to a game event.
3. He is familiar with finite state machines -- for example the entire animation system is built on them -- and can therefore make changes to the game without my input, say changing how the boss works in combat.
4. Plus these changes don't require recompilation, which helps speed up iteration.
The flip side is that it's very easy to wind up with a huge pile of visual code spaghetti strewn across a dozen places, and it's impossible to refactor safely -- pretty serious issues ... but when you're just two people trying to scrape by and release something before flaming out, they're not at the top of my list!
[1]: Very out of date screenshots for those curious: https://store.steampowered.com/app/1446350/You_Will_Die_Here...
[2]: Plus contractors who help with the art, sound, marketing.
Removing the engineer from the content loops lets a lot of work happen really quickly.
1: Highlevel entity logic, something implemented by a number of game characters but nothing that really steals too much performance (and at that point could be rewritten).
2: Shader stuff that is often quite plain formula calculations that doesn't introduce extra iterations and most of that perf cost is just eaten up by the GPU's.
But most importantly, the initial iteration isn't always the same as the final product. If something really becomes a bottleneck a developer can often rewrite the stuff in a more performant way (and often still leave parameters available for tweaking).
It can be (usually is) far less intimidating than text-based coding. Compare:
- a text editor with a hello-world template script, a whole keyboard and now the engine yells at you because you (bravely) did something trivial to start, like adding a blank line in between "hello" and "world"
- a canvas with a big "add node" button which brings up a list of verbs and nouns organised into native-language categories
Asynchronous code can be hard to follow. Visual programming / node graphs are actually pretty good at representing complicated asynchronous logic.
I think this is pretty closely related to why diagrams / drawing / whiteboards are commonly cited as helpful by programmers.
I haven't used Unreal Blueprints. I have used Unreal (3, UDK) Kismet which is not particularly related (to Blueprints) other than the "Unreal" part, AFAIK. It was quite capable for most level design scripting logic, but was not ideal for implementing new mechanics for example. You could also copy nodes in/out as plaintext which I always appreciated as a feature I don't see very often.
Also, games programming is HIGHLY agile. Most of the logic you implement will be thrown away. It's all about rapid prototyping and finding what is "fun". Of course, once you've found something fun you might want to build it into a solid and scalable system, but even in such a system you might want to keep the flexibility for designers to extend and add new elements as they see fit (using visual scripting!). The ability for non-programmers to be able to make gameplay changes is also an important factor.
There, I've said it. Most 'games' are in fact interactive movies, with very little game in them. That's what Game Engines enable.
I'm vote we stop calling them Game Engines and instead call them Interactive Movie Engines.
> The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself,
This is and always was a Bad Idea, let me bring up a very simple example for you, a racing simulator. What sets apart an arcade from a realistic car driving sim? It's not really the graphics, or "gameplay", its the physics engine.
You might argue "oh that's just knobs on the physics engine" - maybe. But the way you handle the graphics, the whole game, even, hinges on how well you have tuned that engine. I don't care how many artists or designers you have - adding doodads to a realsitic racing sim isn't going to make it more fun. And if your arcade gameplay isn't spot on, no amount of "gameplay tweaks" is going to fix your jank arcade racing game.
Game Engines don't really make for building racing sims. They make Ok FPS or world exploration templates, but you kinda want to not even care about assets in these types of games - and they are all geared at creating assets spitting, 10000 collectible doodad dumping, absolute messes.
While I disagree with your argument about game engines being bad for games, you bring up an interesting point. Game engines are becoming cinematic movie engines.
Right now, they're a bit sub-standard. They shouldn't be built for consumer hardware at all, but rather live in the cloud where they have access to a lot of GPU compute for rendering.
The thing they get right is the reduction in film production complexity. Less going to set, less setting up lighting, cameras, etc. Easy tweaking in post, and an almost complete inversion of the production pipeline where directors, actors, and animators can work in lock-step with one another in fast iteration.
Unreal Engine is being stretched to do film things, but it's ultimately a local optimum. We're going to see a lot of new tools emerge in this space. (I'm building one!)
In the near future, films shot on cinema cameras and glass will be in the minority of visual media produced. It's just too time consuming. It'll become an artisanal pastime that directors like Wes Anderson remain attracted to.
The really interesting thing will be what happens to studios like Disney and Netflix that bank on in-house content and IP. Once media is no longer expensive and kids at home are making Star Wars of their own, the linear content moat is gone. Franchises and major IP will probably move to difficult-to-produce (for now) mediums, such as games, since films will turn into something more closely resembling novels - a huge basket of works, a wide distribution of quality, and a very long tail of interests that are catered to.
The next decade is going to be a wild ride.
Why? How are they good for games?
My argument is that 'games' are stagnant, boring nonsense, unless you want interactive movies. What counterpoints do you think you have?
It's no different from using SQL for database access.
Basically, someone has to do a ton of upfront work designing a domain specific language for a task, in this case game scripting then it's easier for people to do the game scripting using the domain specific language than using a general purpose language.
SQL is an early example of a language designed for a specific purpose.
Mental overhead
I hate coding stuff that I know could be better expressed with a visual graph or say, an animation curve. As a software dev on a team I view my job as making tools that the actual game designers and artists can then use to make better games with less effort and while having more fun doing so.
I work with Mecanim in Unity a lot, so it’s not quite Blueprints but it’s similar in that you need to think like a coder still when you’re setting things up.
I hate coding animations in CSS, but I enjoy watching them in e.g. devtools. I really wish I could see the representation of my code visually more often. Immediate mode UIs are sort of like this, but I've rarely seen tools which actually show while coding.
We unit test (or try to) every new feature, why shouldn't we be able to visualize them too?
So I believe the plan is to trick the content creators and less strong programmers into using a purely functional programming language so that they produce less bugs.
Anyway that's my take on it, I only made a few demo games in blueprint and really enjoyed it, I haven't used it in anger so to say so someone who's actually in the industry might speak better to it's actual merit.
The reason blueprints exist in UE is because they needed a way to allow non-expert programmers on the team to write code that isn’t C++, but they didn’t want to use a high level scripting language like Lua.
IIRC, Sweeney said (on Twitter) that in the past, it was a burden to constantly be designing and maintaining language bindings for scripts, especially with a rapidly changing engine.
Also, (I’m guessing here), blueprints result in less bugs since it provides static typing and makes it possible to do some advanced visual debugging. These are things that, even if they were available in a language like Lua, they would be intimidating and/or uncomfortable for the artists/non-programmers on a team. Plus I’d imagine that it’s relatively easy to produce some highly optimized code from blueprints, maybe even compile it to native instructions.
It’s also probably no coincidence that the visual node-based concept is used a lot in other tools used primarily by artists, like for material creation.
Why do you think that is? I mean essentially these are specialized DSLs which you have to maintain bindings for...I can't imagine its easier to test you haven't broken your visual language.
> "These are things that, even if they were available in a language like Lua, they would be intimidating and/or uncomfortable for the artists/non-programmers on a team. "
Ok I can agree that languages don't always provide for the easiest mental translations, but I will say if you are not an artist, i.e. you are a verbal not visual thinker, blocks with lines probably are more intimidating, not less...
In that same vein you probably shouldn't presume a non-programmer prefers visual metaphors - a lawyer or an accoutant probably finds a high level textual description more helpful (dsl, or config file).
There is probably a better middle ground, i.e. lua text blocks which can be visually represented as boxes or as code unit files.
The other supposed benefits you mention are more easily handled by a smart compiler - you can optimize what is inside the block but this will prove difficult to optimize across blocks - whereas code is arguably already broken down to its simplest form, so the whole thing can be optimized (plus, interpreters can do nifty runtime optimizations compiled languages just don't get)
Why isn't visual programning more popular?
The problem is the complexity of overlaid graphs. Text, through references, handles this well and planar layouts do not.
Consider also the density of information; an example is a (visual) AST of an arithmetic expreasion, versus the conventional symbolic representation. You could make a visual tool to build arithmetic trees. It's a very clear repreaentation, easy to follow and would be fun to use. But... real fast... it becomes unweildy.
So, visual programming is great for simple problems, by non-programmers. As other commenters have said, there are a lot of non-programmers in game development - I think most of it is non-programming these days.
Another category is new users. People play games, and then want to make games. Visual programming is more like a game than text programming is. Some of these people really are just "playing" at making games (nothing wrong with that!) But some of them are earnestly making a game - and the fewer obstacles in their way (like learning how to program), the better. Get them onboard, get them started - better for them, better for Epic, and better for the world to get the games they've come up with.
Finally, because of text superiority, programming infrastructure (e.g. git) is also text-based.
BTW spreadsheets are kinda visual, and very popular. "Visual Basic" has some visual programming elements, for GUIs. There's some business tools, like XML mappers, that are visual.
For the logic, you get a table where every column is essentially a class, and each row is an if-then construct. The first column can be a condition, implicitly called once per frame, or an event with an optional condition. In each cell you can add actions that should be called on the instances of the class for its column. Everything is selected through simple dialogs.
For example, you'd make a condition/event like "Bullet collides with enemy", then add an action "Destroy" under "Bullet" and "Enemy" classes, something like "Play 'boom.wav'" under the "Sound" class, and "Add 1" to some "Counter" class. If I recall correctly that is.
This ended up getting me into programming, because I was able to quickly achieve results while being able to start experimenting with the UI before reading a single tutorial or any sort of document. I think discoverability is the killer feature. I could easily see that instead of destroying an entity, I could spawn another one. Or I could create an entity at the point of the collision, so I'd animate an explosion effect. But the explosion would just stay around, so I looked around what I could do... found an "Animation ended" event, so I simply made another rule that would destroy the explosion object when its animation ended. And so on.
I think another reason is that game logic is messy yet simple. So you don't want a lot of boilerplate code or having it scattered across lots of files, otherwise you're not getting a good overview. But I can't vouch for modern visual programming languages to solve that problem since I haven't really tried them.
A while later I accidentally stumbled over the BASIC interpreter of DOS and was amazed how easy everything was there - you could just store a number in a variable and directly do stuff depending on its value!
For anyone interested, here is a (bad quality) video from the 90ies explaining the software on Windows 3.1:
I definitely never got anywhere typed code wise around the same time even though I really wanted to make games, all the options just approached you as if you had a comp sci degree.
It's just another tool in the toolbox. Epic has mentioned how a portion of Fortnite was built using Blueprints. It helped them to prototype features and get the game built quickly.
Think about how handy it is to have a diagram, picture, or plan before writing a single line of code. Epic takes sections made using Blueprints and rewrites them in C++ for better performance.
After using Blueprints for a bit I can see its merit and why it's useful.
Unfortunately, I can't find the source where Epic talked about this. I think it was a GDC talk but I could be wrong. :\
I think that's really why it's so popular: "anyone" with an idea can sit down and cobble something together that looks like a video game. A lot of people will give up when they realize you need to know more than "drag and drop" to customize your game, but it allows a lot of people with game dreams to dive in who would otherwise simply never try because they don't know anything about programming.
Now where did I put those maps to my Fantasy Dragon Quester 2-d jrpg game?
I think Lua in Roblox, or the Godot's python like language, or Unity's C# is strictly better in every way.
Visual Programming languages don't prevent "non programmers" from writing really weird code that makes no sense.
You will find many first time programmers that like visaul programming because they created something cool in Unreal. I think if there was a Lua integration they would have achieved more, faster.
We use words to communicate our thoughts in comments on Hacker News. What would our communication be like if we only had flow charts you could plug variables into?
I guess you can argue stories are all written, but tech is not that way, neither is science, political discourse. So yes, visual artists may be at some disadvantage. Or at least, if they have discovered something, nobody knows about it.
To me, only the code is real because it can be run and is the product. UML is great for niche cases, but it doesn't represent the truth well, and is usually at least one time increment out of sync with reality.
Game design - especially in 3D environments - is an incredibly visual process!
Unless you are incredibly familiar with programming to start - why, if you were approaching game design, and - for instance - had level layouts, character and enemy designs, etc - prepared in advance - wouldn't you?
It's literally the most logical way to approach filling in those gaps with functionality with a visual system of design like that.
Game Design is not visual at all, it's pure logic. "when I pull the trigger, find the thing I am pointing at, if it has armor, reduces its health by 10, otherwise reduce its health by 20"
Game Art is all visual. Red is scary, green is good, sort of.
They are completely separate paradigms.
I imagine you’ve probably been a software dev for a long time - and come from a history of game dev?
(Ha - yeah - you did. I looked you up, you worked on ‘Bioshock’? It is to my credit that I could figure that out before I looked it up, though.)
You see - unlike the ‘00’s - Unity, and even recent UDK updates, etc - have created a fairy “plug and play” sense of game development that was a fever dream in the ‘90’s, and even most of the ‘00’s.
The tech has changed - the approach has changed, massively.
I mean - hell - even 10 years ago cross-platform shit was a nightmare compared to today. It’s because a lot of that underlying code has been taken care of for 90% of average developers. Only AAA developers need worry about low-level shit.
We are very much living in a design-first era. Which is - frankly - awesome. But it’s so easy to forget that or not see that as primarily a developer.
A lot of game programming is tweaking parameters, which the blueprint systems provide in a click-and-drag UI rather than editing numbers in text files and recompiling.
I'm curious to hear other suggestions.
I'll admit a node based system is much more preferable for some systems, like UI or animation. But otherwise, I've yet to meet a technical person who prefers Blueprints over simply typing out the logic. There's a reason why there are several articles and videos out there dedicated to trying to organize "blueprint spaghetti" once our project scales up. It gets messy fast
I view it as equivalent to how Microsoft Excel empowers all sorts of non-programmers to solve problems via the use of formulas (and the occasional macro). As a tools programmer and producer I frequently discovered that some of our designers or writers had cobbled together their own solutions for difficult problems just using excel know-how. Excel teaches ordinary people that computers can do their bidding and visual programming for games does the same thing for game artists, writers, etc.
I’m a visual thinker myself, so I can’t imagine not thinking about code as a diagram. But it seems that from the way most tools are designed , this is not the majority view.
I don't really know why people consider visual programming easier than code once you know how to code I find visual programming very difficult to use or maintain a project of any moderate complexity. Theres no standardisation to visual programming either if you spend time learning one system for games and now want to make a website you now need to learn a whole new system and way of thinking about logic. If you spent all that time learning python then you would know python and could just do whatever you wanted.
I think its popularity comes mostly from fear of code, colourful icons look more approachable and easier to understand than a scary wall of text. I don't think it is easier to learn but I 100% recognise any time I have taught some one to code the number one hurdle is getting them over their fear of trying something new visual programming seems to do that well.
[1] It's a form of visual programming.
Do you know of any developers who otherwise use text-based tools and who switch to visual programming just when they work on games?
Personally, when using visual programming UIs, I instinctively look for some kind of “edit source” function. It just seems like a waste of time to use the mouse to browse through menus and constantly reorganize the board.
My guess is that visual programming is simply more approachable and more appealing than text-based programming when you’re just starting out and you’re intimidated by the unfamiliar conventions of coding. It’s easier to learn when the the language itself looks like the teaching tools (such as flowcharts). And I bet that more people start out by writing games than any other kind of software.
I try to avoid "writing code" when I'm making 3D things in unity until I absolutely have to. I like to work in a flow state and the context switching is murder on that. Then when I've blocked everything out and I know all the variables if needed I sit down and write specific modules if it's needed for performance or something was more difficult in a visual style. That is becoming increasingly rare though.
Games are usually heavily pre-allocated and work tends towards per frame computation operating on a pre-allocated state. Again, this leans into the functional style and thus an easy graphical style.
You can write behavior trees that run per frame without a lot of hidden state. You can write shader graphs as shaders also happen to be very functional in style.
It also helps that the field attracts very visual people by nature.
It's also a graphical field by nature. A console might make sense for some programs but a graphical interface with a built in graphical output makes more sense when you're operating on meshes and textures and such.
The problem are those people that write functions that take endless PgDn to go through, well in visual languages that kind of mess is quite obvious.
And that is, when later I talk with persons from gamedev, I hear nearly same thing form this ad, "I cannot answer your question, you are cool, but I have paws".
They are not bad people, they are extremely good in their sphere, but they are not programmers at all, and in many cases, they are fear real programming, those huge texts. Visual programming is just less fear for them.
When they got stuck, they asked people like me, who are between these two worlds.
This is important in games because iteration is so critical to success. Delegating high level logic to visual scripting can allow different people to focus on low level concerns like performance, so both problems can (hopefully) be iterated on in parallel.
If you can abstract that technical knowledge away from making the art, it can lower your costs. Plus, it becomes easier to hire programmers as they don't necessarily need skills in the visual arts or design.
It is a generalization, but the example is one that some 30+% of games will use . And it's not the only engine with visual programming; even Unity aquired Bolt (a very popular unity plugin for visual scripting) and will likely market that more and more as it's integrated into its engine.
You could also critically think your way to googling "game dev visual scripting" which would tell you much of the same information.
From a quick glance it reminds me of Unreal Niagara, or Unity Visual Effect Graph. Pretty cool.
You can even combine them - outputting values from the geometry nodes to be used by the shaders.
For example, in the case of Unreal Engine, gameplay programmers build the basic blocks via C++, and game designers can access them via Blueprint (Unreal Engine's visual programming tool).
If kids can do Redstone, and business people can do Excel, there's probably a lot more possibilities for average citizen programming.
From a programming perspective, this often leads to poor data access patterns and poor performance (walking over a scene graph and running arbitrary code for each object is not cache friendly at all).
Thankfully, Unreal really shines when you combine them both together: C++ and Blueprints. That's when things really start to click.
I think its great. We lost a lot of culture on the web when Flash was killed. Every site looks like the same sterile cookie cut bootstrap today.
I can't remember the last time a site pleasantly surprised me with a creative rendition.
I despise Apple and Adobe for it.
We have it in UE, Blender, Spark AR to name a few, which are mostly used by creatives who might not have much of a programming experience, to create amazing results.
Visual programming / executable diagrams are (usually, though it seems from mostly just-outside-the-market to ebb-and-flow over time) popular in business integration as well.
The biggest issue is that many devs don't want to pay for their tools, like in any other profession.
For those that pay, or have their employers pay, for their tooling,
This is the value prop -- and the problem -- with "no-code" tools in general. If your visual representation expresses behaviors in a way that is specific enough to be interpretable by a computer, then the constructs in your visual representation are isomorphic to constructs in some textual programming language -- with significant drawbacks compared to a textual programming language. But this zombie keeps getting resurrected because programming is seen as technical scutwork to be undertaken by highly intelligent yet socially inept lizard people -- not the truly important people, the business, marketing, and creative types who make all the key decisions. So if you want to get them to express what they want the computer to do, you will have to provide a means for them to do so that does not resemble using a text editor to write code in some programming language.
It's a bit like the modern version of the problem PC manufacturers had marketing to executives, despite the obvious advantages PCs would provide to them: PCs required typing, and executives considered to be secretarial or clerical work and therefore beneath them.
I think you are trying to say the blueprints in unreal were created to "hide" programming with a nice interface, and you could be right, but I suspect the reason they exists is a lot less thought out.
I suspect there are just some very talented engineers at Epic who really like visual programming and wanted to explore how powerful they can be. I think what they have created is amazing. Watching the flow of execution and the debugging really blows me away.
In the past I was sure that game engines were an impossible tool in the field of engineering where the performance matters so much. Clearly, I was wrong (in large part because of the hardware improvements).
Is visual programming really so popular in game programming, or is it being simply used for specific and particular tasks?
From what I see, nobody is using blueprint to outright program any games because it is too slow, hard to debug, and way too easy to get lost in visual spaghetti.
In context to visual effects, visual "scripting" does comes more into play, because you are doing something like video editing. In that context, you are already dealing with a list of visually identifiable options to achieve an outcome, so visual scripting is the next level up by controlling how the options are applied.
Everything is already setup for the person, it's a matter of what choices and to what degree. If you reduced this to a more primitive concept, we would be talking about which buttons to press and in what sequence. Yes, we often still define this type of interaction as programming, but there should be no illusions that this is more basic and limited. It has its place (visual programming), and clearly more so with artists (who are not programmers by trade), but you still have to do text based programming for the more advanced and creative stuff. Visual programming isn't taking over traditional text based programming, rather it's supplemental.