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. 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

Resolved Is it viable to create a whole game using Visual Scripting?

Discussion in 'Visual Scripting' started by Marou1, Sep 25, 2022.

  1. Marou1

    Marou1

    Joined:
    Dec 13, 2021
    Posts:
    49
    Hi,

    I could not find a clear answer to this. Usually, it is mentioned that it is good for prototyping, it is slower than c# scripts, it has no error control (?)...

    I've been working on a game for several months now, during my free time, and so far so good. However, I'd like to know if it is feasible to do every in VS (beside defining classes or a few short scripts here and there...).

    What are the issues to expect when developing the whole game with VS?
    Are they solvable?

    I am not asking about the fact that it based on nodes, that it can be messy, it can take time to create a script... So nothing related to the UI/UX.
    I am asking about backend issues, like the game will be less stable specifically because it was programmed with VS, major performance issue related to the use of VS, compilation issues because there are bugs in VS or because of the way VS is converted into code...
    I'm just throwing examples of issues that could happen.

    Thank you !
     
    Last edited: Sep 25, 2022
  2. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    895
    Performance

    VS is slower than C# anywhere from 5 to 10 times depending on the scenario.

    There's also a perf cost to the number of instances that exist in a scene for ScriptMachine/StateMachine.

    The presence of UVS also significantly increases load times on platforms like WebGL and mobile.

    If performance is good enough highly depends on what you're making.

    Stability

    1. Stability wise, a lot can break if you rely on reflected nodes even for first party tools like TextMeshPro and Cinemachine.

    These packages on occasion have minor API changes that VS doesn't know how to recover from. Say a method gets a new parameter/argument in a package update, all reflected nodes of that method will break with no compilation errors. The game will throw red errors only when one broken reflected node is triggered in Play mode or the final build. This way you can accumulate a lot of silent but game freezing errors.

    There are options for mitigating this:
    1. Lock in Unity version and don't update packages that have a lot of reflected nodes in your graphs.
    2. Use custom nodes for any package integrations since C# doesn't have a problem with minor API changes such as optional method arguments.
    3. Write C# wrapper scripts and and use reflected nodes only from your own wrappers what won't suddenly change API.
    4. If you discover one broken reflected node and know there's a problem, use Node Finder from the asset store to find all other instances of the node in your graphs and fix them.

    2. Another stability issue is IL2CPP compatibility. Visual Scripting by default does not work on Ahead-of-time platforms (all IL2CPP targets) because it does a lot of runtime code generation which is not allowed on AOT platforms. To mitigate that UVS runs a build preprocessor that scans your graphs and generates stubs so logic contained in graphs is not stripped from the build.

    This build preprocessor currently is faulty because it sorts C# assemblies into runtime and editor assemblies. You won't have problems with runtime only assemblies but the build preprocessor will skip any C# assembly that references Unity editor in any shape or form including valid use cases like #if UNITY_EDITOR conditional compilation code.

    This faulty implementation breaks reflected nodes for most asset store editor extensions and Unity's own first party tooling like Cinemachine. So if you use reflected nodes from these assemblies, the build simply won't work because UVS build preprocessor will skip them by current design.

    You can mitigate this by writing C# wrappers or write custom nodes that don't have UnityEditor references.

    The build preprocessor can also fail on specific platform configurations such as iOS due to bugs with the tool that can't be solved without Unity fixing it on their end. And the last update was like 6-8 months ago, so don't expect hotfixes to be a thing.

    You can completely skip the AOT preprocessor issues and bugs by targeting the Mono scripting backend since it allows runtime code generation. But platform availability is limited, i.e. no consoles.

    3. UVS is also based on a 3rd party serialization technology called FullSerializer which has been sunsetted years ago. No one's kept it up to date. So while you won't come across major issues early in a project, in a year or two you'll have some interesting warnings in console such as "failed to deserialize" a graph or performing an undo will wipe your whole graph clean of nodes. I haven't come across any major stoppers, but it's still concerning.

    Long story short, current UVS is not performance friendly but depending on the kind of game you're making it could be good enough. Stability wise, UVS is significantly flawed and don't expect any improvement in that department in short to mid term.
     
    Last edited: Sep 25, 2022
    DevDunk and Marou1 like this.
  3. Marou1

    Marou1

    Joined:
    Dec 13, 2021
    Posts:
    49
    Thank you for all the details.
    I am not a programmer, that's why I am using VS. So I will have to find workarounds...

    Performance:
    I understand that the performance is slow with VS. The game is about environment discovery and resource management, so I guess the performance is less critical than in an FPS for example. Also it's a PC game, i will be testing the build regularly and monitoring the performance.

    Stability:
    I googled reflected nodes but I couldn't find a definition. Could you provide some explanation or a link to the documentation?
    Could you also provide an example of an existing node that has UnityEditor references? Sorry if it is trivial, but I don't understand why I would have reference to the Unity Editor since its features are only used to create the game but are not compiled in the build.

    I already had nodes deleted in a script, but only when I was editing in play mode.
    You mentioned warnings in 1 or 2 years. Why only in 1 year and not now? Because of some future upgrades? Because of the increasing complexity of the game?

    Thank you very much!
     
  4. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    895
    Reflected nodes are the nodes UVS automatically generates when you add assemblies or types to Node Library and regenerate nodes via a process called Reflection, which is the main driving force behind UVS and the key component of its runtime.

    Also, most of the default nodes are reflected nodes and are automatically generated from Unity's C# scripting API. Very few nodes are actually custom implemented and therefore most UVS nodes are fragile to API changes when you update Unity or packages.

    It's not about one single node having UnityEditor references, it's about the assembly which is sort of a library of scripts. Most Unity tooling like Cinemachine has all their scripts grouped into assemblies. A reflected node points to a C# script that exists in an assembly.

    And since Cinemachine has parts that extend the editor, it obviously also includes editor references in its assembly. Even if you use a reflected Cinemachine node that doesn't directly reference Unity Editor in any way, UVS doesn't care about that. It looks at the assembly as a whole, and if there's one tiny UnityEditor reference in there, it'll throw the whole script library out and ignore it.

    TextMeshPro also extends the editor and didn't work until they whitelisted the TextMeshPro assembly, they haven't whitelisted a lot of other Unity tooling like Cinemachine. And they can't whitelist anything from the asset store or your own code although you can write your code without UnityEditor references.

    If you're targeting PC only and don't care about mobile/WebGL and consoles then you can target Desktop Mono scripting backend which doesn't need the AOT build preprocessor step so you can skip these issues entirely. It's only an issue for multiplatform games where more often than not IL2CPP scripting backend is the only option.

    FullSerializer has a decent amount of edge case bugs that tend to accumulate over time due to the project and UVS going through upgrades and the serializer itself being unable to resolve issues as project grows due to opaque internal errors that are not exposed to console or sometimes you get an undescriptive warning with no clues how to fix it. These issues are also next to impossible to reproduce in a new project so they go unfixed indefinitely. You can minimize these issues by not upgrading Unity/UVS.

    However, none of these serialization issues have been complete showstoppers in my experience, they can be worked around or ignored and It'll be fixed in a couple of years once they migrate from the defunct FullSerializer to Unity's native serializer in the next major version of UVS.
     
    Last edited: Sep 25, 2022
  5. REDACT3D_

    REDACT3D_

    Joined:
    Nov 8, 2020
    Posts:
    221
    Hum, I would simply answer. Yes. You can definitely build a complete game.
    Nothing stopping you but your ability.

    As for performance.
    It would depend on what you make obviously. But I personally don't notice working in HDRP but the end user may if they have old equipment? I don't experience this.

    And if you're new at code, you can write code that's even worse. so it's all relative to your ability.

    I mean, if you can make Pong, that counts as a game, and would be way easier to make with VS. lol The key is to use unity's built-in features though. and not to try and mix hand typed code with VS, that kind of defeats the point in my opinion.

    way fewer keystrokes

    You could make doom in an afternoon for an example.
    if you had the folder of assets ready to go
     
    Last edited: Sep 25, 2022
  6. Marou1

    Marou1

    Joined:
    Dec 13, 2021
    Posts:
    49
    Thank you both for your answers.
    If I try to roughly summarize what @PanthenEye mentioned:
    1)
    - Most of UVS nodes are reflected nodes
    - Reflected nodes are fragile to API changes so Unity and packages upgrades should be avoided.
    2)
    - Reflected nodes are not correctly compiled using AOT
    - AOT is required for mobile and console games. So it is not possible to develop a game for PS5 for example using reflected nodes.
    - Reflected nodes are correctly compiled using JIT, so game targeting PC should not have stability issues related to the use of UVS.
    3)
    - There are some serialization issues that usually are not blockers. They can be minimized by not upgrading.

    Conclusion: for my game targeting PC, I should pay attention to the performance, but beside that I should be fine.
    Is that correct?
     
  7. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    895
    Correct.

    Correct, but existing Unity core API rarely undergoes significant changes. I had one or two core API changes that broke graphs in roughly two year development time I was upgrading Unity regularly so that played a part as well. And TextMeshPro had 3-4 API breaking changes in that time. Packages are more likely to introduce breaking changes.

    Correct, but only for assemblies that reference Unity editor in some way like Cinemachine and similar tools that extend the editor and have their scripts grouped in assemblies.

    AOT is required for mobile and console games - correct. The latter part is sorta correct, you can still develop for PS5 if you write C# wrappers or custom UVS nodes.

    Correct.

    Correct.

    That is correct.
     
    REDACT3D_ likes this.
  8. Marou1

    Marou1

    Joined:
    Dec 13, 2021
    Posts:
    49
    Thanks a lot!
     
    REDACT3D_ likes this.
  9. CameronDWills

    CameronDWills

    Joined:
    Feb 26, 2021
    Posts:
    61
    I can provide a lot here, as at the start of the pandemic I decided to pickup Unity (with no prior coding experience) because I saw they had baked Visual Scripting into the Unity software as an officially supported solution. Now here I am almost 3 years later, and I have a complete mobile (and soon to be Steam/PC) game ready to launch this month... and I've built 98% of it entirely with visual scripting.

    To answer the main question: yes you absolutely can build a game entirely with visual scripting, I've done it!

    Since I don't have any previous experience with game dev or coding, I can't really speak on what its shortcomings are too heavily because it's all I know and have nothing to compare it to. But I'll give you some of the pain points I've had, and some tips on getting the most out of VS.

    Just some quick background on my game, I designed it from the start to be a mobile game. I'm using URP, the latest Unity version 2022.1.18f1, and the style of my game is 2.5D in which I'm using 2D sprites in 3D environments. When I look at some of my script graphs... I'd like to think my game is pretty massive and would have performance issues, but I haven't really had any. I had my URP graphics settings defaulted to 'ultra' just because I didn't think it'd matter, but the feedback I received was that there were laggy moments on Android devices (never had issues on iOS) but after dropping the settings down to medium (which didn't make any noticeable difference visually of my game) that seems to have been resolved.

    My game is also a 1 vs 1 PVP focused game, so it realies heavily on multiplayer and networking/cloud functionality which I leverage Unity Game Services entirely to handle. The bad news about that is VS doesn't really play too nice with UGS out of the box, but I've since created my own Unity asset in the store which allows you to use all of the same services I have with VS (and I was able to write it with my limited C# experience, so making custom VS functionality probably isn't that tough).


    The name of the game is Tactic Legends if you want to check it out, here's the links:
    Official website: https://tacticlegends.com
    Android beta test: https://play.google.com/apps/testing/com.WillsCreative.TacticLegends
    iOS beta test: https://testflight.apple.com/join/OnRQLDUN
    Steam: https://store.steampowered.com/app/1965070/Tactic_Legends/
    Discord: https://discord.gg/Qe47SpeFTx

    Some great Visual Scripting assets I recommend:
    • Node finder for unity visual scripting | Visual Scripting | Unity Asset Store (Free) - One ESSENTIAL tool you'll need and has made my life so much easier. So many reasons why this tool is great, check it out and if you get nothing else, get this.

    • Bolt Pool | Visual Scripting | Unity Asset Store - A paid asset that has made it a lot easier to handle object pooling (reusing the same game objects, think things like bullets, special effects, etc). It says it doesn't work with the latest versions but it does with a couple quick fixes you can find in the reviews. I use this asset to handle all of my visual FX.

    • Multiplayer with Visual Scripting | Visual Scripting | Unity Asset Store - Full disclaimer, this is the asset I created, but if you plan on having any multiplayer functionality it's totally worth it. It would've saved me a solid 40+ hours of work if something like this already existed and if you don't know C# very well then it's an essential. As I utilize more Unity Game Services I'll be updating the asset, but right now it allows you to use the following with visual scripting: Authentication (login), Cloud Code, Cloud Save, Remote Config, Lobbies, Relay, Netcode for Game Objects, Economy (currency, items/inventories, purchases), Microsoft PlayFab, Photon PUN. I'm also about to release an update that lets you use it with the Unity In-App Purchase package in connection with Economy.

    • The Official Unity Visual Scripting Discord server - I've been able to get a ton of help here from others who use VS, moreso than I've been able to get here on the forums and much faster.

    Some problems I've had with VS:
    • If you end up having an issue with one of your nodes, there's really no way to track down the cause. You have to go through all of your script graphs, sub graphs, one by one and try to find the node causing the issue. Node Finder helps immensely with this, but the console log will basically tell you nothing useful.

    • It can be kind of glitchy... there have been a couple times where all of the data I had typed into some of the fields in my nodes just wiped themselves... no idea why. I've had some variables wiped a couple times as well. As a best practice going forward, any node that allows you to type in a field on the node itself, I instead just connect a node of that type to it directly (like a string literal node) instead of typing out my string into the node.

    • When testing the game in play mode while simultaneously having a script graph open can cause a performance drop in the editor and it gets kind of laggy. This may just be due to the size of my project at this point, I'm not sure. The fuzzy finder also usually never loads for me the first try, it locks up Unity unless I close it out and reopen it. Could again be due to the size of my project and all of the custom nodes (some of which are probably broken, I have a couple dozen script graph warnings in my log).

    • In order to have new nodes available to you, you have to constantly add them to your "node types" in project settings. There may be times when you're looking for a certain functionality and you can't find it, 99% of the time it's because you need to add a new node type (wondering why all types aren't available or added automatically, performance?). What's bad about this though, is there's a generated file that saves all of the node types you've added, and if something happens to that file... (as has happened to me) all of your node types get reset to the default and if you've added a bunch it's going to be impossible to remember everything you've added. Fortunately this won't break anything you've already created, but if you go to search for a node to use it won't show up. You'll have to remember what node type you had to add to get it and add it back.
    I've seen some posts here from the Unity team mentioning that the next major update to Visual Scripting will address performance with a big overhaul of how the system works, I think by shifting away from reflection, so it seems it's going to keep being officially supported well into the future and the update should hopefully address any concerns with performance. I think like others have said, depending on the scale and intensity of your game, performance may or may not be an issue for you. In a game like mine it certainly hasn't, especially on PC.

    Hope this helps!
     
    Last edited: Oct 5, 2022
  10. Marou1

    Marou1

    Joined:
    Dec 13, 2021
    Posts:
    49
    Thanks for all the details.
    I have made a mobile game using UVS only, but it was a very basic one, so I didn't push it very far.
    My main concern now is the performance for my new game on PC. I saw a Youtube video comparing UVS to c# scripts and it was something like 150 times slower...
    I can see that some graphs that do some calculations are not instantaneous...
    Is there a release date?
    Is it retro compatible?
     
  11. REDACT3D_

    REDACT3D_

    Joined:
    Nov 8, 2020
    Posts:
    221
    Never come across an instance when the speed of the code executing is a problem for building game logic with VS.
    I think mostly because it's all relative.
    Like how the scale of one object is relative to the next. like that with time too.

    not trying to say that Visual scripting doesn't run slower than code 'can'. just pointing out that it matters more how things are put together. but it's kinda like comparing Python and C#.. both work until you try to combine the two. then it gets messy.

    If you've ever tried to do DSP with python.. its too slow. need fast executions to synthesize every waveform without error at the speeds you want. Thankfully audio is a relatively low frequency in the spectrum. but DSP's another topic. lol
    But what I'm saying is that if you want to do DSP, you write a C# script then just run it with python.

    It would be the same, you just have Visual Scripting execute some action in C# Script.

    I think visual scripting is perfect for someone who would have otherwise not have made a game because lack of programming knowledge. Like- If you're thinking about execution speed, you're probably not a new programmer and can make educated choices on what to do or not do.

    Not sure how it would work in a team environment however.
    if you had a team of VS pros it would be quite powerful because it would remove all the little formatting issues and habits.

    and then there's always the potato computer issue
    only so much you can do about that..
    i imagine when we can just ask the automated AI to generate code for us, that'll be slower than python ^.^

    A guy with an English accent complains about code:
     
    Last edited: Oct 10, 2022
  12. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    895
    No one knows. All we know is that they cancelled version 1.8 that had the new runtime. It was in preview. They've refocused on porting the tool as well as all other Unity graph based tools to Graph Tools Foundation framework. GTF for short. And GTF package hasn't been updated since July 2021, they're now integrating it into the core of the engine. Unity 2023.1 alpha doesn't seem like it has it and for such a major change it's likely in the territory of Unity 2024 or even Unity 2025. i.e. several years most likely.
     
  13. Trindenberg

    Trindenberg

    Joined:
    Dec 3, 2017
    Posts:
    304
    I should think once DOTS is in a stable release 1.0 there will be more on Visual Scripting. DOTS/Burst and high performance VS are big abstractions of C# which itself is ever developing (less so changing), and are at different ends of the scale performance/audience complexity/simplicity wise. Likely VS will have more focus after whatever point DOTS and the Editor becomes more a development than a changing finalisation. Editor definitely needs a refresh in my opinion, if that's what GTF is then great. I realised the biggest bug for me currently is running the editor in 4K with lots of Windows. Not a problem in any other app except Unity! Don't really have a choice as I only work in 4K and I like my windows. I also do music, which relies on very graphical aspects of the whole editor (while not including a 3D game view), my window load might be 40+ graphical, so definitely the Editor struggles somewhat.
     
  14. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    895
    The prerequisite of DOTS support is the new high performance Mono(and DOTS compatible) runtime and Graph Tools Foundation migration. Both of which are not available yet and are fundamental changes. I wouldn't bet on seeing anything DOTS VS related anytime soon.

    And while they call it Entities or DOTS 1.0, it still lacks many common features like DOTS animation. Even if they added DOTS support to UVS, it wouldn't work without serious technical knowledge involving complex GameObject-Entities hybrid workflows that are not accessible to designers. In fact, Unity have stated that UVS is mainly targeted at artist and designer workflows.

    Furthermore, DOTS multithreading requirement is not supported on all platforms Unity targets such as WebGL. It's unlikely they'll drop a whole platform to make UVS DOTS/Burst/w/e based. Mono is 100% the current focus and DOTS will be another option available in 4-8 years with current pace of development.
     
    Last edited: Oct 14, 2022