Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. Join us on Dec 8, 2022, between 7 am & 7 pm EST, in the DOTS Dev Blitz Day 2022 - Q&A forum, Discord, and Unity3D Subreddit to learn more about DOTS directly from the Unity Developers.
    Dismiss Notice
  3. Have a look at our Games Focus blog post series which will show what Unity is doing for all game developers – now, next year, and in the future.
    Dismiss Notice

Official The road to 2021: Visual scripting in Unity

Discussion in 'Visual Scripting' started by UnityHas, Feb 3, 2021.

  1. UnityHas

    UnityHas

    Unity Technologies

    Joined:
    May 1, 2020
    Posts:
    32


    We recently shared our roadmap plans for 2021. Now, we invite you inside Unity to meet some of the teams working toward these goals. In this third post of our new series, we meet with the Visual Scripting team.


    Our Unity 2021 roadmap explains our priorities for the next year. Thanks to the excellent feedback we’ve gathered since that blog post, we’re even more committed to updating production-ready features and delivering new key features. Not only that, we’re determined to improve workflows and your overall quality of life when working in the Editor.

    A key element of our roadmap is communicating with you, our users, about how we plan to put this into practice. By giving you behind-the-scenes looks at our processes, we hope to help you better understand how Unity is working to empower creators.

    Meet Development Manager Adam Blahuta and Technical Lead Theo Richart from the Visual Scripting team. They’ll help us to understand what visual scripting is and why it’s one of the top six priorities for Unity in 2021. You may have already met them over here in the forums or on the visual scripting discord.

    If you’ve played Warhammer: Underworlds Online, then you’ve experienced visual scripting at work. Think of visual scripting as the workflow to create logic for games and apps without writing any code. This workflow uses visual, node-based graphs that both programmers and nonprogrammers can use to design logic or to quickly create prototypes.



    This freedom to streamline creativity matters more than ever today, as we’re constantly reminded of the struggle for work/life balance in the industry. Adam shares how visual scripting could’ve changed his entire team’s workflow on previous projects: “I wanted to go back in time and bring visual scripting with me. I wanted to help the dejected level designer who I’d told for the upteenth time that another interactable he needed to get his scene ready for review wouldn’t get done right away because the developers were busy with other features. I wanted to beg for forgiveness for mangling my artist’s UI with my terrible integration of his vision. I wanted to get the precious hours of my team’s life back stressing over iOS hotfix submissions that could have been avoided if we’d just had the means to push logic to the server directly.”

    By increasing the accessibility of visual scripting in the present, we open up opportunities for other use cases where coding has been the go-to digital solution. Could visual scripting be the way we connect with students in important sciences like robotics? We’re just scratching the surface of its potential. The magic of Unity is that once we put it in the hands of our community, you’re the ones that will really make it sing.

    It’s important to note that visual scripting isn’t meant to replace coding entirely. It enables more seamless collaboration between programmers and nontechnical team members like artists and designers. Think of visual scripting as a high-speed commuter train. You know you need to get from point A to point B, and by cutting out unnecessary stops and delays, you get to your destination a lot faster.

    “A good visual scripting solution is tantamount to giving control to users so they can more actively contribute to the game’s execution. Without it, the programmers become the bottleneck of all gameplay and artistic endeavors,” says Theo. “For users who have no access to programmers, the eventual goal is to ship visual scripting with an extensive library of high-level nodes like that, that can be repurposed for each project. We’ll announce more as we get closer to when.”

    You can use visual scripting to: :
    • Create scripted events like dialog between characters
    • Define new player skills
    • Produce VFX
    • Add traps to levels
    • Insert nodes like spawning guards
    • Adjust trigger boxes
    • Pick the right animation for the scene
    • And more!
    If you love writing code, you can still use visual scripting and code – the nodes are there if you need them, so you don’t have to choose either/or when it comes to how you work best. You can also use visual scripting to create templates for later projects.

    For all of these reasons, Unity is accelerating the development of tools and features for artists. Making the entire process of creating real-time, interactive graphics, content and experiences more intuitive and accessible for visually oriented creators a priority for 2021.

    TL;DR: With visual scripting, you can streamline your creative process by having the option to use nodes to create quick actions, rather than coding.

    We hope that you’ve enjoyed seeing the benefits that Visual Scripting can bring to your projects. We'd love to hear your feedback in the replies. What do you think about these Dev diaries? What has your experience with Visual Scripting been like so far?

    If you have any questions, let us know. The Visual Scripting team will be watching this thread and chiming in.

     
    Last edited: Feb 4, 2021
    chelnok, Mauri, Ruchir and 4 others like this.
  2. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    208
    I have questions but most of them have just been ignored before so... /shrug

    EDIT: Since it seems you're actually answering questions for now, I'll post some again later on.
     
    Last edited: Feb 4, 2021
  3. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    939
    This blog post seems somewhat useless
    Do you have plans at leas answer what direction you move VisualScripting now?
    Something more than that "VS is cool and we do our best to make it to 2021"

    What will be with bolt 2 features or when we can expect anything?
    What good ideas of Bolt2 and community you decide to throw out and what to implement in your vision?
    Actually what is your vision? You say you gather feedback from community but you never say what you do with this feedback just silence.

    Everything we know for now is that you ignore Bolt2 features and go back to good old Bolt1.
    May be now 4 months later you have more to say about your vision and what we can expect from Unity 2021 VS solution?

    For me it is more interesting when you plan to bring Bolt2 like VS into Unity if ever?

    You promise to answer our questions in this thread https://forum.unity.com/threads/visual-scripting-roadmap-update-september-2020.978732/ but it is never happened. May it is time too?
     
    NaoYuYan, joshcamas, tobiass and 4 others like this.
  4. mountblanc

    mountblanc

    Joined:
    Sep 24, 2015
    Posts:
    93
    I have a ton of questions:
    When Bolt was taken over by Unity it was said that bolt 2 would be in the process of being released as beta in a couple of weeks from now(23 April 2020) I had my dough ts already then https://forum.unity.com/threads/welcome-to-bolt-2-beta-coming-soon.874729/page-2#post-5817064

    Bolt 2 seems to be dropped and now bolt 1 is about to be integrated into Unity and it blows my mind even further.
    From what i understand its a rewriting of namespaces and some class and method names to make if work better with the existing structure.
    It's more complicated than that i am sure but the basically its Bolt1 merged into Unity.
    At least that's what i understand about it.

    I have the following thoughts:
    first off Bolt 2 power was that it would generate script files and so reduce much of the added lag using an other layer of coding.
    Secondly it seems Bolt 1 integration isn't using the Graph and GraphView etc libraries but it seems to still use the Ludiq framework still.
    What i find puzzling to say the least.

    Third: How about using visual coding using the Dots system ? Is that project dead in the water?
    I am not sure what the current status of Dots is and about the visual coding that did use Graphview. But it seems Unity is betting on all kind of horses at the same time. (My personal opinion is that Unity should have created a total new branch with only Dots rather then trying to integrate it in the current Unity build but that's an other discussion )

    I understand that there is much interest in visual scripting. Hack i think it has great potential for me at least for big project (Not even game related) to get quicker an overall working of a program and dive deeper in your code and see what is happening visually and visually debug while the program is running.

    For people wanting to code but finding it to hard i can imagine that visual Scripting seems a much lower stepping stone. I just hope that visual Scripting will take on the DOTS and other systems and provide script export functionality to be able to use Visual Scripting with at least performance loss as possible.

    So I do not understand the roadmap and how above concerns i have (And hopefully many others) are being taken care off or are even considered.

    Truth be told i haven't read much the forums and stuff last year so i might be unaware of some stuff but that's reason to write here to get answers and information and be corrected and i am just a hobby unity user .
     
    leni8ec, NaoYuYan and Stexe like this.
  5. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    906
    I’d like an update on what's being technically done to improve the main Bolt 1 issues - performance, API documentation, variables and custom events weak typing/general usability issues, QoL features like graph search and error highlighting in the graph when clicked in console. The roadmap mentions most of these will be addressed, but it's not clear how and how soon they will be improved.

    I’m not asking about concrete dates, I’d just like some kind of list of priorities like the old Bolt 2 roadmap back in the Ludiq days. Lazlo never gave any dates, but we could see what’s the plan and what’s being worked on now. Sure, some list items were later removed and assigned as unfeasible for one reason or another, but that’s part of development.

    Basically I'd like to get some kind of idea in what direction the tool is moving and roughly when it'll get there. Right now it seems it'll be years until all main pain points will be resolved, which is confusing because Bolt 2 already had addressed all my current Bolt 1 issues.
     
  6. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    We have a plan for the performance that doesn't involve generating code for the entire graph, which is problematic in a lot of case.
    The plan is to unify all of our node based tools frontends with the new GraphTools Foundation. However, that takes time, as we first need to split the frontend and backend of bolt, which are heavily coupled.
    No, but the current focus is on the tech that is already released and used by a lot of people: game objects.
     
    Haneferd likes this.
  7. Ruchir

    Ruchir

    Joined:
    May 26, 2015
    Posts:
    885
    There was absolutely no information whatsoever as to what is the actual roadmap for visual scripting, it's just written that it's awesome and will help many developers but that's really useless to be in its own blogpost at such an early stage when visual scripting is so bad right now.

    There have been no updates on the graph view and its usage in other packages or even providing a public API for it
    In its current state Visual scripting is pretty much useless for anything other than prototyping in a small game jam.

    I can't build anything on top of it because it's just really bad right now(no type safety, no error prediction(compiler error kind of thing), nowhere near comparable to performance to C#), and it's sure to have breaking changes in near future, so I really don't see what goal unity achieved by integrating it as core package at such an early stage, I would really like to get some insight into the real roadmap for visual scripting instead of what was in this blogpost
     
    Neonage, Jes28, JoNax97 and 3 others like this.
  8. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    We're working hard on validating that vision so we don't overpromise. it's the usual issue of "too much details and we'll change our mind" vs "not enough details/too careful".

    Bolt2 solves some of those problems and we'll take inspiration from it and from DOTS VS:
    - perf is being worked on. new backend and all
    - frontend will be unified with other unity tools. as said earlier we need to split the front end and back end which are highly coupled in the current implementation
    - typing, weak events, variable boxing are high on our priority list
    - QoL will come next - for most of those features, we'd rather implement them once on the new front end than twice on both front ends.

    I hope that clarifies a bit the plan.
     
  9. WendelinReich

    WendelinReich

    Joined:
    Dec 22, 2011
    Posts:
    227
    Hi @theor-unity - this is great stuff, we're very excited about VS. Could you tell us more about your plans to make it customizablea and allow developers to create custom nodes and maybe even custom graphs? For example, if a developer wanted to use VS to create a custom version of behavior trees (which involve both special nodes and special execution logic), could they do that? If not, is it on the roadmap?
    Thank you!
     
  10. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,263
    Any plans on adding code generation later? or will it be a never
     
  11. Jes28

    Jes28

    Joined:
    Sep 3, 2012
    Posts:
    939
    IMHO better publish you current vision with BIG label of "EXPERIMENTAL VISION!!! EVERYTHING CAN/WILL BE CHANGED UPON RELEASE" :) Than keep us without info about direction Unity is moving.

    Or may be just return BETA users sub forum and restruct access to that forum only for developers that actually understand what is Experimental or Preview version of package :)
     
    Neonage and Ruchir like this.
  12. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    We're still working on the details/processes/... but yeah, you're right, we haven't communicated enough recently
     
    Walter_Hulsebos, Ruchir and Stexe like this.
  13. Neonage

    Neonage

    Joined:
    May 22, 2020
    Posts:
    217
    Any news on Graph Tools Foundation?
     
  14. sinjinn

    sinjinn

    Joined:
    Mar 31, 2019
    Posts:
    149
    I really like Bolt, but I understand it's not perfect,or runs slower than C#.
    Is translating Bolt to C# later straightforward? or is it a minefield?
    How soon are we going to be able to use DOTS within Bolt? I understand there's a lot of things you guys are trying to do, but is this a multi-year thing? I guess I don't understand what the actual plan is anymore. DOTS seems very useful, and the sooner it gets into Bolt the sooner Bolt gets supercharged. It might be a better way to get devs to take advantage of that power without feeling overwhelmed.

    Can you guys even say if you are actively working on the DOTS/Bolt integration now, or is it waiting for something else to get done, like redesigning Bolt first?

    Also, is it likely that Bolt/DOTS will be an order of magnitude faster to run than just Bolt, like DOTS to OOP, or is there still something that will critically slow down the code just by the nature of it being Visual Scripting?

    cheers
     
  15. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    It's going great. The first focus is for internal usage: enable new tools/migrate existing tools to it.

    We're not working on the DOTS integration at the moment - we first need to rearchitecture bolt to support multiple backends, and then to replace the front end with GTF. we'll then reevaluate (see the evolution/adoption of DOTS etc to prioritize correctly the dots/vs integration).

    About perf: I sure hope we'll get another boost with DOTS, but remember that at this point, you'd need your entire project to be made for DOTS to get real benefits, not just your visual scripts.
     
    landonth, toomasio, Nexer8 and 2 others like this.
  16. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    5,966
    Well this one said absolutely nothing useful in a couple of thousand words, so not really happy with it. Dev diaries are great if they're about what developers are actually doing.

    If you have exactly zero things to show for your effort yet, maybe don't make a big fuzz about it? Like

    There's nothing behind the scenes in any of the stuff you wrote? You're just saying that you're working on the same things that you said that you were working on September last year.


    Look, like, we get that it takes time to make stuff. If your engineers doesn't have anything that's ready to be shown, nor anything concrete to promise other than "we'll keep working on it", just wait until they have. We're not in a hurry to be marketed to.


    Edit: Just clicked some more around the forums, and every single one of theor's posts are much more informative, interesting and useful than your entire blog post. Maybe cut out the middle man next time?
     
  17. JoNax97

    JoNax97

    Joined:
    Feb 4, 2016
    Posts:
    597
    Agreed
     
  18. guybro_thunderboots

    guybro_thunderboots

    Joined:
    Aug 27, 2015
    Posts:
    45
    I'm seconding the call for more information on custom nodes and graphs. Being able to call methods on MonoBehaviours is nice and all, but there's some real power to be had from custom nodes. Easy guards for accessing singleton systems from under the hood, multi-flow splits, hooking into generic game systems and exposing their operators through VS, etc.
     
  19. steve_zeng

    steve_zeng

    Joined:
    Aug 6, 2019
    Posts:
    22
    I bought Bolt, and while I was happily waiting for the official V2 release, it was acquired.

    I didn't get any compensation, and I didn't get the features and performance I wanted in the new version, which was very disappointing.

    I think the authorities are too slow and I don't want to wait.

    Later, I bought the uNodeV2 plugin, which implements all the functions of Bolt2 with better performance, and now I use uNode, which I think is fine.There's vertical streaming, there's code generation, and even the ability to turn C# code into nodes, which helps me learn and understand C# code better.

    I've given up on Bolt for now, and based on official development efficiency, I think I'll come back in 2-3 years.
     
  20. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    As long as you're happy!
     
  21. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    208
    I think you misread his post... he isn't happy. The lack of compensation and lack of features / performance alone left him disappointed. The same with so many of us...

    I tried to get a refund from Ludiq / Lazlo but was ignored at every turn -- even when Unity contacted him on my behind. Like... we're just all disappointed and definitely NOT happy with how things turned out. Sacrificing so much for backwards compatibility and then horribly explaining it and what you're going for has soured so many of us... not that we should be surprised since it seems Unity does this at every turn. Like how many years did it take for one of the most requested features (nested prefabs) to get implemented? Yeah... =/
     
  22. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    Can't talk about refunds - I'm just a dev, and I don't have anything to add about Ludiq's point of view.

    I'm probably not the person most able to answer your general complaints about Unity, nested prefabs or feature development time either.

    Breaking compatibility is something we've been yelled at for - except when it's a good thing. It's a tricky subject to navigate; I still think we did the right choice.

    The fact that it was poorly communicated is something I acknowledge - hopefully we'll do better in the future. If you want to discuss it, it would be easier on the discord server, where I do spend a lot of time answering people or just pitching ideas.
     
  23. Karsten

    Karsten

    Joined:
    Apr 8, 2012
    Posts:
    177
    @theor-unity In 2021.1.7f1 Errors thrown in the console in playmode open the script editor when double clicked instead of jumping to the graph where the error is located, imagine you have 256 Visual Scripting graphs and there is one faulty graph throwing errors in playmode ^^
    I wholeheartedly suggest the Visual Scripting team to make this a priority 1 issue, make it quick and easy to find faulty graphs.
    To construct an example, use a switch node and dont provide it with any input values but some cases, link the switch node with the update event, then deselect the object with the graph and press play.
     
    Last edited: Jun 2, 2021
    JoNax97, stuksgens and Ruchir like this.
  24. jaytay579

    jaytay579

    Joined:
    Apr 22, 2013
    Posts:
    3
    Here's maybe an easier question/request: Is it possible to still get "Programmer Naming" when in the Visual Scripting editor in Unity 2021.1? I see there is a checkbox in Preferences for "Human Naming", but when I uncheck it, I don't see a change in Visual Scripting -- not even if I start a new script!

    I'm asking because with Bolt I was having my students start with "Human Naming" then move to "Programmer Naming" before transitioning to writing code directly in C#. This was a great way to get them to understand what's going on in a program before making them read or write good old fashioned blocks of code, so I'm hoping it's still an option and I've just failed to figure it out (despite searching the docs quite a bit)!
     
    NaoYuYan likes this.
  25. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    Sounds like a bug! We'll have a look, thanks for the report
     
  26. jaytay579

    jaytay579

    Joined:
    Apr 22, 2013
    Posts:
    3
    Awesome, thanks for the quick reply! BTW, I am running 2021.1.3f1. I'll try to check if the problem still exists in 2021.1.11 once I have time to update!
     
    theor-unity likes this.
  27. homemacai

    homemacai

    Joined:
    Jul 22, 2020
    Posts:
    50
    So, more and more I see posts and videos that tells to migrate from VS to C# since now that it is a part of Unity, updates will be slower to keep with the Unity Engine updates. For example every feature of Bolt 2 has been either scrapped or in the roadmap for the far future. Do you guys think that this is the case, should I completely scrap VS from my project, or maybe just use it for basic functionality, while leaving the heavy logic to C#, cheers!
     
    Ruchir likes this.
  28. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    906
    Generally, if your Bolt code runs fine, then you're good. Bolt/UnityVS is about 5-10 times slower than C# but then GDscript in Godot is also 10 times slower than their C# implementation and GDscript is the default Godot programming language. You can do a lot even with the considerably slower performance.

    New features do come slowly, we basically haven't had any for the past year besides added support for the new Input system and a few, very niche nodes. They've mostly worked on converting Bolt into a package and general bug fixing.

    That said, 2022 will bring the new runtime which will solve a lot of the performance problems. It remains to be seen how soon it'll actually be usable in production though. So I wouldn't place any bets on that just yet.

    My favorite way of working with UnityVS is to hold all variables in C# scripts (because C# variables can be organized with headers, can be renamed and are strongly typed so you can see variable type icons in graphs. C# variables also take less space in graph visually than a Bolt variable) and offload the performance intesive logic to C# scripts. UnityVS is more of a logic sequencer for me, not the main coding tool.
     
    Last edited: Jul 4, 2021
    homemacai, theor-unity and Ruchir like this.
  29. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    We'll celebrate once we're sure it does work in real life scenarios and that we haven't tested it only on weird cases favorable to it, which is why we want to get it in users' hands quickly !
     
  30. homemacai

    homemacai

    Joined:
    Jul 22, 2020
    Posts:
    50
    Coo! That is the path I am slowly taking, putting most of my variables in C# . Thanks for the tip!
     
  31. nubictvgames

    nubictvgames

    Joined:
    May 29, 2020
    Posts:
    3
    I'm not good at writing readable code, and lo and behold, there is visual programming in it, can I implement everything in the same way as in the code?
     
  32. guybro_thunderboots

    guybro_thunderboots

    Joined:
    Aug 27, 2015
    Posts:
    45
    No. It's not possible right now or planned AFAIK.
     
  33. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    906
    If you're asking if Visual Scripting outputs human readable (or any) C# code like guybro_thunderboots implied, then the answer is no, it does not.

    But Visual Scripting in its current form is a C# visualizer - for every public Unity method and property there's an automatically generated UnityVS node. It can also automatically generate nodes for any C# API be it Asset Store packages or random code from github. As long as the variables, properties and methods are public, UnityVS can access and manipulate them.

    In that sense UnityVS can implement many of the things C# can with a few exceptions. Currently, it can't deal with any kind of generics by default which can be solved with custom coded nodes. It also doesn't support callbacks/delegates which also can be solved by custom coding event nodes. UnityVS also can't really do any kind of inheritance or advanced composition techniques so stuff like interfaces, abstract classes/methods, etc are not possible. So proper project architecture can be a challenge in UnityVS alone but still possible.

    If you can implement something in C# code, you can likely do it with UnityVS as well. It's just not the best tool for the job a lot of the time, in my opinion.
     
  34. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    IMO VS shines when it's used as the glue between systems/functions, not when it is used to replace c#, but YMMV
     
    Neonage, PanthenEye and SugoiDev like this.
  35. guybro_thunderboots

    guybro_thunderboots

    Joined:
    Aug 27, 2015
    Posts:
    45
    I took the question to be more literal: "can I do everything in Visual Scripting that I can do in C#?"

    To elaborate on my answer ("No"), there's a category of things that Visual Scripting doesn't and probably won't support:

    - Implementing C# interfaces
    - Inheriting from C# classes
    - Creating C# events
    - Creating delegates
    - Listening for Unity's magic method invocations

    While you can avoid those things in any Visual Scripting graphs you create, there's going to be times when you need to interoperate with C# code. That code may expect to receive an object that implements an interface, inherits from a class, is a reference to a delegate, etc, etc, etc. In those circumstances you'll be forced to write C# glue code. Thus, a pure VS approach isn't always going to be possible.

    Now, some of these limitations are "resolvable" on Unity's side. For example, if Unity introduced either a core message bus or an event bus, the need for many of these C# features go away when we discuss interoperating with other systems, regardless of implementation (C# or VS) and ownership (your own or a third party's).

    But we're not there and it doesn't seem like Unity is moving in that direction.
     
  36. kurroarashi

    kurroarashi

    Joined:
    Dec 22, 2018
    Posts:
    28
    I'm very curious about Unity's plans for C#-VS interop, and especially job system/burst interop.

    I'm personally not a huge fan of UE4's approach to treating everything like an inheritance because of a rigid single-parent binding, but I can see the merit in its consistency throughout all its systems.

    I personally would really like to see how Unity approaches it because having high-level systems inside VS makes it more accessible for designers to modify, while the low-level performance-sensitive systems can be handled inside traditional text-based code.

    For that matter, I'm also very curious about the approach to a high performance interpreter. Will it have a C++ backend for added performance to the virtual machine, or will it be built on top of C#, which... already runs on the .NET VM.
     
    NaoYuYan likes this.
  37. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    927
    I'm curious, would "High performance interpreter" allow in some way to make vs in runtime? I'm interested as loading C# dlls in runtime isn't possible on il2cpp.


    Battlefield Portal looks interesting:

     
  38. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    That's a limitation of il2cpp, no runtime can work around it sadly
     
  39. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    927
    What do you mean? There are already IL, lua, python interpreters that work in il2cpp but aren't optimized.

    From different thread:
    Looking at trends more and more games allow players to be creators (roblox best example). There are many Unity games that refuse to add scripting as it's not cross platform (won't work in il2cpp ios). Hopefully that will change at some point. This should have a bit higher priority. As you can imagine players that end up learning and scripting in C# in a game would have pretty easy way of picking up Unity. In a sense it's a way of converting players to Unity users.

    Worth saying that Unreal noticed it and they're adding new language for that exact purpose https://twitter.com/Nephasto/status/1340046706642186247/
     
    Last edited: Sep 1, 2021
  40. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    My bad, I misread your question. I answered to "will the new interpreter allow to load C# dlls ?".

    To answer your ACTUAL question:
    - if you're talking about creating a visual script from code at runtime: it's kind of possible today, but you have to account for code stripping/aot stubs etc. with the new runtime, it will be harder at first - one of the goal of the new runtime is to split authoring data and runtime data, and initially the authoring side will be editor only
    - on top of that, having the full vs editor at runtime is impossible for now, and changing the runtime won't change that. it is a long term goal, but so much must be done first : migrating the front end, waiting for a stable runtime UIToolkit, getting some kind of runtime serialization, etc
     
  41. Kamyker

    Kamyker

    Joined:
    May 14, 2013
    Posts:
    927
    Thank you, interesting. Hmm, maybe something simpler: what in a case where players will mod a game (using uMod for ex) in Unity editor. Could new graphs be loaded in runtime on il2cpp? That's what I understand from "enable DLC graphs" but in this case modders don't have access to a full project.
     
  42. theor-unity

    theor-unity

    Unity Technologies

    Joined:
    Feb 26, 2016
    Posts:
    187
    In theory, if you use only nodes that are available in the game (meaning they were used or not stripped in the first place), yes. We haven't tested it yet
     
  43. dogsaregreat

    dogsaregreat

    Joined:
    Sep 5, 2018
    Posts:
    21
    is there any support for async/await functions? I have a monobehavior class with an IEnumerator, that calls upon an Async/Await function.
     
  44. moyashiking

    moyashiking

    Joined:
    Jul 10, 2018
    Posts:
    35
    I have high expectations for Visual Scripting.
    What are the enhancements compared to Bolt at this time?
     
  45. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    906
    1. There's a rudimentary support for the new Input System package.
    2. Renamed a bunch of stuff. Branch → If. SuperUnit → SubGraph. Flow Graph → Script Graph. Flow Machine → Script Machine. Macro Graph → Graph Asset. Control Input/Output → Trigger Input/Output. Value Input/Output →Data Input/Output. Self → This. Unit → Node. Assembly Options → Node Library.
    3. There's also a new, flat'er skin with icons from the now defunct Bolt 2 (I think). Performance in editor might be slightly better than Bolt.
    4. It can now create new graphs from the Graph editor window if no graph is selected.
    5. Support for RenamedFrom attribute on enum members.
    6. Graph Inspector and Variables windows are permanently embedded in the graph editor. You can't open them as separate windows anymore.
    7. Unit regeneration option has been transfered from Tools/Bolt to Project Settings/Visual Scripting. In the process we've lost the manual option to Update Unit Options rather than doing a full regen. It's still exposed in the API, however. So you can add your own button for it.
    8. On that note, AoT Pre-compile is now run automatically before building and also automatically cleaned up after.
    9. Slightly better documentation for the C# scripting API as there are concrete examples for custom nodes.
    10. A few dozen bug fixes that might or might not be an issue inside Bolt. I know I often get ghost Null Reference errors when selecting/deselecting graphs in an old project I have to maintain.This appears to be fixed in UnityVS.
    11. A few new nodes:
    • SetScriptGraph node
    • SetStateGraph node
    • GetStateGraphs node
    • GetScriptGraphs node
    • GetScriptGraph node
    • GetStateGraph node
    • HasStateGraph node
    • HasScriptGraph node

      The changes so far are mostly bug fixes and superficial improvements. All the good stuff like the new runtime, the new UI, the variable management improvements, etc are all still ahead. But at the current pace, probably at least a couple years away from being production ready.
     
  46. moyashiking

    moyashiking

    Joined:
    Jul 10, 2018
    Posts:
    35
    Thank you for your polite commentary!

    After all, the integration with Unity is the biggest update.
    It looks like it will take some time to implement the advanced features that Unity Technology is aiming for.
     
  47. SurreyMuso

    SurreyMuso

    Joined:
    Mar 16, 2020
    Posts:
    59
    Crikey. If the new VS is really 2 years away that's very disappointing. I realise that you don't have an inside line but I know you have an excellent grasp of things so I listen to you.
     
  48. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    906
    They will release the alpha for the new runtime for testing later this year or early next year. And considering how engine releases work where they have planned everything, like 4-6 months ahead at least, that runtime is not releasing in 2022.1. Maybe in 2022.2. Can't happen in 2022.3 LTS since LTS versions of the engine don't include major new features. So in the worst-case scenario, it'll be stable by 2023.1.

    The lead developer on the new high performance runtime has left the VS team for a different internal Unity project, so 2022.2 looks hopeful since most of the major work is done by now. I guess it largely depends on how stable the alpha test will be and if it'll require a lengthy beta test after that.

    The current UI is still the old IMGUI based one. They intend to replace it with UI Toolkit based solution called Graph Tools Foundation. The GTF package has received no updates since July because they're now integrating that into the core engine as well. It might be in 2022.1 or 2022.2, but it's hard to say from an outside perspective. And by in, I mean available for use to other Unity teams. The integration with it is a whole different matter.

    The Graph Tools Foundation package has been moving forward at a glacial pace because all graph based tools - Shader Graph, VFX Graph, the new animation graph, Unity Visual Scripting, etc - will migrate to it. So they have to support them all and communicate between several geographically scattered teams. I highly doubt the GTF migration will happen next year, especially because the VS team will be focusing on the new runtime, but maybe? My somewhat educated guess would be that this will happen sometime in 2023.

    Unity have mentioned some other enhancements, like the variable management improvements and serializer tech migration from FullSerializer to Unity's native serializer, but that's not happening before the new runtime is in. So further improvements will happen either in the second half of next year or in 2023/2024.

    Recently, I've started to doubt the direction of the package. It seems that Unity value backwards compatibility with Bolt and early versions of UnityVS (which is still re-skinned Bolt at this point in time) above all else. That means they intend to inherit some suboptimal design decisions from Bolt 1, like having the GameObject variables still be a separate component not tied to a graph. Which means you can't reuse graphs as easily as you can C# scripts because you have to manually recreate all variables on every reuse. That also has implications on their plans for variable improvements and making variables GUID based so they can be safely renamed and safely referenced. Can't really have GUID based Object Variables if they only exist on a GameObject instance.

    I feel like they lack a strong creative direction for what VS should be. And it's extra frustrating because they have to solve the same issues Bolt 2 already fixed, albeit it also introduced a few new ones which the Unity approach avoids. The new runtime from a design perspective is a great piece of tech and I'd say it's more future proof than what Bolt 2 had. But at the same time, their thinking on the UI/UX and general UnityVS architecture, which prioritizes backwards compatibility with Bolt 1, is frustrating. Bolt 1, while great for its time, is not exactly the peak of visual scripting.
     
    Last edited: Oct 16, 2021
  49. SurreyMuso

    SurreyMuso

    Joined:
    Mar 16, 2020
    Posts:
    59
    This is the most disappointing of all. I've used Blueprints and not enjoyed the experience. I guess it's the old problem of backward compatibility...

    To be honest, I'd rather they ditched backwards compatibility for the new VS. Leave the Bolt/VS as it currently is and develop a high-performance, no-compromise visual architecture that is capable of supporting multiple stakeholders. Sure, we'll never want to use it for real in high performance games (complex conditional logic and looping anyone?) but there are dozens of genres that might have 100% visual games, not to mention the value to the dev lifecycle of collaboration and stubbing.

    I'll be downloading the alpha on day 1 and trying it out because. I see great value in education (I'm teaching a new module at Uni starting this semester using VS) because I can separate language complexities from good games design practice. My young son can do far more in VS than he can in code, though I would expect that to change for all actors over time.

    Thanks for your insights. Always very useful...
     
  50. Trindenberg

    Trindenberg

    Joined:
    Dec 3, 2017
    Posts:
    304
    Part of the new interpreter is codegen, so that avoids old Bolt altogether which is a big reflection engine, and hence why when building to IL2CPP, Bolt seems to run at the same speed. While I haven't had the opportunity to test the new interpreter on IL2CPP yet (not currently working) I assume on top of the already massive speed difference (or loss of node latency which was always the issue), there should also be the improvements when building to IL2CPP as you would with normal code, especially if a whole graph can be amalgamated into a piece of code (one day) rather than per node. If the one is possible, I'm sure the other is too. Although, I think the direction is that it's still meant to be a visual interface for plugging high performance code together from an AAA perspective programmer/designer, rather than writing something completely using it. Although this is still very possible to write something completely using just a visual interface.

    The main advantage of visual scripting over coding, is no compile time. I don't know how many times I've waited that 10 seconds after I changed 1 item in code! So it also means, if you are prototyping some high performance code that does something in particular, well at least you can find the best method of achieving the goal output before that. Also don't know where Visual Studio hot reloading comes into things, and whether that will also change the code/compile/play aspect, but I hope so!
     
    theor-unity, SurreyMuso and EagleG like this.