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

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 !

 

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.

 

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!

 

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.

 

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

 

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?

 

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.

 

Thanks a lot!

 

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!

 

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?

 

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:

 

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.

 

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.

 

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.

 

Seems like the editor reference assembly problem finally has been fixed: https://issuetracker.unity3d.com/is...gnores-assemblies-that-reference-unity-editor

I'm using UVS for quite a large game but never encountered any weird problems that could not be fixed in one way or another. There's always a backup sitting behind your back when some unfixable weird bugs happen, but now this rarely happens compared to the Bolt times.

I constantly update both Unity LTS and 3rd party assets that I code with UVS and everything is good so far. It's been around 6 months and I use and script many Asset Store assets with UVS such as Rewired, Sky Master, DoTween etc.

I'm not saying that it's perfect but it looks like it's certainly possible to make games entirely with UVS. The only thing I was a bit worried about was the IL2CPP and would love someone who uses assets with editor references to confirm it's been fixed. Other than that, everything seems pretty stable enough.

I hope the current UVS doesn't get totally abandoned until the new one comes out in 10 years

 

It is, they reversed the change that caused it.

It's def more stable now than Bolt 1 was, but after more than two years of bug fixing and almost no new features, it really should be.

It'll continue to be good as long as API doesn't change but once it does you can have a lot of graphs with broken nodes that are hard to find and only trigger errors at runtime i.e. in Play mode or final build. This is how we managed to push and update to Steam with broken TextMeshPro nodes. Thankfully, in our case it only didn't display some text instead of hardlocking the game but it can go very wrong. As the project grows and you continue to upgrade, the potential for silent runtime only errors also grow. Although now that Node Finder exists, it's much easier to track down all instances of a broken thing once you're aware.

And UVS 1.8.0 converts broken API nodes to dummy nodes now. Not sure what the implication for the change is, perhaps they don't trigger runtime errors when they're triggered. I haven't tested it.

It's certainly possible now, since they've solved the major technical issues more or less.

It is fixed in 1.8.0.

Per the stickied November 2022 update, current version won't receive any new features this year, only stability improvements if necessary. They've refocused on the next major version of the tool which according to the post will take "2-3 release cycles"(years) to finish.

 

Thanks for your quick reply. Yeah, Node Finder definitely brings more color to dev life
Should've been native feature even during the Bolt times. I had even suggested that back then to Lazlo but he didn't seem to get the importance of it

These hidden troubles you mention sound very annoying, but as long as they're possible to trace down eventually, I'm fine with it as I'm not a programmer and one of those people that wouldn't code at all if not for visual scripting

I'm happy that there are no big showstoppers at the moment that would totally break everything. And I hope it will be possible to bring my game to the consoles one day without any big troubles and with all the assets I love and use.

 

Bolt 2 had it. Bolt 1 never got it because Lazlo refocused on developing Bolt 2 from 2018 until 2020 when the tool was acquired by Unity.

Hey, that was me back in the day but I was forced to pick up C# due to Bolt 1 being stuck in limbo while Bolt 2 was developed and then continued to stay in limbo while Unity were busy integrating the thing into the editor.

At the end of the day Visual Scripting in its current form is nearly 1:1 with regular C# scripting, it just visualizes it and removes some of the initial complexity like having to declare namespaces and understand inheritance. If you ever find yourself limited by Visual Scripting, consider trying out Rider IDE. It does a lot for you automatically like adding namespaces and made my transition from Visual Scripting to C# rather seamless.

Fingers crossed!

 

Visual scripting's actually better than typing in code by hand, especially for people who have the spelling/grammar of a dsylexic 4 year old (describes some of the newbies on here methinks)

 

Personally, I think it's a bizarre way of creating a game. I mean e.g for a simple line of

Code (CSharp):

1. rigidbody.velocity= new Vector2(rigidbody.velocity.x, jumpStrength);

You have to add 5 big rectangle boxes of visual script !!
This violates the very first principle of programming, which is being "easy to read and understand!"

 

Different people have different functioning brains. For me, having different box sizes with different colors, positions and names helps to better organize thoughts. And putting certain boxes under groups (comments), that you can assign different colors helps tremendously as well. It makes me much easier to concentrate. I tried learning regular code a bit and it was much more difficult.
Could be ADHD or smth too, but I am very thankful strong visual tools exist for normal scripting and shaders as well.
I might sound strange but I love logic, just not in the form of text. And I think it's actually easier for the majority of people, most just don't even start because they're afraid of traditional scripting.

Also, probably a very unpopular opinion, but I think all scripting is slowly evolving in some form of visual scripting because it's easier to start with and looks prettier, something you can move around and interact with. And the traditional one will be used only by hardcore programmers for low-level programming stuff in the future.

 

This just makes coding in VS a lot slower but not impossible.

The real problem is the fact that Visual Scripting doesn't support any kind of proper video game architecture.

No inheritance, no interfaces, no strong typing, no tools for refactoring graphs, no way to organize or even know how many custom events are defined in a project or what their arguments are, no support for delegates/callbacks, lack of editor tooling for multiple graph editing and debugging assuming an object has more than one graph. As a result everything gets tightly coupled in large monolithic god graphs.

It's still viable for many types of smaller games but if you want to go at it seriously, C# is an inevitability at some point.

 

There's definitely a lot to improve. I'm pretty sure everything you mentioned is possible.

Also, I've figured out how to use multiple graphs at the same time. It was easily accessible feature with Bolt, not sure why Unity decided to hide it. You can do it by clicking on a Subgraph node inside a graph and then clicking "Open in new window" in the Context Menu that pops up after right-clicking. You can then keep the window forever and use it with any graph if selected.

You can also use a free and wonderful asset called "Node finder for unity visual scripting" to quickly find nodes you're looking for, including the count of how many custom events you got across all your graphs.
But beware, have only one active graph window while searching or it can cause some serious errors as the node finder isn't made for multiple graph windows (hidden feature discovered yet only by few).

Hope that helps someone ☀

 

If this is something you have to do more than once, you can make your own custom subgraph so you only have to make it once, and condense it into 1 simple node that even has an editable field(s) for the variables. Basically the equivallent of making a C# method that you can reuse anywhere else, but without all the complicated syntax and inheritance, classes, etc.




I think to someone who doesn't know any code, and probably even to a lot of those that do, this looks way simpler. I don't have to know what all of that code means, or how to write it, or the proper way to write it. I can just drag and drop a couple of boxes, don't have to create any files, set any dependancies, remember any syntax, etc.

It also allows me to watch what's going on in the code visually, while the game is in play mode, and edit and make adjustments to my graphs in real-time without having to exit play mode and reload everything. If something breaks, it highlights in red exactly where in my graph the issue is and gives me an easy to read error message.

State graphs help a lot in keeping things organized and not so massive as well.

Here I have the logic of my entire game in this one state graph. I could probably organize it better, but this was good enough for me:


For me, looking at a github project for example is a pain to try to understand because code is seperated into so many different files and classes, and then you have to read through all of this text... but as long as you organize things in a good way, it's much easier to understand a visual scripting project at a glance.

Ultimately all things are going to end up being visually scripted, if not automated completely by AI. Just look at the web development industry... a decade ago you needed to hire a web developer. Now there's 101 drag and drop website builders. Mobile apps have a lot of the same tools. Unity.. Unreal both have them. The barrier to entry of highly complex knowledge is being erased every day as new tools are released designed to make it easier

 

Yeah... Thanks for reminding about the power of subgraphs and real-time code editing. They're great.
Looks like it already has around 50% of features people who've never tried it think it's missing.
I also need to use states more. I make too much state logic inside flow graphs lol.

Didn't know you can't edit C# during play mode and see the changes right away. So there's even a technical aspect that is ahead of C#, wow!

 

Just a word of warning ... our app got rejected by Apple when we used PlayMaker to create our games. The reason Apple stated was that it was possible for us to download code via AssetBundles this way, and Apple must have access to all code at the time of submission.
I don't know if they apply the same rule to Unity's visual scripting, but now you're warned.

 

Omg!! What nonsense!

 

Well, Apple's main focus is to protect users and it is technically correct that you could visually script malicious code and download it via AssetBundles, but yeah ... they are strict. Worst thing is, we never mentioned using PlayMaker, they somehow detected it.

 

Visual Scripting doesn't support downloading new code that doesn't exist in the main app. They plan to enable that in the next major version of Visual Scripting, however.

 

Almost all humans have that brain, until they learn how to program, and then typically one compact line of instructions suddenly seems more intuitive than 5 boxes floating arbitrarily in space tied together with rope.

I get that programming looks like confusing mathematical cancer when you don't know how to read it, and your brain just wants to shut down. Perfectly natural. Here is where I warn people not to assume that their brains are simply not setup for writing code if they experience this feeling.

 

hi , do you know the solution for this, i am buying playmaker and i dont want to get trouble releasing for ios.

 

hi, please reply, is visual scripting 1.8 which has not been updated since nov/dec 2022 . is performance improved ?. because earlier many were saying its like 5 times slower than tradional coding.

 

Nothing has improved in a very long time and is unlikely to improve anytime soon.

 

If that number is correct it's already very fast for visual scripting. UE5's Blueprint is on average 10x slower than C++ which is about twice as fast as C#. So if it's truly 5x slower than C# then it's on par with one of the best. For more performance you're going to have to learn C#.

 

AFAIK you cannot use PlayMaker on iOS devices. You need to create your own subset of components to build games with (we have), or maybe find something less known that they don't detect for.