I've noticed the proliferation of visual scripting systems in game engines. It seems to work pretty well for building games. However, we all know that visual scripting has never took off for building other kinds of software.<p>I'm curious as to why. What in the nature of "normal" software makes visual scripting inconvenient compared to games.
Some more reasons (as an erstwhile enterprise dev turned gamedev who has embraced visual coding):<p><pre><code> 1. Merging visual code is basically impossible in my experience.
2. Likewise for refactoring.
3. Likewise for finding all references, etc.
</code></pre>
The above make visual code difficult to scale with larger teams or teams with lots of turn over.<p><pre><code> 1. Games often are released and that's it (though this has changed significantly) this puts less emphasis on maintenance.
2. In my experience there were way fewer non-technical people involved with the enterprise product. There were designers and PMs, but not so many. In contrast a game is extremely content heavy which means many artists, game designers, sound designers, etc. Visual coding empowers these people.
3. Non-game stuff often has very basic interactive elements/art. Like, you can get away with the system's UI toolkit. Games are the opposite, everything is bespoke because it all has to connect to the game's artistic vision. Visual tools such as shader graphs make this easier.
4. Iteration in games is essential. It's the engine that drives quality. Visual tools empower this. In my experience normal software iterates less or at least differently.</code></pre>
Visual programming fundamentally lacks the technical expressivity of code.<p>It works well where the underlying technical "problem" is fairly stable and can be represented through a relatively small vocabulary of elements and relationships.<p>So it works for <i>some</i> games because a lot of game engine concepts and even many popular game mechanics are established. The expressivity for those games is in the art and narrative layers above the technical layer. But even then, high-production value games and deeply innovate games can't make do with it, because they're pushing on the technical problem and need more expressivity.<p>Likewise, it actually does work well for a variety of "normal" software domains and is used regularly. It's just the boundaries of these domains are narrow.<p>Visual programming will always be around and will make stable domains more easily programmable, but there will also always be value in the greater expressivity of coding.<p>--<p>That said: games also have special opportunity for being an art form, so doing something interesting within the constraints (as of a limited technical expressivity, modern pixel graphics, new games for old platforms, etc) is itself an artistic work to be appreciated. That extra benefit doesn't apply to plainly commercial projects.
I asked the same thing a while back<p>Some good discussion here<p><a href="https://news.ycombinator.com/item?id=30937201" rel="nofollow">https://news.ycombinator.com/item?id=30937201</a><p>One thing to keep in mind is that it’s not actually “no code”<p>I’ve worked at a big studio and if something was pretty complicated, performance critical, or just not supported by the engine it would be written in C++ and exposed via a new “block” that can be dropped in.<p>So one reason it works is because most projects you still have programmers on hand to abstract the hard stuff
AppGyver has done pretty good job.<p>It’s React based web app where you can build mobile apps from drag’n’drop UI components, and also define application’s logic in visual way.<p>The end result is React Native application that can be targeted for Mobile, Tablet and TV.<p>There are few enterprise apps built with it. Although those are quite simple apps, nevertheless they’re real commercial products.<p>I see that this “no code” stuff is quite natural progress and will get extended to lot more places. I mean how many standard website today was hand coded? It’s taken for granted now that you can build nice standard websites without knowing any HTML or CSS. Most websites have almost identical structure and functionality anyways so it’s not very hard to create such tools.<p>And now you can create standard business app without knowing Swift, React Native, Flutter or whatever is out there. It’s only starting now. You could say that AppGyver is at Wordpress 1.0 state.<p>Also these visual tools can be replaced with other UI systems. Like soon you can talk to computer and describe what kind of app or website you would like to have and watch live preview as it’s coming into existence.
I don't feel the need of "visual scripting" in mainstream software.<p>What I miss is RAD tools, the power and development speed of tools like Borland Delphi, Borland C++ Builder, Windows Forms. They made a breeze adding a GUI to an app.<p>Doing GUIs only in code is tedious and boring.
"General," specifically enterprise, software has to deal with changing requirements, external integrations, and multiple stakeholders, whereas games are relatively static, have a single stakeholder type, and have limited and defined external integrations. To put it another way, LOCNOC tools work great for things that are largely isolated and don't need to change much over time; they're a disaster otherwise, to the point that I've literally never seen a successful LOCNOC project, despite literally millions of dollars of project investments in them.
It did take off... Delphi and Visual Basic 6 were immensely popular.<p>In either case, you had drag/drop GUI elements, property inspectors, and easy ways to call methods on all the relevant events. You simply designed your GUI forms, then wrote code to connect up the pieces.<p>You didn't have to figure out how to build call back handlers, or much of the grief of a main event loop in Win32.
BPMN and BPMN-based or related tooling is pretty popular within businesses for, well, business process automation. It offers a no/low-code way of moving manual processes to an automated form and can work well. But these are relatively simple programs that often boil down to a dataflow-style + decision tables. The diagrams are desirable for communicating the process to non-programmers anyways so it's handy that you can (more or less) use them to at least describe the <i>flow</i> of the system, if not all actions (like you may write code for some of the actions, but overall you can accomplish most things with the diagrams and tables and built-in tools for your particular BPMN service).<p>I had similar experiences with LabVIEW 12+ years ago, it was effective for what we were using it for which, similarly, boiled down to a dataflow-style program and decision tables pulling from various data sources and pushing to various data sinks.<p>The biggest challenge I faced working on a team with things like this was that scaling to more complex systems only works if your design is reasonably modular. If it's not, then it's hard to simplify the current presentation sufficiently to make it comprehensible above a certain size of diagram. Of course text-based programs have the same problem (the 10k SLOC function with the same 100 lines repeated throughout but in slightly different orderings and with different variable names), but most programmers are more familiar with that situation and can either slog through it or know how to refactor it to get out of the mess.
Could take a look at ladder programming/diagrams that electrical engineers use for PLC programming. Works well enough for a lot of people there.<p>Personally I think something technical turns to spaghetti far faster than text(from looking at such systems). The editors are also severely locked down with DRM (software you can usually choose to shove raw text files into the compiler if you want to).
Visual scripting makes sense because game logic is fairly simple (eg. when $POINTS > 100: $TEAM wins), but their data structures (teams, players, stats, scores, state, etc) are not. Video games are one of the few places where object-orientation isn't a matter of diminishing returns, and it pays dividends in places like this.<p>If you're interested in more visual scripting, I think there's definitely still pockets of the industry where it's useful. Blender has a fantastic node-based shader programming environment, which is both simple to use and wickedly powerful. As for "general software" analogs, I think Docker/Kubernetes has really abstracted all of that problem space away. People seldom need simplified interfaces to modify their tools, most users will just want a "road warrior", set-and-forget option that works ad-infinitum, and containers fit the bill. For better or worse, statefulness and good automation options often seem to be at-odds with each other.
I have been working with no code solutions for almost a decade.<p>It works great if you understand it's limitations and it's strong points. It works particularly well for data intensive applications - think moving a complex spreadsheet to an app with users, roles and authorizations.<p>It is more difficult to style it any which way you want - that that is also mostly due to the skill set of developers using and building with it. For example, in my case the biggest uses are business analysts using it to build internal applications and dashboards. They use it effectively to process data but don't have the design chops to make it look impressive - so it looks like modern design with rough edges.<p>But overall I feel that it still still has multiple uses for easy to prototype data driven applications.
The shortest answer is that the "hard part" of software development is not syntax, but logic and architecture. These parts get harder the more complex the app becomes. Hundreds of years of human history have shown that text is the easiest and most readable/writable way to represent complex logic and algorithms, so this leads to the need for text-based languages and text editing tools for working with most general purpose software of any non-trivial complexity.
I wouldn't say it works well for games. The "no-code" solutions like blueprints or shader graph are more of a visual configuration for technical artists to use, but built on pretty well defined code-heavy systems. You might use a visual system to configure something like a AI Behavior Tree, but you wouldn't be able to build a whole new type of system with it.<p>That said, they are very good and powerful, and open up a lot of flexibility to tech artists.
Requirements.<p>The hardest part of any software project is getting people to know what they want.<p>Nocode tools won't save you unless you build a Nocode tool that correctly assesses business requirements.
I wrote a lengthy reply in the thread arduinomancer gave but I’ll simplify it here. Game code is largely about making API calls to the engine. You use a relatively small number of blocks to build things. It tends to be object oriented. You tend to use a lot of void functions. You don’t write a lot of algorithms.<p>When those assumptions don’t hold you tend to prefer code. Most well designed games on unreal will use both.
I think it's because you need a stable "meta" of functions to be able to build a graphical user interface and with general software, there's just so many unique problems you're sometimes solving for the first time or solving in a novel way, it would be hard to build something that stays useful.
"General" software contains too much variability.<p>The "no code" for building games is <i>for building games</i>. If you wanted a no code platform for building, say, embedded software, it would be a <i>different</i> no code platform. For building GUIs? Another different platform.<p>There actually is (or was, 15 years ago) a "no code" platform for embedded systems. It basically builds a state machine, plus tables of structs that look a lot like SQL tables (not how you access them, but the style of how data is organized into tables). It had the ability to run snippets of actual code when entering or exiting states. It was not generally used, though. The main thing it brought to the table was the ability to test the code (or at least the model of the code) on the desktop.
Whenever this is posted it always sounds like it comes from someone who has never worked outside of engineering.<p>The world runs on a visual low code scripting system called Excel.
No code" works well for making games but not general software... yet<p>It isn't that farfetched to believe that at some point, language models are going to be trained on things like complete front end generation, database setup, cloud infrastructure, at which point you will be able to create software through simple language with a few visual tools
Probably because a game just has to entertain. If there is something the platform can’t do then no biggie.<p>For business software the thing the nocode can’t do can completely make it infeasible to build the thing in the nocode tool.