For example Unreal Blueprints
What is it about them that makes it so popular?
* makes the engine api very discoverable, which is huge. It’s a step above intellisense and auto complete. The api is likely the reason it’s so dominate in games. It’s the bulk of game programming. Visual programming isn’t very good for coding new things from scratch.
* let’s you read code and clearly follow execution from start to finish.
* let’s you visually document concepts with collapsed nodes, and colored containers and what not. Good blueprints are literally written as long form pseudo code, with double clicks to see actual implementation.
* concepts like const functions are just conceptually clearer. Const functions have no execution pin. They (should) have no side effects. Just a calculation. The engine doesn’t enforce this I don’t think but it’s close…
What it explicitly does not do is allow you to code games without knowing how to code. Countless beginners just die on the first steps. You still need to understand object oriented design and basic coding concepts to do well.
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.
1. He is comfortable tweaking parameters in a visual environment. This means he can iterate without me which is faster. He comes to me with a list of things he wants accomplish. I create a bunch of tools. He's off to the races.
2. For certain problems it's faster for me to whip together some visual code using re-usable code-building-blocks I've written. For example, sequencing through a series of states for some moment in the game or reacting to a game event.
3. He is familiar with finite state machines -- for example the entire animation system is built on them -- and can therefore make changes to the game without my input, say changing how the boss works in combat.
4. Plus these changes don't require recompilation, which helps speed up iteration.
The flip side is that it's very easy to wind up with a huge pile of visual code spaghetti strewn across a dozen places, and it's impossible to refactor safely -- pretty serious issues ... but when you're just two people trying to scrape by and release something before flaming out, they're not at the top of my list!
[1]: Very out of date screenshots for those curious: https://store.steampowered.com/app/1446350/You_Will_Die_Here...
[2]: Plus contractors who help with the art, sound, marketing.
Removing the engineer from the content loops lets a lot of work happen really quickly.
It can be (usually is) far less intimidating than text-based coding. Compare:
- a text editor with a hello-world template script, a whole keyboard and now the engine yells at you because you (bravely) did something trivial to start, like adding a blank line in between "hello" and "world"
- a canvas with a big "add node" button which brings up a list of verbs and nouns organised into native-language categories
Asynchronous code can be hard to follow. Visual programming / node graphs are actually pretty good at representing complicated asynchronous logic.
I think this is pretty closely related to why diagrams / drawing / whiteboards are commonly cited as helpful by programmers.
I haven't used Unreal Blueprints. I have used Unreal (3, UDK) Kismet which is not particularly related (to Blueprints) other than the "Unreal" part, AFAIK. It was quite capable for most level design scripting logic, but was not ideal for implementing new mechanics for example. You could also copy nodes in/out as plaintext which I always appreciated as a feature I don't see very often.
Also, games programming is HIGHLY agile. Most of the logic you implement will be thrown away. It's all about rapid prototyping and finding what is "fun". Of course, once you've found something fun you might want to build it into a solid and scalable system, but even in such a system you might want to keep the flexibility for designers to extend and add new elements as they see fit (using visual scripting!). The ability for non-programmers to be able to make gameplay changes is also an important factor.
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.
The reason blueprints exist in UE is because they needed a way to allow non-expert programmers on the team to write code that isn’t C++, but they didn’t want to use a high level scripting language like Lua.
IIRC, Sweeney said (on Twitter) that in the past, it was a burden to constantly be designing and maintaining language bindings for scripts, especially with a rapidly changing engine.
Also, (I’m guessing here), blueprints result in less bugs since it provides static typing and makes it possible to do some advanced visual debugging. These are things that, even if they were available in a language like Lua, they would be intimidating and/or uncomfortable for the artists/non-programmers on a team. Plus I’d imagine that it’s relatively easy to produce some highly optimized code from blueprints, maybe even compile it to native instructions.
It’s also probably no coincidence that the visual node-based concept is used a lot in other tools used primarily by artists, like for material creation.
Why isn't visual programning more popular?
The problem is the complexity of overlaid graphs. Text, through references, handles this well and planar layouts do not.
Consider also the density of information; an example is a (visual) AST of an arithmetic expreasion, versus the conventional symbolic representation. You could make a visual tool to build arithmetic trees. It's a very clear repreaentation, easy to follow and would be fun to use. But... real fast... it becomes unweildy.
So, visual programming is great for simple problems, by non-programmers. As other commenters have said, there are a lot of non-programmers in game development - I think most of it is non-programming these days.
Another category is new users. People play games, and then want to make games. Visual programming is more like a game than text programming is. Some of these people really are just "playing" at making games (nothing wrong with that!) But some of them are earnestly making a game - and the fewer obstacles in their way (like learning how to program), the better. Get them onboard, get them started - better for them, better for Epic, and better for the world to get the games they've come up with.
Finally, because of text superiority, programming infrastructure (e.g. git) is also text-based.
BTW spreadsheets are kinda visual, and very popular. "Visual Basic" has some visual programming elements, for GUIs. There's some business tools, like XML mappers, that are visual.
For the logic, you get a table where every column is essentially a class, and each row is an if-then construct. The first column can be a condition, implicitly called once per frame, or an event with an optional condition. In each cell you can add actions that should be called on the instances of the class for its column. Everything is selected through simple dialogs.
For example, you'd make a condition/event like "Bullet collides with enemy", then add an action "Destroy" under "Bullet" and "Enemy" classes, something like "Play 'boom.wav'" under the "Sound" class, and "Add 1" to some "Counter" class. If I recall correctly that is.
This ended up getting me into programming, because I was able to quickly achieve results while being able to start experimenting with the UI before reading a single tutorial or any sort of document. I think discoverability is the killer feature. I could easily see that instead of destroying an entity, I could spawn another one. Or I could create an entity at the point of the collision, so I'd animate an explosion effect. But the explosion would just stay around, so I looked around what I could do... found an "Animation ended" event, so I simply made another rule that would destroy the explosion object when its animation ended. And so on.
I think another reason is that game logic is messy yet simple. So you don't want a lot of boilerplate code or having it scattered across lots of files, otherwise you're not getting a good overview. But I can't vouch for modern visual programming languages to solve that problem since I haven't really tried them.
It's just another tool in the toolbox. Epic has mentioned how a portion of Fortnite was built using Blueprints. It helped them to prototype features and get the game built quickly.
Think about how handy it is to have a diagram, picture, or plan before writing a single line of code. Epic takes sections made using Blueprints and rewrites them in C++ for better performance.
After using Blueprints for a bit I can see its merit and why it's useful.
Unfortunately, I can't find the source where Epic talked about this. I think it was a GDC talk but I could be wrong. :\
I think that's really why it's so popular: "anyone" with an idea can sit down and cobble something together that looks like a video game. A lot of people will give up when they realize you need to know more than "drag and drop" to customize your game, but it allows a lot of people with game dreams to dive in who would otherwise simply never try because they don't know anything about programming.
Now where did I put those maps to my Fantasy Dragon Quester 2-d jrpg game?
I think Lua in Roblox, or the Godot's python like language, or Unity's C# is strictly better in every way.
Visual Programming languages don't prevent "non programmers" from writing really weird code that makes no sense.
You will find many first time programmers that like visaul programming because they created something cool in Unreal. I think if there was a Lua integration they would have achieved more, faster.
We use words to communicate our thoughts in comments on Hacker News. What would our communication be like if we only had flow charts you could plug variables into?
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.
A lot of game programming is tweaking parameters, which the blueprint systems provide in a click-and-drag UI rather than editing numbers in text files and recompiling.
I'm curious to hear other suggestions.
I'll admit a node based system is much more preferable for some systems, like UI or animation. But otherwise, I've yet to meet a technical person who prefers Blueprints over simply typing out the logic. There's a reason why there are several articles and videos out there dedicated to trying to organize "blueprint spaghetti" once our project scales up. It gets messy fast
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.
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 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’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.
[1] It's a form of visual programming.
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.
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.
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.
And that is, when later I talk with persons from gamedev, I hear nearly same thing form this ad, "I cannot answer your question, you are cool, but I have paws".
They are not bad people, they are extremely good in their sphere, but they are not programmers at all, and in many cases, they are fear real programming, those huge texts. Visual programming is just less fear for them.
When they got stuck, they asked people like me, who are between these two worlds.
This is important in games because iteration is so critical to success. Delegating high level logic to visual scripting can allow different people to focus on low level concerns like performance, so both problems can (hopefully) be iterated on in parallel.
If you can abstract that technical knowledge away from making the art, it can lower your costs. Plus, it becomes easier to hire programmers as they don't necessarily need skills in the visual arts or design.
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).
From a programming perspective, this often leads to poor data access patterns and poor performance (walking over a scene graph and running arbitrary code for each object is not cache friendly at all).
Thankfully, Unreal really shines when you combine them both together: C++ and Blueprints. That's when things really start to click.
I think its great. We lost a lot of culture on the web when Flash was killed. Every site looks like the same sterile cookie cut bootstrap today.
I can't remember the last time a site pleasantly surprised me with a creative rendition.
I despise Apple and Adobe for it.
We have it in UE, Blender, Spark AR to name a few, which are mostly used by creatives who might not have much of a programming experience, to create amazing results.
Visual programming / executable diagrams are (usually, though it seems from mostly just-outside-the-market to ebb-and-flow over time) popular in business integration as well.