Ask HN: Why is visual programming so popular for game programming?

* makes the engine api very discoverable, which is huge. It’s a step above intellisense and auto complete. The api is likely the reason it’s so dominate in games. It’s the bulk of game programming. Visual programming isn’t very good for coding new things from scratch.

* let’s you read code and clearly follow execution from start to finish.

* let’s you visually document concepts with collapsed nodes, and colored containers and what not. Good blueprints are literally written as long form pseudo code, with double clicks to see actual implementation.

* concepts like const functions are just conceptually clearer. Const functions have no execution pin. They (should) have no side effects. Just a calculation. The engine doesn’t enforce this I don’t think but it’s close…

What it explicitly does not do is allow you to code games without knowing how to code. Countless beginners just die on the first steps. You still need to understand object oriented design and basic coding concepts to do well.

Everything you wrote is just as true for a well written text program, and untrue for badly written blueprint spaghetti!

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.

Lua is great and I'm a huge proponent of it but different tools are meant for different use cases.

I say that as someone who's worked on both sides and shipped production Lua, Unreal script and C++ during that era. Visual scripting/programming tools are for your designers/artists/animators or as glue code between content that is under high iteration cycles. You can do things such as "find all references to this actor" or realtime visualization of states that just aren't as streamlined as text based languages.

The tradeoff is there's a level of complexity where text based languages are better at expressing abstractions and structure, you use them in different contexts and for different parts of a project.

I can understand why you might want to use it for shaders. (but not really)

And when it comes to placing volumes and marking up the scene I'll absolutely want visual gizmos.

I genuinely believe that if Epic had taken all the effort they put into blueprints, and put it into a text based programming environment, game designers would be more productive.

Sure, that's pretty clear :). If you want to re-read my post above I wasn't saying that would be as good at game rules and there's a very real limitation as soon as you get away from scripted encounters and into anything more complex.

At the same time consider there may be people, teams and designers who it does work for. Very few things are in absolute and there are places where I've seen tools like this used effectively.

The only reason I commented at all was because the OP listed a bunch of stuff that was good in blueprints, but I believe all those things are good in text too.

update: just watched Tim Tillosons twitch stream about it. I had not seen that before.

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...

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!

Also: Blueprints reload instantly and are easy to debug.

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.

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.

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.

Monobehaviours in Unity alone can't show logic, they contain them, they're just components that don't describe an inherent execution order among themselves.

  1. He is comfortable tweaking parameters in a visual environment. This means he can iterate without me which is faster. He comes to me with a list of things he wants accomplish. I create a bunch of tools. He's off to the races.
  2. For certain problems it's faster for me to whip together some visual code using re-usable code-building-blocks I've written. For example, sequencing through a series of states for some moment in the game or reacting to a game event.
  3. He is familiar with finite state machines -- for example the entire animation system is built on them -- and can therefore make changes to the game without my input, say changing how the boss works in combat.
  4. Plus these changes don't require recompilation, which helps speed up iteration.

The flip side is that it's very easy to wind up with a huge pile of visual code spaghetti strewn across a dozen places, and it's impossible to refactor safely -- pretty serious issues ... but when you're just two people trying to scrape by and release something before flaming out, they're not at the top of my list!

[1]: Very out of date screenshots for those curious: https://store.steampowered.com/app/1446350/You_Will_Die_Here...

[2]: Plus contractors who help with the art, sound, marketing.

Removing the engineer from the content loops lets a lot of work happen really quickly.

For the logic, you get a table where every column is essentially a class, and each row is an if-then construct. The first column can be a condition, implicitly called once per frame, or an event with an optional condition. In each cell you can add actions that should be called on the instances of the class for its column. Everything is selected through simple dialogs.

For example, you'd make a condition/event like "Bullet collides with enemy", then add an action "Destroy" under "Bullet" and "Enemy" classes, something like "Play 'boom.wav'" under the "Sound" class, and "Add 1" to some "Counter" class. If I recall correctly that is.

This ended up getting me into programming, because I was able to quickly achieve results while being able to start experimenting with the UI before reading a single tutorial or any sort of document. I think discoverability is the killer feature. I could easily see that instead of destroying an entity, I could spawn another one. Or I could create an entity at the point of the collision, so I'd animate an explosion effect. But the explosion would just stay around, so I looked around what I could do... found an "Animation ended" event, so I simply made another rule that would destroy the explosion object when its animation ended. And so on.

I think another reason is that game logic is messy yet simple. So you don't want a lot of boilerplate code or having it scattered across lots of files, otherwise you're not getting a good overview. But I can't vouch for modern visual programming languages to solve that problem since I haven't really tried them.

A while later I accidentally stumbled over the BASIC interpreter of DOS and was amazed how easy everything was there - you could just store a number in a variable and directly do stuff depending on its value!

For anyone interested, here is a (bad quality) video from the 90ies explaining the software on Windows 3.1:

https://www.youtube.com/watch?v=LUTpumYboDs

It can be (usually is) far less intimidating than text-based coding. Compare:

- a text editor with a hello-world template script, a whole keyboard and now the engine yells at you because you (bravely) did something trivial to start, like adding a blank line in between "hello" and "world"

- a canvas with a big "add node" button which brings up a list of verbs and nouns organised into native-language categories

Asynchronous code can be hard to follow. Visual programming / node graphs are actually pretty good at representing complicated asynchronous logic.

I think this is pretty closely related to why diagrams / drawing / whiteboards are commonly cited as helpful by programmers.

I haven't used Unreal Blueprints. I have used Unreal (3, UDK) Kismet which is not particularly related (to Blueprints) other than the "Unreal" part, AFAIK. It was quite capable for most level design scripting logic, but was not ideal for implementing new mechanics for example. You could also copy nodes in/out as plaintext which I always appreciated as a feature I don't see very often.

Also, games programming is HIGHLY agile. Most of the logic you implement will be thrown away. It's all about rapid prototyping and finding what is "fun". Of course, once you've found something fun you might want to build it into a solid and scalable system, but even in such a system you might want to keep the flexibility for designers to extend and add new elements as they see fit (using visual scripting!). The ability for non-programmers to be able to make gameplay changes is also an important factor.

There, I've said it. Most 'games' are in fact interactive movies, with very little game in them. That's what Game Engines enable.

I'm vote we stop calling them Game Engines and instead call them Interactive Movie Engines.

> The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself,

This is and always was a Bad Idea, let me bring up a very simple example for you, a racing simulator. What sets apart an arcade from a realistic car driving sim? It's not really the graphics, or "gameplay", its the physics engine.

You might argue "oh that's just knobs on the physics engine" - maybe. But the way you handle the graphics, the whole game, even, hinges on how well you have tuned that engine. I don't care how many artists or designers you have - adding doodads to a realsitic racing sim isn't going to make it more fun. And if your arcade gameplay isn't spot on, no amount of "gameplay tweaks" is going to fix your jank arcade racing game.

Game Engines don't really make for building racing sims. They make Ok FPS or world exploration templates, but you kinda want to not even care about assets in these types of games - and they are all geared at creating assets spitting, 10000 collectible doodad dumping, absolute messes.

While I disagree with your argument about game engines being bad for games, you bring up an interesting point. Game engines are becoming cinematic movie engines.

Right now, they're a bit sub-standard. They shouldn't be built for consumer hardware at all, but rather live in the cloud where they have access to a lot of GPU compute for rendering.

The thing they get right is the reduction in film production complexity. Less going to set, less setting up lighting, cameras, etc. Easy tweaking in post, and an almost complete inversion of the production pipeline where directors, actors, and animators can work in lock-step with one another in fast iteration.

Unreal Engine is being stretched to do film things, but it's ultimately a local optimum. We're going to see a lot of new tools emerge in this space. (I'm building one!)

In the near future, films shot on cinema cameras and glass will be in the minority of visual media produced. It's just too time consuming. It'll become an artisanal pastime that directors like Wes Anderson remain attracted to.

The really interesting thing will be what happens to studios like Disney and Netflix that bank on in-house content and IP. Once media is no longer expensive and kids at home are making Star Wars of their own, the linear content moat is gone. Franchises and major IP will probably move to difficult-to-produce (for now) mediums, such as games, since films will turn into something more closely resembling novels - a huge basket of works, a wide distribution of quality, and a very long tail of interests that are catered to.

The next decade is going to be a wild ride.

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.

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.

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 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.

  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.

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 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?

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.

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.

[1] It's a form of visual programming.

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.

Games are usually heavily pre-allocated and work tends towards per frame computation operating on a pre-allocated state. Again, this leans into the functional style and thus an easy graphical style.

You can write behavior trees that run per frame without a lot of hidden state. You can write shader graphs as shaders also happen to be very functional in style.

It also helps that the field attracts very visual people by nature.

It's also a graphical field by nature. A console might make sense for some programs but a graphical interface with a built in graphical output makes more sense when you're operating on meshes and textures and such.

The problem are those people that write functions that take endless PgDn to go through, well in visual languages that kind of mess is quite obvious.

Thankfully, Unreal really shines when you combine them both together: C++ and Blueprints. That's when things really start to click.

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.

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.

[0]: https://www.youtube.com/watch?v=UMk963QdShA

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

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).

You could also critically think your way to googling "game dev visual scripting" which would tell you much of the same information.

From a quick glance it reminds me of Unreal Niagara, or Unity Visual Effect Graph. Pretty cool.

You can even combine them - outputting values from the geometry nodes to be used by the shaders.

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.

If kids can do Redstone, and business people can do Excel, there's probably a lot more possibilities for average citizen programming.

From a programming perspective, this often leads to poor data access patterns and poor performance (walking over a scene graph and running arbitrary code for each object is not cache friendly at all).

The biggest issue is that many devs don't want to pay for their tools, like in any other profession.

Game design - especially in 3D environments - is an incredibly visual process!

Unless you are incredibly familiar with programming to start - why, if you were approaching game design, and - for instance - had level layouts, character and enemy designs, etc - prepared in advance - wouldn't you?

It's literally the most logical way to approach filling in those gaps with functionality with a visual system of design like that.

Game Design is not visual at all, it's pure logic. "when I pull the trigger, find the thing I am pointing at, if it has armor, reduces its health by 10, otherwise reduce its health by 20"

Game Art is all visual. Red is scary, green is good, sort of.

They are completely separate paradigms.

I 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 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.

This is the value prop -- and the problem -- with "no-code" tools in general. If your visual representation expresses behaviors in a way that is specific enough to be interpretable by a computer, then the constructs in your visual representation are isomorphic to constructs in some textual programming language -- with significant drawbacks compared to a textual programming language. But this zombie keeps getting resurrected because programming is seen as technical scutwork to be undertaken by highly intelligent yet socially inept lizard people -- not the truly important people, the business, marketing, and creative types who make all the key decisions. So if you want to get them to express what they want the computer to do, you will have to provide a means for them to do so that does not resemble using a text editor to write code in some programming language.

It's a bit like the modern version of the problem PC manufacturers had marketing to executives, despite the obvious advantages PCs would provide to them: PCs required typing, and executives considered to be secretarial or clerical work and therefore beneath them.

I think you are trying to say the blueprints in unreal were created to "hide" programming with a nice interface, and you could be right, but I suspect the reason they exists is a lot less thought out.

I suspect there are just some very talented engineers at Epic who really like visual programming and wanted to explore how powerful they can be. I think what they have created is amazing. Watching the flow of execution and the debugging really blows me away.

In the past I was sure that game engines were an impossible tool in the field of engineering where the performance matters so much. Clearly, I was wrong (in large part because of the hardware improvements).