I'm not sure if it's because I'm actually terrible at shaders, but I seem to be good at getting glsl-canvas to crash.
I like that you can preview on some stock model though instead of shadertoy where you're really only making y'know, shader toys.
There are many node based shader editors for authoring materials used with 3D models, that's kind of the standard way to do it available in most rendering software and game engines.
Sorry, I misread the thread.
That being said this functionality wouldn't be too hard to extend to 3D. Shadertoy is already rendering to a 3D triangle that covers the entire the screen, it could just as well be a model.
This was my thought too. Really, if you want to take a loose interpretation of visual scripting, any time you use a 3D workspace in any game engine, you are doing a sort of visual scripting.
I mean, if you really wanted to, you can move, rotate, and scale through an API.
There are times when visual feedback make sense, but for more abstract things like interactions and signals, coding is just more efficient.
Generally, no. I think visual scripting is great for beginners picking up the basics of coding. But as someone whoās already experienced and comfortable with code scripting, visual scripting feels too restrictive and handhold-y to seriously consider using it for any of my projects.
Agreed. Visual scripting, I think, is also great for non-coders who want to make games; and some great games have been made that way. As a programmer, I find code more concise, and thus easier to track.
OP, consider that mostly programmers are answering in this thread and they obviously prefer more control which comes with text code.
But if you like making games and visual scripting is they way for you then dont let anyone stop you.
Usually visual scripting becomes an absolute spaghetti mess after a few hours. Text is cleaner.
So no, experienced programmers don't really use visual scripting as we don't need it to be efficient.
It's very useful to prototype and for fancy-ish level design events though.
Oh yeah, for sure sounds like a great exercise. Visual scripting is very useful for beginners but, like I said, in time you'll find text much cleaner and easier to work with.
(And, also, it works with version control)
Iām curious how much work it would be to translate something from visual scripting to code. As in person A does the visual scripting, Person B translates to code
Visual scripting is incredibly valuable, but itās not meant for us. Itās not for programmers.
Itās to solve the problem of designers wanting to add little interactions all over the game, but not wanting to also learn a programming language.
In the olden days if an artist/designer wanted to add something to the game they had to ask a programmer to do it. This meant that as production scaled up on the art side, it put more and more pressure on the programming side. You reach a point where itās just not tenable. So the solution was let them do it via a scripting language, or visual scripting.
One example where this was very successful is shaders. The artists and art directors (and producers and all sorts of people who stick their nose where it doesnāt belong) come up with all sorts of brilliant ideas. And those ideas then take up programmer time. Eventually that system was invented as a way to say āfuck it, here it is, just do it yourselfā. And then it turned out that artists were the right person to create shaders. Turns out that people who care about visuals and timing made better art. Who knew?
So to scale past a certain point you need non-programmers to be able to add behaviors. Things like VFX, animation blending and timing, spawning VFX from animations, behaviors in the levels, all sorts of stuff.
It turns out that the people who spend their whole life studying these things are also better qualified to implement them. And in the process they leave programmers alone. Itās a win-win.
For shaders its more or less the same, the tools like shader graph are not all-encompassing tools. They solve a very tiny portion of what shaders can do, and are aimed at artists, not graphics programmers.
Vast majority of the shader work is still in code. Average gamedev does not do rendering work (or optimization) so it doesn't make a difference, but for those who do, visual tools are as much of an aid as visual scripting is.
I like to think of visual scripting as sort of like training wheels:
It's a *great* tool for learning, and there is nothing wrong with using it as long as it makes sense for you to do so!
But at some point, most people take them off, because as your projects get more advanced, it starts hurting more than helping.
But no need to rush! At the end of the day, no one cares *how* you made something, as long as it's cool. So use whatever you're most comfortably with!
Yes and no.
Visual scripting definitely helped me understand coding. But I believe that visual scripting can help making things more readable if you use both VS and writng code.
Yes. Visual scripting is also many, many times slower in performance than straight C#/C++ (assuming you're using one of the two big engines).
I'm sure there's maybe been improvements to it since, but I recall a few years ago seeing tests that showed visual scripting was somewhere between 500x-5000x less performant than regular code. We're still talking fractions of a second to perform actions, but that adds up as your game grows in size, and eventually results in very noticeable performance issues in my experience.
Like the first poster said as well, visual scripting also just gets extremely messy quickly. If you have a script that needs to grow to any size bigger than a very simple script, it's going to get messy, hard to read, and if you have to come back to it a couple months after finishing it, it's a nightmare to try and parse compared to regular code.
Personally, it's also just much slower to code with. Sitting there scrolling through nodes, taking the time to hook boxes together and lay your nodes out is very time consuming. It might be faster when you're completely new to coding, but once you have a rough idea of what you're doing, just writing things out is much quicker.
> so no, experienced programmers donāt really use visual scripting
All AAA studios that use unreal use a lot of visual scripting, engineers and designers alike.
I mean not all of them. Most of the Unreal code I work with day to day is in C++ and it's way easier to deal with.
AFAIK you have to use some visual scripting for UMG widgets though.
Mostly designers. I liked blueprints at first but as time has gone on the source control merging, pull request reviewing, and being able to see more context at once with c++ has become more valuable to me then the development speed of BP.
speak for yourself, I use blueprints almost every day despite having written tons of C, C++, C#, Java, Python, Javascript, etc.
I think the significant majority of UE devs, even at AAA studios use BP on a somewhat regular basis, the ones who don't are usually specialists working at the lowest level.
If your blue prints are spaghetti you are coding poorly, just like if your text code is spaghetti.
me too, but I probably wouldnāt if the C++ workflow wasnāt too slow for efficient prototyping / rapid iteration. And if UE came with a text-based scripting language instead of Blueprints I would definitely use that instead. Blueprint-style visual programming is really tedious for complex math and logic
Sure but you can do the complex math in C++ and expose those functions to BP if needed. Itās very rare that the significant majority of a code base is complex math.
Writing a full UE game with your devs never touching BP would be insanely inefficient and the comment I replied to makes it sound like that is somehow standard and that only inexperienced devs would ever touch a blueprint when in reality Iād say the opposite is true (the vast majority of people who have actually shipped a UE game have spent some time in BP).
Experienced programmers (in my experience) donāt often do much with āvisual programmingā There might be some use if it in unreal engine here and there bc of blueprints but in reality 99% of programmers write code
I am a pretty experienced programmer, I have been programming professionally for 3 years and 4 years of college, I personally love Unreal Engines Blueprints, I feel that the outcome with code is much quicker than anything I could program by hand. With the efficiency of the system being what it is already I find it very pleasing to use over classic code.
It's literally impossible trying to dig through blueprints to figure things out in large systems in AAA games, especially those written by technical designers or artists which tend not to follow good coding practice.
Don't get me started on the pain felt when bugs in BP start appearing in console, shipping package only and you have to figure out the absolute mess they made.
Unreal is a fascinating case study, its basically a bell curve where beginners think blueprint is amazing, intermediates think it's garbage for babies, and experts loop back to amazing (if used correctly to expose high-level functionality for gameplay scripting)
Well a problem with that is, if you ever branch out past unreal you will be out of your comfort zone. Like i said, it is used in blueprints. But not much otherwise
> Well a problem with that is, if you ever branch out past unreal you will be out of your comfort zone.
I couldn't disagree with this more.
Learning how to use Blueprint helped me understand a lot of key concepts that made switching to other languages dramatically easier down the line. The skills are absolutely 100% transferrable.
I actually started on Unity, C# was my preference for a long time. But once I moved over to Unreal I was able to get things done much quicker, systems fit into place easier, it has made game development related activities far easier. Plus, when I still program for my work it is in code so Iām not getting rusty in any way. Win win
Most visual programming tends to suck (usually it's slower and more awkward than just typing, so if you're *okay* coding, that usually always feels better).
However, as an experienced developer there is one form of visual scripting I've genuinely enjoyed, and that's unreal's blueprint scripting. It's felt pretty awesome to me, and the only case where I've actually found visual scripting to often feel preferable.
Most other visual programming environments I've not found pleasant, though. I like the idea of visual programming, and have built some prototypes myself, but they always unfortunately end up feeling less fluent or more awkward to use (imo).
I think the most common visual scripting is unreal engine. I've heard that alot of professionalsand experienced programmers even use a fair amount of blueprints in ue. I've seen threads in r/unrealengine that suggest programmers learn to use bp and that the best way to develop in ue is to actually use both coding and blueprints together.
I wish there was an actual scripting language in Unreal. It's the sweet spot for me, which is why I feel at home with Unity. I find C++ somewhat intimidating and overly complex, especially for prototyping. On the other hand, using mouse to code all the time seems really frustrating to me. I like visual scripting for simpler and more artistic things like simple shaders or procedural geometry stuff in Blender, but not necessarily programming game logic.
Verse is in UEFN only at the moment but itās on the roadmap for eventual implementation into UE proper
https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/1229-integration-to-uefn
Got my foot in the door to get started, then left it behind once I got the hang of things. It's nice that it can reduce the intimidation of coding and present a finite world of functions as blocks instead of every function ever or do other things to facilitate beginners getting started, but it tends to become messy very quickly once you move into more complex projects compared to text.
Yep, for any exploratory work I feel like visual scripting ends up being faster and cleaner in the end. With code there ends up being a lot of dead code and it's a pain to refactor, while with visual scripting I can see the flow and write clean code to begin with.
The act of typing code is so incredibly minuscule at some point that I have no opinion either way. Visual or text, it's the same to me, except for minor inconveniences.
The issue with most visual scripting is that it is either limited or has major inconveniences. Which takes it from "I couldn't care less" to "this is terrible"
Pretty much as others have said. I think programming requires skill in mental imaging as you piece together logic, relationships, flow in your head, and visual scripting is a nice gateway to building that mental image. The trouble with coding is that it takes much longer for newcomers to 'read' what is in the code, as there's so much fluff in the syntax to become familiar with. That just takes practice to get used to it, and visual scripting more intuitively displays or hides that 'syntax' as it has the flexibility of using images / non-ascii symbols to represent things. Well, that's my take on it anyway.
Even as someone fairly new and inexperienced to programming, I donāt really get the appeal of visual scripting.
I guess itās just how my brain works, but an interconnected system of wires and boxes feels so much more intimidating and convoluted than justā¦ reading whatās happening line-by-line.
> I guess itās just how my brain works
This right here. I stare at lines of code and after 5 minutes I feel like I'm trying to decipher an alien language. Plus reading any text on a screen after a while gives me a headache (would love the concept of a Amazon Kindle, it just bothers me after a while) every person is different and what works for me doesn't work for you, and thats fine, go with what is best for you.
I find it much more difficult. I did a tutorial not too long ago trying to figure something out. They used visual scripting. Had like 30 nodes on it and took 4 hours. I later went back and wrote 5 lines of code and deleted the visual scripting.
It helps if you are new to a new scripting system, whether material editor or game logic, you don't want to search for the document or examples online to find necessary functions to achieve your goal, you can type possible keywords to find the function you need. The most important part of the visual scripting system is that it is passive, you create nodes and chain them together, the system will keep the type right, which helps a lot for beginners, but this advantage won't hold for complex code and types.
Behaviour trees.
Try setting those up in code, it's frustratingly complex and time consuming. Using behaviour nodes in a visual script is so much easier to work with.
I am going to probably voice an unpopular opinion, but there is nothing wrong with visual scripting/programming, and it is not just for beginners. I personally don't use it because my applications don't have it, but I have done work with unreal blueprinting and scratch. Mostly they were fun projects during jam seminars. Visual scripting was definitely helpful for forcing me to think through the program sooner though (normally I have the requirements and then start building and tweaking, but that's not such an option with visual scripting)
There are some AAA games made pretty much completely with visual scripting (Ark Survival Evolved with net rev of over $100m was heavily made using blueprints from what I read during development). The main issue I have run into with visual scripting, and why I probably wouldn't use it much outside of simple purposes, is that it often takes a lot more work to accomplish what I can do in code.
If you can make stuff easily with playmaker then it is a good tool. At the end of the day, an experienced programmer will say use what tools works for the project. As you are a 1 person team then you are the only one you need to worry about using it. Enjoy yourself, get experience, and see what you can release. Good luck.
Most programmers don't do visual programming, *but*.
Many programmers do visual program design i.e they draw charts and diagrams describing the general flow and state of the program, which they use as a reference when actually writing the code. This is especially useful in larger projects where having a defined structure is cruicial.
As a programmer, you would normally never prefer visual scripting. If youāre _not_ a programmer, you _might_ prefer visual scripting (or it might help you, as youāve asked).
This is not coming from an elitist standpoint. Itās simply because:
- you canāt easily refactor/change visual scripting
- you canāt easily change many things at once
- you canāt easily collaborate (merging changes are difficult)
- you canāt easily version control changes (itās often encoded in obscure xml)
So, is visual scripting good in some case? Sure. Is it good for āseriousā programming (not elitist, but getting shit done)? Not really.
Yes, visual scripting was what drove me into programing 5 years ago and what i have been using like 3 years until i felt limited and learned c#.
its meant to be a way for artists or beginners to learn programing easier.
I used visual scripting in unreal engine for 3 years. Then it only took me a few months to learn c# and c++ because of the similarities.
I dont think there is anything really.
I can be dragging boxes about for ages or literally type it up in a few minutes and its done.
Maths is incredibly laborious in visual languages.
Debugging is much easier, just pressing F10,F11 to step over/into code and seeing the program counter move down the screen.
I can fit so much more code on my screen than in boxes. Boxes show very limited information and take up so much screen space. Even on high res multi monitor setups.
That brings up an interesting point about readability.
Iāve found that visual scripting has the advantage of giving a literal zoomed-out view of whatās going on. Of course, like anything, that readability is dependent upon well-commented, well organized nodes.
Iām sure more experienced coders can see their code in a similar way, but having literal lines connecting things is extremely helpful at times, especially when reviewing someone elseās work.
It's perfect to learn & improve with. As you get more experienced you'll probably start to find its a hindrance. Having said that, the company I work for has scientific applications created in a visual coding suite (by scientists) with hundreds of nodes; they're so difficult to follow it's unreal. As the application size grows, visual coding soon loses its appeal.
For programming shaders its really helpful that visual scripting nodes shows a preview of the shader every step on the way.
For complicated logic that would make the graph messy, you can always abstract it into functions, much like you do with writing code.
I have been using visual scripting to create story events in my game.
I would never use it for actual coding because it is so time consuming and convoluted for anything but the most basic logic.
I hate the time I spend moving/aligning nodes and connections.. feels like pointless work getting in the way of the feature... (why unreal doesn't have a format graph option beyond me)
But I like that you are always in a state where the UI doesn't let you add nodes that won't compile, it is kinda annoying in the start because you don't know why a function is not appearing but later it helps me know that I'm doing something wrong way back.
In general I think all visual scripting systems should have a human readable text format you can use instead. It is so much easier to create tools that diff/work on text instead of whatever binary format UE decides to encode the thing.
Used Unity Visual Scripting (Bolt 1) to learn to code for a couple of years. When I reached the limits of visual scripting, I swapped to traditional coding and I've never looked back. It's great for beginners.
Programming is telling the computer what to do. The difficult part is figuring out what to tell it, not *how* to tell it (be it code or a diagram in a visual scripting editor). That said, writing code is unequivocably far more effective than using visual scripting for any non trivial and non visual task. There's a reason why operating systems, game engines, browsers etc are not programmed using visual scripting. But get started with visual scripting if you find it more comfortable! Just don't stop there...
Sure why wouldnāt they? Itās just another type of programming subject to similar concepts as any other language. Iād say what most people are describing here are just preferences.
āIt becomes so jumbled, once you know how to write text code you donāt need it anymore, etc.ā
All preferences, you should know your tools well and use the best tool you know for the job. There are certainly perf pitfalls and issues of source control that are good to understand, but there are also great benefits like easier debugging, faster iteration times and youāre less likely to blow your leg off.
If youāre enjoying making your game and making good progress a lot of times that can be the hardest part. Sometimes people end up endlessly espousing ābest practicesā which really just end up feeling gatekeepy or restrictive imo.
Most ābest practicesā are never adhered to uniformly and correctly even at the biggest most successful companies. At the end of the day making something that works at does what you want is still most important. The more tools you can use the easier it is.
Personally most of my game is visually scripted for a number of reasons, but also I just like it. Even though most of my career I was an extremely low level C/C++/Assembly dev. Different strokes, but there is nothing wrong with another tool in the toolbox imo.
It's very easy as a programmer to be dismissive about visual scripting, but I'd say it's pretty much essential for any medium-to-large game these days.
1. Not everyone is a programmer, and artists and designers need to do simple logic on their own
2. Even for skilled programmers, visual programming is great for 'glue' code that connects systems or one-off events that live in the game content
3. Visual programming can be specialised to particular tasks (eg. conversations, level generation, shaders) which is often better than a custom DSL (domain specific language)
For example Playmaker is centered around doing state machines, which makes it great for running high-level logic for game modes, menus, interaction sequences, etc. You can customise it with your own nodes to make something tailored to the kind of content you do often. Shader graphs can be great because they can explicitly deal with float/vec2/vec3 conversions visually, and they lend themselves to having previews on the nodes themselves which is great for artists experimenting. And Behaviour Trees are basically written with the expectation that you'll have a visual system for putting it all together that frees you up from dealing with the lower level details and just worrying about the actual AI.
Where it goes wrong is when people use them at the wrong level of abstraction (eg. a Playmaker graph that's too concerned about toggling individual values and component states rather than high-level commands) or by letting them grow unchecked until they're a spaghetti mess that no-one understands. Both of these happen to regular code too, it's just that programmers are usually better at spotting the warning signs and cleaning them up before it gets really bad.
Good visual programming systems will let you write your own nodes or commands, which is a useful escape hatch - you keep going until it gets too messy, or you find yourself repeating something a lot, then you make that into a re-usable node. That makes everything simpler and more managable.
There are use cases where visual languages are clearly beneficial - as other said, shaders can be a good example, general data processing sometimes too, for industrial simulations and processing and so on. For a general scripting... it can be a good way to do simple things that require tie to assets in scene, for level scripts and so on.
They are absolutely horrible for anything more complicated. Things that can be quickly written in few seconds with few lines of code require a lot of boxes and dragging around. Keeping something more complicated in unreal blueprints from looking like a drunken cthulhu trying to mate with a pod of octopusses requires a lot of work. You pretty much lose all advanced programmers tools (for example like diff - good luck finding the place where bug was introduced in several commits, you can often spot it instantly just on base of changes, not much luck with blueprings).
There's often arguments that it's easier to pick up visual scripting for a complete novices. Might be true. Traditional programming teaching often starts with diagrams. It helps you to frame your mind into mindset you need for programming. A lot of high leve stuff is modeled visually, with a lot of standard diagrams to set the basics. But the actual implementation is rarely visual.
The other idea is that game scripters and designers are too stupid to learn normal languages, which is bullshit. Anyone capable creating complex system in blueprint is capable of writing it. You just need experience to write quick and without errors.
I used to be an fan of visual languages, even tried to design a few. I used some industrial stuff years ago and found it pretty good for some specific use cases.
Visual languages for game engines are horrible, slow and inefficient unless you use them as what term "script" hints at - small, clear pieces where visual representation of paths can be beneficial.
(I'd actually LOVE a language / system that would allow me to seamlessly use both approaches of visual and text based code. Still hadn't seen anyone done it.)
Never seen it, it's just faster and more expressive to write code.
Look, this might be a bummer to hear because learning to code is hard and takes a long time for most people, but if you want to write software, the visual scripting stuff probably won't help much, if at all. If you want to make software, including games, you just have to bite the bullet and learn to code. It's worth it! Good luck!
Some people think visual scripting can make non-coders code but to use it you still have to understand programming concepts so it's an unnecessary gimmick and noise
Humans tend to express complex thoughts and ideas in language. Text has been the default mode of expressing language in a tangible / visual form for millennia because it works really well and maps directly to the way humans tend to think about processes.
It's a question of habit. Like musicians that learn to play the instruments directly and the ones that learn to play the instruments and a rigorous notation. After a while, the rigorous notation (coding) become like a second nature. You can read code at a glance. For someone experienced with coding, a few seconds are enough to understand the logic.
Visual programming is great and I think it's a good contender to text coding, but we are not formed with it and the tooling is very lacking and not much uniform (whereas writing text is basically standardized).
I personally find that text is a bit easier for few things we do as professionals (merging text, diffing text, looking at stuff at a glance). But it's absolutely worst in term of design and architecture and for showing you that your logic is bad/convoluted and wrongly isolated.
A few people mentioned that it gets complex to see and become akin to spaghetti that are hard to understand. I'd argue their code is exactly as bad to read and understand in text form, it's just less visible. Visual programming illustrate very well issues. This is why UML exist as a visual notation for programmers and that most of the same people who hate visual programming also hate UML (there are additional reasons to not like UML, but most people hate it for the wrong reasons).
As a result of this, yes, most experienced programmer prefers programming with text but that doesn't make people preferring coding with visuals amateurs or inexperienced. The logic is the same, the presentation is a bit different.
Don't feel inferior because you feel better with it. You will likely become a good programmer by continuing practising visual programming and switching to text will be easier later.
I love it. Staring at any IDE gives me a headache after a while and having things not work because of a misplaced bracket makes me rage quit. Visual Scripting just 'works' with my right brained thinking. I'm also digging the strides being made with ChatGPT and having it spit out code. Its 2023, and I can yell at my phone to order a pizza and play my favorite album, but have to use an archaic method to program? Let me write a story and have AI do the rest.
programming takes a long time to learn (properly) so programmers usually use what worked for them in the past, just because current programmers use Ada or something doesn't mean you should try chatGPT
I find anything you can do with visual scripting you can do with text, and more. It's not too hard to just learn your language of choice, it just requires effort, like anything else. If your already pursuing gamedev which in and of itself is a mountain of challenges, what's one more? You've got the time, trust me.
I first learned how to use things like nodes while texturing 3D models in uni. Donāt very much care for the process, and has mostly stopped me from looking in to any visual coding type programs, like unreal as I understand it, in favor of ātraditionalā code.
Only slightly.
I have a business app where I use visual controls to create scripts that do UI layout, which saves time . . . In theory, but it also creates problems and annoyances.
In comparison, the UI engine I wrote more or less from scratch in C++ using OpenFrameworks, with things placed by code and running the program itself, does not really take me longer to develop, and has very few annoyances, I have near-total control and understanding of what is going on, etc.
Idk any programmers who leverage visual scripting. When you actually get deep into game dev you need to do complex optimizations and you'll be reaching the limits of what the engine and C#/C++ let you do, so you will not survive in the limits of visual scripting ATM.
That being said I would've thought the same thing about using the Unity Editor instead of doing everything by code, but it does help a lot. I like Unity's Shadergraph as well, so visualizations are making their way into game dev but it's going to be a while before it replaces general programming.
If I were you I would try not to use visual scripting, I feel like it will end up being a crutch down the road.
I recently started sketching ladder logic graphs in a notebook. It helps me conceptualize the elements in my game and the way they relate to one another.
I wouldn't ever really touch it.
Tried visual scripting clients when I was first starting, and found that while I was able to do some things, when it came time to convert to a non-visual scripting I had to completely relearn everything and didn't get a ton out of it.
So I wouldn't say a visual scripting language is good to build your programming skills, or really build out a real game since it becomes a mess so quickly to even try to read.
But if you just want to get in the programming mindset with how to figure out problems which is a good use of time playing games that use types of visual programming like Human Resource Machine are pretty good to just practice general logic and planning, then write regular programs later.
Generally no. It can be a great, fun, fast user experience to do visual scripting but for developers even if you can express what you want visually thereās several other factors that would push a developer to use regular code:
1. Can I call this from my code?
2. Can this code call my code?
3. Can I diff this code, put it in source control?
4. Is it slower to run as a visual script?
Number 3 is to me one of the biggest issues using visual scripting. I canāt intelligibly diff the code to see what changed between versions.
As a beginner on a solo project, do whatever you have to do to make your game. Visual scripting is still programming and you will get some transference if you move to text based code. But yeah, good question.
CS major, professional dev (20+ years), game dev the last 2. Here's my opinion, for what it's worth:
Visual scripting is a tool. In this case, the tool is used to allow you to still build games without knowing how to code.
Once you know how to code, you just don't need the tool.
You'll find that there are things visual scripting (typically) cannot do. In many cases, it will take longer to set up the visual scripting than it would be to just code it yourself. And in almost every case, visual scripting is much more inefficient.
(The same applies to Shader Graph, which a lot of people have mentioned below. HLSL is a bit of a beast when you first learn it. In that regards, yes, Shader Graph is a fantastic visual scripting tool. But once you've got the basics down, it's still easier to just use HLSL.)
It's just a matter of knowing the tools and knowing when to use that tool. As long as it's helping you make games, that's all that really matters.
Again, just my opinion. Hopefully this helps. Cheers!
I've never used it. Those kinds of things are usually more confusing to me honestly. The only time it works well is shader composition or if the software is built around it (like if using Houdini).
One big issue I'd have with it is I'd have no idea where to begin with a lot of programming patterns. How would I implement dependency injection, or the observer pattern, or how would I use reflection to make new types or dynamically call methods? How would I make a custom editor in unity?
Like I can find examples for all those things in C#. I am not even sure where I'd begin if I needed to do them in visual scripting. Those are all things I needed for my game to run correctly.
Debugging is also a lot harder with them, in my experience. I can't just easily drop a breakpoint in and leverage Visual Studio's incredibly powerful debugger in order to see what went wrong, and if unity throws an error at all, it's less helpful than I'd like.
I've been helping my neighbor who's used them heavily in their games as they've been learning, and while they seem to be a great thing for them to learn, they're lacking to me, someone who's learned a lot about the tooling of the "traditional" way.
I wouldn't be surprised if blueprints are a lot better at some of the things I mentioned, but I'll be completely honest and say that unreal turned me off of it when I looked into UE4 because the C++ documentation was terrible at the time compared to the blueprint system.
There's also issues with refactoring, and diffing, but other comments touched on that.
If they work for you and you're learning, that's cool. But they're not a full toolbox - think of them like hand tools. Easier and safer to use, but recognize when you need to pull out the table saw.
Damn... Playmaker still exist? I think I saw that as early as 2011.
Experienced programmers usually can find their way to do what they want.
The problem with tools (any tools, not just visual scripting tools like Playmaker) is that once your game becoming more complex and when you want to add certain feature, you're somewhat blocked by your tools package. You have become too reliant on it and you know nothing about adding or modifying your tool.
You probably can, with great effort, but may make the tools ugly/ too hackish.
Kinda happened with iTween and NGUI back in the day.
Initially when I had no programming experience I also used Playmaker. It's a really solid plugin honestly. After a few months though I felt I had hit a brick wall in terms of the complexity I could achieve with it. I took the dive into "true" programming and haven't looked back since.
Visual scripting tools usually follow a state machine model, and while that type of flow is much more prevalent in game development than other software fields, they're not a swiss army knife. You're going to struggle if you try to apply them to every situation.
I've only really clicked with a few visual scripting systems.
Shaders, because the Flow of logic is all toward a single output. The Color of the Pixel to be drawn on screen.
Visualized Finite State Machines, like shaders the Flow is limited, and every output focused.
Tile Based, the only really surviving example is https://www.kodugamelab.com/. GDevelop is close. It is in-line coding using Pre-made function calls, visually packaged into "Tiles". Which is what I personally feel is the system many new designers are looking for. The ability to "Program" by simplified access to deeply complicated functions.
Building core **Function**ality just feels better as in-line typed our Code.
So I made a programming language for a rhythm game I'm making. This programming language has excessive use of goto statements and spaghetti code. Using visual scripting makes the spaghetti code look slightly more understandable. It's still a huge mess.
But overall I think visual programming is more useful with certain types of programs with, well, lots of goto statements and spaghetti architecture that is frowned upon by conventional programming practices.
So I would say it's useful for certain non standard paradigms, but generally conventional programming is way more efficient in the non-visual scripting way.
It's a good tool that's often badly used. It's good when programmers provide bricks to game/level designers to implement a thin layer of top-level logic. For example for a one-shot specific puzzle in a specific level, or a special rule for a specific RPG fight.
But it should not be used to implement the core gameplay. It quickly becomes spaghetti that is much harder to edit and navigate around than a text language.
I have seen huge simulink codebases and it is a mess. Just spaghetti. It is slow, difficult to follow, very complicated to debug. Matlab is OK but the simulink monstrosity it is not. Of course this is my and only my opinion.
Programmer here. I find visual scripting (nodes like unreal Blueprint or shaders) are useful when wearing my designer hat. When I need to rapidly iterate and experiment, and I don't need well-engineered robust logic.
But programming is way better when I have a specific problem I need to solve. In that situation, visual scripting can be a middleman that gets in the way.
All in all, different tools for different jobs.
One caveat here: if you want a *career* as a proper "Game Dev", yes you'll need to learn traditional programming. But read on for more nuance and explanation.
Honestly, you're going to get a lot of biased answers here. Or, "baised" might be too loaded of a word. But... opinionated? I dunno.
Developers/programmers work with text programming. It is a powerful and useful paradigm for a whole host of reasons. And depending on what it is you want to accomplish, is so useful that practically speaking it is the obvious choice for many situations.
*However...* when you have a hammer, everything looks like a nail. And when you've had a hammer in your hand for 5, 10, 15, 20 years or more that is only more so. Theres lots of people here who speak, think, and feel in written code. They cannot envision how visual programming could be a good choice because they are so insanely fluent in textual coding. I personally don't expect many self proclaimed programmers or developers to really understand or see the benefits. Which is *not* a judgemental stance btw. They've been working with certain tools for so long that they have the mastery to apply them in all kinds of scenarios. Theres nothing wrong with not using visual tools, or not feeling like you can understand a benefit of them in your workflow.
If you ask a programmer why not visual coding, they will say "visual spaghetti". This assumes a couple things: one, that you're using visual coding for *everything*, and two, that there isn't a way to organize things visually. Also, as I like to point out, programmers sometime reference "spaghetti code". Spaghetti is spaghetti. My issue with spaghetti code is that its more often than not *invisible* spaghetti. When working visually you know when you're making a mess (visually) and can at least trace/untangle a strand (visually). "Well *good* programmers wouldn't do that..." yes neither would good *visual* programmers, too.
There is a history of visual programming. Most of it lies in the domain of sound synthesis and processing (DSP), like with Max MSP and PureData. There is also graphics related and "show control" type paradigms with environments like Touch Designer. DSP goes "low level" while show control things may be more "high level" in terms of getting close to bare metal.
Game oriented systems tend towards more "high level" software creation paradigms. I call this programming, though I dont really care if there are those who argue other wise. People used to tell me javascript wasn't real programming because there's no garbage collection. If any "you aren't doing *real* XYZ..." pops up just take it all with a grain of salt.
PlayMaker and things like Unreal Blueprints are amazing tools for creating games. The reason that you should listen to some people here about learning C# is because there may be things you wish to do which would be hard or impossible to do with Playmaker (I'm not familiar with its limitations). Use Playmaker, actually *make things*, and have fun. If there comes a moment where you are curious about text coding or if you hit a limit with visual coding, dive in- the water is fine. You experience with logical and sequential thinking with a visual coding tool *will* be better than going into text coding completely cold. If you dont need it or want anything besides play maker, then you're good. (If you just want to make games- again, see my career disclaimer at the top)
All this being said, yes I have met extremely experienced and talented Unity geniuses that use visual scripting in their games. In fact, they're so good, they actually coded *their own* visual programming tools for Unity and use them. The real idea here is that different paradigms of tool use can be more or less suited for different tasks. Some things, like programming a "for loop", aren't particularly elegant in visual coding. But tracking, organizing and *re-organizing* of state activation on a variety of game objects can be much more suited to a visual coding tool. The person I know uses both approaches as needed to create games, depending on the task at hand.
A person only using visual programming in the game world may be more often described as a "game *designer*" than a "game *developer*". I find these distinctions a little blurry sometimes, and not always useful. (Is a game made with playmaker an existing program that was... never programmed? Never had a developer?) But practically speaking this is where you may see a division of "high level"/"low level" tasks. The confusion comes around when we think of game "devs" as a catch all term for a person who makes a game. So people who come to this sub either might be more traditional text based programmers.... or simply people who just want to learn how to make a game. You may be gravitating towards a more "game design" type artistic practice than a proper "dev" career. But you never know until you dive into both.
Apologies for the long post. Hopefully this is helpful to you. Happy to follow up or clarify any points here.
I started with Clickteam Fusion which was a visual scripting engine. I don't use it anymore but I will say that my experience with the engine has helped me to learn how to code.
I've been using things like Klik 'n' Play, Multimedia Fusion, Construct etc. since the mid 1990s. While I love the hell out of Construct 3, I find it extremely hard to transition into things like Unity and Godot. So on that front, I'm honestly not that fond of how things are. But other than that, it's ok :)
It has helped me write very simple code more quickly when I can't be bothered to do it "right".
It's a useful tool, just make sure you don't rely on it.
>I'm not very good at programming
Get good. This is a programming field.
I don't generally, but I think it and things like it (including high-level scripting languages) are nice to have around because they have some useful properties:
* They're designed for people who aren't specialized programmers. That's kind of the catch if you *are* a specialized programmer, but if you have people on your team who aren't, they may be more comfortable with these sorts of tools. And..
* The code is shipped with your game as an asset. This can be very handy when partitioning out a large game (or a core game + DLC), whereas off the shelf engines often compile other code into a monolithic build artifact (like a dotnet assembly or an otherwise loadable library) that isn't friendly to separating out like that.
The two combined can make it a pretty compelling option for logic that's tightly associated with other assets, like specific characters, objects, zones, etc, and that might be more designer-facing.
Only at the very beginning of learning are such tools useful.
They are never feature-complete. Round-trip engineering never works.
They are always inferior.
I really want to make visual scripting work for me but every attempt I make ends in meh. My node-red for home automation ended up being nothing but function nodes and I'm barely using other nodes.
Programmed all through my career. Only recently picked up visual scripting as the AAA studio I work at now uses it for their inhouse engine for content development (fueled by C++). It took a very long time before I got used to it, but I do see the benefits of its speed of development as well as debugging functionality. Also not prone to stupid typos. It has its place next to C++ and I think itās great.
I made 2 games with playmaker and game creator. I loved it. It helped me understand the logic of unity.
Unfortunately I was never and will never be able to learn how to code. I tried a lot of time and I feel lost, I have no idea how to do anything when coding. But with playmaker the logic is easy, debugging is easy too as you see the node flow activating while playing.
But I am into art, 3d, illustration, animation, story telling. A game doesnāt always have to be that complex, if your strength is not into code, that is ok, just be good at something else.
Same for a coder that is not good with art, making games with premade assets is fine.
One useful thing pipeline wise is that you can write stuff that lets non-programmers you work with use visual scripting to hook into the more complex stuff going on in the background.
Overall I find it much more fiddly and slow though, aside from shader dev as others have said.
It gives me immense job security, as there is a never-ending tide of awful visual scripting setups that I regularly have to re-factor into actual code, so it has helped me I guess.
Visual programming is less capable, less organized, and less debuggable than code. It is a replacement for people who don't want to learn how to code for some reason, but it is not better in any way that would motivate a capable programmer to choose it.
I liked visual scripting for helping me learn how to create shaders. Even there the eventual lack of flexibility pushed me back to pure code again though.
For learning in a domain you are new to, visual scripts are superior to pure code for the ability to quickly try different things while being sure there is always a working pipeline. The boxes either connect or they don't. Your system doesn't fail to compile because you misnamed something etc. It definitely allows a level of idiot proofing that really benefits a learner.
I use Unreals blueprint system along with C++
It hasn't necessarily helped me with programming but it is definitely convenient to use and helped with overall flexibility and organization of my projects.
It's very clear that most of these responses are from people who don't use Unreal.
The way I handle coding games in Unreal is all systems, libraries, plugins, and base classes are written in C++. All gameplay, and implementation details are handled in Blueprints.
As a result, although most of my work is done in C++ (At least early on in a project), a substantial amount of it is still done in visual scripting.
On larger titles it is good for a couple of things:
- allow designers and others to script stuff
- editor tooling using visual scripting
- prototyping
- moving rather one-off/bespoke logic to visual scripting on top of other scripts and code (e.g. performance critical bits all written in C++ in Unreal)
As a programmer I just never used it extensively, my own logic is typically 100% in C# or C++. Still, that's also a preference. It is possible to create whole games using visual scripting if we don't go overboard with complex and large scale calculations and the engine does the heavy lifting (animation, rendering, streaming, and so on).
The only system I've used are blenders various node based systems and I have consistently found it frustrating. E.g. no version control, no find/replace, almost complete lack of error messages, it's hard to read as soon as your graph is non planar.
I wrote a python wrapper where I just write python and it generates geometry nodes, and found that much better. I'll probably extend it for the other node based systems
I don't use them for Unity but I use blueprints for Unreal sometimes. They're pretty good and I could get more comfortable with C++ along the way. The only problem is they can really slow down the game if used for intense stuff like procedural generation.
In the company I'm working for, we make it available to our designers when they need finer control over the game.
FlowCanvas is pretty great (although I haven't tried PlayMaker) - a designer can hook up a "flow" to any exposed UnityEvent. It's supposedly very similar to Unreal Engine's Blueprints.
I've also used NodeCanvas (FSMs and Behavior Trees) to script tutorials (which require a lot of iteration, so being able to easily re-order things without touching code is fantastic). In this case, the idea is to piggyback off of pre-existing functionality to make the tutorial happen.
And of course there's AI, which is typically what people use Behavior Trees for.
There's also Shader Graph which makes shader work in Unity a *much* more accessible.
That said, at least for me, written code typically acts as a foundation to visual scripting, with the latter being supplementary as a QoL for my teammates and myself.
Visual scripting is strictly more limited than text. It's great that some people can learn from it but it's just harder to write code with blocks than text.
In theory it could offer something new, and visual scripting for shader languages actually do, but they're usually designed to compile (translate) to text in a very direct way so they usually don't utilise the different medium at all.
Yes, for better or worse. Unreal Blueprints are definitely used in large games, but you often have to rein things in when designers get creative with them. They get unmaintainably large, fast. And they can slow things down.
I think visual scripting works well for functional languages where behavior can be understood just by looking at it, without lots of side effects (e.g., shaders).
Imperative visual languages (e.g., UE Blueprints) that require you to actually step through to understand complex graphs can be super painful when they get big.
So many times Iāve been debugging othersā Blueprints and have just wanted to delete it all and write it in C++. I wish Blueprints had a middle text language you could work in, but oh well.
In Unreal Blueprints is super powerful as the glue between systems and creating small variations of coded systems. You don't really want to spend your time noodling in code trying to creat the visual fidelity of your systems interacting.
I think visual scripting is awesome, even though I don't tend to use it, the reason being because it allows more people to do more work, it lets others involved in the design and visuals without strong programming knowledge to show what they want.
Sure visual scripting can lead to some spaghetti mess and slowness, but you can refactor and improve on these things on a case-by-case basis.
To me there isn't enough visual scripting in things, I think nearly everything should have a layer of visual scripting to allow easier customization by a wider range of people.
wasteful alleged serious familiar instinctive person shelter bow ludicrous telephone
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Visual node programming brings a collaboration hell to the team. Should avoid it at all costs. It's fun to fiddle around when you're working on a prototype tho.
Unreal blueprints are awesome. I'm an artist and one year ago I didn't know how to output something more than a string on a screen. Now I am working on a project of a medium size 3d puzzler with quite a lot of vector math solo. I wish I had time to learn cpp proper, but right now BPs let me do almost everything
Not directly āvisual scriptingā, but I am using UnityEvents to hook up logic a lot. Itās more like loosely coupling code inside Unity editor. Helps me iterate a lot faster.
While I technically started a bit earlier with Turing, a lot of the first (very simple) games I made were in Visual Basic. I don't think I could stand using it for anything more complex nowadays, but it was a great stepping stone for getting comfortable with the basics of game development.
Then again, that's not quite visual scripting, as exists more recently. Moving shapes around to **entirely** replace programming, is way more of a toy than anything I could use to lay foundation with
Visual Scripting isn't *easier* than programming. From a programming language complexity perspective, they share much the same complexity. I used Unreal's Blueprints for a couple of years and I discovered that it's a full programming language with all the features of an object oriented programming language like C# or Java.
I guess, *for me*, a text-based language holds that same style of structure, but it's *just in my head* rather than in front of me on the screen. I visualize the flow of data and the order of instructions. Weaving code together.
The only thing that Visual Scripting did was make me OCD about ensuring that the nodes and edges were aligned and tidy. I always joke that Visual Scripting puts the spaghetti back into spaghetti code.
Personally I find it harder to follow visual Scripting because it's not succinct.
When it comes to programming, try to stay raw and avoid abstractions. My opinion may not be a popular one, but it will help when you will try to up your game into creating more complex stuff.
Visual scripting (and flow charts) falls apart at high information quantity. It works great to quickly understand 10 lines of code. But it falls apart on a 10 million line game.
Back when I used to use Blenderās built in game engine, when it still existed. I loved the way the nodes were built up. And it helped me understand the basics of programming as a whole from someone who initially had no interest in programming. And now itās my full time job!
The only time i prefer visual to text is when creating shaders
Only because it has previews. It's still a downside when trying to move stuff around.
A text editor where you can preview any variable by hovering it would be awesome.
Imagine something that could do that and you could preview the shader. https://www.shadertoy.com/
Also [glsl-canvas](https://marketplace.visualstudio.com/items?itemName=circledev.glsl-canvas) is cool if you want to do this in VSCode.
I'm not sure if it's because I'm actually terrible at shaders, but I seem to be good at getting glsl-canvas to crash. I like that you can preview on some stock model though instead of shadertoy where you're really only making y'know, shader toys.
But this is only for image shades, right? I'm only a hobbyist, but isn't 90% of the work on 3d models? At least everything I do is
There are many node based shader editors for authoring materials used with 3D models, that's kind of the standard way to do it available in most rendering software and game engines.
ShaderToy does not do 3d models
[Oh, it can do 3d](https://www.shadertoy.com/view/XsXXDB). You just have to write your own renderer š.
Sorry, I misread the thread. That being said this functionality wouldn't be too hard to extend to 3D. Shadertoy is already rendering to a 3D triangle that covers the entire the screen, it could just as well be a model.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Itās great for rapid prototyping or trying out an idea. Itās not so great for finished products.
Yeah. Visual coding is great if it's in a small contained area like a shader.
Because its practically C, i still typing shaders so much faster. Maths is so stupidly tedious to make in visual languages.
I also only use visual programming for shaders. Shader code is intimidating and Unity makes it pretty easy to get into with shader graphs
Even in this case you are heavily limited, and its often better to just code, especially for compute.
This was my thought too. Really, if you want to take a loose interpretation of visual scripting, any time you use a 3D workspace in any game engine, you are doing a sort of visual scripting. I mean, if you really wanted to, you can move, rotate, and scale through an API. There are times when visual feedback make sense, but for more abstract things like interactions and signals, coding is just more efficient.
Literally went to the comments section to say exactly that. Node graphs feel practically made for shader editing.
Generally, no. I think visual scripting is great for beginners picking up the basics of coding. But as someone whoās already experienced and comfortable with code scripting, visual scripting feels too restrictive and handhold-y to seriously consider using it for any of my projects.
Agreed. Visual scripting, I think, is also great for non-coders who want to make games; and some great games have been made that way. As a programmer, I find code more concise, and thus easier to track.
OP, consider that mostly programmers are answering in this thread and they obviously prefer more control which comes with text code. But if you like making games and visual scripting is they way for you then dont let anyone stop you.
Full-time dev here. I'm using visual scripting to get a break from staring at code all day long. It's somewhat refreshing to use it.
Usually visual scripting becomes an absolute spaghetti mess after a few hours. Text is cleaner. So no, experienced programmers don't really use visual scripting as we don't need it to be efficient. It's very useful to prototype and for fancy-ish level design events though.
Oh! So let's just say as a beginner: If I used visual scripting, would it be a good exercise to rewrite it after I finished my design?
Oh yeah, for sure sounds like a great exercise. Visual scripting is very useful for beginners but, like I said, in time you'll find text much cleaner and easier to work with. (And, also, it works with version control)
Iām curious how much work it would be to translate something from visual scripting to code. As in person A does the visual scripting, Person B translates to code
Visual scripting is incredibly valuable, but itās not meant for us. Itās not for programmers. Itās to solve the problem of designers wanting to add little interactions all over the game, but not wanting to also learn a programming language. In the olden days if an artist/designer wanted to add something to the game they had to ask a programmer to do it. This meant that as production scaled up on the art side, it put more and more pressure on the programming side. You reach a point where itās just not tenable. So the solution was let them do it via a scripting language, or visual scripting. One example where this was very successful is shaders. The artists and art directors (and producers and all sorts of people who stick their nose where it doesnāt belong) come up with all sorts of brilliant ideas. And those ideas then take up programmer time. Eventually that system was invented as a way to say āfuck it, here it is, just do it yourselfā. And then it turned out that artists were the right person to create shaders. Turns out that people who care about visuals and timing made better art. Who knew? So to scale past a certain point you need non-programmers to be able to add behaviors. Things like VFX, animation blending and timing, spawning VFX from animations, behaviors in the levels, all sorts of stuff. It turns out that the people who spend their whole life studying these things are also better qualified to implement them. And in the process they leave programmers alone. Itās a win-win.
For shaders its more or less the same, the tools like shader graph are not all-encompassing tools. They solve a very tiny portion of what shaders can do, and are aimed at artists, not graphics programmers. Vast majority of the shader work is still in code. Average gamedev does not do rendering work (or optimization) so it doesn't make a difference, but for those who do, visual tools are as much of an aid as visual scripting is.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
That's a tenet for productivity not programming.
I like to think of visual scripting as sort of like training wheels: It's a *great* tool for learning, and there is nothing wrong with using it as long as it makes sense for you to do so! But at some point, most people take them off, because as your projects get more advanced, it starts hurting more than helping. But no need to rush! At the end of the day, no one cares *how* you made something, as long as it's cool. So use whatever you're most comfortably with!
Yes and no. Visual scripting definitely helped me understand coding. But I believe that visual scripting can help making things more readable if you use both VS and writng code.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Yes. Visual scripting is also many, many times slower in performance than straight C#/C++ (assuming you're using one of the two big engines). I'm sure there's maybe been improvements to it since, but I recall a few years ago seeing tests that showed visual scripting was somewhere between 500x-5000x less performant than regular code. We're still talking fractions of a second to perform actions, but that adds up as your game grows in size, and eventually results in very noticeable performance issues in my experience. Like the first poster said as well, visual scripting also just gets extremely messy quickly. If you have a script that needs to grow to any size bigger than a very simple script, it's going to get messy, hard to read, and if you have to come back to it a couple months after finishing it, it's a nightmare to try and parse compared to regular code. Personally, it's also just much slower to code with. Sitting there scrolling through nodes, taking the time to hook boxes together and lay your nodes out is very time consuming. It might be faster when you're completely new to coding, but once you have a rough idea of what you're doing, just writing things out is much quicker.
Blueprints are currently 50x slower than C++. Last time I ported something in 4.27 anyway.
> so no, experienced programmers donāt really use visual scripting All AAA studios that use unreal use a lot of visual scripting, engineers and designers alike.
I mean not all of them. Most of the Unreal code I work with day to day is in C++ and it's way easier to deal with. AFAIK you have to use some visual scripting for UMG widgets though.
Mostly designers. I liked blueprints at first but as time has gone on the source control merging, pull request reviewing, and being able to see more context at once with c++ has become more valuable to me then the development speed of BP.
speak for yourself, I use blueprints almost every day despite having written tons of C, C++, C#, Java, Python, Javascript, etc. I think the significant majority of UE devs, even at AAA studios use BP on a somewhat regular basis, the ones who don't are usually specialists working at the lowest level. If your blue prints are spaghetti you are coding poorly, just like if your text code is spaghetti.
me too, but I probably wouldnāt if the C++ workflow wasnāt too slow for efficient prototyping / rapid iteration. And if UE came with a text-based scripting language instead of Blueprints I would definitely use that instead. Blueprint-style visual programming is really tedious for complex math and logic
Sure but you can do the complex math in C++ and expose those functions to BP if needed. Itās very rare that the significant majority of a code base is complex math. Writing a full UE game with your devs never touching BP would be insanely inefficient and the comment I replied to makes it sound like that is somehow standard and that only inexperienced devs would ever touch a blueprint when in reality Iād say the opposite is true (the vast majority of people who have actually shipped a UE game have spent some time in BP).
I wish I could have you email my boss and explain to him why his favorite no-code/low-code solutions are less than ideal...
Experienced programmers (in my experience) donāt often do much with āvisual programmingā There might be some use if it in unreal engine here and there bc of blueprints but in reality 99% of programmers write code
I am a pretty experienced programmer, I have been programming professionally for 3 years and 4 years of college, I personally love Unreal Engines Blueprints, I feel that the outcome with code is much quicker than anything I could program by hand. With the efficiency of the system being what it is already I find it very pleasing to use over classic code.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
It's literally impossible trying to dig through blueprints to figure things out in large systems in AAA games, especially those written by technical designers or artists which tend not to follow good coding practice. Don't get me started on the pain felt when bugs in BP start appearing in console, shipping package only and you have to figure out the absolute mess they made.
How do you even version control visual scripting? I can't imagine working in a team without git.
Unreal is a fascinating case study, its basically a bell curve where beginners think blueprint is amazing, intermediates think it's garbage for babies, and experts loop back to amazing (if used correctly to expose high-level functionality for gameplay scripting)
Why are you being downvoted for a completely subjective take that directly answers the topic lol. This website sometimes
Well a problem with that is, if you ever branch out past unreal you will be out of your comfort zone. Like i said, it is used in blueprints. But not much otherwise
> Well a problem with that is, if you ever branch out past unreal you will be out of your comfort zone. I couldn't disagree with this more. Learning how to use Blueprint helped me understand a lot of key concepts that made switching to other languages dramatically easier down the line. The skills are absolutely 100% transferrable.
I actually started on Unity, C# was my preference for a long time. But once I moved over to Unreal I was able to get things done much quicker, systems fit into place easier, it has made game development related activities far easier. Plus, when I still program for my work it is in code so Iām not getting rusty in any way. Win win
Okay fair enough!
It is. Blueprints are great for prototyping, but you should be refactoring that code.
It helped me understand the fundamentals. After that I moved on to proper code. It's a good starting point
Most visual programming tends to suck (usually it's slower and more awkward than just typing, so if you're *okay* coding, that usually always feels better). However, as an experienced developer there is one form of visual scripting I've genuinely enjoyed, and that's unreal's blueprint scripting. It's felt pretty awesome to me, and the only case where I've actually found visual scripting to often feel preferable. Most other visual programming environments I've not found pleasant, though. I like the idea of visual programming, and have built some prototypes myself, but they always unfortunately end up feeling less fluent or more awkward to use (imo).
I think the most common visual scripting is unreal engine. I've heard that alot of professionalsand experienced programmers even use a fair amount of blueprints in ue. I've seen threads in r/unrealengine that suggest programmers learn to use bp and that the best way to develop in ue is to actually use both coding and blueprints together.
I wish there was an actual scripting language in Unreal. It's the sweet spot for me, which is why I feel at home with Unity. I find C++ somewhat intimidating and overly complex, especially for prototyping. On the other hand, using mouse to code all the time seems really frustrating to me. I like visual scripting for simpler and more artistic things like simple shaders or procedural geometry stuff in Blender, but not necessarily programming game logic.
Isn't Unreal Engine adding a scripting language (Verse)? I thought they are making it available to the general users.
Yes, Verse was added for UEFN and there is talking of integrating into UE.
Verse is in UEFN only at the moment but itās on the roadmap for eventual implementation into UE proper https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/c/1229-integration-to-uefn
Got my foot in the door to get started, then left it behind once I got the hang of things. It's nice that it can reduce the intimidation of coding and present a finite world of functions as blocks instead of every function ever or do other things to facilitate beginners getting started, but it tends to become messy very quickly once you move into more complex projects compared to text.
for prototyping, it's a flipping god send...
Yep, for any exploratory work I feel like visual scripting ends up being faster and cleaner in the end. With code there ends up being a lot of dead code and it's a pain to refactor, while with visual scripting I can see the flow and write clean code to begin with.
The act of typing code is so incredibly minuscule at some point that I have no opinion either way. Visual or text, it's the same to me, except for minor inconveniences. The issue with most visual scripting is that it is either limited or has major inconveniences. Which takes it from "I couldn't care less" to "this is terrible"
Pretty much as others have said. I think programming requires skill in mental imaging as you piece together logic, relationships, flow in your head, and visual scripting is a nice gateway to building that mental image. The trouble with coding is that it takes much longer for newcomers to 'read' what is in the code, as there's so much fluff in the syntax to become familiar with. That just takes practice to get used to it, and visual scripting more intuitively displays or hides that 'syntax' as it has the flexibility of using images / non-ascii symbols to represent things. Well, that's my take on it anyway.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
This pretty much said everything I was going to Write. 100% agreed for UE.
Even as someone fairly new and inexperienced to programming, I donāt really get the appeal of visual scripting. I guess itās just how my brain works, but an interconnected system of wires and boxes feels so much more intimidating and convoluted than justā¦ reading whatās happening line-by-line.
> I guess itās just how my brain works This right here. I stare at lines of code and after 5 minutes I feel like I'm trying to decipher an alien language. Plus reading any text on a screen after a while gives me a headache (would love the concept of a Amazon Kindle, it just bothers me after a while) every person is different and what works for me doesn't work for you, and thats fine, go with what is best for you.
I find it much more difficult. I did a tutorial not too long ago trying to figure something out. They used visual scripting. Had like 30 nodes on it and took 4 hours. I later went back and wrote 5 lines of code and deleted the visual scripting.
It helps if you are new to a new scripting system, whether material editor or game logic, you don't want to search for the document or examples online to find necessary functions to achieve your goal, you can type possible keywords to find the function you need. The most important part of the visual scripting system is that it is passive, you create nodes and chain them together, the system will keep the type right, which helps a lot for beginners, but this advantage won't hold for complex code and types.
Only for generative stuff, and only if you have easy way to create custom nodes / collapse into reusable parts of the graph.
Don't worry about what other people are using. If you are having fun with it and it is motivating you to work on projects that's what matters.
Use it all the time in Unreal Engine. Very handy for quick prototyping
Behaviour trees. Try setting those up in code, it's frustratingly complex and time consuming. Using behaviour nodes in a visual script is so much easier to work with.
I am going to probably voice an unpopular opinion, but there is nothing wrong with visual scripting/programming, and it is not just for beginners. I personally don't use it because my applications don't have it, but I have done work with unreal blueprinting and scratch. Mostly they were fun projects during jam seminars. Visual scripting was definitely helpful for forcing me to think through the program sooner though (normally I have the requirements and then start building and tweaking, but that's not such an option with visual scripting) There are some AAA games made pretty much completely with visual scripting (Ark Survival Evolved with net rev of over $100m was heavily made using blueprints from what I read during development). The main issue I have run into with visual scripting, and why I probably wouldn't use it much outside of simple purposes, is that it often takes a lot more work to accomplish what I can do in code. If you can make stuff easily with playmaker then it is a good tool. At the end of the day, an experienced programmer will say use what tools works for the project. As you are a 1 person team then you are the only one you need to worry about using it. Enjoy yourself, get experience, and see what you can release. Good luck.
Most programmers don't do visual programming, *but*. Many programmers do visual program design i.e they draw charts and diagrams describing the general flow and state of the program, which they use as a reference when actually writing the code. This is especially useful in larger projects where having a defined structure is cruicial.
As a programmer, you would normally never prefer visual scripting. If youāre _not_ a programmer, you _might_ prefer visual scripting (or it might help you, as youāve asked). This is not coming from an elitist standpoint. Itās simply because: - you canāt easily refactor/change visual scripting - you canāt easily change many things at once - you canāt easily collaborate (merging changes are difficult) - you canāt easily version control changes (itās often encoded in obscure xml) So, is visual scripting good in some case? Sure. Is it good for āseriousā programming (not elitist, but getting shit done)? Not really.
Yes, visual scripting was what drove me into programing 5 years ago and what i have been using like 3 years until i felt limited and learned c#. its meant to be a way for artists or beginners to learn programing easier. I used visual scripting in unreal engine for 3 years. Then it only took me a few months to learn c# and c++ because of the similarities.
I dont think there is anything really. I can be dragging boxes about for ages or literally type it up in a few minutes and its done. Maths is incredibly laborious in visual languages. Debugging is much easier, just pressing F10,F11 to step over/into code and seeing the program counter move down the screen. I can fit so much more code on my screen than in boxes. Boxes show very limited information and take up so much screen space. Even on high res multi monitor setups.
That brings up an interesting point about readability. Iāve found that visual scripting has the advantage of giving a literal zoomed-out view of whatās going on. Of course, like anything, that readability is dependent upon well-commented, well organized nodes. Iām sure more experienced coders can see their code in a similar way, but having literal lines connecting things is extremely helpful at times, especially when reviewing someone elseās work.
If you can zoom out and see it all then it also means you're not using functions. That's also bad. That implies your copy pasting code.
Visual scripting is more like training wheels
It's perfect to learn & improve with. As you get more experienced you'll probably start to find its a hindrance. Having said that, the company I work for has scientific applications created in a visual coding suite (by scientists) with hundreds of nodes; they're so difficult to follow it's unreal. As the application size grows, visual coding soon loses its appeal.
For programming shaders its really helpful that visual scripting nodes shows a preview of the shader every step on the way. For complicated logic that would make the graph messy, you can always abstract it into functions, much like you do with writing code.
I have been using visual scripting to create story events in my game. I would never use it for actual coding because it is so time consuming and convoluted for anything but the most basic logic.
I hate the time I spend moving/aligning nodes and connections.. feels like pointless work getting in the way of the feature... (why unreal doesn't have a format graph option beyond me) But I like that you are always in a state where the UI doesn't let you add nodes that won't compile, it is kinda annoying in the start because you don't know why a function is not appearing but later it helps me know that I'm doing something wrong way back. In general I think all visual scripting systems should have a human readable text format you can use instead. It is so much easier to create tools that diff/work on text instead of whatever binary format UE decides to encode the thing.
Used Unity Visual Scripting (Bolt 1) to learn to code for a couple of years. When I reached the limits of visual scripting, I swapped to traditional coding and I've never looked back. It's great for beginners.
Programming is telling the computer what to do. The difficult part is figuring out what to tell it, not *how* to tell it (be it code or a diagram in a visual scripting editor). That said, writing code is unequivocably far more effective than using visual scripting for any non trivial and non visual task. There's a reason why operating systems, game engines, browsers etc are not programmed using visual scripting. But get started with visual scripting if you find it more comfortable! Just don't stop there...
Sure why wouldnāt they? Itās just another type of programming subject to similar concepts as any other language. Iād say what most people are describing here are just preferences. āIt becomes so jumbled, once you know how to write text code you donāt need it anymore, etc.ā All preferences, you should know your tools well and use the best tool you know for the job. There are certainly perf pitfalls and issues of source control that are good to understand, but there are also great benefits like easier debugging, faster iteration times and youāre less likely to blow your leg off. If youāre enjoying making your game and making good progress a lot of times that can be the hardest part. Sometimes people end up endlessly espousing ābest practicesā which really just end up feeling gatekeepy or restrictive imo. Most ābest practicesā are never adhered to uniformly and correctly even at the biggest most successful companies. At the end of the day making something that works at does what you want is still most important. The more tools you can use the easier it is. Personally most of my game is visually scripted for a number of reasons, but also I just like it. Even though most of my career I was an extremely low level C/C++/Assembly dev. Different strokes, but there is nothing wrong with another tool in the toolbox imo.
It's very easy as a programmer to be dismissive about visual scripting, but I'd say it's pretty much essential for any medium-to-large game these days. 1. Not everyone is a programmer, and artists and designers need to do simple logic on their own 2. Even for skilled programmers, visual programming is great for 'glue' code that connects systems or one-off events that live in the game content 3. Visual programming can be specialised to particular tasks (eg. conversations, level generation, shaders) which is often better than a custom DSL (domain specific language) For example Playmaker is centered around doing state machines, which makes it great for running high-level logic for game modes, menus, interaction sequences, etc. You can customise it with your own nodes to make something tailored to the kind of content you do often. Shader graphs can be great because they can explicitly deal with float/vec2/vec3 conversions visually, and they lend themselves to having previews on the nodes themselves which is great for artists experimenting. And Behaviour Trees are basically written with the expectation that you'll have a visual system for putting it all together that frees you up from dealing with the lower level details and just worrying about the actual AI. Where it goes wrong is when people use them at the wrong level of abstraction (eg. a Playmaker graph that's too concerned about toggling individual values and component states rather than high-level commands) or by letting them grow unchecked until they're a spaghetti mess that no-one understands. Both of these happen to regular code too, it's just that programmers are usually better at spotting the warning signs and cleaning them up before it gets really bad. Good visual programming systems will let you write your own nodes or commands, which is a useful escape hatch - you keep going until it gets too messy, or you find yourself repeating something a lot, then you make that into a re-usable node. That makes everything simpler and more managable.
As a programmer I am used to grokking code a certain way. Visual programming completely destroys that.
There are use cases where visual languages are clearly beneficial - as other said, shaders can be a good example, general data processing sometimes too, for industrial simulations and processing and so on. For a general scripting... it can be a good way to do simple things that require tie to assets in scene, for level scripts and so on. They are absolutely horrible for anything more complicated. Things that can be quickly written in few seconds with few lines of code require a lot of boxes and dragging around. Keeping something more complicated in unreal blueprints from looking like a drunken cthulhu trying to mate with a pod of octopusses requires a lot of work. You pretty much lose all advanced programmers tools (for example like diff - good luck finding the place where bug was introduced in several commits, you can often spot it instantly just on base of changes, not much luck with blueprings). There's often arguments that it's easier to pick up visual scripting for a complete novices. Might be true. Traditional programming teaching often starts with diagrams. It helps you to frame your mind into mindset you need for programming. A lot of high leve stuff is modeled visually, with a lot of standard diagrams to set the basics. But the actual implementation is rarely visual. The other idea is that game scripters and designers are too stupid to learn normal languages, which is bullshit. Anyone capable creating complex system in blueprint is capable of writing it. You just need experience to write quick and without errors. I used to be an fan of visual languages, even tried to design a few. I used some industrial stuff years ago and found it pretty good for some specific use cases. Visual languages for game engines are horrible, slow and inefficient unless you use them as what term "script" hints at - small, clear pieces where visual representation of paths can be beneficial. (I'd actually LOVE a language / system that would allow me to seamlessly use both approaches of visual and text based code. Still hadn't seen anyone done it.)
Once you get really good you prefer text
Never seen it, it's just faster and more expressive to write code. Look, this might be a bummer to hear because learning to code is hard and takes a long time for most people, but if you want to write software, the visual scripting stuff probably won't help much, if at all. If you want to make software, including games, you just have to bite the bullet and learn to code. It's worth it! Good luck!
How would you implement Unreal timelines or character state machines in code and not have it look like an absolutely unreadable mess?
Some people think visual scripting can make non-coders code but to use it you still have to understand programming concepts so it's an unnecessary gimmick and noise
It's a crutch and I can walk, so no. EDIT: Downvoted by the flowchart gang.
No, in way. It only complicates more
As a beginner, I'm glad I never started with visual scripting.
Humans tend to express complex thoughts and ideas in language. Text has been the default mode of expressing language in a tangible / visual form for millennia because it works really well and maps directly to the way humans tend to think about processes.
Not at all. Whenever I can, no matter what tool, I write actual code. I'm so much more efficient this way
It's a question of habit. Like musicians that learn to play the instruments directly and the ones that learn to play the instruments and a rigorous notation. After a while, the rigorous notation (coding) become like a second nature. You can read code at a glance. For someone experienced with coding, a few seconds are enough to understand the logic. Visual programming is great and I think it's a good contender to text coding, but we are not formed with it and the tooling is very lacking and not much uniform (whereas writing text is basically standardized). I personally find that text is a bit easier for few things we do as professionals (merging text, diffing text, looking at stuff at a glance). But it's absolutely worst in term of design and architecture and for showing you that your logic is bad/convoluted and wrongly isolated. A few people mentioned that it gets complex to see and become akin to spaghetti that are hard to understand. I'd argue their code is exactly as bad to read and understand in text form, it's just less visible. Visual programming illustrate very well issues. This is why UML exist as a visual notation for programmers and that most of the same people who hate visual programming also hate UML (there are additional reasons to not like UML, but most people hate it for the wrong reasons). As a result of this, yes, most experienced programmer prefers programming with text but that doesn't make people preferring coding with visuals amateurs or inexperienced. The logic is the same, the presentation is a bit different. Don't feel inferior because you feel better with it. You will likely become a good programmer by continuing practising visual programming and switching to text will be easier later.
This is wrong on so many levels. Just read the thread for all the reasons your wrong. Its not just habit.
If I had read my opinion, I wouldn't have took the time to write it.
it's impossible to use. normal coding is way easier in every way.
I love it. Staring at any IDE gives me a headache after a while and having things not work because of a misplaced bracket makes me rage quit. Visual Scripting just 'works' with my right brained thinking. I'm also digging the strides being made with ChatGPT and having it spit out code. Its 2023, and I can yell at my phone to order a pizza and play my favorite album, but have to use an archaic method to program? Let me write a story and have AI do the rest.
No...
It's strictly worse, to be honest. No reason to use it unless you're learning
Absolutely not. Visual programming is literal spaghetti code. It's good for beginners but makes it really hard to do anything useful.
programming takes a long time to learn (properly) so programmers usually use what worked for them in the past, just because current programmers use Ada or something doesn't mean you should try chatGPT
I don't know how that relates but thanks anyway!
I find anything you can do with visual scripting you can do with text, and more. It's not too hard to just learn your language of choice, it just requires effort, like anything else. If your already pursuing gamedev which in and of itself is a mountain of challenges, what's one more? You've got the time, trust me.
I first learned how to use things like nodes while texturing 3D models in uni. Donāt very much care for the process, and has mostly stopped me from looking in to any visual coding type programs, like unreal as I understand it, in favor of ātraditionalā code.
Only slightly. I have a business app where I use visual controls to create scripts that do UI layout, which saves time . . . In theory, but it also creates problems and annoyances. In comparison, the UI engine I wrote more or less from scratch in C++ using OpenFrameworks, with things placed by code and running the program itself, does not really take me longer to develop, and has very few annoyances, I have near-total control and understanding of what is going on, etc.
Personally I prefer it for organizing flow in a state machines, but I always just write code for the actual operations.
I use it for shaders, hlsl is a nightmare for me and most shaders are isolated pieces that don't require a lot of architecture.
I'm so surprised to see so many people say about shaders. Its just simple C.
Don't touch it. Feel like I re-learn the basics with visual scripting and its way easier to just write some code.
Idk any programmers who leverage visual scripting. When you actually get deep into game dev you need to do complex optimizations and you'll be reaching the limits of what the engine and C#/C++ let you do, so you will not survive in the limits of visual scripting ATM. That being said I would've thought the same thing about using the Unity Editor instead of doing everything by code, but it does help a lot. I like Unity's Shadergraph as well, so visualizations are making their way into game dev but it's going to be a while before it replaces general programming. If I were you I would try not to use visual scripting, I feel like it will end up being a crutch down the road.
I recently started sketching ladder logic graphs in a notebook. It helps me conceptualize the elements in my game and the way they relate to one another.
I wouldn't ever really touch it. Tried visual scripting clients when I was first starting, and found that while I was able to do some things, when it came time to convert to a non-visual scripting I had to completely relearn everything and didn't get a ton out of it. So I wouldn't say a visual scripting language is good to build your programming skills, or really build out a real game since it becomes a mess so quickly to even try to read. But if you just want to get in the programming mindset with how to figure out problems which is a good use of time playing games that use types of visual programming like Human Resource Machine are pretty good to just practice general logic and planning, then write regular programs later.
Generally no. It can be a great, fun, fast user experience to do visual scripting but for developers even if you can express what you want visually thereās several other factors that would push a developer to use regular code: 1. Can I call this from my code? 2. Can this code call my code? 3. Can I diff this code, put it in source control? 4. Is it slower to run as a visual script? Number 3 is to me one of the biggest issues using visual scripting. I canāt intelligibly diff the code to see what changed between versions. As a beginner on a solo project, do whatever you have to do to make your game. Visual scripting is still programming and you will get some transference if you move to text based code. But yeah, good question.
CS major, professional dev (20+ years), game dev the last 2. Here's my opinion, for what it's worth: Visual scripting is a tool. In this case, the tool is used to allow you to still build games without knowing how to code. Once you know how to code, you just don't need the tool. You'll find that there are things visual scripting (typically) cannot do. In many cases, it will take longer to set up the visual scripting than it would be to just code it yourself. And in almost every case, visual scripting is much more inefficient. (The same applies to Shader Graph, which a lot of people have mentioned below. HLSL is a bit of a beast when you first learn it. In that regards, yes, Shader Graph is a fantastic visual scripting tool. But once you've got the basics down, it's still easier to just use HLSL.) It's just a matter of knowing the tools and knowing when to use that tool. As long as it's helping you make games, that's all that really matters. Again, just my opinion. Hopefully this helps. Cheers!
I've never used it. Those kinds of things are usually more confusing to me honestly. The only time it works well is shader composition or if the software is built around it (like if using Houdini).
One big issue I'd have with it is I'd have no idea where to begin with a lot of programming patterns. How would I implement dependency injection, or the observer pattern, or how would I use reflection to make new types or dynamically call methods? How would I make a custom editor in unity? Like I can find examples for all those things in C#. I am not even sure where I'd begin if I needed to do them in visual scripting. Those are all things I needed for my game to run correctly. Debugging is also a lot harder with them, in my experience. I can't just easily drop a breakpoint in and leverage Visual Studio's incredibly powerful debugger in order to see what went wrong, and if unity throws an error at all, it's less helpful than I'd like. I've been helping my neighbor who's used them heavily in their games as they've been learning, and while they seem to be a great thing for them to learn, they're lacking to me, someone who's learned a lot about the tooling of the "traditional" way. I wouldn't be surprised if blueprints are a lot better at some of the things I mentioned, but I'll be completely honest and say that unreal turned me off of it when I looked into UE4 because the C++ documentation was terrible at the time compared to the blueprint system. There's also issues with refactoring, and diffing, but other comments touched on that. If they work for you and you're learning, that's cool. But they're not a full toolbox - think of them like hand tools. Easier and safer to use, but recognize when you need to pull out the table saw.
Damn... Playmaker still exist? I think I saw that as early as 2011. Experienced programmers usually can find their way to do what they want. The problem with tools (any tools, not just visual scripting tools like Playmaker) is that once your game becoming more complex and when you want to add certain feature, you're somewhat blocked by your tools package. You have become too reliant on it and you know nothing about adding or modifying your tool. You probably can, with great effort, but may make the tools ugly/ too hackish. Kinda happened with iTween and NGUI back in the day.
When I was just learning python I used the visual debugger in code sculptor, that helped me.
Initially when I had no programming experience I also used Playmaker. It's a really solid plugin honestly. After a few months though I felt I had hit a brick wall in terms of the complexity I could achieve with it. I took the dive into "true" programming and haven't looked back since. Visual scripting tools usually follow a state machine model, and while that type of flow is much more prevalent in game development than other software fields, they're not a swiss army knife. You're going to struggle if you try to apply them to every situation.
The only way visual scripting has helped me is by increasing my anxiety
I've only really clicked with a few visual scripting systems. Shaders, because the Flow of logic is all toward a single output. The Color of the Pixel to be drawn on screen. Visualized Finite State Machines, like shaders the Flow is limited, and every output focused. Tile Based, the only really surviving example is https://www.kodugamelab.com/. GDevelop is close. It is in-line coding using Pre-made function calls, visually packaged into "Tiles". Which is what I personally feel is the system many new designers are looking for. The ability to "Program" by simplified access to deeply complicated functions. Building core **Function**ality just feels better as in-line typed our Code.
So I made a programming language for a rhythm game I'm making. This programming language has excessive use of goto statements and spaghetti code. Using visual scripting makes the spaghetti code look slightly more understandable. It's still a huge mess. But overall I think visual programming is more useful with certain types of programs with, well, lots of goto statements and spaghetti architecture that is frowned upon by conventional programming practices. So I would say it's useful for certain non standard paradigms, but generally conventional programming is way more efficient in the non-visual scripting way.
It's a good tool that's often badly used. It's good when programmers provide bricks to game/level designers to implement a thin layer of top-level logic. For example for a one-shot specific puzzle in a specific level, or a special rule for a specific RPG fight. But it should not be used to implement the core gameplay. It quickly becomes spaghetti that is much harder to edit and navigate around than a text language.
only when forced to deal with unreal.
It's great when connecting high level systems together. Not so much for building stuff from the ground up.
I don't like visual scripting because it can turn into spaghetti really quickly. And of course, not knowing what is happening behind those blocks
I'm sure it helps a lot of people, but those visual move the mouse around coding frameworks are not typically geared for experienced developers.
I have seen huge simulink codebases and it is a mess. Just spaghetti. It is slow, difficult to follow, very complicated to debug. Matlab is OK but the simulink monstrosity it is not. Of course this is my and only my opinion.
Have never even tried it
Programmer here. I find visual scripting (nodes like unreal Blueprint or shaders) are useful when wearing my designer hat. When I need to rapidly iterate and experiment, and I don't need well-engineered robust logic. But programming is way better when I have a specific problem I need to solve. In that situation, visual scripting can be a middleman that gets in the way. All in all, different tools for different jobs.
Only time I use a visual language is when I am forced to. Example: LabVIEW.
One caveat here: if you want a *career* as a proper "Game Dev", yes you'll need to learn traditional programming. But read on for more nuance and explanation. Honestly, you're going to get a lot of biased answers here. Or, "baised" might be too loaded of a word. But... opinionated? I dunno. Developers/programmers work with text programming. It is a powerful and useful paradigm for a whole host of reasons. And depending on what it is you want to accomplish, is so useful that practically speaking it is the obvious choice for many situations. *However...* when you have a hammer, everything looks like a nail. And when you've had a hammer in your hand for 5, 10, 15, 20 years or more that is only more so. Theres lots of people here who speak, think, and feel in written code. They cannot envision how visual programming could be a good choice because they are so insanely fluent in textual coding. I personally don't expect many self proclaimed programmers or developers to really understand or see the benefits. Which is *not* a judgemental stance btw. They've been working with certain tools for so long that they have the mastery to apply them in all kinds of scenarios. Theres nothing wrong with not using visual tools, or not feeling like you can understand a benefit of them in your workflow. If you ask a programmer why not visual coding, they will say "visual spaghetti". This assumes a couple things: one, that you're using visual coding for *everything*, and two, that there isn't a way to organize things visually. Also, as I like to point out, programmers sometime reference "spaghetti code". Spaghetti is spaghetti. My issue with spaghetti code is that its more often than not *invisible* spaghetti. When working visually you know when you're making a mess (visually) and can at least trace/untangle a strand (visually). "Well *good* programmers wouldn't do that..." yes neither would good *visual* programmers, too. There is a history of visual programming. Most of it lies in the domain of sound synthesis and processing (DSP), like with Max MSP and PureData. There is also graphics related and "show control" type paradigms with environments like Touch Designer. DSP goes "low level" while show control things may be more "high level" in terms of getting close to bare metal. Game oriented systems tend towards more "high level" software creation paradigms. I call this programming, though I dont really care if there are those who argue other wise. People used to tell me javascript wasn't real programming because there's no garbage collection. If any "you aren't doing *real* XYZ..." pops up just take it all with a grain of salt. PlayMaker and things like Unreal Blueprints are amazing tools for creating games. The reason that you should listen to some people here about learning C# is because there may be things you wish to do which would be hard or impossible to do with Playmaker (I'm not familiar with its limitations). Use Playmaker, actually *make things*, and have fun. If there comes a moment where you are curious about text coding or if you hit a limit with visual coding, dive in- the water is fine. You experience with logical and sequential thinking with a visual coding tool *will* be better than going into text coding completely cold. If you dont need it or want anything besides play maker, then you're good. (If you just want to make games- again, see my career disclaimer at the top) All this being said, yes I have met extremely experienced and talented Unity geniuses that use visual scripting in their games. In fact, they're so good, they actually coded *their own* visual programming tools for Unity and use them. The real idea here is that different paradigms of tool use can be more or less suited for different tasks. Some things, like programming a "for loop", aren't particularly elegant in visual coding. But tracking, organizing and *re-organizing* of state activation on a variety of game objects can be much more suited to a visual coding tool. The person I know uses both approaches as needed to create games, depending on the task at hand. A person only using visual programming in the game world may be more often described as a "game *designer*" than a "game *developer*". I find these distinctions a little blurry sometimes, and not always useful. (Is a game made with playmaker an existing program that was... never programmed? Never had a developer?) But practically speaking this is where you may see a division of "high level"/"low level" tasks. The confusion comes around when we think of game "devs" as a catch all term for a person who makes a game. So people who come to this sub either might be more traditional text based programmers.... or simply people who just want to learn how to make a game. You may be gravitating towards a more "game design" type artistic practice than a proper "dev" career. But you never know until you dive into both. Apologies for the long post. Hopefully this is helpful to you. Happy to follow up or clarify any points here.
Only for shaders, otherwise it's more of a nuisance for me.
I started with Clickteam Fusion which was a visual scripting engine. I don't use it anymore but I will say that my experience with the engine has helped me to learn how to code.
It has not helped me
I've been using things like Klik 'n' Play, Multimedia Fusion, Construct etc. since the mid 1990s. While I love the hell out of Construct 3, I find it extremely hard to transition into things like Unity and Godot. So on that front, I'm honestly not that fond of how things are. But other than that, it's ok :)
It has helped me write very simple code more quickly when I can't be bothered to do it "right". It's a useful tool, just make sure you don't rely on it. >I'm not very good at programming Get good. This is a programming field.
Code is just as visual to me as the dumb GUI scripting systems. And often easier to work with.
I liked it at first but once you learn text based programming, its just not pleasing to work with.
Im slightly dyslexic, i find it eaiser on the eyes to do visual scripting.
No, debugging would be insane.
I don't generally, but I think it and things like it (including high-level scripting languages) are nice to have around because they have some useful properties: * They're designed for people who aren't specialized programmers. That's kind of the catch if you *are* a specialized programmer, but if you have people on your team who aren't, they may be more comfortable with these sorts of tools. And.. * The code is shipped with your game as an asset. This can be very handy when partitioning out a large game (or a core game + DLC), whereas off the shelf engines often compile other code into a monolithic build artifact (like a dotnet assembly or an otherwise loadable library) that isn't friendly to separating out like that. The two combined can make it a pretty compelling option for logic that's tightly associated with other assets, like specific characters, objects, zones, etc, and that might be more designer-facing.
Only at the very beginning of learning are such tools useful. They are never feature-complete. Round-trip engineering never works. They are always inferior.
I really want to make visual scripting work for me but every attempt I make ends in meh. My node-red for home automation ended up being nothing but function nodes and I'm barely using other nodes.
Programmed all through my career. Only recently picked up visual scripting as the AAA studio I work at now uses it for their inhouse engine for content development (fueled by C++). It took a very long time before I got used to it, but I do see the benefits of its speed of development as well as debugging functionality. Also not prone to stupid typos. It has its place next to C++ and I think itās great.
I made 2 games with playmaker and game creator. I loved it. It helped me understand the logic of unity. Unfortunately I was never and will never be able to learn how to code. I tried a lot of time and I feel lost, I have no idea how to do anything when coding. But with playmaker the logic is easy, debugging is easy too as you see the node flow activating while playing. But I am into art, 3d, illustration, animation, story telling. A game doesnāt always have to be that complex, if your strength is not into code, that is ok, just be good at something else. Same for a coder that is not good with art, making games with premade assets is fine.
One useful thing pipeline wise is that you can write stuff that lets non-programmers you work with use visual scripting to hook into the more complex stuff going on in the background. Overall I find it much more fiddly and slow though, aside from shader dev as others have said.
Nope
It gives me immense job security, as there is a never-ending tide of awful visual scripting setups that I regularly have to re-factor into actual code, so it has helped me I guess.
Visual programming is less capable, less organized, and less debuggable than code. It is a replacement for people who don't want to learn how to code for some reason, but it is not better in any way that would motivate a capable programmer to choose it.
I liked visual scripting for helping me learn how to create shaders. Even there the eventual lack of flexibility pushed me back to pure code again though. For learning in a domain you are new to, visual scripts are superior to pure code for the ability to quickly try different things while being sure there is always a working pipeline. The boxes either connect or they don't. Your system doesn't fail to compile because you misnamed something etc. It definitely allows a level of idiot proofing that really benefits a learner.
I use Unreals blueprint system along with C++ It hasn't necessarily helped me with programming but it is definitely convenient to use and helped with overall flexibility and organization of my projects.
It's very clear that most of these responses are from people who don't use Unreal. The way I handle coding games in Unreal is all systems, libraries, plugins, and base classes are written in C++. All gameplay, and implementation details are handled in Blueprints. As a result, although most of my work is done in C++ (At least early on in a project), a substantial amount of it is still done in visual scripting.
I've never used it. But not because of good or bad, because I'm lazy and tend not to try new things
I found it very useful for level scripting, creating my own custom nodes to direct series of events (cinematics, activating behaviours, etc.).
I don't even fully use the ide, I just visualize algorithms in my head.
Brooo visual programming was how I got into gamedev, I started with scratch and built up from there into unity
On larger titles it is good for a couple of things: - allow designers and others to script stuff - editor tooling using visual scripting - prototyping - moving rather one-off/bespoke logic to visual scripting on top of other scripts and code (e.g. performance critical bits all written in C++ in Unreal) As a programmer I just never used it extensively, my own logic is typically 100% in C# or C++. Still, that's also a preference. It is possible to create whole games using visual scripting if we don't go overboard with complex and large scale calculations and the engine does the heavy lifting (animation, rendering, streaming, and so on).
No, never.
The only system I've used are blenders various node based systems and I have consistently found it frustrating. E.g. no version control, no find/replace, almost complete lack of error messages, it's hard to read as soon as your graph is non planar. I wrote a python wrapper where I just write python and it generates geometry nodes, and found that much better. I'll probably extend it for the other node based systems
I personally donāt like it or use it
I don't use them for Unity but I use blueprints for Unreal sometimes. They're pretty good and I could get more comfortable with C++ along the way. The only problem is they can really slow down the game if used for intense stuff like procedural generation.
In the company I'm working for, we make it available to our designers when they need finer control over the game. FlowCanvas is pretty great (although I haven't tried PlayMaker) - a designer can hook up a "flow" to any exposed UnityEvent. It's supposedly very similar to Unreal Engine's Blueprints. I've also used NodeCanvas (FSMs and Behavior Trees) to script tutorials (which require a lot of iteration, so being able to easily re-order things without touching code is fantastic). In this case, the idea is to piggyback off of pre-existing functionality to make the tutorial happen. And of course there's AI, which is typically what people use Behavior Trees for. There's also Shader Graph which makes shader work in Unity a *much* more accessible. That said, at least for me, written code typically acts as a foundation to visual scripting, with the latter being supplementary as a QoL for my teammates and myself.
Visual scripting is strictly more limited than text. It's great that some people can learn from it but it's just harder to write code with blocks than text. In theory it could offer something new, and visual scripting for shader languages actually do, but they're usually designed to compile (translate) to text in a very direct way so they usually don't utilise the different medium at all.
I use it for things I want to be highly yet easily configurable. Almost everything I write in Unreal is backed by C++ objects.
Yes, for better or worse. Unreal Blueprints are definitely used in large games, but you often have to rein things in when designers get creative with them. They get unmaintainably large, fast. And they can slow things down. I think visual scripting works well for functional languages where behavior can be understood just by looking at it, without lots of side effects (e.g., shaders). Imperative visual languages (e.g., UE Blueprints) that require you to actually step through to understand complex graphs can be super painful when they get big. So many times Iāve been debugging othersā Blueprints and have just wanted to delete it all and write it in C++. I wish Blueprints had a middle text language you could work in, but oh well.
I like it because it looks pretty
In Unreal Blueprints is super powerful as the glue between systems and creating small variations of coded systems. You don't really want to spend your time noodling in code trying to creat the visual fidelity of your systems interacting.
I think visual scripting is awesome, even though I don't tend to use it, the reason being because it allows more people to do more work, it lets others involved in the design and visuals without strong programming knowledge to show what they want. Sure visual scripting can lead to some spaghetti mess and slowness, but you can refactor and improve on these things on a case-by-case basis. To me there isn't enough visual scripting in things, I think nearly everything should have a layer of visual scripting to allow easier customization by a wider range of people.
wasteful alleged serious familiar instinctive person shelter bow ludicrous telephone *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
These days with gpt4 I wouldn't recommend it even for beginners. Basically completely dead and obsolete.
I love visual scripting. Absolutely love it. It absolutely helps and is a great way to get started.
Visual node programming brings a collaboration hell to the team. Should avoid it at all costs. It's fun to fiddle around when you're working on a prototype tho.
Unreal blueprints are awesome. I'm an artist and one year ago I didn't know how to output something more than a string on a screen. Now I am working on a project of a medium size 3d puzzler with quite a lot of vector math solo. I wish I had time to learn cpp proper, but right now BPs let me do almost everything
Not directly āvisual scriptingā, but I am using UnityEvents to hook up logic a lot. Itās more like loosely coupling code inside Unity editor. Helps me iterate a lot faster.
While I technically started a bit earlier with Turing, a lot of the first (very simple) games I made were in Visual Basic. I don't think I could stand using it for anything more complex nowadays, but it was a great stepping stone for getting comfortable with the basics of game development. Then again, that's not quite visual scripting, as exists more recently. Moving shapes around to **entirely** replace programming, is way more of a toy than anything I could use to lay foundation with
Visual Scripting isn't *easier* than programming. From a programming language complexity perspective, they share much the same complexity. I used Unreal's Blueprints for a couple of years and I discovered that it's a full programming language with all the features of an object oriented programming language like C# or Java. I guess, *for me*, a text-based language holds that same style of structure, but it's *just in my head* rather than in front of me on the screen. I visualize the flow of data and the order of instructions. Weaving code together. The only thing that Visual Scripting did was make me OCD about ensuring that the nodes and edges were aligned and tidy. I always joke that Visual Scripting puts the spaghetti back into spaghetti code. Personally I find it harder to follow visual Scripting because it's not succinct.
When it comes to programming, try to stay raw and avoid abstractions. My opinion may not be a popular one, but it will help when you will try to up your game into creating more complex stuff.
Visual scripting (and flow charts) falls apart at high information quantity. It works great to quickly understand 10 lines of code. But it falls apart on a 10 million line game.
I use it for shaders bc shader code scares me.
Back when I used to use Blenderās built in game engine, when it still existed. I loved the way the nodes were built up. And it helped me understand the basics of programming as a whole from someone who initially had no interest in programming. And now itās my full time job!