Ask HN: Why is visual programming so popular for game programming?
154 comments
I’m a huge fan of blueprints. A few things it does well:
* 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.
* 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.
I think you are only a huge fan of blueprints because they is no alternatives in Unreal. I think if you could compare an Unreal Lua integration to Blueprints you would reach for Lua every time.
Everything you wrote is just as true for a well written text program, and untrue for badly written blueprint spaghetti!
Everything you wrote is just as true for a well written text program, and untrue for badly written blueprint spaghetti!
We used to have UnrealScript and 9/10 our designers still reached for Kismet instead.
Lua is great and I'm a huge proponent of it but different tools are meant for different use cases.
Lua is great and I'm a huge proponent of it but different tools are meant for different use cases.
UnrealScript had problems, that why they dropped it 10 years ago.
Sure but as far as scripting languages go it was enough to get the job done at the time. I don't think swapping to Lua would fundamentally change that.
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 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'm also in the industry as an artist, level designer and gameplay programmer and have shipped games in Unreal 2, 3 and 4 and Unity, and you'll never convince me that creating boxes and wiring them up will ever be as good as text at expressing game logic and game rules.
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.
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.
> ... and you'll never convince me that creating boxes and wiring them up will ever be as good as text at expressing game logic and game rules.
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.
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.
Sure.. I'm with ya.
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.
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.
And is kind of what they’re doing now with their Verse language.
Yep, I'm looking forward to it. Have they publicly talked more about it since 2020?
update: just watched Tim Tillosons twitch stream about it. I had not seen that before.
update: just watched Tim Tillosons twitch stream about it. I had not seen that before.
There is confirmation its coming this year(2022). They previously stated they wanted to release beta late 2021 but got delayed.
I think it'll be a massive game changer for unreal and am super excited for it.
I think it'll be a massive game changer for unreal and am super excited for it.
It's funny, I am having a blast fiddling around with UT99 and UnrealScript (thanks in no small part to the source code that you can find if you look around on github), but at my very basic level the only real issue I've encountered is the lack of good editor support.
There certainly are alternatives in Unreal. You can implement everything (and far more) in C++ without ever needing to use blueprints.
Compiling C++ is not a alternative to a game scripting language. Unreal doesn't provide first party support for any other form of scripting.
> I think you are only a huge fan of blueprints because they is no alternatives in Unreal.
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...
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...
Ok, I will revise my statement to read "You are only a huge fan of blueprints because the only alternative is c++"
It barely provides human-time-scale compilation!
I have been using lua a lot recently and it fucking sucks lol. The language itself is tiny and great don't get me wrong and also you can't do anything with it. What you'll need to figure out instead is whatever jank ass mutation-heavy api someone half-accidentally exposed to it from the real stack. And of course it'll be a modified lua 5.1 or some shit, possibly with some of its most powerful and flexible features stripped out.
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.
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.
I find some parts of Lua quite ugly and weird. It _is_ weird to have a lists a dictionary be the same thing, but you have access them differently, pairs() and ipairs() etc ect.
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.
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.
I really don't get why this is being downvoted, you cannot rely on blueprints alone. If you've ever shipped a game ( and I've invited oneoff786 to share any titles he has released in the past) before. Blueprint simply is not a replacement for programmatic text.
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!
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!
You can absolutely ship a game with blueprints. The performance drop is relatively minor. There are some things that are impossible to do in blueprints, but many games will not need them, or can just handle that small % in c++, which is what I do. Specifically I refer to complicated rpc stuff.
> 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?
> 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?
victorbstan(1)
Despite limitations, if you can find ways to simply tolerate these techniques, you will find that you then automatically empower others on your team.
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 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 would love it if they released Verse, but no, I love blueprints. The discoverability is so key for new learners. The impossibility of syntax errors is nice. It’s relaxing to code in bp.
Same with industrial control ladder logic. It literally is a language based on old ladder electrical control diagrams which were popular for industrial machinery. They were easy to follow as the logic sequence went from top to bottom. The rungs are a circuit and the vertical bars are the hot and return lines of the control power supply.
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.
|----||----||----()
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.
That’s a really interesting comment, thanks. It always seems like UE’s Blueprints are a victim of poorly-informed expectations. Hearing the additional context here is hugely helpful.
It’s in no small part because they are marketed as something that you don’t need to be able to code with. But there’s a big gap between no code solutions like website builders and blueprints. Blueprints involve a lot of coding familiarity.
Let me add one more big thing: With Blueprint, the engine team can check-in binaries into Perforce and the rest of the team can use those custom binaries and their custom APIs in Blueprint without ever having to touch a compiler.
Also: Blueprints reload instantly and are easy to debug.
Also: Blueprints reload instantly and are easy to debug.
Can you diff them?
Yes. Sorta.
Unreal has a blueprint diffing tool to compare against different commits.
Its a frequently overlooked feature. Itd be great to have more accessible outside the editor.
Its a frequently overlooked feature. Itd be great to have more accessible outside the editor.
Perforce usually does check out check in precisely because artists hate diffs.
No. Which is very frustrating, because bp seem to be storeable as a json sort of thing which you can copy paste into text, but gets saved to get as a binary thing.
On the larger game teams I've worked on, most people using blueprints and schematics aren't the programmers but the content creators. The programmers are providing said blueprint elements/building blocks as well as extending (or modifying) the engine with other logic that content creators don't need access to via their visual tools.
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.
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.
To build on this, those parameters that are exposed require a ton of tuning, more tuning and retuning. As a game programmer, exposing those numbers to someone who cares a lot about it and whose job it is to monkey with them frees them up to iterate without you in the loop. They get better results (because more iterations) and you are out of the loop so you can work on teh next thing. This is vital because, unlike accounting software, there is no "right answer" to arrive at.
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.
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.
Yep, and Kismet before that. The usual consumers are designers and tech artists, at least in the teams I was on.
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.
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.
This explains why there's a simplified scripting layer but not why it's a graph based programming language. Unity has an example of configurable game objects without graphs but still the momentum is towards graph based systems in many places.
Graphs show logic flow. It's as simple as that.
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.
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.
I'm working on a survival horror action RPG^1 with a friend. We're two people^2. At a high level, I write the code, he does the art. I use visual scripting a lot. Here's why:
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.
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.
Beacuse you can expose functionality to non-programmers and let them go HAM with the components you have created. I'm constantly amazed at what artists and animators and producers can do themselves if given half the chance. Plenty of people have the "engineering Tao" but not the training for traditional programming.
Removing the engineer from the content loops lets a lot of work happen really quickly.
Removing the engineer from the content loops lets a lot of work happen really quickly.
What type of games are we talking about here though? Removing the engineers from the loop potentially allows for a lot of rapid prototyping, but probably not a lot of shipping at perf on cross-gen console and PC architecture.
What's built in these things are quite often of 2 kinds:
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).
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).
Every AAA is built like this
A proven by Minecraft, Angry Birds among others, you don't need a last gen perf game to pay the bills and get comfortable.
It's an exceedingly popular way of writing materials/shaders in 3D content tools -- I'd guess more so than any game programming/logic (of course big game engines tend to have visual shader tools as well)
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.
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.
With the availability of game engines, gameplay programming is actually very high-level. Most of the logic is handling some input or some collision or updating some position or timer every frame. The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself, so the games programmer usually only need to interface with the high-level API of these systems.
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.
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.
Game Engines Suck.
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.
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.
> There, I've said it. Most 'games' are in fact interactive movies, with very little game in them. That's what Game Engines enable.
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.
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.
This seems backwards to me, since live action film is a lot more expensive than CGI animation. It's true that high-quality cameras and video editing software have become more of a cheap commodity, but this does almost nothing to impact the actual factors that push the cost of live action film up. Look at what people post on video sites, that's a far better representation of what's actually "cheap" in video.
> While I disagree with your argument about game engines being bad for games
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?
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?
If you can use a Domain Specific Language (DSL) for a task, or in this case a Domain Specific Modelling Language (DSML), why wouldn't you use one?
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.
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.
Well sure, but the question is why are graphical languages the DSL of choice?
I think they make the restrictions of pure functional programming more intuitive to deal with. Working in blueprint is basically like working in Haskell, but anyone who spends 5 minutes learning the ropes in blueprint can immediately be productive. Contrast to Haskell where programmers need to almost have their brains restructured to work within the confinements of pure programming and be productive.
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.
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.
I’ve been trying to clarify my own opinion on this in words for awhile now and what you’ve written is pretty much what I think too.
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 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 stuff that I know could be better expressed with a visual graph or say, an animation curve.
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?
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?
And visual editors for DSLs are also easier to implement with libraries like Blockly, because the user is editing the AST directly, there's no parsing step. Also, you can make it much more obvious where things are invalid.
> why wouldn't you use one?
Mental overhead
Mental overhead
Just because Unreal does it doesn’t mean it’s “popular”. I’m not familiar with any other game engine that has something like this as a first class feature.
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.
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.
> "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."
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 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)
Not many game engines are well documented so there's more than a few out there that do this. One that I worked on used Maya DAG extensively for similar features(although it made it fun to fight over the floating licenses sometimes).
FWIW, it’s heavily used in Blender as well.
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.
Accessibility. For newer developers, it puts the component parts in front of you as visual objects you can manipulate, instead of relying on you memorizing keywords (or knowing enough about syntax to leverage things like IntelliSense). For design teams, it lets people who have less or no code experience - writers, artists, mechanical designers - safely manipulate parts of complex game logic for balance and feel.
Before I learned how to program, I used this software called "Klik&Play", later replaced by "Multimedia Fusion". This was over 20 years ago, but apparently the software still exists and works in a similar way:
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.
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.
Ha, I also started with programming using Klik&Play when I was around 9! I only had the free shareware version, and if I recall correctly, it was not possible to use custom variables or if/then/else constructs in the free version. You had to be creative to somehow store the game state using only the position of objects, and then using collisions to decide on an action. Since you could spawn objects at arbitrary locations, you could use this to do primitive geometrical if/then/else branching. I also remember that you could generate a single exe file which you could give to your friends. I created so many DynaBlaster clones and other Jump&Run games.
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:
https://www.youtube.com/watch?v=LUTpumYboDs
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:
https://www.youtube.com/watch?v=LUTpumYboDs
GameMaker (version 4… in 2001, man I’m getting old) had a similar system. It’s also what got me into programming, as I could also attach my own scripts to event triggers (and sets of event triggers, in a linear visual GUI logic way), and so I learned GML as my first programming language.
Klik&Play was awesome. Must have made at least 30 dumb games with it when I was around 12-13.
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.
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.
Ease of use.
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. :\
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. :\
For me, someone who wanted to build a NES Dragon Warrior or Final Fantasy clone back in the early 90's and had no idea how games were even made, let alone owned a computer, the idea today that I can show my kids they can build a game without them needing to fully understand how to code is mind blowing.
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 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 its only because Unreal has one, and everybody wants to be like Unreal.
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 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 rarely see a piece of art that is 'new' or interesting - if you check out an art forum, you see a lot of duplication, similar motifs. Nobody has innovated with art in a very, very long time.
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.
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.
I rather have people giving me their architecture documents in UML than incomprehensible prose.
This isn't about architecture so much as implementation, though. Would you prefer to look at a sequence diagram there, or actual code?
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.
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.
Why the heck wouldn't it be?
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 - 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.
I love this answer. . .
There is really something to be said about context. Thank you for your this!!
That answer would make only make sense if you did the programming in the 3d scene.
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.
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.
Uhh…this comes from an insanely programmer-biased perspective.
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.
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.
I do think the because it is 3d is an oversimplification but to me it is valid.
Of course design is a lot of logic, but that isn't the only place the fun lives. Most of the fun is in the visual enviroment.
Many people working on games have graphic design backgrounds rather than programming, so they're more comfortable with it.
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.
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.
Even for me as a programmer, waiting for a lengthy compile cycle in order to test something like a simple logical change is pretty painful. Game programming is overwhelmingly done in low-level languages like C++/Rust which have awful compilation performance and very limited hot-reloading support.
scripting languages can similarly solve that too. OP is asking why they use visual programming instead.
Because many people getting into game development aren't technical people. And Epic and other engines are more than happy to sell the pitch of "Make your dream video game without any coding!" (nevermind that visual programming is STILL programming, but I digress)
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'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
Programming is hard, and there's a market for making it easier. Visual programming has a quick on-ramp (albeit a low ceiling).
The simplest way I can put it is that visual programming in games lets non-programmers meaningfully contribute to code-adjacent and 'code' parts of game content, like pixel shaders or character AI or simple object behaviors. These parts are typically not so performance critical or complex that you need a programmer to do them by hand, and more importantly, if you empower the game designer or artist to fiddle with them directly, they can quickly iterate until they hit something that is nearly perfect. At that point if there's something wrong with it, you can hand it off to a programmer to fix.
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 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.
A counter question to programmers in other fields - do you visualise the structure of code in your head almost like a graph, or do you think in code blocks? I feel like more visual thinkers would naturally also be drawn to games.
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’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.
First you need to define what 'visualise' means, as an aphantasian programmer I can't visualise anything. What does thinking in code blocks mean? I can mentally hold stuff, but it's certainly not visual. Feynman[0] has a good video going through this.
[0]: https://www.youtube.com/watch?v=UMk963QdShA
[0]: https://www.youtube.com/watch?v=UMk963QdShA
Depends on the context! I think in terms of state machines for state, reactive code is a dependency graph, object graphs for OOP architecture.
Visual programming is generally considered easier to learn and there are lots of people who can't code who want to make games.
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.
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.
If you want a hands on answer OP, download Blender and follow the donut tutorial on YouTube. As a software engineer with 10+ years of experience, the geometry nodes in Blender just make sense[1]. The comparison here is your are creating a 3D object from scratch, just like a game designer would create a 3D scene from scratch.
[1] It's a form of visual programming.
[1] It's a form of visual programming.
Blender nodes are pretty much the same as Unreal Blueprint. The differences are smalll enough to not matter for the purposes of this discussion.
How do you know it’s so popular? And popular with who?
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.
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.
[deleted]
I've used a lot of Playmaker with Unity3D. I'm a programmer who works in NUI and I make visual art with Unity and blender but my day job is mostly python and go. I've taught 3D artists and people who were not programmers to use Playmaker to get things made in Unity and they take to it quick.
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.
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.
Graphs fit well with functional code styles. Art and games have a lot of places where a functional style makes sense.
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.
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.
What seems to help is that Epic came up with a modular blueprint system. Blender used to have a game engine, with blocks connected via wires, but the entire game was in one giant diagram. Epic blueprints tend to be of modest size.
Nothing new in that regard, I was doing modular digital circuit design already in Windows 3.1 based simulation software.
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.
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.
My take is that game studios have a lot of "designers" who need to express a lot of basic scripting logic but may not be familiar with traditional programming. So graphical nodes may be more accessible for them
Few months ago, in Ukraine run virus ad, where the cat asks to salesman, how he could buy in their shop, as he has not hands, he said "I have paws!"
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.
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.
Blueprints, or node graphs more generally, allow people to encode programmatic logic without needing to learn the syntax of a programming language. If they can read a flow chart, they can implement simple (or not simple) functionality without the perceived technical hurdle of "learning to code."
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.
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.
I think part if it stems from how multidisciplinary a game studio can be. In my experience, visual programming languages allow people with minimal programming experience (artists, designers, etc) to implement ideas. Im willing to bet onboarding someone with a visual language like Unreal’s blueprints is a much better time than trying to teach them C++. I also find prototyping, especially collaborative prototyping, to be easier with visual languages; its easier to “follow the fun” when all it takes is a drag-and-drop to change some logic.
Computer programmers are relatively expensive to hire, especially ones that have specialized knowledge about making games (eg: deferred rendering, ECS gameplay patterns, network topology models, etc.). There's generally a minimum amount of technical knowledge to create the sort of art you're looking for.
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.
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.
Visual programming have the advantage to be more approachable to non-programmers. In the gaming industry, you need a tone of small event reactions and logics to make great game. If you push all of those needs to a separate programmer team, you add complexity to your production and lower your agility. Given live editing supported, code will always be more efficient for programmers but getting all the talents (design, level design…) that are also fluent programmers may be unrealistic at scale.
Is it? You make a generalization giving just one example: Unreal Blueprints.
As somebody not familiar with game programming but familiar with critical thiking I am unconvinced.
It is extremely popular. From Flowgraph in CryEngine to Godot's VisualScript. Even Unity bought the most popular visual scripting asset package, Bolt, and made it standard for all Unity plans.
You could also critically think your way to googling "game dev visual scripting" which would tell you much of the same information.
You could also critically think your way to googling "game dev visual scripting" which would tell you much of the same information.
Also in game-engine adjacent spaces blender, and Houdini have similar visual languages.
Oh nice, I didn't realize Blender had a visual scripting system. I knew that they had a Python API like Maya, but the visual stuff is a nice feature to have for art teams. I keep telling myself I'm going to force myself to learn Blender one day. It seems to have really matured over the years.
From a quick glance it reminds me of Unreal Niagara, or Unity Visual Effect Graph. Pretty cool.
From a quick glance it reminds me of Unreal Niagara, or Unity Visual Effect Graph. Pretty cool.
[deleted]
It has a couple, one for writing shaders and another for manipulating geometry.
You can even combine them - outputting values from the geometry nodes to be used by the shaders.
You can even combine them - outputting values from the geometry nodes to be used by the shaders.
Houdini is also pretty popular. Just another example I'm familiar with, as a non-game dev.
Unreal is one of the most popular engines out there, and they push blueprints extremely hard, to the point where it's actually somewhat difficult to search up c++ tutorials (and the documentation of UE4 isn't the best once you dig past the basics).
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.
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.
I'm not sure if it's really that popular but Visual Programming gives the ability for designers to quickly implement their ideas without having to ask and waiting for a programmer to implement them via code.
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).
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).
I remember hearing that studies have shown that the biggest impediment to absolute beginner programmers is the strictness of language syntax. Visual programming makes syntax errors impossible, and that's a huge benefit to those who don't have programming experience. (This was the whole motivation underlying Scratch's visual programming language, by the way.)
I really wish someone would invent something like Excel but with Scratch for the macros and functions. I'm pretty convinced average non coders can do quite a bit of programming with the right tools.
If kids can do Redstone, and business people can do Excel, there's probably a lot more possibilities for average citizen programming.
If kids can do Redstone, and business people can do Excel, there's probably a lot more possibilities for average citizen programming.
Developer GUI is a practical necessity for building 3D scenes, unlike 2D. Many of those GUIs were extended to add support for OOP scripting.
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).
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).
[deleted]
Blueprints is okay until you start to reach some branching or conditionals. You can always compartmentalize things into Blueprint functions, but Blueprints do have some limitations.
Thankfully, Unreal really shines when you combine them both together: C++ and Blueprints. That's when things really start to click.
Thankfully, Unreal really shines when you combine them both together: C++ and Blueprints. That's when things really start to click.
Simple, it appeals to a demographic with an interest in gaming but not coding.
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.
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.
Simple: it allows non-programmers to program to some extent, which is enough for many of the basic tasks.
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.
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.
> Why is visual programming so popular for game programming compared to other domains?
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.
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.
Because gamers are naturally visual creatures. People who create games these days usually are gamers who enjoy games. and so that visual stimulation and visual way of playing, learning probably carries across, at least for the beginners.
Because games are visual. It is a shame that so much of programming is still through text files. Web programming for example should be completely done visually.
Here for you, https://www.outsystems.com
The biggest issue is that many devs don't want to pay for their tools, like in any other profession.
The biggest issue is that many devs don't want to pay for their tools, like in any other profession.
My speculation is that because game industry know to design better UI patterns, they simply made better visual programming languages.
This makes sense, it’s like if all web development were done in the canvas or webgl and there wasn’t CSS then front end engineers would have built more tooling.
They did, but then the FOSS movement took them away without proper replacements.
For those that pay, or have their employers pay, for their tooling,
https://www.outsystems.com
https://webflow.com
https://playcanvas.com
https://www.adobe.com/products/animate.html
For those that pay, or have their employers pay, for their tooling,
https://www.outsystems.com
https://webflow.com
https://playcanvas.com
https://www.adobe.com/products/animate.html
Technical artists.
It helps people who don't identify as programmers/developers program without thinking they're programming.
Whether you identify as a programmer or not should not prevent you from having a good tool for the work. Even the very polished Blueprints in Unreal are not as good as a text based programming.
I agree with you. But the "content creators" who are responsible for most of modern game development will flee in horror from anything that looks too much like programming. If you want to market a game engine with customizable behavior (i.e., it's programmable) to large AAA game dev teams where programmers are only a small subset of the whole team, you have to provide a way to allow people to program the engine without believing they are programming it.
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.
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 don't know who these "content creators" are that flee from programming, but I have never met or even heard of one. If you mean writers and artists, then sure, but you don't want them working on your game logic anyhow. If you can understand what is going on in visual code, you can understand what is going on in text code.
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.
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.
I bet there are a couple of talks on the subject at GDC Vault, so they are relatively easy to find out.
Visual is good for prototyping for production I'll go for traditional approach
It gives more power to artists to tweak things in engine.
i hate visual programing if i am the customer. slow, crashes, buggy. the lower the code, the better tbe program, but obviously harder.
Not sure what any of those complaints have to do with visual programming. BPs are pretty fast, and efficient BPs will be faster than inefficient C++ for example. Crashes and bugs are hardly unique to visual programming either.
I think he means BP are very slow to create, and hard to read and navigate
No, I think he means that the product of visual programming is often slow and buggy. Which I can agree with to a point - there is a price to pay for all these abstractions. From my own experience - the closer to the metal a product, the more performant and stable it is.
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).
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).
question is why isn't visual programming more popular amongst "traditional" or non-gamedev programming?
to make it possible for non-coding designers and artists to build games.
> Why is visual programming so popular for game programming compared to other domains...
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.
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.
It's mainly because of the history of VFX tools and pipelines. A lot of game studios adopted tools from ILM and Pixar. One of the first notable presentation on compositing must be from the 1984 SIGGRAPH held by Porter and Duff. They both went and implemented a node based workflow through the whole pipeline at ILM and later at Pixar. Visual Programming also is a lower barrier of entry, at VFX and Game Studios artist need to proficient in the underlying architecture to get optimal performance and visual fidelity it's easier to give them tools like node base shaders or blueprints instead of code. Most visual programming is also realtime which makes it a lot easier to understand for non programmers.
https://keithp.com/~keithp/porterduff/p253-porter.pdf
https://keithp.com/~keithp/porterduff/p253-porter.pdf
Because non-programmers can make games. Let's face it, for many games assets are 90% of the work and the programming is pretty simple. Hell, lots of games produced today would have been considered an engine 'mod' 20 years ago.
For example Unreal Blueprints
What is it about them that makes it so popular?