Hacker News Reader

Comment by jayd16 | Hacker News Reader

Anyone who mentions visual scripting without mentioning the game industry just hasn't done enough research at all. Its actually a really elegant way to handle transforming data.

Look up Unreal blueprints, shader graphs, procedural model generation in blender or Houdini. Visual programming is already here and quite popular.

View on HN

[post author] I am familiar with those and have used a couple. There are similar examples in music, where visual programming dominates.

The implied audience of this post (not clear) is people writing business applications, web dev, etc. The examples are picked to reflect what could be useful to those developers. In other words, all the examples you mentioned are great but they are not how a "software engineer in a software company" does their job.

> In other words, all the examples you mentioned are great but they are not how a "software engineer in a software company" does their job.

creating blueprints or max/msp programs is definitely software engineering, it requires you to think about correct abstractions, computations, data flow and storage, etc.

also, there's currently 398 Rust jobs worldwide advertised on linkedin, vs. 1473 for "unreal blueprints"

game developers are definitely software engineers in software companies.

My experience is that the software engineers at game companies generally hate the visual programming tools. They want to work with code. It's the game designers who (sometimes) like using visual tools.

Some are bad but Blueprints is great. Main issue is they don't always play nice with text based coding tools.

I spent about a year working with blueprints a while back and I found some things just really annoying. like making the execution line go backwards into the a previous block. if you do it straight there, it wont let you, if you use a single reroute note you get an ugly point, so you have to use two reroute nodes to get it to work properly and nicely. Also they don't have all the nodes you need so you end up having to write some new ones anyway

And AI - which kind of changed the game in the recent years. A "blueprints copilot" akin to Github Copilot will be very difficult to create because there's no "blueprints text" to train an AI on. Nowadays in my hobby pet projects I find it easier to write C++ with copilot than Blueprints.

There's a JSON format of the blueprints that you can see when you copy/paste. Its just a bit ambiguous than the usual binary format. Its not an impossible problem at all.

Not an impossible problem only in theory. It's currently practically impossible and will take at least a year to solve if anybody starts to work on this at all.

Since my current project does involve wrangling AI to do stuff - forcing it to output a consistent, complete, large JSON with an exact specific format is very difficult and takes a lot of time (you won't be able to draw Blueprints line by line to show to the user that AI is processing). Definitely no autocomplete-like experiences maybe ever.

For example, look at the text representation of these 6 (!) nodes:

https://blueprintue.com/blueprint/yl8hd3-8/

It's enormous.

And the second even bigger problem: On forums and basically everywhere all users share screenshots with descriptions. There's not enough training data for anything meaningful.

I tried to force copilot/gpt to output even a small sample of copy-pastable blueprint and it just can't.

Of course, but you know what they're saying.

Developer here that started doing Analysis work for complex systems that require some thorough Bsuiness Modelling. Take a look at

- BPMN https://nl.m.wikipedia.org/wiki/Business_Process_Model_and_N...

- MDA https://en.m.wikipedia.org/wiki/Model-driven_architecture

- MBSE https://en.m.wikipedia.org/wiki/Model-based_systems_engineer...

The tooling on these for Analysts I feel is not on par with tools for Developers. Often outdated and enterprise-only both in price and complexity of use.

- https://en.m.wikipedia.org/wiki/Model-driven_engineering#Too...

Any more insights welcome. At first I expected to find a complete “draw a model, generate api + sourcecode with validation functions” ecosystem of interoperable ecosystems. Apparently the market is not there yet.

I've been looking at using Godot for desktop apps, and seeing how the game world thinks about memory has given me a ton of ideas.

As someone who works for games, I think the biggest problem of node-based systems is... they're all different (in terms of UI/UX).

Unreal blueprints, Substance Designer, Houdini, Blender's geometry node, Unity shader nodes... they all look different and act differently. Different shortcuts and gestures. Different window/panel management.

Different programming languages have different syntax rules and libraries, of course. But at least they're all manipulated with one single interface, which is your editor. If you use vim binding, you don't need to worry about "what pressing K does". It moves the cursor down for all the languages.

People who spent X hours customizing their vim/emacs will benefit from them no matter what language they use next. I spent a lot of time customizing my Houdini keybindings and scripts, and this effort will be thrown out the window if I later switch to Blender.

You know, this is actually really insightful. A standard graph format that all these tools could import/export to could lead to a lot more reusable tooling.

The incentives aren't quite there at the moment but maybe someone like Microsoft or Jetbrains takes a stab at it.

You think Microsoft is going to make a format that's cross-platform?

I guess that leaves jet brains

You mean like for example the Language Server Protocol?

One could even go further and expand this to the players themselves, as there are certain games that might be viewed as visual programming tools. Factorio is a great example, as, conceptually speaking, there isn't much of a difference between a player optimising their resource flow in the game vs a developer managing the data flow in a State Machine.

I've been using ComfyUI recently to manage complex image diffusion workflows, and I had no idea it was inherited from much older shader editors and vfx. It's a shame we can end up using a tool for years without knowing anything about its predecessors.

One major difference I’ve seen in shader graph type tools is that they are stateless, or almost stateless. The output of the shader graph is a function of time and some fixed parameters, and there are rarely feedback loops. When there are feedback loops in shader graphs, they are represented explicitly via nodes like TouchDesigner’s feedback TOP.

This way of expressing computations lends itself well for shader programming where the concurrency of the GPU discourages manipulation of arbitrary state.

In contrast, business logic programmed for the CPU is generally more stateful and full of implicit feedback loops. IMO these types of computations are not expressed well using node based visual programming tools because the state manipulation is more complex.

I used blueprint's predecessor 'kismet' quite extensively. I absolutely hated it. Give me unrealscript any day. Blueprint is popular because that's all you have. They removed unrealscript. To do anything even slightly complex you have to use C++ now.

I wonder the sweet point between BP and C++. One of my friends is making a commercial indie game in UE and he is doing everything in BP because he is an artist, so C++ is particularly daunting for him. He did complain about the spaghettis hell he eventually came upon, without anyway to solve it, but from the number of wishlistings (targeting 10K), I'd say it is probably going to be a successful game, judging by first indie game standard.

TBH I think Blueprints gets used because it is forced upon the UE developers.

Blueprints gets used because the only alternative in UE, writing decade-old paradigm C++ code with 2 decades old macro DSL on top of it, is a lot worse.

Unity has had multiple visual programming packages and people don't really care. Writing 2017 era C# paradigm code with an API resembling 2004 Macromedia Flash is not nearly as bad.

> Unity has had multiple visual programming packages and people don't really care.

People cared enough for Unity to buy one and make it official but Unity doesn't care so it mostly just rots.

Its important to note that some successful Unity games were still made with visual scripting tools e.g. Hollow Knight used Playmaker.

Reply on news.ycombinator.com