8:15 I hope you go into more detail about this particular point sometime in the future. It's a point that I often hear state but never elaborated upon. Not to say I don't believe you, but without concrete examples, it's hard for a beginner like myself to understand why this is the case and just comes off as "visual scripting bad", which is obviously not the message you're trying to convey in this video. As a beginner, I really enjoy writing code. But as someone with no software engineering background, I often find it very difficult to script simple things. Most tutorials I've seen that use code don't really "teach" as much as they ask you to follow along, which is great for specific gaps in knowledge but does very little for actually arming newbies with the tools to create things on their own. Obviously, the answer to this is to experiment and hack away at it until you start to understand it, but visual scripting helps with this specific stage because all of my basic necessities are laid out in front of me and accessible with a click. I can see what methods I need, what parameters they take, what data types those parameters are expecting, and what attributes are accessible to me for any given piece of data. These options being laid out in front of me is so much more helpful in making me understand the data I'm working with opposed to writing something badly, Googling an error, and reading documentation, all to still not really understand why what I did initially didn't work. So I often don't feel like I'm learning anything from the experience. Apologies for the long-winded explanation, but this has been my biggest hurdle when it comes to learning code, and visual scripting seems to alleviate this; so, to hear you mention this point really has me wanting to know why you (and many others) say it. Because as you said, one can start with visual scripting and then transition over to text-based code, but visual scripting has its own ways of doing some things that I don't want to rely on too much (like Custom Events, because C# Events make no sense to me) if I'm going to eventually have to dump it.
Sorry, if this sounds condescending that's really not the intention, but many of the missing features can't be made use of by beginners or just won't seem like necessary features - which is part of the reason I left them out. Maybe that was a mistake. I think many folks who get started whether it's with text-based code or visual scripting have the same issue - why would I need to use X or Y? A simple example of missing features is return values. I made a couple videos about creating this functionality with Bolt. It's not easy (actually the most complicated videos I made about Bolt) but is a virtually necessary functionality for a system like Object Pooling to work. Object pooling is a basic optimization function used by virtually all games - not needed for a prototype but almost always needed for a commercial product (even small solo indie games). Another example would be refactoring your code - a common practice and often a requirement when iterating on a design. Renaming a variable in VS can break code as the name doesn't automatically update. The lack of functions, while it could be argued this is a style or VS just does it differently, lack of functions is tough. Functions help with debugging, organization, readability, and reducing the amount of code needed by reusing code. Events are another great example. With VS it's not easy to have objects communicate with each other. Custom Events are okay, but they are akin to public functions but aren't type-safe (you can misspell the name and not know it). While not always a bad thing this kind of coupling is not how you want to engineer your whole project - delete the wrong object and an error gets thrown and the project breaks. Even worse, with VS it can be hard to track down where the error came from. All of this may seem like non-issues to a beginner and doesn't seem to be worth the effort. And, honestly, they may not be worth the time for a beginner. There's a ton to learn and you can only learn so much at a time. But not having access to these tools or not eventually learning to use them will 100% prevent progress. It will result in failed projects, discouragement, and a desire to give up. After all, you've spent 9 months on a pile of spaghetti code, and whenever you add or change something it all breaks. Either you learn and improve or you will repeat your mistakes. There are a whole bunch of tangential topics to this. Tutorial hell. Stages of progress with game development. Lack of teaching from YT channels. Scoping games. Finishing games. Etc. If this isn't helpful or if you still have questions, feel free to jump over to the OWS discord and ping me. I can talk endlessly about this - both as a YT'er and as a real-world teacher focused on my student's success.
@@OneWheelStudio I anticipated that the missing features would be something deeper than a beginner may be ready to try to learn, but the examples you've given here definitely help. I've even found myself complaining about the lack of automatic variable renaming. I started your video on return values in Bolt, and I already see what you're talking about. Thanks for taking the time to write such a robust response. I very well may join the Discord.
One particular example is Saved Variables aren't very good if you want to have a proper save system. It seems like you can't even revert to initial state of the game without clearing PlayerPref, which is a bit silly.
Spend a year on a project and you will discover a lot of little things you can do with Visual Scripting but you will find it is easier doing it in code. As an example, my first project was a cross-platform calculator with lots of input fields and example values a user can select. Selecting example values as well as performing calculations are a lot easier to do in code. The spaghetti on complex graphs can get in the way so coding in C# and incorporating it into your visual scripts sometimes make it a lot more understandable. There is a middle ground here and the answer for me was to learn both but start with Visual Scripting and then learn to code as you grow.
I've been playing around in Unity for about a year and I just started exploring bolt. I think it's great, it has helped me understand C# and game logic as a non-programmer. I enjoy text based scripting too, but bolt has been light and easy to jump into.
I work in unreal a lot and the visual scripting works really well when combined with C++. So I've been exploring if I can do the same thing with unity visual scripting. So far In unity I have found visual scripting works better for simple stuff that would only need 1 line of code or some UI stuff. Also if I get stuck making something in C# I find trying to make the same thing in visual scripting can really help me to figure out a solution. I reckon on a large project you could really speed up some workflows by having designers program in visual scropting and then having a programmer write new nodes and write scripts that tie into visual scripts. Essentialy you switch your programming style from creating scripts that other programmers can understand easily to scripts that anybody with basic programming skills can understand. Thus bridging the gap between programmers and designers which in my opinion speeds up the workflow bigtime.
I have no issues with writing the code. But when I do have the option to go for some visual, I most of the time take it. It just takes a huge load of my brain and makes it easier to both see and know what is going to happen or not happen. I think visual scripting is great, it also opens programming up for those that might be on the edge of learning cause 'Coding looks hard'. This way they'll have a *much* easier way to get started learning the basics of programming; and if they later want to get down and dirty, it'll be a lot smoother.
This is an honest take on this all. I’m still a believer for a truly powerful visual scripting plugin, I learned and do mostly C# since the Microsoft’s XNA days, however I think high level ‘state graphs’ are better suited for a visual representation, “is the game paused?”, “is it in a state waiting for ‘go to next room event’?” And many others… Myself when I start thinking in sequences, the sorts of “trigger a camera shake, wait two seconds, play sounds, etc” I just go with the “FEEL” plugin on the asset store and just start visually stacking all those things: “trigger haptic and random sounds from a list”, “trigger camera shake”, “trigger bloom shake”, “wait for: random between 1 - 2 seconds” (changes each play)”, “trigger a character damage blinking”, “trigger an inspector wired unity event”, etc etc etc instead of adding lines of code for each thing in a single inspector.
I think there are definitely good use cases. State machines are great with a visual interface. I saw the “Feel” asset the other day. Looks good and again a good use of visual interface over purely text based.
I think Unity's Visual Scripting is extremely handy for it's State-Machine feature. It allows the designers to adjust functionality really easily without having to change a single line of code.
First of all thank you for a well thought out and honest video. I've bounced back and forth between Unreal / Unity for various work projects and I've been debating what engine to use for my next project. For it's particular needs Unity feels like it would be the better choice but their pattern of creating half baked features and buying up good add-ons and then screwing them up really makes me hesitant to invest in their ecosystem any further.
Unity's pattern is pretty frustrating, but they certainly aren't the only company to do it. My process is generally to wait until the tool is fully out of beta, generally a 1.x release. This is often years after the tool is announced, but I've learned that when I hear about a new tool to mostly just mentally bookmark the tool for later reference and ignore the hype. I also am reasonably convinced that small development teams or solo folks really don't need the latest and greatest. Those tools are generally aimed at larger teams. Our games should be simple and creative. Through that lens, both Unreal and Unity provide plenty of features and stability in my opinion.
I look forward to where Unity will take it. Given the massive competition on the other side of the fence, I know they would like to have everything up and running with dots, visual scripting, the new unity ui. They will get there but not sure on the timeframe. As for previous Bolt users, I think as long as migration is easy for them then that is what matters. When it comes out the other end I'm sure it will be more popular than it ever was, as long as flexibility isn't sacrificed.
A tool is a tool and only a bad artist blames his or her tools. Visual Scripting is so amazing at teaching how things flow in a programming environment for those of us who need that visual input to grasp things. Just discovered your channel and look forward to watching your videos! It may be a long shot to ask, but I would love to see a video one day on Visual Scripting + Corgi Engine (for those of us who want to make 2D platformers as well as learn to use custom assets in VS).
I fully agree, visual scripting can be a great learning tool! Can't promise anything with more videos on VS with or without the Corgi Engine. I'll keep it in mind - the next few months are crazy busy, but hopefully come fall I have more time.
The reason I don't use visual scripting is because I spend so long searching through long list of variations of "Transform" or "Rigidbody" or "OnCollisionEnter" trying to find the variant that I need and I know that it would be ten times faster to just type it into an IDE.
Tbh, I have been pretty successful in using bolt for creating games. Yes they are very simple, especially when tied together with other assets. There are some things I can’t do, sure, but that’s where I can always go to C#. So bolt is still my preferred method that I expand on.
I loved using Visual Scripting but I got to the point where my games would run at 20 FPS or less and then I discovered that Visual Scripting is about 150-200 times slower than C#. The performance is just to bad so I'm moving on to C#
visual scripting is back it's built-in it called script machine in newer version i still mix visual scripting with c#(VS for only movement and basic collision it's faster); weirdly minecraft command block is the first programming language i learn then javascript(included html and css) then python and now c#
Agree 100%. I started my journey learning Unity with Bolt, but as you said, it is an onboarding tool since I searched for more and had to code 30% of my initial project in C#. So although I was sold on using Unity by that time, I was still getting stuck into learning C# and Bolt. Today I'm in a situation where I have found the best of both worlds building my projects with both C# and Visual Scripting and I'm happy. The only concerns are that Visual Scripting tends to run a lot slower than pure C# but it should not be of concern unless you make computational loops that need to be performed each frame. So yes Visual Scripting is not perfect and I'm also disappointed about the fact that Bolt 2.0 got canceled. ps. Big corporates spend millions on deals buying out good ideas and then ditch the project the moment they have to pay a team to implement it. I'll stop before I go on a rant ;-)
Wonderful video. Thanks for sharing! I think we should all be more open about the struggles that are somewhat inevitable when developing a craft like game making. I've used C# in Unity for more than a decade but I'm planning to integrate visual scripting for a few aspects of my next game. Your experience with students sounds invaluable because you must have seen so many disparate attempts at doing too much with the tech. I'd love to see a follow-up video showing the ways that visual scripting can be integrated with code and where the pros and cons are.
Thanks for the kind words. I have two more VS videos in mind. One to show how to use C# with it and the second expanding on that to use the VS state machine with C#. I think they’d be useful and show, like you suggest, good use cases of VS.
excellent point, excellent video! seems though that there are some that do make games in VS... I mostly just use it for onboarding game designers in some simple programming choices
I'm just curious what kind of functions and possibilities aren't possible within Unreal Engine's visual scripting. What kind of limitations might I run into?
I don't have any experience with Blueprints in Unreal, but I would imagine there are similar issues to other VS solutions. Largely they don't scale well to medium or large projects.
Absolutely what I wanted to hear! And I'm so glad I didnt waste my time with it. (I know what you said in the video) For ME, it would have been MOSTLY time wasted
The theory here is sound but doesn't track in commercial production. Unfortunately, "best practices" are rarely adhered to in the way described. Video game archeology shows this is true regardless of genre, budget, or experience. Action 52 for the Nintendo Entertainment System is an amazing example. Describing Visual Scripting as only appropriate for prototyping dismisses the prevalence of Visual Scripting developed games making money on several digital store fronts. Ultimately, this whole discussion is best summed to: Visual Scripting, as with anything, is excellent at delivering the results that are commensurate to the feature set.
in unreal using blueprints is a common thing. in unity vs made close to unreal is flow canvas. the only disadvantage that other programmers understand only code. so its harder to sell game to another company if it made with Vs.
Is it fair to say that it mostly depends on the game you're making? Like C# is a better fit for RTS or a management game, where there's lots of numbers and logic. And VS is good for platformers or FPS. It seems to me that Cuphead can be made entirely with VS and AFAIK Hollow Knight was made pretty much entirely in Playmaker. I'm curious about specific aspects that aren't possible in VS.
In my opinion no not really. Sure some will types will be nearly impossible and others more possible, but moving a game from a prototype to a polished finished project is REALLY hard and The limits of VS are very likely to show up. That said If you have a C# programmer creating nodes for designers then it is much less likely you’ll hit the limits of VS but that’s not how the majority of folks out there are using it.
Mmm. Not a lot. But the state machine functionality combined with C# could be very powerful. It’s an edge case, but definitely a real one and a useful one.
@@OneWheelStudio i personly use the animator system for state machine my question if want to do quite prototype and stuff on that area visual code is good for that or bold is not a good option for that ?
Now that I think of it: Visual scripting is all over the video game and multimedia landscape. Houdini, Blender, Mocha, Silhouette, Cinema 4D, Godot, and many more. This video is a bit typical for a teacher and over emphasizes the "how" rather than "make it by any means necessary." After 30+ years in multimedia I have learned few care about how you made it, only that it got made.
id say yes do it ,it will get you in the problem solving mindset which is really hard to do if you have taking a break or complety new to programing lets be honest no game dev wants to program if there's a option to do it easy take it lol all that matters is making a game even if it sucks
I stopped using Visual Scripting because of how bad the performance is. My goal is to make large games for mobile, like games that feel like switch games and every time I build a game and put it on my phone and they all run so bad, no matter how hard I try to optimize everything in my games, I just counsel the get even a simple game to run at over 30 FPS
Thanks. This experience from you is really helpful for me. Right now, I am making a game for mobile going to use the Visual-Script( also with c#) for better readability and understanding of the flow of the game's function. If the performance optimization can not be satisfied to above 30 fps on most Android mobile, visual script should not be regarded as an option.
I love your programming tutorials and clean teaching style. I just feel so bad, for you that Unity pulled the rug out from under everyone interested in Bolt 2.0 As a programmer, I've been down C++ roads long before Visual Scripting, but love your thoughts and passion for V.Scripting. Anyways was excited for where it was going, saw a few tutorials from you and others. I started with Visual Basic, would I want/need a stepping stone like Bolt today, WHO knows, you sell that as a great thing, and sad to have such a working alpha and Higher ups go NOPE, not going to make enough money off it, or something!
There is just too big of a gap between visual scripting and regular scripting. I won't get too deep into what I think about bolt but as someone who already knows how to program I find very little use of it if any. Only prototyping for other people and even then it's very limited and slow on top of it all. Unless you are making something very basic and very simple, visual scriping just ain't the tool that will get you those results
8:15 I hope you go into more detail about this particular point sometime in the future.
It's a point that I often hear state but never elaborated upon.
Not to say I don't believe you, but without concrete examples, it's hard for a beginner like myself to understand why this is the case and just comes off as "visual scripting bad", which is obviously not the message you're trying to convey in this video.
As a beginner, I really enjoy writing code. But as someone with no software engineering background, I often find it very difficult to script simple things.
Most tutorials I've seen that use code don't really "teach" as much as they ask you to follow along, which is great for specific gaps in knowledge but does very little for actually arming newbies with the tools to create things on their own.
Obviously, the answer to this is to experiment and hack away at it until you start to understand it, but visual scripting helps with this specific stage because all of my basic necessities are laid out in front of me and accessible with a click. I can see what methods I need, what parameters they take, what data types those parameters are expecting, and what attributes are accessible to me for any given piece of data.
These options being laid out in front of me is so much more helpful in making me understand the data I'm working with opposed to writing something badly, Googling an error, and reading documentation, all to still not really understand why what I did initially didn't work. So I often don't feel like I'm learning anything from the experience.
Apologies for the long-winded explanation, but this has been my biggest hurdle when it comes to learning code, and visual scripting seems to alleviate this; so, to hear you mention this point really has me wanting to know why you (and many others) say it.
Because as you said, one can start with visual scripting and then transition over to text-based code, but visual scripting has its own ways of doing some things that I don't want to rely on too much (like Custom Events, because C# Events make no sense to me) if I'm going to eventually have to dump it.
Sorry, if this sounds condescending that's really not the intention, but many of the missing features can't be made use of by beginners or just won't seem like necessary features - which is part of the reason I left them out. Maybe that was a mistake. I think many folks who get started whether it's with text-based code or visual scripting have the same issue - why would I need to use X or Y?
A simple example of missing features is return values. I made a couple videos about creating this functionality with Bolt. It's not easy (actually the most complicated videos I made about Bolt) but is a virtually necessary functionality for a system like Object Pooling to work. Object pooling is a basic optimization function used by virtually all games - not needed for a prototype but almost always needed for a commercial product (even small solo indie games).
Another example would be refactoring your code - a common practice and often a requirement when iterating on a design. Renaming a variable in VS can break code as the name doesn't automatically update.
The lack of functions, while it could be argued this is a style or VS just does it differently, lack of functions is tough. Functions help with debugging, organization, readability, and reducing the amount of code needed by reusing code.
Events are another great example. With VS it's not easy to have objects communicate with each other. Custom Events are okay, but they are akin to public functions but aren't type-safe (you can misspell the name and not know it). While not always a bad thing this kind of coupling is not how you want to engineer your whole project - delete the wrong object and an error gets thrown and the project breaks. Even worse, with VS it can be hard to track down where the error came from.
All of this may seem like non-issues to a beginner and doesn't seem to be worth the effort. And, honestly, they may not be worth the time for a beginner. There's a ton to learn and you can only learn so much at a time. But not having access to these tools or not eventually learning to use them will 100% prevent progress. It will result in failed projects, discouragement, and a desire to give up. After all, you've spent 9 months on a pile of spaghetti code, and whenever you add or change something it all breaks. Either you learn and improve or you will repeat your mistakes.
There are a whole bunch of tangential topics to this. Tutorial hell. Stages of progress with game development. Lack of teaching from YT channels. Scoping games. Finishing games. Etc.
If this isn't helpful or if you still have questions, feel free to jump over to the OWS discord and ping me. I can talk endlessly about this - both as a YT'er and as a real-world teacher focused on my student's success.
@@OneWheelStudio
I anticipated that the missing features would be something deeper than a beginner may be ready to try to learn, but the examples you've given here definitely help. I've even found myself complaining about the lack of automatic variable renaming.
I started your video on return values in Bolt, and I already see what you're talking about.
Thanks for taking the time to write such a robust response. I very well may join the Discord.
One particular example is Saved Variables aren't very good if you want to have a proper save system. It seems like you can't even revert to initial state of the game without clearing PlayerPref, which is a bit silly.
Spend a year on a project and you will discover a lot of little things you can do with Visual Scripting but you will find it is easier doing it in code. As an example, my first project was a cross-platform calculator with lots of input fields and example values a user can select. Selecting example values as well as performing calculations are a lot easier to do in code. The spaghetti on complex graphs can get in the way so coding in C# and incorporating it into your visual scripts sometimes make it a lot more understandable. There is a middle ground here and the answer for me was to learn both but start with Visual Scripting and then learn to code as you grow.
I've been playing around in Unity for about a year and I just started exploring bolt. I think it's great, it has helped me understand C# and game logic as a non-programmer. I enjoy text based scripting too, but bolt has been light and easy to jump into.
I work in unreal a lot and the visual scripting works really well when combined with C++. So I've been exploring if I can do the same thing with unity visual scripting. So far In unity I have found visual scripting works better for simple stuff that would only need 1 line of code or some UI stuff. Also if I get stuck making something in C# I find trying to make the same thing in visual scripting can really help me to figure out a solution.
I reckon on a large project you could really speed up some workflows by having designers program in visual scropting and then having a programmer write new nodes and write scripts that tie into visual scripts. Essentialy you switch your programming style from creating scripts that other programmers can understand easily to scripts that anybody with basic programming skills can understand. Thus bridging the gap between programmers and designers which in my opinion speeds up the workflow bigtime.
I have no issues with writing the code. But when I do have the option to go for some visual, I most of the time take it. It just takes a huge load of my brain and makes it easier to both see and know what is going to happen or not happen.
I think visual scripting is great, it also opens programming up for those that might be on the edge of learning cause 'Coding looks hard'. This way they'll have a *much* easier way to get started learning the basics of programming; and if they later want to get down and dirty, it'll be a lot smoother.
Subscribed you out of respect for your hard work! Keep pushing
This is an honest take on this all.
I’m still a believer for a truly powerful visual scripting plugin, I learned and do mostly C# since the Microsoft’s XNA days, however I think high level ‘state graphs’ are better suited for a visual representation, “is the game paused?”, “is it in a state waiting for ‘go to next room event’?” And many others…
Myself when I start thinking in sequences, the sorts of “trigger a camera shake, wait two seconds, play sounds, etc” I just go with the “FEEL” plugin on the asset store and just start visually stacking all those things: “trigger haptic and random sounds from a list”, “trigger camera shake”, “trigger bloom shake”, “wait for: random between 1 - 2 seconds” (changes each play)”, “trigger a character damage blinking”, “trigger an inspector wired unity event”, etc etc etc instead of adding lines of code for each thing in a single inspector.
I think there are definitely good use cases. State machines are great with a visual interface.
I saw the “Feel” asset the other day. Looks good and again a good use of visual interface over purely text based.
I think Unity's Visual Scripting is extremely handy for it's State-Machine feature.
It allows the designers to adjust functionality really easily without having to change a single line of code.
I fully agree. I have maybe two more bolt videos in mind. One being using C# with bolt that leads into using the state machine with C#.
@@OneWheelStudio Wow that will be super doper awesome! I can't wait for it!
First of all thank you for a well thought out and honest video. I've bounced back and forth between Unreal / Unity for various work projects and I've been debating what engine to use for my next project. For it's particular needs Unity feels like it would be the better choice but their pattern of creating half baked features and buying up good add-ons and then screwing them up really makes me hesitant to invest in their ecosystem any further.
Unity's pattern is pretty frustrating, but they certainly aren't the only company to do it. My process is generally to wait until the tool is fully out of beta, generally a 1.x release. This is often years after the tool is announced, but I've learned that when I hear about a new tool to mostly just mentally bookmark the tool for later reference and ignore the hype. I also am reasonably convinced that small development teams or solo folks really don't need the latest and greatest. Those tools are generally aimed at larger teams. Our games should be simple and creative. Through that lens, both Unreal and Unity provide plenty of features and stability in my opinion.
You are a great teacher! Straight to the point and no nonsense approach is definitely needed these days. Stay free! I love visual scripting.
😉 I’ve been tempted to rename the channel No BS Tuts or something. I’m rarely accused of using too many words. Glad you’re finding the videos useful.
see I'm at that weird spot where I understand text based stuff, but visual scripting is so much easier to work with because of my brain.
You definitely aren’t alone in that way.
Thank you for answering the questions I never knew I had
I look forward to where Unity will take it. Given the massive competition on the other side of the fence, I know they would like to have everything up and running with dots, visual scripting, the new unity ui. They will get there but not sure on the timeframe. As for previous Bolt users, I think as long as migration is easy for them then that is what matters. When it comes out the other end I'm sure it will be more popular than it ever was, as long as flexibility isn't sacrificed.
A tool is a tool and only a bad artist blames his or her tools. Visual Scripting is so amazing at teaching how things flow in a programming environment for those of us who need that visual input to grasp things. Just discovered your channel and look forward to watching your videos! It may be a long shot to ask, but I would love to see a video one day on Visual Scripting + Corgi Engine (for those of us who want to make 2D platformers as well as learn to use custom assets in VS).
I fully agree, visual scripting can be a great learning tool!
Can't promise anything with more videos on VS with or without the Corgi Engine. I'll keep it in mind - the next few months are crazy busy, but hopefully come fall I have more time.
The visual scipting in gamemaker 2 has the power to make a game as if it were in the code language, albeit less efficient
The reason I don't use visual scripting is because I spend so long searching through long list of variations of "Transform" or "Rigidbody" or "OnCollisionEnter" trying to find the variant that I need and I know that it would be ten times faster to just type it into an IDE.
Same happens to me. Visual Scripting really slows me down.
A less edited blog post for the video: onewheelstudio.com/blog/2021/4/29/boltvscsharp
Tbh, I have been pretty successful in using bolt for creating games. Yes they are very simple, especially when tied together with other assets.
There are some things I can’t do, sure, but that’s where I can always go to C#. So bolt is still my preferred method that I expand on.
I loved using Visual Scripting but I got to the point where my games would run at 20 FPS or less and then I discovered that Visual Scripting is about 150-200 times slower than C#. The performance is just to bad so I'm moving on to C#
visual scripting is back it's built-in
it called script machine in newer version
i still mix visual scripting with c#(VS for only movement and basic collision it's faster);
weirdly minecraft command block is the first programming language i learn
then javascript(included html and css) then python and now c#
This was really honest and well said. We appreciate you!
Thank you.
State machine is good for animations
Agree 100%. I started my journey learning Unity with Bolt, but as you said, it is an onboarding tool since I searched for more and had to code 30% of my initial project in C#. So although I was sold on using Unity by that time, I was still getting stuck into learning C# and Bolt. Today I'm in a situation where I have found the best of both worlds building my projects with both C# and Visual Scripting and I'm happy. The only concerns are that Visual Scripting tends to run a lot slower than pure C# but it should not be of concern unless you make computational loops that need to be performed each frame. So yes Visual Scripting is not perfect and I'm also disappointed about the fact that Bolt 2.0 got canceled. ps. Big corporates spend millions on deals buying out good ideas and then ditch the project the moment they have to pay a team to implement it. I'll stop before I go on a rant ;-)
Wonderful video. Thanks for sharing! I think we should all be more open about the struggles that are somewhat inevitable when developing a craft like game making. I've used C# in Unity for more than a decade but I'm planning to integrate visual scripting for a few aspects of my next game.
Your experience with students sounds invaluable because you must have seen so many disparate attempts at doing too much with the tech. I'd love to see a follow-up video showing the ways that visual scripting can be integrated with code and where the pros and cons are.
Thanks for the kind words. I have two more VS videos in mind. One to show how to use C# with it and the second expanding on that to use the VS state machine with C#. I think they’d be useful and show, like you suggest, good use cases of VS.
excellent point, excellent video!
seems though that there are some that do make games in VS...
I mostly just use it for onboarding game designers in some simple programming choices
I'm just curious what kind of functions and possibilities aren't possible within Unreal Engine's visual scripting.
What kind of limitations might I run into?
I don't have any experience with Blueprints in Unreal, but I would imagine there are similar issues to other VS solutions. Largely they don't scale well to medium or large projects.
Absolutely what I wanted to hear! And I'm so glad I didnt waste my time with it. (I know what you said in the video) For ME, it would have been MOSTLY time wasted
The theory here is sound but doesn't track in commercial production. Unfortunately, "best practices" are rarely adhered to in the way described. Video game archeology shows this is true regardless of genre, budget, or experience. Action 52 for the Nintendo Entertainment System is an amazing example.
Describing Visual Scripting as only appropriate for prototyping dismisses the prevalence of Visual Scripting developed games making money on several digital store fronts.
Ultimately, this whole discussion is best summed to: Visual Scripting, as with anything, is excellent at delivering the results that are commensurate to the feature set.
in unreal using blueprints is a common thing. in unity vs made close to unreal is flow canvas. the only disadvantage that other programmers understand only code. so its harder to sell game to another company if it made with Vs.
Is it fair to say that it mostly depends on the game you're making? Like C# is a better fit for RTS or a management game, where there's lots of numbers and logic. And VS is good for platformers or FPS. It seems to me that Cuphead can be made entirely with VS and AFAIK Hollow Knight was made pretty much entirely in Playmaker. I'm curious about specific aspects that aren't possible in VS.
heartstone made with playmaker too
In my opinion no not really. Sure some will types will be nearly impossible and others more possible, but moving a game from a prototype to a polished finished project is REALLY hard and The limits of VS are very likely to show up.
That said If you have a C# programmer creating nodes for designers then it is much less likely you’ll hit the limits of VS but that’s not how the majority of folks out there are using it.
Love your video
yes that is good and all but for people like my self that already know how to code is ther eny reason to learn unity visual code ?
Mmm. Not a lot. But the state machine functionality combined with C# could be very powerful. It’s an edge case, but definitely a real one and a useful one.
@@OneWheelStudio i personly use the animator system for state machine
my question if want to do quite prototype and stuff on that area visual code is good for that or bold is not a good option for that ?
@@watercat1248 It just depends. Give it a try. I'm faster with C# than with visual scripting. For some folks it's the other way around.
@@OneWheelStudio okay thanks
Now that I think of it: Visual scripting is all over the video game and multimedia landscape. Houdini, Blender, Mocha, Silhouette, Cinema 4D, Godot, and many more.
This video is a bit typical for a teacher and over emphasizes the "how" rather than "make it by any means necessary." After 30+ years in multimedia I have learned few care about how you made it, only that it got made.
The question is, you need use visual scripting? Nice vídeo
id say yes do it ,it will get you in the problem solving mindset which is really hard to do if you have taking a break or complety new to programing lets be honest no game dev wants to program if there's a option to do it easy take it lol all that matters is making a game even if it sucks
I just reached the day where I need to move on
It does eventually come. But that also means you’ve stuck with it so congrats! You’ve made it further than most.
I stopped using Visual Scripting because of how bad the performance is. My goal is to make large games for mobile, like games that feel like switch games and every time I build a game and put it on my phone and they all run so bad, no matter how hard I try to optimize everything in my games, I just counsel the get even a simple game to run at over 30 FPS
Thanks. This experience from you is really helpful for me. Right now, I am making a game for mobile going to use the Visual-Script( also with c#) for better readability and understanding of the flow of the game's function. If the performance optimization can not be satisfied to above 30 fps on most Android mobile, visual script should not be regarded as an option.
I love your programming tutorials and clean teaching style.
I just feel so bad, for you that Unity pulled the rug out from under everyone interested in Bolt 2.0
As a programmer, I've been down C++ roads long before Visual Scripting, but love your thoughts and passion for V.Scripting.
Anyways was excited for where it was going, saw a few tutorials from you and others.
I started with Visual Basic, would I want/need a stepping stone like Bolt today, WHO knows, you sell that as a great thing, and sad to have such a working alpha and Higher ups go NOPE, not going to make enough money off it, or something!
Please give your hands some rest, othervise you'll create visual noise. Other than that, nice video.
Hey Ive read this already. I see you edited out the swear words though.
I did. Tried to take a deep breath and be more objective. 🤷♂️
And yet "programmers" will happily purchase art assets.. Why not learn how to illustrate?
There is just too big of a gap between visual scripting and regular scripting. I won't get too deep into what I think about bolt but as someone who already knows how to program I find very little use of it if any. Only prototyping for other people and even then it's very limited and slow on top of it all.
Unless you are making something very basic and very simple, visual scriping just ain't the tool that will get you those results