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

I hate coding animations in CSS, but I enjoy watching them in e.g. devtools. I really wish I could see the representation of my code visually more often. Immediate mode UIs are sort of like this, but I've rarely seen tools which actually show while coding.

We unit test (or try to) every new feature, why shouldn't we be able to visualize them too?

So I believe the plan is to trick the content creators and less strong programmers into using a purely functional programming language so that they produce less bugs.

Anyway that's my take on it, I only made a few demo games in blueprint and really enjoyed it, I haven't used it in anger so to say so someone who's actually in the industry might speak better to it's actual merit.

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.

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.

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.

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

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!

I agree this is a shitty way to manage complexity, but at the same time it's super intuitive for lots of people. Maybe find ways to apply it conservatively and guide the non-hardcore emacs users down a path that won't drive you mad.

I haven't yet run across a lua integration that was actually reasonable to use. Every time it's a choice between "just hack in what I need to but there is no way to verify I've accounted for all the edge cases and it will be fragile as fuck" or "spend dozens of hours wrapping the exposed api in a safer and more usable OO or FP interface."

Oh also I hope you like implementing build systems virtually from scratch, and also dealing with every downside of C if you need anything more powerful than prototypical inheritance.

Six months of professional lua work has really, really drilled into me that a programming language isn't shit without its ecosystem, and it's meaningless to discuss one apart from it. I haven't used blueprints but it sounds a lot better than any lua system I've worked on.

The only really fun part is you'll often come across an undocumented function that someone obviously forgot to remove or didn't understand the implications of and you'll get DEEP system access through abusing it, or even just a straight root shell. No joke.

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

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.