You COULD make a full game with Bolt. If you're not a programmer and that's the option you have, I'd say its certainly much better than NOT making a game. You will definitely run into issues, but don't let that stop you. If you have the choice though, don't do the logic with Bolt - just use it as a tool to manage application flow.
Thank you for this info i am currently relearning unity and im going ot use VS/Bolt for my projects. If you have any more tips i would love to see them. Right now im just going through collecting tips and tricks for VS so i can avoid or learn from them before i get knee deep and cant dig my way our.
great video, thanks for the tips! I'm a bolt adventurer and I have no idea how to avoid bolt variables as I don't know how to write a line of code. I think I will remain lost in the variables for a while longer. and... well lost!
These are just my recommendations, they aren't the only way to do things. If using C# variables isn't an option for you, then go ahead and use Bolt Variables. The world won't explode. XD
A 3rd option to the beginning is writing the code as a bolt unit so it can become a node; if you know it may be used in multiple places in this case you are representing a class that inherits unit, where you define the inputs in code running the logic within it and then returning the outputs you need. In this way you are hiding your scripts while still keeping the node look and your script can take multiple bolt inputs to fill variables and run methods without needing scripts plugged into scripts and listening to events.
Making a new super unit for each piece of functionality will create a file hierarchy nightmare. If that is you're only option, by all means! But if you can code, best to just avoid it.
cheers, I find videos like these invaluable, it shows an alternative way of thinking based on experience... I'm making a game and using Bolt for the first time (due to being a weak coder), but hope to increasingly understand the value of these methods, as I'm already concerned about super large unwieldy graphs... anyway, just a few questions: 5:28 would ctrl-z recover the graph? 6:10 would select/copy/paste work? 18:35 if CleanUp Store were added as a Transition (like the ones being added here), wouldn't it always trigger after XButton clicks?
I'm going to answer based on remembering what was at those time-stamps rather than going back to look at the video, so if my answer is way off the mark, that's why. 1) I'm actually not sure. If you delete a node in the graph, undo will restore it. If you delete a script in the unity inspector, undo will restore it. But I'm not sure if it will restore just the script reference, and ALSO the embed serialized graph. 2) You can copy paste nodes and sequences etc., but what happens then if you want to change the functionality? You would then have to remember where you copy pasted it to, and then go in and manually fix each spot. That's not a winning strategy, especially when you can just use the serialized graphs. 3) As a generalized response, I'll say that if you keep the response to the input inside the graph, and then trigger a transition from within the graph, you can control when/where/what gets called. If you want cleanup called every time, you can! If you want it skipped sometimes, you can do that too! But if you listen for the input in the transition node itself, you have no control over where that graph exits from. It will just exit immediately, and you always want to err on the side of having control of an application flow or you'll end up with tons of unanticipated bugs and unexpected behavior that's hard to track down.
Point 1 - Use super units (sub-graphs) for logic. you can reuse and edit the super unit and changes are copied across every node referencing the super unit. Code is still faster to write, but if your allergic to code, it will work pretty much the same upkeep/maintenance/bug-fix wise
I do some hand waving in the video to indicate it's possible, just that it gets messy fast (a file per function) and that code is better if you can code. If you can't, then yes this is the solution.
I am really new to Unity Visual Scripting been at it about 60 days at this point, here is my 2 cents, take it for what it's worth. Visual scripting is NOT fast. It can be clean, with a little effort, but setting up the nodes is slow. I really don't get the rancor for the variable system. Graph is private, everything else is public. It's a simple way for people who have no idea about coding to quickly wrap their head around it the idea. Personally, I tend to use scene and app 'variables' for constants and often used object references. In the video the author flips back to the object inspector to add the variable, this is unnecessary simply hit the plus sign and add the variable there. The author uses an example of multiple stores, this can be done using Prefabs, simply drag the object off the hierarchy to the assets window, I suggest using folders. Seriously, use folders. You can either update the Prefab directly or you can update the instance and then use the override button in the inspector to update the prefab, depending on your needs. You can even make prefabs of prefabs if you want something general to become something more specific. You do not need to learn c# to do most things... but I admit it is much, much, faster if you already know how. Typing a few lines of code is faster than dragging the nodes and connections. It can very quickly get messy. Which brings me to my last point: Embeds, embeds do have a place, they are basically private functions for visual scripting. If you find that an embed can be used in another graph convert it and it becomes it's own graph nested in the original (public). Once again, I suggest you USE A FOLDER to save your no-longer embedded functions. If I find the need to Control-Drag and colored window to make a note about a block of nodes... it's time for an embed. The colored windows are pretty but currently a bit buggy and lets face it the embeds make the readability of the code easier. The rest of the video I completely agree with. The great thing about unity is there is many ways to get to the finish many are personal taste, but some are skill level. I didn't see anything the author did that you cannot do through visual scripting but I will be the first to admit, it is a slow process to set up as opposed to C#. All in all great video, thumbs up :)
Nice video! Gives Me a lot of ideas too. I just recently switched over to the new input system in Unity2021, and been having issues with First person controls not working right. I'm making a space shooter/salvager game, and wanted some off ship parts. My ship controls work fine, but FPS with a gamepad is all wonky (using Bolt/VS). Might have to use C# for the FPS parts. Oh btw, I'm from WMass too.
thx for this now i was thinking maybe bolt is useful but I'll stick to code I was already confused af (and I hate variable system from start b4 even knowing that one u mentioned )
Nice Video :) I think Bolt would be good it it lets you get specific outputs as you can with C# imprementing, cause as you said you can have all the scipts embeded and get calles in different scipts. But i have tiny issue with your method How will you set the GameObject variable as In Bolts Variable Game Object type, that you select and then you have it "forever". I explain roughtly my method, I have a Scene Variable that links to GameObjects "Player" and "Scene Logic" In my project I have ton of childs with the respective codes and variables colling the childs (stupid I know) And then I start linking in Bolt Game Object Variables Object type. To locate where the vartiable that I need is. That way, in my script I dont´t have to link each gameobject that I want to use. {I will talk thinking in Bolt C# implementation, not code itself} In yout method (correct mw if I'm wrong :) ) To get that fist object to call the childs, I have to link my script to every one of the scripts that needs this reference. Is there anyway to call the Game Object globally like in a scene variable. I don´t need to select it, as it is in Bolt, I don´t know if I have to put a GameObject.Find in a void Start or how can I manage that :0? In order to not defining each time a specific variable for each object that needs it. Thanks in advance, great tips, I had messy reference for events, and this is suuuuper coool :)
I'm not sure I understand the context, so maybe you can clarify. Setting variables in a C# variables script is identical to using any other MonoBehaviour in Unity. You can either set those variables in the editor where they will be serialized, or if you won't know the exact variable until runtime you can set it then. Whatever you want access to via Bolt, you create a variable field in the variables C# script. If you would rather provide a single game object, and then use coded logic to find and return the appropriate scripts on that objects children, you can setup a method or property to return those values.
My response: 1. The use of super units is exactly for this situation as are flow macro files. Any object that uses the same macro uses the same graph. 2. A good warning. 3. A good warning but why not use a string variable? 4. Maybe i’m lucky and its super recent, but this is exactly what a scene variable is for. A scene variable is bolt’s version of a static variable or public variable on a manager script as a scene variable is global to the scene. Their are also saved variables for cross scene data. Your suggestion is a good one, but appears to be based on old experiences. Also, renaming a variable is just as much a pain in C#, so i do not understand this criticism. 5. I have no experience, but it appears helpful. All written at work so forgive its briefness.
I know this video is a year old, but your concern about logic in Bolt vs code seems no longer relevant with the introduction of Super Units. Is that true? Also, your concern with variables, you proved your point only using object variables. Do these problems still exist when using scene and application variables?
Yeah, Yeah... For every change in code (like add new var or new script) - Please, click "Build" button and wait! Super! ... For Every Bolt Flow create an addition script for Vars, and for logic. Super!... Maybe you will use just code?)
Putting aside the snark, this seems like a problem that would only occur in very rare edge cases. Every time you save a code file Unity performs an editor recompile anyway, so unless you are having large recompile times AND are ONLY using Bolt for development (no code) this is misplaced blame. I've not run across projects like this (High compile times and only using visual scripting for logic) but your mileage may vary. Ultimately, long compile times isn't a Bolt issue, its a project and Unity issue. If you have really long compile times, you're not going to be solving it by avoiding adding a field to a variables script for each super state (not flow). You'll waste a lot more time dealing with Bolt's variable system in an effort to avoid a problem not being caused by Bolt, and better solved via other means - like splitting up your project into smaller assemblies.
This answers the vast majority of questions I had. Finally found a good video
Great tips! Exactly what I intended to use Bolt for, just for diagramming out the flows and states.
Interesting. I was under the impression it was possible to create a full game with Bolt. Is that not the case?
You COULD make a full game with Bolt. If you're not a programmer and that's the option you have, I'd say its certainly much better than NOT making a game. You will definitely run into issues, but don't let that stop you. If you have the choice though, don't do the logic with Bolt - just use it as a tool to manage application flow.
Thank you for this info i am currently relearning unity and im going ot use VS/Bolt for my projects. If you have any more tips i would love to see them. Right now im just going through collecting tips and tricks for VS so i can avoid or learn from them before i get knee deep and cant dig my way our.
great video, thanks for the tips!
I'm a bolt adventurer and I have no idea how to avoid bolt variables as I don't know how to write a line of code.
I think I will remain lost in the variables for a while longer. and... well lost!
These are just my recommendations, they aren't the only way to do things. If using C# variables isn't an option for you, then go ahead and use Bolt Variables. The world won't explode. XD
Thanks! you do a very nice job with this. Greetings.
A 3rd option to the beginning is writing the code as a bolt unit so it can become a node; if you know it may be used in multiple places in this case you are representing a class that inherits unit, where you define the inputs in code running the logic within it and then returning the outputs you need. In this way you are hiding your scripts while still keeping the node look and your script can take multiple bolt inputs to fill variables and run methods without needing scripts plugged into scripts and listening to events.
This video is amazing thank you!
Surely super units will let you reuse flow graphs and remove the first issue listed in the video?
Making a new super unit for each piece of functionality will create a file hierarchy nightmare. If that is you're only option, by all means! But if you can code, best to just avoid it.
cheers, I find videos like these invaluable, it shows an alternative way of thinking based on experience... I'm making a game and using Bolt for the first time (due to being a weak coder), but hope to increasingly understand the value of these methods, as I'm already concerned about super large unwieldy graphs... anyway, just a few questions:
5:28 would ctrl-z recover the graph?
6:10 would select/copy/paste work?
18:35 if CleanUp Store were added as a Transition (like the ones being added here), wouldn't it always trigger after XButton clicks?
I'm going to answer based on remembering what was at those time-stamps rather than going back to look at the video, so if my answer is way off the mark, that's why.
1) I'm actually not sure. If you delete a node in the graph, undo will restore it. If you delete a script in the unity inspector, undo will restore it. But I'm not sure if it will restore just the script reference, and ALSO the embed serialized graph.
2) You can copy paste nodes and sequences etc., but what happens then if you want to change the functionality? You would then have to remember where you copy pasted it to, and then go in and manually fix each spot. That's not a winning strategy, especially when you can just use the serialized graphs.
3) As a generalized response, I'll say that if you keep the response to the input inside the graph, and then trigger a transition from within the graph, you can control when/where/what gets called. If you want cleanup called every time, you can! If you want it skipped sometimes, you can do that too! But if you listen for the input in the transition node itself, you have no control over where that graph exits from. It will just exit immediately, and you always want to err on the side of having control of an application flow or you'll end up with tons of unanticipated bugs and unexpected behavior that's hard to track down.
Point 1 - Use super units (sub-graphs) for logic.
you can reuse and edit the super unit and changes are copied across every node referencing the super unit.
Code is still faster to write, but if your allergic to code, it will work pretty much the same upkeep/maintenance/bug-fix wise
I do some hand waving in the video to indicate it's possible, just that it gets messy fast (a file per function) and that code is better if you can code. If you can't, then yes this is the solution.
i need to really learn this i can't understand code in any programming language
Why you use bolt instead of c# even if its gives x8 less performance? (no offense just wondering)
What about super units? Can't you keep the logic there and reuse over and over again?
I can not find a book on Unity Visual Scripting or BOLT - any ideas?
I never looked for one! If you find one I'd be interested to know if you found it useful.
I am really new to Unity Visual Scripting been at it about 60 days at this point, here is my 2 cents, take it for what it's worth. Visual scripting is NOT fast. It can be clean, with a little effort, but setting up the nodes is slow.
I really don't get the rancor for the variable system. Graph is private, everything else is public. It's a simple way for people who have no idea about coding to quickly wrap their head around it the idea. Personally, I tend to use scene and app 'variables' for constants and often used object references. In the video the author flips back to the object inspector to add the variable, this is unnecessary simply hit the plus sign and add the variable there.
The author uses an example of multiple stores, this can be done using Prefabs, simply drag the object off the hierarchy to the assets window, I suggest using folders. Seriously, use folders. You can either update the Prefab directly or you can update the instance and then use the override button in the inspector to update the prefab, depending on your needs. You can even make prefabs of prefabs if you want something general to become something more specific.
You do not need to learn c# to do most things... but I admit it is much, much, faster if you already know how. Typing a few lines of code is faster than dragging the nodes and connections. It can very quickly get messy. Which brings me to my last point: Embeds, embeds do have a place, they are basically private functions for visual scripting. If you find that an embed can be used in another graph convert it and it becomes it's own graph nested in the original (public). Once again, I suggest you USE A FOLDER to save your no-longer embedded functions. If I find the need to Control-Drag and colored window to make a note about a block of nodes... it's time for an embed. The colored windows are pretty but currently a bit buggy and lets face it the embeds make the readability of the code easier.
The rest of the video I completely agree with. The great thing about unity is there is many ways to get to the finish many are personal taste, but some are skill level. I didn't see anything the author did that you cannot do through visual scripting but I will be the first to admit, it is a slow process to set up as opposed to C#.
All in all great video, thumbs up :)
Nice video! Gives Me a lot of ideas too. I just recently switched over to the new input system in Unity2021, and been having issues with First person controls not working right. I'm making a space shooter/salvager game, and wanted some off ship parts. My ship controls work fine, but FPS with a gamepad is all wonky (using Bolt/VS). Might have to use C# for the FPS parts. Oh btw, I'm from WMass too.
thx for this now i was thinking maybe bolt is useful but I'll stick to code I was already confused af (and I hate variable system from start b4 even knowing that one u mentioned )
Nice Video :)
I think Bolt would be good it it lets you get specific outputs as you can with C# imprementing, cause as you said you can have all the scipts embeded and get calles in different scipts.
But i have tiny issue with your method
How will you set the GameObject variable as In Bolts Variable Game Object type, that you select and then you have it "forever".
I explain roughtly my method, I have a Scene Variable that links to GameObjects "Player" and "Scene Logic" In my project I have ton of childs with the respective codes and variables colling the childs (stupid I know) And then I start linking in Bolt Game Object Variables Object type. To locate where the vartiable that I need is.
That way, in my script I dont´t have to link each gameobject that I want to use.
{I will talk thinking in Bolt C# implementation, not code itself}
In yout method (correct mw if I'm wrong :) ) To get that fist object to call the childs, I have to link my script to every one of the scripts that needs this reference.
Is there anyway to call the Game Object globally like in a scene variable.
I don´t need to select it, as it is in Bolt, I don´t know if I have to put a GameObject.Find in a void Start or how can I manage that :0? In order to not defining each time a specific variable for each object that needs it.
Thanks in advance, great tips, I had messy reference for events, and this is suuuuper coool
:)
I'm not sure I understand the context, so maybe you can clarify. Setting variables in a C# variables script is identical to using any other MonoBehaviour in Unity. You can either set those variables in the editor where they will be serialized, or if you won't know the exact variable until runtime you can set it then.
Whatever you want access to via Bolt, you create a variable field in the variables C# script. If you would rather provide a single game object, and then use coded logic to find and return the appropriate scripts on that objects children, you can setup a method or property to return those values.
My response: 1. The use of super units is exactly for this situation as are flow macro files. Any object that uses the same macro uses the same graph. 2. A good warning. 3. A good warning but why not use a string variable? 4. Maybe i’m lucky and its super recent, but this is exactly what a scene variable is for. A scene variable is bolt’s version of a static variable or public variable on a manager script as a scene variable is global to the scene. Their are also saved variables for cross scene data. Your suggestion is a good one, but appears to be based on old experiences. Also, renaming a variable is just as much a pain in C#, so i do not understand this criticism. 5. I have no experience, but it appears helpful. All written at work so forgive its briefness.
I know this video is a year old, but your concern about logic in Bolt vs code seems no longer relevant with the introduction of Super Units. Is that true? Also, your concern with variables, you proved your point only using object variables. Do these problems still exist when using scene and application variables?
thank
Yeah, Yeah... For every change in code (like add new var or new script) - Please, click "Build" button and wait! Super! ... For Every Bolt Flow create an addition script for Vars, and for logic. Super!... Maybe you will use just code?)
Putting aside the snark, this seems like a problem that would only occur in very rare edge cases. Every time you save a code file Unity performs an editor recompile anyway, so unless you are having large recompile times AND are ONLY using Bolt for development (no code) this is misplaced blame. I've not run across projects like this (High compile times and only using visual scripting for logic) but your mileage may vary.
Ultimately, long compile times isn't a Bolt issue, its a project and Unity issue. If you have really long compile times, you're not going to be solving it by avoiding adding a field to a variables script for each super state (not flow). You'll waste a lot more time dealing with Bolt's variable system in an effort to avoid a problem not being caused by Bolt, and better solved via other means - like splitting up your project into smaller assemblies.
lol we use bolt because we don't know how to code and you tell me to add code to bolt seriously ??
1. Nonsense. Simply create re-useable macro with inputs and outputs. It's same as classic method.
Watching a video about visual scripting becouse I don't want to code. Tip 1 don't use visual scripting for game logic. Write your own code...
this is hilarious
delete bolt variables from existence.
First Comment.
First reply.
First question, why?