Official Visual scripting roadmap update - September 2020

I’d like the portal page to go up soon too, but if they rush it now and later have to go back on some highly voted features, there will be another community backlash. So I’d rather they make sure everything that is going up on that page is relevant long term.

And we all would like more clarity on the specifics of what the roadmap mentions. That's at least feedback Unity can take action on. They've answered more technical questions on Discord when the roadmap went up both publicly and internally in alpha tester channel. The alpha testers (and Bolt veterans) were also deeply involved in giving feedback about major Bolt 1 issues this roadmap addresses. Unity came to us and asked what the community needs. So while Bolt 2 is not happening, they're listening and communicating.

You have to give them time - a lot has happened in the past few months from complete directional change, to Bolt team expansion to existing graph based tools team reshuffling.

The roadmap was posted just over a month ago and outlines what they're working on now (in pre-release stage) and what they will focus after that. Rohit posts (official, approved by his manager) work logs weekly and him and other devs answer questions on Discord regularly. Hardly a complete silence. These things take time to do right, especially when multiple teams have to coordinate (probably internationally too).

 

I don't keep track of anyone's messages here. I was just catching up on that thread yesterday since I hadn't read a lot of it and I remembered someone had said that about that youtube video. It just seemed like a similar funny situation when technical issue(s) gets boiled down over a game of telephone into generalizations like "this engine causes low framerate" similar to "this visual scripting solution causes stuttering." Not that there isn't some truth to some possible issues that are commonly encountered (like the dev blog post that Unity made recently on addressing inconsistent FPS and delta time) and how Unreal Blueprints don't allow for some deep optimization with C++ some games may benefit from on certain platforms could resolve stuttering. So, I don't mean anything personal. It just sounded like a similar generalization.

 

Seconded.
But to be fair -- this is a difficult topic that has to be heavily-understood from the ground up.
Even with a solid 20+ years of experience under my belt in this area, Visual Scripting has its own unique demands -- many seemingly impossible without the proper (low-level) scaffolding to build upon (if you care about performance).


To speak on something similar:

These points are something many of us who care a lot about the Visual Scripting technicalities are wondering a great deal about. This affects how flexible or "low-level" we can actually get with the scripting language -- and how much we have to go back-and-forth to something like C# when we (inevitably) need to modify Unity itself, for example.

The fact that Unity has not seemed to share any specifics on how (or if) any of the particulars that made Class-like structures "useful" are in the pipeline -- much less even "compatible" with many of our workflow needs. We have, however, had plenty of examples and specifics about how Unity is NOT going to be delivering on what it promised at first -- and as such, people have the right to be worried.


Unity themselves should really step in here and diffuse some worries and concerns.

My guess is that most of their concern right now is how to get DOTS and Monobehaviour talking amongst themselves (which probably has something to do with the "interpreter" bit).
This was something that was initially deemed "impossible" with DOTS VS which was why we had two separate systems to begin with. Now that it somehow seems possible to "mix" the two -- I would like to know if Unity has any concrete plans for how to do this (without killing performance for job-based DOTS and ECS-style workflows).
The system I have been working on should totally solve this issue of compatibility between the two systems and their workflows (without the need for an explicit interpreter), but I am leaving Monobehaviour as "legacy" while focusing on ECS-style architecture that only _minimally_ relies on gameobjects (i.e. for scene positioning) as was what seemed to be the case in Unity's drop 6 era in regards to things like MegaCity and Visual Scripting.

Before I go 100% all in and code the damn thing on loose, unresolved, technology, with alpha-level implementations and no documentation to distinguish between feature and bug -- I'd like to actually know what's in the cards with the direction of the technology (and how firmly-established that is) to determine whether or not I should go forth with this solution myself -- or simply wait and "mod" Unity's implementation to fit my design later.

From what has been said about variables being "local" to the graphs (and not entities) -- I suppose ECS-based workflows that consider entity-level data are being thrown to the wolves? -- Or is there a way to make a graph either global or local -- or both?
@LaurentGibert (or anyone @Unity who wants to chime in on this?)
Above all -- I want my Systems to remain "modular" and therefore process entity-level data. There are times when I would like to write my own jobs and even entity component definitions (or have their respective scripts be automatically generated for me at least) in order to maintain performance. How is low-level stuff such as this going to be handled?
Like what others have said, it is clear that, right now, there are not clear enough plans in place to provide us with a true and clear-cut expectation of things-to-come. For people like me to have an idea of what will remain "Bolt 1" and what will be "evolved" by Unity going forward could really REALLY help ease our concerns.


@Ex-Crow is doing Unity's job right now.

But despite his attempts to be helpful -- Nothing will do better than more answers straight from the horse's mouth on what the low-level workflow is going to look like (and how rigid and/or slow we can expect lower-level workflows -- and ultimately performance -- to be).
However, no matter what you do -- (perceived) Radio silence is not the answer.

 

General thoughts about Visual Scripting progress:

I was excited when I saw Drop 6 in DOTS VS -- but then it changed direction entirely after one (unreleased) build. At that point, sh*t hit the fan for me. Instead of something new and original -- something I could actually make games with for once -- it was looking a lot like Bolt 1 suddenly. It was as if @Unity had trapped lightning in a bottle -- and then let it go as quickly as they caught it because they were afraid it might somehow 'shock' them. :/

I think @Unity has a decent "skeleton" of a plan going forward with their position on integrating the UI and underlying technologies for graph tools, but the "meat" of this plan (and its eventual shape) can still make or break it.


Scripting Workflow Concerns:

User workflows must remain both data-oriented _and_ flexible to be extremely performant (even if this is all under the hood). But they also need to be user-friendly and intuitive when the user might want to modify their behavior.

My biggest fear is that I don't get the feeling that anyone @Unity really has a sense of the overall workflow just yet. This is why I am working on my Visual Scripting tool's design (considering Unity technology at its core) -- I am familiar with every workflow inside (and outside) of Unity as far as where design friction in the workflow exists, so if Unity doesn't see the same friction I do, and the more inflexible the underlying system is (or the harder THAT is to modify), the harder I must work to redesign the workflow in my own vision.


Visual Scripting workflows are notorious for design friction -- even the few that have been battle-tested in recent years. There are always unexpected (extremely varied) use-cases _and_ performance-sapping routines that target EVERY single (existing) Visual Scripting language's Achilles heel.

Examples of the Achilles heel of various Visual Scripting languages:

• "State-based" or "Flow-based" languages (like Playmaker) are extremely "containerized" and can be extremely inflexible without constant coding (in larger projects), requiring specially-written nodes to extended.
  The Achilles heel for Playmaker's design (for example) is mostly in the ergonomics of scalability.
  
  
  
• "Unit-based" or "Snippet-based" languages like Bolt 1 or Fungus or even GameMaker whose "Units" (or 'code' "snippets") are extremely easy to extend, also ultimately tend to face extremely performance-intensive requirements very early on, since these kinds of languages require an unpredictable data scope in order to remain "flexible" and 'easy' to use and extend. While this can sort of make them more "scalable" than "State-based" languages to an extent, performance (thanks to unpredictable structural design and data scope) is often the bottleneck that prevents these from being viable in all cases, which ends up being the Achilles heel of something like Bolt 1 -- even with a Job-based backend.
  
  
  
• "Optimization-based" languages (like Blueprints or even art-tools like ShaderGraph and/or Houdini) that use an (essentially "blackboxed") set of nodes are generally designed this way to be more "performant" than more freeform "Unit-based" languages like Bolt 1 -- BUT in order to do that, they ALSO require you to know and follow strict rules and (usually extremely unclear) methodologies that (ironically) requires you to study and learn how to use "magic" combinations of nodes to do certain tasks, which can only be learned by (sometimes years) of intense study, learning each and every ("blackbox") node, its capabilities, and the (ironically internal) shortcomings of the node's processing methodologies in regards to performance -- inside and out -- in order to use them in a truly "performant" way.
  Many intensive data type conversions are inherently required to keep things "performant", but will (more-often-than-not) actually bottleneck much of the performance gains you would receive from strict optimization, syntax, and data conversion requirements due to the simple number of conversions required in a system, as well as the increasing bloated complexity that quickly devolves from this requirement in both project-size and memory and CPU performance requirements too, as wildly-duplicated data is shifted around to be converted non-stop.
  While caching and pre-processing data can help complex graph performance -- this kind of thing cannot always be predicted beforehand (especially when it is necessary at runtime) and cannot be relied upon without clever design affordances (i.e. by processing variations of the whole graph once and "shrinking" the data required to process it through an "interpreter" later) or by focusing on convenient "cache" points in the design (i.e. Houdini caches open-world geometry that takes hours to "bake" so that it can be further processed in the graph), which, again, has very little use in realtime applications.
  
  The true Achilles heel in "Optimization-based" VS languages is a combination of the learning curves required by the "blackbox" nature of the nodes and methodologies themselves and the fact that node behavior often cannot be altered or tweaked without resorting to either a (slower) interpreter-style implementation (Bolt 1) and/or coding in the "original language" (to keep performance) which defeats the purpose of any "Visual Scripting" to begin with. This is why Bolt 2 wouldn't work. Still, workflows and even the systems using the 'optimized' node for practical applications are often slower, more complex, and require more data "conversion" operations than would otherwise be necessary with more malleable nodes. The nodes take a performance hit regardless of the "optimization" approach (which can be huge in some cases). The bloated and convoluted systems you end up with after silently shifting the inherent complexity onto your shoulders (in order to maintain performance). "Designing" performant node combinations is simply not your job as a designer. This is the true Achilles heel of this kind of Visual Scripting editor.

To design a language that places a major priority on performant, fast, intuitive, optimized, speedy iteration for designers is something that just doesn't exist. Solutions that are designed around these exact principles can fight back (Bolt 2 and the early version of DOTS VS was a good start, though for reasons already mentioned -- didn't pan out thanks to a design limitation or three), but a proper solution like this has lots of knowledge requirements about design affordances and deep-level technology workflow interrelationships that, as far as I've seen -- you won't ever find in your standard college grad.

I think Unity (and everyone else by now) really hates me for saying this kind of stuff -- but I can't help it.
It really breaks my heart to know how a single failed design is all it takes to crush a person's hopes and dreams.


I take that very seriously.

 

@awesomedata Honestly, if you want to take up on making a new VS asset, more power to you, I'd be the first one to buy the asset. So far, over the years, I have bought practically all VS solutions ins and out of Unity myself, kept searching for something that would be intuitive, flexible, and decently performant solutions for mid sized games as well as other applications.

 

like what @cpberi above ;post post https://forum.unity.com/threads/visual-scripting-roadmap-update-september-2020.978732/page-5#post-6492897 I too would be standing inline to get your VS solution.

 

@LaurentGibert @theor-unity
I would like to share my humble toughs based on 5 years experience developing visual scripting asset named Logic Forge.
1) Live Editing. Designing logic in visual tool should have work in Play mode. (That's after you hit that Play button on top in Unity IDE ). While Play mode developer can drag and drop any asset AnimationClip, AudioClip, BlendTree,Prefab, Image, MonoBehaviour Script,....and event other logic design asset and nodes will be auto created in graph. Developer can drag and drop also components from inspector(example can drag TransformComponent), or if it put node inside the graph design, component will be shown in Inspector too. Developer can add/remove/reconnect/edit,copy,paste,cut.... and everything done will persist in Edit mode. Developer can even edit Script while in Play mode and changes will after recompile and reload, affect the design.



Graph designed can be transferred between projects (ScriptableObject/Prefab), can work seamlessly with Prefab/Prefab Instance scenario, meaning if change node values in Prefab will affect PrefabInstance,or PrefabInstance can override Prefab.... ,can be part of AssetBundle, can be loaded runtime and when applied to GameObject will implement designed functionality.
2) Designing efficiency. Design logic in graph should be approaching the speed of codding and if we take in calculation recompiling time saved while coding prototype (see step one), then will have even better efficiency.
Opposite to that designing 200 static nodes(Node class with defined inputs and outputs can't be changed)
for every function inside Unity, plus or/and all atomic math operation, conditions,selects and so on, will make app huge, huge memory requirements and huge graphs for simple things.
For example you have Node that do addition of 2 variables, so it has 2 inputs and one output. Then for every type that support addition you have new version of the node, for Vector2,Vector3,int32, int64,... . Now multiply that for +,-,/,...cast,select,switch,....you will end huge number of nodes. But let see how this will affect graph for simple if(a+b/(c-d)>5) then 3 else 1 will be designed. One Add,one Div, one Sub, one Compare and one Select.
Compared to one dynamic node with evaluator. ONE. if you write a+b it will have 2 inputs, if you have a+b/c-d will have 4 inputs automatically on same node. Type of inputs are also dynamic, so you can define input type. If you use some function very often then you can generate node for it and then drag-drop, reuse.
Even more graph minimization, can be done if properties, sub properties are on connections, losing the need of setters and getters, additional nodes.
Ex. Transform Node -> Get Position Node -> Vector3 variable Node VS
Transform Node ---position---> Vector3 Variable node, 3 vs 2 nodes
Multi setter and getter node functionality.
Instead of having Transform Node -->Set position Node, Transform Node Set Rotation node you have same node where you can attach input connection of what you plan to set and get.


3) Group. Developer can create group, traverse hierarchically, export group as separate asset, not just simple boxes, similar to Mecanim Editor.
4) Logging and Debugging. Every node can have extensive log info. Clicking on log info will jump to the node that it generated and you can see values logged on the node. Frame by Frame debugging, But for 21st century, developer can save number of frames and can shift in time back to see what happens visually in the graph nodes and in the scene in playmode.
5) Code generation. Should be fast, generate just changed,... From Code viewer you can jump to any node that generate that line. You can generated not just C# code from the design, but also generate new Node more complex, from simple ones, that can be reuse,drag and drop right away.
6) Release optimization, JIT->ILLCPP and so on depends of target platform.
May the Forge Be with YoU.

 

If you want to make the graph general, can you create an option that allows you to scroll up, down, left and right with two fingers on the trackpad?

Currently, I'm touching and dragging with the trackpad while holding down the Alt key or cmd key, so the operability is very poor.
The same is true for shader and particle graphs.

 

Now that the much desired features for visual code generation with Class and functions support with any good ability to handle data has been killed off by Unity can we please see an open source release of Bolt 2?

Many of us really do not want or care for the direction Unity is taking now here and we'd very much appreciate the help instead of having to build what was going to be Bolt 2 again from scratch.

 

Tried for the last 3 months by going through multiple different channels and kept escalating it. Ultimately, they just gave me a 20% coupon yesterday and essentially said "too bad." :-/

I had written longer complaints here and on Discord but they got eaten so I haven't posted much. Was hoping to have some good news to share but based on them escalating it to the internal teams and them refusing to do anything I doubt anything will happen now.

 

That is HORRIBLY sad and makes me lose complete faith in Unity. Bolt 2 was an incredible tool that was a real game changer and for them to do this is not only heart wrenching, but boggles your mind as to how they can be so short sighted. I was actually using Unity to do more than just develop games and Bolt 2 was a big part of some plans in this regard to build a cross platform ecosystem for a very robust system. I'm floored and now that the previous alpha/beta is essentially dead by extension then I'm moving on from Unity.

 

I don't understand why... after all, the current team working on VS already said that most of the bolt 2 (And DOTS) features are going to be incorporated into the Unity visual script, so there is no point in releasing bolt 2 now since the same will be implemented later...

And even screw 2 would be quite an implementation, as it would take well over 1 year or 2 years to become fully functional

So between having a tool ready in 2 years (like bolt2 or vs dots) I prefer a functional tool now that I know that in the future it will be much more stable, with better performance, with the features of bolt 2 + DOTS and perfectly functional without having to rewrite my codes in a new tool ... (after all, bolt1 and 2 are incompatible with each other, not counting the VS DOTS)

 

One image is 1000 words. So maybe this video will put more lights on Visual Scripting future. This is the way!

 

As someone who has made (and had a couple people play at most) a small pittance of a game once with a game building tool (aka other than programing directly), but has bought multitudes of $100s in assets... I was excited about Bolt 2 generating code and the structure it used, when I found out about. I planned to make my first mobile game with it. This is a non-programmer creator speaking, supposedly the target for this thing.

I want not only a GOOD product, but an EXCELLENT and near maximally performant product to be possible without needing a ton of rewrite later. Bolt 2 seemed to solve that, and it also made a ton of sense structurally to my script kiddy head. I was excited for it.

I have read through this OP and the previous, it sounds like the code generation is going away and instead you're making high performant interpreters and code blocks... I can say it will cause confusion when you have two methods for doing the same thing, and when the wealth of unity reference material for c# in the community to leverage is almost useless, where Bolt 2 would have it.

I am highly skeptical now after reading and before was really disappointed it's gone - and I may be, still.

I'm now looking at a different asset that will not have official unity support to generate c# code from visual coding. I am doubtful Bolt 1 , from what I read, can perform up to par for my mobile game I am developing, from what I read.

 

I can't speak for them, and with visual scripting being integrated directly, I think a lot of these complaints will subside, especially with performance being top priority, but I can see why for a couple reason.

To redistribute, which integrated in the editor makes this really unessecary across the board at that point. So in my opinion, any idea of redistribution is totally pointless and no longer needed, just a hidden proxy script or on the fly generation in your case works fine. Before I think it was, as we weren't going to see performance increases without it.

Two, and my whole reason for having been so involved in learning visual scripting creation was to expose visual scripting outside the intended Monobehaviour and Jobs/Entities framework. I want to make more tools, extend more parts of Unity, I like making games but I'm more invigorated creating stuff for making other stuff., Graphs aren't the end. They are the beginning to something new, and a great tool that could be used to get us into the future faster. I'll effectively be ready to release my solution that does this in just weeks, but it's always better if we could just do this already without a third party solution to purchase. Just thinking from a customer's perspective.

Learning. I already know what it produces myself, but to be better when you struggle to learn code, it's helpful. But in the end this is another point I think is irrelevant. Do you want to make stuff, or learn how to make stuff to learn to make stuff. Id rather lose all C# syntax if it meant I can produce from mind to screen faster.

I think if performance is there, the ability to have more extensible options for graph usage, what else to complain about but it's general UI/UX improvements and structure of the projects..

 

I was excited about the way the UI worked, someone who cares a lot more about explaining it than I do made a post that shows how Bolt 2 was friendly to someone with basic code understanding but didn't want to deal with syntax and all that:
https://forum.unity.com/threads/vis...update-august-2020.951675/page-2#post-6205770

Assets like playmaker, you have to learn a whole different way of thinking about accomplishing things, where with Bolt 2 the design flow just made sense with meshing how you want to communicate with the minor coding knowledge you may have. It minimized the distance between the two bases of knowledge.

As a striving producer, as well, in production and leveraging liquid assets (money), I want to be able to hire someone to take over a project later after I've formed my vision and basic franchise. I want to minimize the costs of them picking that up and using it later to make it really performant - that saves on the bottom line.
With regard to the question, having C# code generated meant the bottom line costs go down hiring a typical programmer to leverage their skills with a codebase later on.

That said, if you can promise performance - like I said, I'm skeptical but skepticism is skepticism instead of disappointment.

In the immediate, my concern is the many posts that said Bolt 1 is not performant for mobile -now-, and that is making me look at other solutions.

 

I personally do not care all that much for C# generation. The only reason for that to me was to get the IL2CPP performance. But if Unity VS can deliver performance, especially if some of the newer high level node delivers DOTS performance for that function, then of course I'd rather have that in a heart beat.

Number of people talked about C# generation being useful for education for new developers, but that's assuming VS solution would not be a good choice for optimization and performance side. Basically "If you are a new developer, and wants to make products professionally, then you should learn C# - even though it's more cumbersome and harder, it's cleaner and much more performant," kind assumption. I really hope Unity can change that.

Honestly, if Unity VS can deliver near similar performances, and on some specific occasions, better performances to native c#, I don't see much people wanting to learn C# for Unity at all. And I sincerely hope Unity VS becomes the default ways to make games and apps in a long run. It's very much like all shader networks in Maya's of the world, and now even Unity, are all done in Visual node. No-one really talks about how to write shader code in IDE, unless you are hyper specific engine graphics engineers. Most developers make use of the visual node to create their shaders. Of course that's only possible because Unity makes sure shader graph shaders and materials have great enough performance.
Well, I can dream, right? :]

Anyway, I'm eagerly waiting for the Unity VS. Do we still have no visibility on the rough timeline? I've been downloading 2021.1 alpha, hoping to see the preview version...

 

I honestly don't think this is possible, given that there's still code generation going on under the hood.

Also on a more personal note, I do believe "it's cleaner" to be a very valid reason to use code over visual scripting solutions. Most node graph systems are often cumbersome in a very different way than code can be, needing huge networks of nodes to represent logic that could be stated in a few code statements. Keep in mind that when you work in teams, your logic needs to be easily readable to everyone else, and I've yet to see an example of a visual scripting project that I can open and easily read what's going on.

 

I go into that a great deal here:

https://forum.unity.com/threads/vis...ate-september-2020.978732/page-5#post-6487921

But, in short -- I consider the "interpreted" approach one of three possible ways of a scripting scenario can have an Achilles heel. While performance can be "better" with DOTS -- I can't imagine it's possible to be as "close to the metal" as DOTS can be -- when it is inherently an interpreted language.

But I'd really like to be wrong.

Sadly, "code is cleaner" is evidence of an inherent flaw in people's idea of what a "Visual Script" is -- and can be.

Unity seems to think that simply moving around nodes (visually) is what makes visual scripting a "solution" to non-coders -- at least, that's what the acquisition of the Bolt solution (and the direction of drop 8 and onward with DOTS VS-to-Bolt1) said to me.

But that "snippets" thing tells me they're heading down the wrong path on at least one major element.

For example, I work in Houdini a lot, so I know exactly how scary-complex node graphs can become -- despite them being seemingly "simple" step-by-step modeling operations. Houdini has this "code is 'cleaner' " thing too where you can use "code" snippets inside special "code" nodes (which sounds like what Unity is going for -- and just like when I was first learning Houdini, this concept makes me shudder with terror all over again because, again, our graphs are no longer "visual" -- just complex nightmare spaghetti monsters obfuscated to hell and back with hidden code operations).

Code is definitely cleaner in this case.


But even without code "snippets" -- you quickly end up with graphs like these:



Code is "cleaner" only because it takes up less visual space, has less visual spaghetti, and has a seemingly 'clear' start/end to systems and operations -- at least, in theory -- but it is very different in practice -- especially when you're dealing with someone else's code -- which happens in game productions all the time.


Forgive the length of this, but like I describe in the link below (and throughout that thread), code too (especially C# style OOP) has its own insurmountable structural problems as a language -- in particular the problem with how functions/methods obfuscate your code (and its intentions) so thoroughly -- just by its natural structure.

The problem with C# is that the "language" is not structured to communicate with humans.


Functions / Methods have always been seen to "abstract" away explicit code (and make things more readable and understandable) -- in practice, this isn't the case most of the time.
While you need some way to "hide" explicit functionality (like the massive amount of samey / repetitive operations it takes to obtain input and apply that to other data with speed/deltatime), most functionality doesn't _need_ to be hidden -- it simply needs a better context / scope.

Enter the (metaphorical) "magic line" here:

https://forum.unity.com/threads/dat...-structure-of-a-language.819939/#post-5498875



This ugly green "line" is not meant to be a UX element in and of itself -- it is a metaphor mainly intended to illustrate a basic visual principle for visualizing language structure: the pacing and delineation of concepts into their proper scope.


Bolt 1 and UE4 Blueprints requires "traditional" scope pacing/delineation to make sense as a language -- i.e. Subjects (importing and preparing of data to be operated on), Verbs (the actual transformation and output of the operations on the imported data), and Main Ideas (import and usage of verb output to determine operational context).

If you have a keen eye, you might have noticed from my description that similar data needs to be imported TWICE in order to determine the true result from before the operation (verb) and then plugged back into the operational context (main idea) at the end.
This requires (at least!) two separate reads to memory.
On top of the potential performance hit for each and every operation, that pile of subject data that needs to be imported and formatted so it can be passed along to the "verb" operation is also still not very clear / easy to decipher -- despite the overall script looking a little bit better with the introduction of the "magic line" as a visual concept.
But this is where the "magic line" as a visual metaphor breaks down.
The only thing that can save this kind of spaghetti nightmare code is breaking down the "scope" and "pacing" to be a bit more granular. To give a hint -- "scope" is actually divided into self-contained (modular) systems of concise subjects and behaviors (think ECS concepts), and "pacing" is the particular approach used to string data across these systems, subjects, and behaviors.

This is where the structure of the graph itself gets involved.

Speaking of which -- I plan to share my work on the specifics of this pretty soon. You'll see a graph that is capable of being easy to understand (at a glance) with the proper pacing/scope/delineation necessary to make this possible.
I am trying to find a way to make this happen in my own (very small) bit of spare time, because, like you -- I want a very performant solution (that's as "close to the metal" as one's software can be) that anyone, even non-coders, can work with.
You'll be in for a pleasant surprise soon though -- Stay tuned.

 

Jumping on the train, haven't read the whole thread. Just a though, it would be huge if Bolt supports C# event.
I use them a lot and right now there is no way to listen or trigger a C# event. Also it doesn't seems to support UnityEvent, unless doing some kind of awkward workaround.

I would like to start using Bolt for future games and prototypes at work. It look promising, but it miss some fundamentals features right now ... On top of my head is C# events as I said and the ability to distribute new behaviour with Adressables without having to rebuild and resubmit the game.

 

Oh we could go into a huge tangent about how computers themselves aren't built to communicate with humans, and how modern programming languages are the best we could come up with as of yet (unless you somehow like assembly), but as someone quite comfortable working with with raw code and this "'traditional' scope pacing/delineation" you describe, I am curious about this proposal of yours. How well would this structure of yours lend itself to debugging? Because I'm struggling to think of a solution that lets you see exactly what instructions are being executed one step at a time that flows any more naturally than literal lines of instructions.

 

That explanation was excellent and makes a lot of sense.

And I say more, it goes far beyond a simple logic problem. It is a structural problem not only of OOP, but of C #, so the DESIGN behind a visual programming language should not be dependent on a programming language.

And in VS, spaghetti is not the biggest problem, but the structure as the graphic should work. I read his topic several times, and it reminded me of my programming classes where there are commands and attributes ...

so I want to make a post explaining from my point of view this, because it is very interesting

 

Thanks! -- I'm not about "fluff" either. So I'll get to the point:

That's a great question -- and the answer is: "It would lend itself extremely well (probably even better) to the idea of debugging (by humans) because it would happen at the rate of human-based logic, readability, reasoning, and understanding -- not at the rate of understanding endless lines of meaningless instructions without any real (global or local) context or meaning toward the (usually more ambiguous) concepts involved."
The assumption modern computer science has made is that dumb, localized, "step-by-step" logic is somehow superior to "global simultaneous access to containerized logic and reasoning" -- yet any supercomputer (with its thousands of CPUs) will tell you that is simply not true. In fact -- "global simultaneous access to containerized logic and reasoning" is exactly what the human brain is capable of -- and where computers currently fail us.
However, if we give the brain even a little (visual) assistance to more smoothly access the (containerized) "scope" of operations, making the effort faster and more frictionless, you would be amazed at how fast the brain is capable of working out problems -- and the enormity of the data in which it can access (and process) on its own simultaneously to help it do that -- letting one debug any issue, at any moment in time -- with next to zero effort.

In fact, a great metaphor for understanding the difference in debugging stuff my way (versus the method of the status-quo) is how "easy" is it to understand the matrix transformations of a 3d object that was moved, rotated, and scaled -- but through calculations on paper -- versus actually using a 3d application like Blender and visually performing that operation with a widget to move, rotate, and scale an object. Clearly, you don't always need to know (step by step) what specific instruction causes the 3d object to move, rotate, and be scaled -- but you can clearly see when it was (properly) moved, rotated, or scaled -- and when it wasn't.
Who needs (step-by-step) syntax to understand a problem when pure logic and reasoning will suffice? Having a tool that is structured around an idea of the human having global simultaneous access to the whole project's logic and reasoning (and behavior) isn't only 'good enough' (and ultimately is what fixes the most bugs already) -- but it is oftentimes many times faster too -- especially when combating the heavily-contrived organizational structures based around complex (and error-prone) syntax and styling details.


------

To push this point further -- In general -- it is syntax-heavy language, along with many layers of abstraction (and therefore, obfuscation) that often leads to the majority of bugs in the first place. This is a failure of communication with the human brain -- not a problem with the step-by-step (logical) operation of the computer.
As you should now be able to see -- modern-day debugging is "brute-forcing" technology to help it solve the wrong problems.
To make the logical intent and pacing (and therefore the proper delineation of each element) of a game project frictionless and understandable to the mind is my ultimate goal -- and I assure you, it is a valid (and effective) goal to have, even when it comes down to debugging, since you are no longer debugging the computer -- you are debugging the logic itself.


To go further on illustrating this argument, if you're interested:

Spoiler

Continuing from my example above -- When your 3d object is suddenly stretched out, partially upside-down, and not at all wherever you intended it to be after operating the widget, it's pretty clear the widget's 3d matrix transform operation has failed. Rather than needing to see the exact computer instruction that failed to compute the proper transform operation in the proper way in the proper order, one can still (intuitively) gather with what they've seen so far that matrix mathematics has failed them somewhere (as long as they know how matrix transformations should work mathematically of course -- and what it might look like when they aren't done properly). At this point, the computer's computation process is not the problem anyway. The computer is 1000x more capable at math calculations than most users. The user's own (step-by-step) process of telling the computer exactly _what_ to calculate -- and when to do so is what has failed. 80% of debugging is user-error (i.e. not understanding the exact step-by-step logic that is being fed to the computer), and the other 20% has to do purely with confusion arising from syntax-heavy instructions and/or layers of (sometimes conflicting) behavioral abstraction in the design.
In the matrix example above, the only recourse for the user to "debug" their work is to go back and double-check their logic (step by step) until they find the unintended flaw in the flow of their matrix transformation's operational logic. This can be an immense task in many syntax-heavy projects with lots of abstraction (to keep things 'readable'). On the other hand, if there is next to zero abstraction -- they don't need to look _everywhere_ in their project to find the 'bug' in their logic "flow" -- they just need to look _exactly_ in the place where the mathematics were (logically) necessary to affect that particular 3d object in that particular way. Which is _always_ where the operation actually performs transformations on the data in question to begin with -- at least that's where it _should_ be done -- IF it were located in the proper scope to begin with.
That's the trick to debugging though -- scope is exactly where one should be looking, and the literal, step-by-step, logic of your operations is exactly what you should be looking at. Always.


Debugging is simple when you have direct control over (and frictionless access to) the global context and reasoning (that is, the scope of the data) for the step-by-step (logical) operations on all of your data across your project. This, sadly, is not what typical programming languages offer. To visually gather (or make sense of) logical operations quickly is critical to debugging quickly. Therefore, any scripting structure that visually (and smoothly) defines proper (logical) scope in a way that champions the visual flow of logical operations on the data and funnels that data into a sensible (reasonable) scope (and therefore proper logical operational context for behavior within that scope) has a huge advantage, whether said scope is local or global (or some logical / bridged combination of the two, but with a sensible and clear UI to make this "bridge" visually-intuitive), and has the kind of structure capable of being extremely fast and easy to follow (and therefore simple to quickly and globally decipher specific step-by-step logical operational flow and behavior with the brain alone). The brain is often assisted by timely and properly-designed visual cues and delineation acting as an aid to make the process for global intuitive understanding even more frictionless -- especially to someone that hasn't yet built a mental model of the project in question (and its logical structure) -- which helps newbies quickly decipher and debug portions of the project that they have only simply glanced at -- (and therefore easily understood) -- which should be the goal in all Visual Scripting endeavors, imo.

It's hard to explain something like this -- so please forgive my verbosity. Hopefully what I've offered so far makes sense well enough though.

 

Is DOTS VS included in the bolt asset from asset store??

 

When was the last comment from Unity ?

 

That was the last post from Unity. Oh, you mean about Bolt / Unity VS?

They haven't really said much else. I know personally I've tried to get a refund but Unity refused and Lazlo / Ludiq is not responding to emails or messages from me or Unity themselves. /shrugs

 

Stay on topic, no personal attacks. Cleaned up off-topic derail.

 

I think it's time for you to let this go. I can't count how many assets have been depreciated before I've even used them, or assets I've gotten just to inspire me to do something. Try to think of assets like this:

1. Will I be inspired by it?
2. Will I learn from it?
3. Will I be successful from it?

The first can be satisfied by just owning it, if that alone fuels your personal creativity then it was worth it (at least a little).
The second can be satisfied by using it, but not necessarily getting much practical use out of it. This would be worth buying in a more major sense.
The third is highly unlikely, but should you find yourself successful from buying any asset, it would be worth many times what you paid for it, and therefore can be considered a profitable investment.

I'm guessing you were at *least* inspired by purchasing Bolt initially?

 

See

It isn't about the money. It is about the principle of the thing. Deprecated assets are a problem too, but at least we have access to them. I have no access to Bolt 2, which is what I was requesting from Unity. Whatever was left before the sale -- same as any deprecated asset.

 

Well, I can't help you I'm afraid.

 

@LaurentGibert

When do you think we will get the next update on the roadmap. It's been a while.
Any update would be appreciated.

 

We have a weekly update through the bolt discord, this week a post was posted about version 1.5 of the Unity Visual Script (available in 2021.1_B1)

I have transcribed the changes below:

### Release Notes for 1.5:

- Added Visual Scripting as built-in package as of Unity 2021.1
- Added New Input System Support. You can import the Input System package, activate the back-end and regenerate units to use.
- Added AOT Pre-Compile to automatically run when building AOT platforms
- Improved UI for deprecated built-in nodes
- Added automatic unit generation the first time the graph window is opened

### Changed

- Switched to delivering source instead of pre-built .NET 3/4 assemblies
- Updated Documentation
- Renamed assemblies to match Unity.VisualScripting naming scheme (Ex: Bolt.Core -> Unity.VisualScripting.Core)
- Merged Ludiq.Core and Ludiq.Graphs into Unity.VisualScripting.Core
- Moved Setup Wizard contents from pop-up on Editor startup to Player Settings. You can change the default settings from "Player Settings > Visual Scripting"
- Renamed "Assembly Options" to "Node Library"
- Renamed "Flow Graph" to "Script Graph"
- Renamed "Flow Machine" to "Script Machine"
- Renamed "Macro" graphs to "Graph" in machine source configuration and "GraphAsset" in Assets
- Renamed "Control Input/Output" to "Trigger Input/Output"
- Renamed "Value Input/Output" to "Data Input/Output"
- Updated built-in nodes. The Fuzzy Finder still accepts earlier version names of nodes.
- Renamed "Branch" node to "If"
- Renamed "Self" node to "This"
- Deprecated the previous Add unit. The Sum unit has been renamed to Add.
- Updated Window Naming - Changed "Variables" window to "Blackboard"
- Changed "Graph" window to "Script Graph" and "State Graph"
- Updated Bolt Preferences
- Renamed Bolt Preferences to "Visual Scripting"
- Removed BoltEx
- Moved settings previously accessed from "Window > Bolt" to preferences
- Renamed Control Schemes from "Unity/Unreal" to "Default/Alternate" (Neither control scheme currently matches their respective editors' controls and will be updated in a future release)
- Consolidated Graph editor, Blackboard and Graph Inspector into a single window
- Updated Third-Party Notices

### Fixed

- Corrected UGUI event management to trickle down correctly when the hierarchy contains a Unity Message Listener [BOLT-2](https://issuetracker.unity3d.com/is...roper-trickling-of-ugui-events-in-hierarchies)
- Fixed backup failures with large projects [BOLT-10](https://issuetracker.unity3d.com/issues/bolt-1-backup-fails-to-complete)
- Fixed "Null Reference" when opening the Graph Window for the first time [BOLT-996](https://issuetracker.unity3d.com/is...-when-graph-window-is-opened-on-a-new-project)
- Fixed IL2CPP build crash on startup [BOLT-1036](https://issuetracker.unity3d.com/is...n-there-is-at-least-1-node-present-in-a-graph)
- Fixed IL2CPP issue around converting certain managed types [BOLT-8](https://issuetracker.unity3d.com/is...ed-type-which-it-cannot-convert-ahead-of-time)
- Fixed deserialization issues when undoing graphs with Wait nodes [BOLT-679](https://issuetracker.unity3d.com/is...-coroutine-with-wait-node-is-present-in-graph)
- Fixed "SelectOnEnum" node behavior enums containing non-unique values e.g. "RuntimePlatform" [BOLT-688](https://issuetracker.unity3d.com/issues/select-on-enum-doesnt-work-with-the-runtimeplatform-enum)

 

Since bolt 2 is not releasing, so snippet based code generation is coming to bolt 1 so does that mean complete redesign of bolt and how will the DOTS VS will be integrated in it and will it it generate ECS code as well?! And when will the snippet based code generation for bolt 1 and DOTS VS will be out?!?

 

Do we have any progress on opensourcing the visual scripting system?

 

Thank you very much. I wish it would also stay on github so we could fork them too

 

I would like to mention that AOT 'looking into plugins' is taking a lot of time when building the project: around 7 mins before actually going ahead with the build.

I am testing the latest beta version of Unity ( 2021.1.0b6 ), with visual scripting only used for the tutorial module, in not such a large project but with quite a few asset pack ending up with many sprites and other files in the Assets folder.

 

Is it one VS graph for the whole game just intuitive or just trap for a greenhorn? Are you code the whole game in one script? Is it Unity build of one GameObject and all components, scripts, and the rest, all there? If NOT, and you know is bad practice, then why you are pushing such a concept as standard. You don't want good future game developers, but smooth entry "involvers" that will build the revenue.

 

Not sure what you're on about - you can have as many graphs as you want (although multiple flow machines on the same gameobject are annoying to manage). But you can also infinitely nest graphs inside other graphs via superunits.

 

So you say managing multiply Monos on GameObject is annoying??? Do you think that Transform, Renderer, Animator should be only one component not to be annoying? If we think of later as code substituted of visual-scripting?
ScriptableObject can't have other ScriptableObject that can have other Scriptable object. I couldn't find that term in Unity "superunits". Is it superunit a Prefab or I need to compile something, seems very complex to be Unity workflow. It is also weird why Unity employes like only post they support their work, not the constructive critics. Probably that is inside the contracts they sign.

 

I'm saying managing multiple Bolt Flow Machine components on the same GameObject is annoying mostly due to Live Editing defaulting to the highest graph (or was it last opened graph, I don't recall) so you have to manually find the instance of the GameObject, then open the right graph from Inspector.

C# components don't have Live Editing so it's not a problem there. And a GameObject can have N amount of Flow Machine components with N amounts of graphs. Bolt does not enforce some kind of monolithic graph structure, it's up to you how you structure your graphs.

Also, visual scripting is not a substitute for C# but you can follow the aforementioned Transform, Renderer, Animator structure pretty closely with Bolt.

And I'm not sure what Scriptable Objects have to do with Bolt graphs besides the fact that graphs can be asset based. Perhaps read the Bolt manual first. You don't seem to be informed on how the tool works. https://docs.unity3d.com/bolt/1.4/manual/bolt-super-units.html It's not complex and you don't have to compile anything.

The superunit comment was meant to address the Live Editing issue by having only one Flow Machine component on a GameObject that nests other asset based graphs ie Transform, Renderer, Animator for easier access and fewer UI/UX issues. Performance wise there won't be any noticeable impact and each graph is still individually editable if they're macro graphs rather than embedded graphs.

 

I thought a graph containing logic for Player is on Player, on Enemy other separate graph.
Cause I'm seeing people using one game object, put one graph(multiply inside) and put all the game logic there. or For Player,for Enemy, for UI for all, seem like over used GameManager concept.
Yeah, may your native is Franch, but you understand English as Candian and second only when comments are in line with Unity

 

I try understand the super units concept of reusable graphs. But then why I can't drag one graph into another and be reusable simple as that. No super anything. Any graph can be reused. I read the help and find not intuitive to worry of all this
Here are some very important constraints to keep in mind while defining inputs and outputs:

• The key cannot be null or empty.
• The key of each port must be unique across the entire graph. You cannot have an input and an output with the same key, even if they are of a different kind or type.
• If you change a key, all connections to that port will be removed. Bolt uses keys to identify ports, so if you change them, the connections become obsolete. If you want to change the name of a port without losing all the connections, you can override it with the Label property, which is purely cosmetic and has no impact on functionality.
• Each value input and output must have a type.

Also what is that macro graphs, embedded graphs.... why not just graphs, ... too complex. sorry

 

Who are these people and where can I view their graphs? All tutorials I've seen generally approach solving issues with multiple graphs. Or if they stick to a single graph, they do that to better communicate the idea of the tutorial without extra complexities.

Yes, you can build monolithic graphs same as you can write monolithic C# scripts, but this is not some kind of Bolt design issue. Bolt is not its own language, Bolt is a C# visualizer. Meaning for every public Unity property and method there's a node for it. And you can also generate nodes with Unit Options Wizard for 3rd party and your own script variables, properties and methods.

In short, you build Bolt graphs in nearly the same way you'd write a C# script on a base level.

The constraints you mention also exist in C# methods, which require unique input parameter names and assigned types, same for return values. Changing the types of these or removing them will break C# code as well.

And Bolt superunit input/output type can be of type Unity object which means it'll accept any Unity object.

Macro/Embedded concept is simple and documented, each has its own strengths and weaknesses. Ie Macro is asset based and reusable but can't directly reference scene objects in the graph, embedded lives on a GameObject and can reference scene objects directly in the graph but can't be reused.

 

This has been in the pipeline for a long time but has never really been explained.
I am really interested in what is meant by "snippet-based" code gen. I'm mainly curious what this means in terms of context-specification.



Speaking of specifying context --
I am in need of a visual graph-based solution that offers a better way to control said context for one (or all) gameobjects alike (at the flick of a switch) -- but pick-off the instances/entities I want (or don't want) BEFORE the query is ever executed. Rather than a for loop, I want to always apply data changes to one or all instances -- all at once. The standard "super-unit" setup isn't terrible, but it pigeon-holes me into having to always specify WHICH gameobject I want to apply changes to rather than just letting me say I want this specific one -- or all of these no matter what. That latter bit is what is so great about databases (and Queries).
Why not double-down on this? A game is just a database with a fancy interface.




Ideally, I would like to sort of "nest" these as an "automatic for loop" -- sort of like what you'd do with ECS.

That way, the Monobehaviour architecture and the DOTS architecture could begin to line up a little better (and require fewer changes in the future).


To clarify -- Let's say I make a spaceship (and an enemy) type...
If I want to change the model (or specific behaviors) for P1 and P2 to completely different things but keep everything else the same (such as P3 to PN), I would be forced to use Prefabs / Monobehaviours (and the _current_ Unity architecture -- which, by its very definition, is incompatible with DOTS and ECS methodologies -- alongside lots of code -- just to 'transition' my logic between the various architectures). This is unnecessary -- and painful.

The bigger problem is -- this would mean breaking my Visual Scripts up too.



This leads to a more fundamental problem of most visual tooling:

I need my actions (i.e. script behavior) and my scope definition (i.e. logic / context / tools) ALL IN THE SAME PLACE.

This is THE major problem with the Unity Editor.
This is also THE key to designers being able to use a Visual Scripting solution comfortably and effectively.


Getting back to the spaceship example:

Breaking up the Visual Scripts is not an option due to complexities in scalability.
I want this to be an MMORPGMOSTAWESOMESPACESHIPGAEM after all.

To have to go back and forth between the Prefab, the Gameobject, and the various Visual Scripts just to change how a thing acts for ALL objects (save a few particular ones -- or vice-versa, for just one, when using the DOTS / ECS architecture), when I originally decided I wanted the behavior to happen for ONE object (but later changed my mind to two of them, since I didn't really need that level of complexity in the single object after all, like I originally thought I did, so I needed a quick way to allow me to easily pick the one or two I wanted out of ALL entities/gameobjects by simply tagging these with a special model tweak 'Tag' used during the 'automatic for loop' (i.e. the Query) to apply the new model settings to nothing except these specially 'Tagged' ships.)
Now, with my dataless 'Tag' to define the scope of the object I need to isolate, I can simply ignore anything that doesn't have that 'Tag' in the rest of the logic and only change the models of those things that have a 'Tag' in a _separate_ piece of logic in the Visual Script (or in another Visual Script, linked to this one by way of an index in a database consisting of a list of bits / bytes for lookup, if desired) -- rather than "if-then if-then if-then" to hell and back during the for loop.

The standard 'for loop' pattern is a common occurrence in code -- if not THE most common -- but it slows down everything. More importantly -- it is what bars the way to modular coding practices.
Visual Scripting is able to be more helpful than text-based code in this area.
To be more performant though, you want your code to make changes to as much data as possible in one go -- all at once -- wherever possible. In order to do this, you should be able to assume your code applies (by default) to all items at once (like ECS/DOTS proposes) -- and then change that behavior only when you have special circumstances (such as a level-specific object or action). This seems to be the best route to go at all times.

BUT -- This 'all at once' ECS / DOTS structure also has a problem:

This method means, structurally, that if I want to write a special gameobject behavior or three, I have to occasionally rewrite whole systems, often including whole data-exchange networks (as well as rewriting their respective data-exchange mechanisms). This rewriting should be as instant as possible in any Visual Scripting system -- yet this is extremely rare.
The problem with ECS/DOTS as a full-on architecture is that I am expected to be able to assume the end structural design for all of the objects I need in a highly level-specific area of my game should be already specified and determined at the start of the design of the level / area -- BEFORE I program anything that happens to these objects in that specific level / area. This is often not possible.
Many people often don't know the exact/explicit structural design circumstances of their objects BEFORE they want to test them in the game or level architecture -- However, they need the objects to exist (in place) in some (primitive) form to help this be more fully determined -- especially when still iterating on a design.

While 'officially', this should be done in the prototyping phase, sometimes the level design still needs tweaking and tinkering afterwards -- and sometimes even a full rewrite of base game and respective data-exchange systems and mechanisms. When using ECS / DOTS as my base architecture, my (often efficient) ECS / DOTS architecture becomes just as rigorously volatile for me as a designer to scale and maintain as the "single-gameobject" approach that Monobehavior employs (i.e. think Undertale, where every event is unique and very little gameplay / very few scenarios are ever repeated).
Generally, my highly-specific "single-object" based approach doesn't scale well with an 'automatic for loop' approach, like ECS / DOTS tends to advocate whenever it needs slight changes in behavior for a special case or two. Or an ENTIRE GAME.
Trying to define scope without a dataless 'Tag' approach makes this task a nightmare for game logic.

The dataless 'Tag' solution doesn't work well (alone) when dealing with lots of multi-dimensional array data (i.e. verts, vector3s, dictionaries, etc.) -- but this is by design. The 'Tag' is 'dataless' after all. However, to make this system work the way it is intended, you can simply 'Tag' an entity/gameobject as a 'DataType' -- and use it as an array/vector3/dictionary -- or whatever. That means any 'Float' can be processed the way the user wants it (i.e. as a 'Double', for open worlds). This can be done behind the scenes (i.e. for common datatypes ) -- but for floats, vector3s, and even Classes, an 'entity' or 'gameobject' with a corresponding VisualScript (System) that processes it works very well for this type of processing. Treating a gameobject like a datatype / class is what we ALREADY DO. So the workflow itself really isn't going to change for that part. The only thing that would change is how it is handled in scripts (and, eventually, behind the scenes).

Data is just data.



The "all or nothing" approach we are currently taking to Visual Scripting scope and basing it around architecture (i.e. ECS/DOTS vs Monobehavior) is hard to stomach -- whatever the architecture is being used behind the scenes -- because we need both. And we need full control over when, where, and what architecture is being deployed -- without even having to be conscious of it.


This is a DESIGN issue at its core -- and one that needs to be solved at the core of the logic BEHIND the scripting workflow.

I'm hoping this design issue is solved with the architecture behind those "code snippets" somehow and that my ramblings here are much ado about nothing.
If not, please feel free to PM me and I'll offer some further (visual) thinking on how this might be done. However, without any info on your current plans -- it is difficult to offer in any concrete way forward otherwise.
That said -- I hope I've helped solidify some things.

I don't want to bloat up the thread any further. D: