Postcards from Unreal, pt 3: on spaghetti monsters

Unreal Engine 4

We're now a few weeks into the Unreal level design class, and things seem to be going OK. Our students have enough familiarity with Unity that they're able to digest a lot of the 3D workflow without too many problems. People are happily grayboxing here and there, and we recently did an intro to Blueprint scripting.

In the past, I've been pretty skeptical of teaching visual programming methods to students. Teaching a specific visual scripting tool always felt like we were locking students to that toolkit, versus learning how to code in C# or Lua or JS, which is a generalized language useful across multiple engines and multiple industries. Visual programming was considered a relatively niche practice, where you might mock-up an art installation in MaxMSP but not much else, and even Unreal used to confine visual programming to its Kismet level scripting system. (The precursor to Blueprint.)

However, that criticism of visual programming is gradually losing its power as this type of practice becomes more common in the game industry. Many Unreal Engine 4 devs (as well as Epic themselves) make heavy use of Blueprint for making games, a lot of Unity devs rely on the third-party Playmaker plug-in, and even upstart engines like Godot support a visual programming workflow. AAA texture generating darling Substance Designer also has a heavy node-based workflow. It's everywhere!

Substance Designer

So to me, some of the benefits of teaching something like UE4's Blueprint vs textual programming seem like:

• Working with text is hard: indenting things, maintaining white space and cases, fighting with the auto-correct when you forget to close scopes, etc. are often frustrating and annoying for beginners. Imagine trying to learn the logic behind defining a computational procedure while wrestling with spelling "transform" correctly ("no, not Transform, but transform!")
• Data-types feel better: you can't link a square red wire to a yellow round pin, and that distinction feels intuitive to beginner developers. Or even if you did drag a "float" output wire onto a "string" input pin, UE4 will automatically add an intermediate node that transforms the float into a string. This is both more explicit and more helpful to a beginner than invisibly calling "ToString()" in Unity C#. ("Wait but why is it ok to put a float for a string, but not a string for a float? Well, in Javascript...")

Godot Engine

However, some of the big workflow problems of teaching BP stem from its abdication of text...

• Complexity is still overwhelming, and now it's definitely your fault. If you visually program spaghetti code, your node networks will literally resemble spaghetti. It'll literally be difficult to read and parse what is going where. Which is funny. But still not great. This isn't really a problem for beginners, who would likely scope their projects to be small, but learning how to arrange your networks to be legible is like another separate skill you have to develop when doing visual programming. It's almost like you need to be a good graphic designer in order to visually code any larger projects.
• Can't copy and paste / difficult to search. There's no easy way to google a problem on StackOverflow or whatever, because there's no easy way to copy and paste snippets of BP. Instead, people usually post screenshots of their BP networks from the editor, and you have to methodically recreate everything yourself. There's a free third-party service BlueprintUE.com that lets you visualize BPs in a web browser and copy / paste, but it's not supported by Epic and it's unclear how many people actually use this / how long the service will exist.

MaxMSP

Lastly, it's unclear how much this really does fix the core problem of learning how to code: it's hard to internalize how to structure data and formalize procedures for a computer to understand. If you still can't "think in code" when typing, there's still a good chance that using BP or visual programming tools will still be hard, because it's basically the same thing and even mirrors the same API structures. It's important to try to make tools accessible, but it's also important to counter any hype that any given technology is a magic bullet that will finally make coding easy for everyone.

Stay warm,
-- R