Regarding visual languages, I never thought about it that it might make the artistic process more simpler for you. (...) I have always thought of them as something that simply was easier to learn for a non-tech person, and not as something that that actually allowed more artistic expression. Could you elaborate more on this?
In my experience, visual programming languages are not easier to learn at all. If only because they are all so different (as opposed to scripting languages which resemble each other a lot). It takes me several months to get up to speed in a visual programming environment (as opposed to hours or maybe a few days with scripting) and even at optimal speed, I haven't found it to be faster than coding either (with the exception of math problems and debugging).
For me programming in code always feels like a rupture in the process. Playing a game and programming a game is something that I can do with the same parts of my brain, as it were. Both require aesthetic sensibility, pattern recognition, short-term logical thinking, holistic intuition, etc. Coding on the other hand requires an entirely different kind of concentration. Probably because it's language-based and leans towards mathematics (if not in the actual algorithms then definitely in its syntax). Coding is more symbolic, more rational.
Visual programming constantly triggers my sense of aesthetics. Even if I'm constructing elaborate logic systems, I'm continuously aware of the visual presentation: I align the blocks, make sure that the lines that connect them are neat and straight: I make pretty visual compositions with the "code." It often feels to me as if a neat graph will also run better in the engine. Even if that is untrue, the kind of magic and superstition involved with such intuitions ensures that my mind remains in the artistic zone. You're constantly dealing with aesthetics, in the game that you're making as well as in the programming logic behind it.
If the visual programming language exposes everything (logic as well as assets), as Quest3D does, then the artist is stimulated to make connections between all those things. And this is exactly where games become interesting: when the appearance of the objects in the games are influenced by the behavior of the player, for instance, or when the sound is influenced by the state of the game, or the speed of an animation by the time of day, etc. It's all numbers, in the end, and a visual interface allows you to make calculations with all of them. This can lead to wonderful environments that feel much more alive than things that can only be built through careful and rational construction.
But a visual interface is only one part of the solution (and one that is now available in Unity too, thanks to Antares Universe and uScript). The other aspect is
realtime programming: to be able to change something in the "code" and see the change immediately reflected in the game. This is extremely powerful as it puts programming closer to other artistic activities as drawing and painting and making music. Realtime editing allows for a direct connection between producing and experiencing: the two happen simultaneously.
Artistic creation gets more fluent this way: you do something and see its effect. If the editor works well, you can do this very quickly, even instantly. So if I want to, say, change the color of the light, I simply drag a slider until it is exactly correct. Done. Or if I want to make this color depend on the x position of the avatar, I connect the two values. If that looks weird, I can connect it to the speed of the wind instead. If that's too extreme, I just add another block that smoothes it out or inverts the value or something. All in realtime, directly in the code, and thus part of the game. When I'm done tweaking, the game is done. Such a process makes even concept art largely unnecessary: you just work directly in the game engine.
An important helpful aspect of visual programming that is sometimes overlooked is visual representation of the logic flow. In both Quest3D and Universe, the parts of the graph that are active are highlighted. This way you can know exactly what code is being executed at any given time. This is incredibly useful for finding bugs.
And finally: compiling. Compiling is evil. The requirement to compile code before you can see your work disrupts all artistic flow. This requirement pushes an artist to a behavior of constantly switching between the two. Because we need to see the result of every little tweak, you'll see us compiling after changing a single character. If this character is a value after the period in a float, you can imagine how frantic the back and forth can become. It's completely idiotic and soul-crushing. Even the minor time it takes Unity to compile scripts before running is too much (not to mention that it starts from the beginning of the level every time). Not only are we forced to speak like machines (to talk in code), but we're also forced to do the repetitive behavior of a machine (code/compile cycle + getting to the relevant point in the level over and over again).
I do think that visual programming needs to fit someone's mind. Some people -including many artists- are perfectly comfortable with the separation between creation and experience that script-based programming enforces. I guess they are more like engineers or architects, or like more classically inclined artists who would make many studies and an elaborate sketch before starting with a painting. But people who are more sense-oriented, more spontaneous in their art work, like more romantic painters, performers and musicians, perhaps, will do much better when programming in a realtime visual programming environment (sadly, of course, most people capable of
building such a system with the tools currently available belong to the first category, which explains why this form of programming has been explored so little).
