DOTS Visual Scripting 6th experimental drop

I’m not a fan of visual scripting as such mainly because I’ve seen what a mess you can make with blueprints but damn as a learning tool on how to code for dots this is awesome, well done!

 

It kept giving me the error even after removing the DOTS Editor package, I just can't figure out what other package(s) might be causing this so I went for your solution to move the package local to the project and edit it accordingly to @Guedez .
Works like a charm PLUS i can use the DOTS Editor package, just a bit more work when the VS package updates.

 

not working?

 

Hey awesome stuff. When is new drop scheduled, because I want to try it out, but if its only a few days I might wait. I know it's every six weeks. So should be very early February right?

 

I see Visual Scripting as being the thing the majority of Unity's users use, me included. Really I should only be doing actual code that can't reliably be expressed with nodes or is too much for nodes - pretty much same as Unity's shadergraph. So I'm really happy about the latest drop.

I do have some issues with it but these the staff have said are just basically going to be fixed with sugar nodes later, quality of life stuff.

 

wood be nice if we can see some node docs. cant understand most nodes.

 

Get Property, as seen in following graph, seems to produce duplicated code per component that is output from it
it seems very inecfficient and hard to read, is that by design?
I'd expect each already computed struct result (float2, float3, ...) that is being split by Get Property node to be stored into temporary variable and reused instead of computed from scratch per component. As computing it from scratch just keeps duplicating code exponentially with every nested use of the Get Property

generated code, containing duplicate math

expected code could look something like this (untested, may contain mistakes):

 

When using roslyn package (com.unity.code-analysis) and Memory Profiler, it throws ReflectionTypeLoadException at every script recompilation. Of course, Visual Scripting packages too (because it depend on roslyn).

Reported as Case 1214728.
https://forum.unity.com/threads/cas...es-throws-reflectiontypeloadexception.816714/

 

Thanks, that gave me a bit of a kick up the backside to give this a fair crack of the whip so I'm trying to dedicate a few hours a week to exploring this. It seems like a great way to get in to DOTS.

Also thanks to @CodeMonkeyYT & @wilson_p for the great tutorials.

So far one thing I'm not sure about is the way in which you get & set properties. At first it seemed great, drag the component on then add a get property node etc, but it takes up a lot of screen space for a single action.
Would combining the get/set propery node with the component be an option?
You could drag on the GetProperty node then drag the component on top and choose the property you wanted to get.

EDIT: Meh. Scrap that thought. I have a small screen and I was just looking for ways to reduce the node count but you could say the same for multiply & add nodes and then you probably end up with something less readable.

 

I am curious about this lack of code reuse as well...
I hope it's just lack of polish, but I've been burned making that assumption before... So how about this:


@Joachim_Ante , @ans_unity , or @jeanedouard_unity:

Why not (during code generation) traverse the nodes backwards to look for cases like these and optimize them? In addition to this, cache the results of the generation, to be used as a single pre-generated block. This cached block would be used until some part of the cached node hierarchy changes or is broken by changes to one of the precached nodes, that way the node (or the code generation) isn't always having to run through these optimizations each time the graph is added to (only when the existing hierarchy or nodes are changed). The full optimization loop would only occur once, after a code generation command is issued by the user. Finally, a partial optimization loop would be performed for non-cached nodes (or any optimization-relevant nodes in the hierarchy) for a faster code-execution.

"Performance by default", remember?

 

i am getting this error,how to fix it?

 

I was getting ready to test this drop. I noticed you are using "2019.3.0f6" did the issue also occur in "2019.3.0f3"? Curious what work arounds have been found as others seem to be able to play with it. Have you been able to work around the issue by using a different preview version of Memory Profiler / Code Anal...often in these preview packs I try dropping back one by one and many times it all syncs up and I can hit play even when using an older preview than what is listed.

Anyone else run into this or find a work around? I was going to test on Windows 10...also I have seen in the past even though the req./recommends says "2019.3.0f3" at start of this thread for this drop...that part isn't a hard lock all the time and can be manually rolled back to previous versions till everything is groovy gravy.

 

@CommunityUS I tested it in 2019.2.17, 2019.3.0f5 and it throws exception too. (Code Analysis packages can be available in 2019.2) So I think that this is a package issue, not Unity editor. I received response from Unity that it is successfully reproduced.

 

Thanks for the reply. Curious - do we have a git repo for Memory Profiler / Code Analysis yet?

RE: above
ok, that saves me a download. I wonder if when they did the drop they were working from a earlier CodeAnalysis commit. And the "preview branch" for those has moved on, without a preview version bump. (Or are there earlier previews to try if it is a package issue? like a preview.1 if they are using preview.2)

*forgive the lack of not knowing exact packages I am trying to figure out a good place to start. Did you try "2019.3.0f3" though? I see you tried 2019.2 but see below for my partial understanding on all this preview goodness.

I get what you are sayin about "it isn't an editor thing." But the packages can be somewhat smart. And you may be getting a bug that was fixed exactly for the "2019.3.0f3" package or didn't show up in the commits with everyone working off different branches.

Example from SRP - what I have seen and worked around in previews:
Like in SRP HD pipeline, they are working on SpeedTree...I am following it closely.
https://github.com/Unity-Technologi...render-pipelines.high-definition/package.json
In the JSON the "smart" package manager part is...
```
"version": "7.2.0",
"unity": "2019.3",
"unityRelease": "0b4",
```
- so in the case above if those packages are "unityRelease":"0f3" but the commits kept going without a new branch/package version number, perhaps it is possible to download the same package version name but get two different results based on the editor.
Above was only as a example, I know we are talking codeAnalysis. But I don't know if we have those repos on GitHub yet or internal some place we can grab at the commit level. My guess from above is that we may yet be able to get it at the commit level if the "unityRelease" acts as a sort of "tag" for us.
The package manager sometimes can be a tad slop in these preview releases. Where maybe it says downloading the right preview package, but if the "unityRelease" (here the editor you are using matches) you may get the commit is higher than you wanted.

Any thoughts on this wall of text lol.

 

Edit TracingRcordingSystem throws error from the line var frame = Time.framecount. Uninstalled to continue beating my head against the wall until morale improves.
------------
Edit..missed the comma..seems to be doing it's thing properly now.
--------
Did this. Ended up with a console full of errors. Things like UnityEngine.UI and other core packages were said to not be found. Took that line out and it reimported everything.

 

is it possible to create custom nodes using C# at this point? If so how would you go about that? I hit some roadblocks during testing by not being able to find some math nodes so I want to just fill the gaps until they get officially added

 

how to fix this error ?
Unity 2019.3.0f6

 

Hi!

I am totally new to this visual scripting stuff, but I mostly want to use it because you can create some lightning fast code with it (dots). ..Writing dots directly seems a little bit too complicated for me, so my hope is that this visual scripting is developing fast.
I want to use the normal unity workflow but mix it with visual scripting (dots) for faster calculations (enemy behavior, background calculation, path finding ..)
Anyway.. I have noticed a fundamental problem:
I downloaded and installed the visual scripting preview 0.2.3 (latest) and tried to make a test build for android (using unity version 2019.3.0f6).. but I got this error (the scene is totally empty, only the main camera is in it, no scripts attached):

Library/PackageCache/com.unity.visualscripting.entities@0.2.3-preview/Runtime/TracingRecorderSystem.cs(9,7): error CS0246: The type or namespace name 'UnityEditorInternal' could not be found (are you missing a using directive or an assembly reference?)

Seems it tries to build part of the code that is for editor use only.

How can this be solved?

Thanks!

 

its alpha stage. ofc there will be errors inside. this package not ment to be used in projects, but use it in personal education/overwiev.
im sure they know about errors and problems better that you and me. so just relax and wait when this feature came to version 0.9 atleast =)

 

Hey thanks for making this, I finally figured out how to get it to work after many hours of struggle with lots of different things mostly a trial version watermark bug in 2020, Among other things mostly because I used an old project from a new version to test it i think, but yea anyway.. Once I finally read the main post properly I realized what to do and Also that it says "NOT For Production use" lol I was just wondering if that's ever going to change at all?

And is it ok to still make free games without an abn/Registered Business or Full Unity Licence? as promotion etc?? I'm not sure if the Licencing link in the package manager is leading to a licence you actually agree with, could you possibly provide more info? Is it going to be paid content?

I have to say I got very excited after seeing code monkeys video, I'm about to have a look at it now finally lol.. But yea i really like the way its been laid out and the way it functions.. its just what i've been looking for since I started trying to use unity/code even lol.. I have no "Real" experience.. and well I didn't want to pay for Bolt or uNode and now that I've seen this i totally don't want too lol.. I'am 100 % willing to pay for this at a decent price..

 

Really? But why? I mean, I love shadergraph, but, for example, just the subgraph for plugging in the bumpmap features of the standard shader into an URP shader is like 14 nodes... alternatively a custom node with 3 lines of shader code. So while I understand the idea of node-based systems I really don't see how they would be useful anywhere outside of the most trivial solutions. It feels like yet another layer of abstraction, this time without line numbers and with a massive amount of annoyance involved in writing comments.

 

I can understand the motivation behind it, I guess I'm not seeing the big advantages though. Probably just my personal perspective though

Oh well, as long as there's no plan to deprecate the C# API I'm okay with it

 

Big advantages:

• Immune to employee churn, don't need to learn a sensitive and risky codebase
• Easier to employ & cheaper: don't need rock star engine programmers
• Cheaper to maintain and easier to follow (good designed graphs are clear as day)
• Can make safe changes to a game like in DLC without touching core code
• More people understand the problem and solution at the same time
• No performance disadvantages when used correctly, and it's hard to use incorrectly
• Black boxing safeguards internals
• Share methodologies with animation, physics, effects, dialogues, AI, shaders etc
• Runtime code changes for debugging on the fly

I mean if you can't see them, that should worry you...

 

Perhaps. But I'd still say that visual scripting is not exactly the silver bullet.

• No need to learn a risky code base how? Any custom nodes will still be in the code base, any kind of external system will still be in the code base, just that now you'll need to use a visual scripting environment to bring that code to run.
• agreed, that is an advantage.
  
• cheaper to maintain and easier to follow - perhaps, while they are small and trivial. I've yet to see a node-based way of representing vector algebra that makes more sense than, say, x1 = (x0 + v) * Time.deltaTime; but also making a well designed graph is not as trivial as it would seem.
• I can't see how that's an exclusive advantage of visual scripting. Nor how it's easier to enforce with visual scripting.
• Yeah, that's true. More people will be able to follow along, at least to an extent.
• Agreed
• Agreed, but again I fail to see how black-boxing would be limited to visual scripting.
• Yup, good point.
• This is true, though to be fair, Unity seems really fast in compiling the code, particularly when compared to UE4.

Using the editor is, of course, a good point and a good example of visual setup, but I really don't think I'd call that visual scripting. Of course you can't avoid using it and why would you even want to? But again, for any kind of non-trivial mathematical operations, any kind of non standard setup, you cannot set this up via the editor nor via a node-based solution. At least not in a way that would ever make more sense. Even non-programmers will have less of a hard time reading a few lines of C# code that projects a parabola onto a plane than following edges through nodes. Sure, you can write comments on nodes... but again, not a solution exclusive to visual scripting.

 

Well, there's always a part to play for everyone. Your mindset right now seems to be on a sole developer rather than a team. Engines like UE4 and Snowdrop have programmers who develop custom nodes (if/when needed) for the designers and other programmers who work on the project.

Actually Snowdrop basically only uses nodes and that's for everything. UI (They don't have a standard UI editor, all the positions and such is determined by nodes), AI, and all the designing features for The Division are made with nodes. There's a lot of GDC talks showing this as well (Snowdrop Engine and it's Node-based tools. The one for the AI is something else).

It doesn't seem like you've looked into the successful games that use nodes. There are juggernaut games out there made with nodes like Fortnite, The Division, Rocket League (It might have changed now but the first release was all Blueprints)
It definitely proves capable. With that said it doesn't seem like Unity will just go solely node based for scripting so both will go hand in hand. Don't think you have anything to worry about scripting wise. Visual scripting and other graph-based tools will and have definitely been useful.

 

A team of two actually. And this is part of the problem. Commenting code and discussing it by lines is simple, with shader graph we tend to just do our own graphs because it's just faster. It's true that we both write and read code though.

I'm not saying node-based solutions don't have their place, of course they do. Animation controllers, shaders,... definitely show that there's a place for them. But I can't help but wonder, since with ECS it almost feels as though the engine is being redone from the ground up, what the documentation will look like, say, 2 years from now? How will examples be handled? I'm currently on a 1920x1080 screen, in order to look at the really trivial example up above that just takes input I need 1.5 screen in order to see it. How does that translate into stackoverflow? How does it translate into googling? How does it translate into meetings? And while I can see the advantage of people not needing to know C# in order to connect something up quickly, how do you bring in new people? What skill do they need? Would you say Blueprints is 1:1? Blueprints experience plus 1 week and you're set? 2 weeks?

And of course, I'm not saying there aren't solutions to these problems nor am I saying visual solutions are not needed or useful. Just that like any solution it comes with its own set of problems, that's all I'm saying.

 

See this:

Data-Oriented Visual Scripting -- The Structure of a Language


---

You're actually one part of the audience I was writing this for.
Perhaps it could give some insights.

Visual Scripting isn't new at all -- the Data-Oriented portion, however, IS. -- Semantics really do matter.


Unreal fails with Blueprints in many ways (not for lack of trying though!), but Visual Scripts can actually be (even more!) legible than code. Check it out:

https://forum.unity.com/threads/data-oriented-visual-scripting-the-structure-of-a-language.819939/

 

Those are some very good points, and I do agree.

The data-oriented paradigm, if we want to call it that (I kinda think paradigm is a slightly overly-pretentious word ) is a fairly new concept with a fairly old idea behind it - keeping data contiguous and as small as possible, and broken up into nicely sized and general chunks, in order to minimize cache misses, and, with a bit of luck, organize the data flow into nicely encapsulated readable pipes.

And while I do agree I'm still not too convinced it'd be easier for me to read a graph than code. Of course, having Blueprints to go by doesn't help too much, they are about as awful as the UE4 C++ API and I will admit that Unity's flavour of visual scripting does seem to look nicer.

 

Yea, that's what's happening. DOTS is the future of Unity, all the new tools are being made with it in mind. Monobehaviour will still be around for a long time as they've stated many times but moving forward the new will be DOTS.

I get these concerns for sure. Currently, Blueprints have a lot of third party sites for sharing code and such but that's because of how the engine deals with its file system. In Unity everything is an asset so you can easily share things around.

Visual scripting and Blueprints won't ever translate 1-1 since Blueprints is kind of its own scripting language/system and not even just translating C++ to a node based system. Visual scripting is a Visual representation of C# ECS code and that's why it generates C# code on the fly as well. For blueprints, you have to compile that to C++ when making a build, so they are completely different. The docs situation will be like any other package. Visual scripting will have it's own docs and C# ECS will have its own as well. The good part of this is whether it's the ECS C# docs or Visual Scripting docs both would be able to translate to the other just like shaders (node-based or HLSL). So Visual Scripting in Unity will be just like using nodes to write the code and that's the strength.

In the far future ECS will probably be the only way of scripting but for now and the foreseeable future there will be both ECS and Monobehaviour so everyone will have a chance to transition. People who want to code in ECS have already started using the Visual Scripting tool to learn the concept to then transition to code after so that's another benefit.

 

I can understand the desire to move away from MonoBehaviour and yeah, it's probably for the best. The C# code generation (on the fly or otherwise - though obviously on the fly is better) is definitely better than what Blueprints do in UE4 because with Unity visual scripting system it at least feels like a far more solid foundation - C# is a tried and tested language and at least from what I've seen so far the generated code is really pretty much as readable as something that an IDE would autogenerate for you, so that's definitely a huge plus.

My concern with sharing is more about sharing snippets etc. You know how any decent search engine drops you straight into Unity docs when you look for, say, Physics.Raycast. Then there's intellisense helping you out with function arguments (hitting the down key will let you browse through overloaded functions on the fly). Code examples, even spaghetti-ish, can be read through more easily than browsing through spaghetti Blueprints, I'd say. At least for me.

 

When is the next drop, or is there even another drop before 20.1 ?

 

holywar begans…

would love to hear about official samples.

 

Is it possible to create a custom node where you can add your own code, similar to how you can create custom nodes in shader graph?

 

@ans_unity

I honestly think the gameobject-based workflows aren't that great -- they tend to be too granular.
Nested Prefab-inspired workflows, on the other hand, are really nice. I seriously hope you guys will stick with something that plays to the strength of DOTS and Nested Prefabs "parallel behavior" (eliminating the need for for loops and things of that nature) -- This kind of processing needs to be fully explored before you pander to the OLD gameobjects workflow just because that workflow is "familiar". The fact is -- the old gameobject workflow is definitely not scalable until you start considering it in the context of our awesome Nested Prefabs. Please consider scalability of our scripts above all else before you start working on node semantics.



I'm a big fan of very data-oriented scripting -- i.e. One change makes a sweeping change to all things (minus a very small number of things) that rely on it. This is how most games are best programmed. You guys should integrate the "variant" workflow from Nested Prefabs with DOTS visual-scripting in order to maintain that kind of wide-reaching flexibility and scalability across one's code. That scalability is what we just didn't have with strictly gameobject-based workflows.

Please make variants a central tenet to DOTS Visual Scripts.



Also -- this:

It's worth a read.

PLEASE avoid spaghetti-code like in Unreal -- PLEASE adopt the magical power of the line....
I HATE spaghetti "structured" C# scripts -- And spaghetti Visual Scripts too.

 

That would be awesome if you could make dots visual scripting compatible with the new input system and ui elements. With UI Elements, I'd like to create whole editor windows with visual scripting, instead of having to create a c# script.

I probably won't use Entities a lot in my game. However, jobs can optimize my code dramatically. It would be nice if I could create c# jobs using the new visual scripting tool.

 

didn't saw that unity VS can be spaghetti so far...

but strongly want to see docs for nodes (or atleast short notes)… please, it will be very helpfull

 

@ans_unity:

You guys might be interested in both this post AND this post as well.

I wrote those two articles specifically for any tool programmers -- and specifically about DOTS Visual Scripting design too. Since you guys are doing something that's never been done quite this way before, I genuinely think it is worth a read. ^___^

The form Unity uses (the "layer/processing stack" approach to what I call the "main idea" in that article) is great (amazing, in fact!) for helping Visual Scripts avoid the spaghetti-code dilemma. This format is a perfect start to the most awesome visual scripting solution out there. However, visual-script spaghetti-code is still possible because there is still one very important (critical!) part of the equation missing in DOTS Visual Scripts:



I call it the "magic line" technique -- otherwise known as "punctuation and pacing" -- for Visual Scripts. This line separates the work from the setup (data creation and import), and the work (data changes) from the main idea stack (final formatting of data for its actual use as well as the actual use of that data).

This "magic line" allows the brain to visually separate and actually see the setup, execution, and overall main idea portions of a Visual Script, separately -- in a single glance. It is what lets our brain process and quickly decode concepts like "Jim" and "jumps" -- all without needing to understand or decode each individual "word" or "slang/jargon" in-line with the rest of the code. We can instantly see that "Jim" (the function of a human) does something -- i.e. "jumps" (the function of propelling something into the air) -- and the main idea is still the same as it would be whether those functions were expanded or not. We are still talking about "Jim's ascent into the air". The "magic line", as I called it, would be drawn in the same places whether those functions were "expanded" to include the full definitions/decoded functions or not.

For more information on the (i.e. green) "magic line" concept -- see the article I wrote.

Without the powerful "magic line" as "punctuation" to combat the ever-increasing lack of pacing created alongside any irrelevant information to a clear understanding of the parts of a "sentence" (the data flow through the graph into the main stack) that always (inevitably) arises in Visual Scripts (due to a lack of magic lines). DOTS Visual Scripting may be less likely to devolve as quickly into Unreal 's blueprint spaghetti-code, but it is still highly possible even with non-programming artists/designers. Why? Because as artists and designers, we aim to break conventions, and our designs (and our code) will try to do that at some point. Advanced 3d artists eventually go with a tool like Houdini because it allows us the flexibility to do this more freely (i.e. on the mesh-processing level). So don't underestimate us. We really REALLY appreciate it when we are not pigeon-holed into a single mechanical "simple" workflow which quickly becomes inflexible the moment we try to scale it. See my second post in this thread. We don't need our tools to be "simple" -- We just need them to be "simple to understand" -- no matter how complex the interface is.


-- Fin

 

Looking forward to Drop 7, sounds like it will be a huge change.
Can you post a screenshot on exactly what you mean by simpler nodes and simpler DOTS concepts?

 

I am your target audience. See my post above.
Yeah, I can program, but I would never claim to be a programmer -- I'm a designer first.
If you've read my article or posts, you'd probably understand why.
Nothing personal though, yo. For example, I think CodeMonkey's a cool enough guy.

If you read my post carefully, programmers can benefit from the added readability from what I call the "magic line" approach, which adds a layer of pacing and punctuation to visual code that is very difficult to get in a text editor.

So a few major uses I'd like to use it for:

1. Editor/Scene/Mesh/Gizmo programming / processing behaviors and multi-window tools w/scene shortcuts
2. As Inputs to (Native!) Unity State Machines
   
3. Programming general gameplay behavior components
4. Visual element tweaks -- i.e. materials, scale, meshes, etc.
   
5. Combining behavior components (preferably in a behavior-tree styled appraoch -- see NodeCanvas)
6. Sweeping changes to my node data used across all my gameobjects simultaneously
7. Variants on component values based on their location in (template) prefab hierarchies -- i.e. replace a mesh/animation/behavior/script component on a gameobject (based on a specific default template), creating a data-oreinted variant of that prefab structure, allowing me to create any object I'd like -- with lots of code reuse.
8. Restructure only "highly-mutable" hierarchies such as elements inside an object-pool, or labeling a component structure as "mutable" (in case I need to side-step the "variant" workflow for things like procedural meshes).
9. The ability to change or convert a "mutable" data structure into a full-on template data structure with variant support, etc. for things like object factories, which would allow us to keep the DOTS performance and only use the "extra" gameobject-style (less-performant) workflows on command -- and only when we absolutely need them -- I really don't think they should be default at ALL (remember "performance by default" -- Yeah, that.)
   
10. Quickly understanding my existing scripts at-a-glance (see "magic line" approach)

Honestly, until I see the 7th drop, I still prefer your 6th drop DOTS Visual Scripting setup over all solutions out there.

There is one thing it's missing though (besides the "magic line" punctuation/pacing of the scripts) -- Behavior Tree support. Behavior tree support would be so easy in DOTS -- It could be helpful for putting "main ideas" into more of a "Branching-Narrative" styled "paragraph" setup by doing this on a "script-to-script-to-tree-to-script-to-tree" level -- (i.e. Behavior Trees made out of a stack of our Visual Script references or Behavior Tree references, in any order or sequence, to quickly build up layers of complex DOTS script behaviors.)

This powerful functionality is just a no-brainer and should NOT be left out.

 

a bit hard to read so much text there, sorry =( English not my primary language

all I know, playmaker makes my life easier. in fast, I already did few demos (games) and all I can say for making games its enough.
other deal is tools. cant make a tool soft with playmaker.

all easy stuff - go state machines
all stuff you cant do with state machines - go write code
all stuff you cant write - go grab programmers =)
don't like it? do it as you wish =)

 

I got playmaker in bundle, but havn't used it because of this transition to DOTS. I figure there's lots of tools I already neeed to master so I can wait some months to go with official Unity Tech. But I do like your list. It makes a lot of sense.

 

@ans_unity:

Due to the success of old (somewhat limited) plugins like Playmaker to artists/designers, State Machines really should be integrated into the DOTS Visual Scripting solution -- though, for performance reasons, not directly. For example, plugging in a reference to a Visual Script from a "State" (which just acts as kind of an editor-only container to help the "State Machine" reference and execute a particular Visual Script behavior). This loose connection would keep the DOTS factor alive, and keep the logic of the State (the Visual Script) modular -- separate from its behavior -- which would increasing the overall performance and reusability of all behavior-oriented code, letting Visual Scripts be easily-batched to run in parallel.

The idea is that you would keep "stateful" data separate from "behavioral" data, which rarely ever requires explicit references to "statefulness" for logic (because data-oriented-data always wants to remain modular). In general, most explicitly "stateful" logic can just as easily be represented with "loose" (as opposed to explicit) references to stateful data, which means a HUGE boost in performance in the context of a game-loop running over and over the behaviors the entire time.This means MANY fewer Update() loops with more easily-authored behaviors.




Here's the idea:

• A "State" must exist in a "StateMachine" in order to exist
  • State can be named anything and doesn't need to reference anything but its own index in a StateMachine
  • States, if they have output, keep count of how many possible outputs (and also inputs) it requires
    
  • A State also keeps track of what scripts it references
    
  • States cannot be standalone (unless they are an EndState, ReturnState, or RepeatState)
  • StateMachine contains the actual processing data of the current state (StateTime, VisualScript, etc.)
  • If multiple StateMachines are running concurrently, it is possible to combine results by having "EndStates" in one StateMachine point to another StateMachine
    
• StateMachine must always have at least one "EndState" -- (i.e. EndState, ReturnState, or RepeatState) -- but can have more (and more are required, depending on the number of branches)
  • • EndState simply stops execution after the VisualScript attached to it (if any) is finished
      • If the NextState is set to "Automatic" in the VisualScript, stops execution after WaitTime ends
    • ReturnState returns all the way back to the beginning of a StateMachine
      • By default, ReturnState simply returns to the beginning of its own (current) StateMachine
        
      • Can also be specified to "Return" to an entirely different StateMachine
    • RepeatState repeats the current state forever (until NextState is manually set to a new StateMachine's State)
  • EndState can point to any other State in any StateMachine (the latter is a "hard" reference, the former is relative to the current machine), but normally EndState just ends execution when "NextState" node in a Visual Script (see "StateData" below) is set to "Automatic"
    
• Any VisualScript referenced in any StateMachine gets automatically marked for special state-based error-checking that only happens in the Unity Editor when a Visual Script is changed or saved
  • Error-checks can happen manually when the user runs a "Test" function in the VisualScript editor
    
  • Test function can also be run automatically -- for example after VisualScript and/or StateMachine changes
    
  • Test always runs when user saves the VisualScript (but only when VisualScript contains StateData nodes)
    
  • VisualScripts "marked" for state-based error-checking do not persist this data at runtime
    
  • VisualScripts can be in two modes in the Unity Editor: StandardVisualScript and StateMachine modes
    
  • VisualScripts have no special "runtime mode" -- a VisualScript is just a regular DOTS VisualScript and runs the same way any other VisualScript runs
    
  • Minus the extra "error-checking" in the Unity Editor, (which is the only difference between "state" and "standard" script data), a VisualScript is just a VisualScript, whether it supplies behavior data to a StateMachine -- or not
    
  • A VisualScript in StateMachine mode simply lets the VisualScript reference and use extra rules and stateful data that only apply to (and exist in) StateMachines so that the VisualScript itself doesn't have to (internally) host any data for the State or its specific behavior to work -- This design will allow it to keep its immutability (and therefore its DOTS performance) since its major parts still remain modular and atomic (i.e. very simple to separate / work with). This is why GameObjects are "easy" btw.
    
    
• VisualScripts are the (immutable) "behavior component" of States, but the StateMachine itself does the actual work (such as scheduling VisualScripts from its own States)
  • StateMachines actually maintain the reference to a list of VisualScript behaviors, which the State simply hints at during the authoring of the StateMachine's State flow -- StateMachines maintain a master list of the required VisualScripts States need to execute, and the States themselves are really just "dumb" containers that have a name and a script (or list of scripts) they want to associate with
    
  • StateMachine "master lists" (described above) keep data from being repeated (i.e. which VisualScripts to execute), keeping data atomic and performant, with minimal references
    
  • StateMachines keep track of the currently-executing State's behavior (i.e. StateTime, NextState, WaitTime, etc.)
  • Only one State is kept track of at a time by the StateMachine, leading the "stateful" data to being reusable, as only one State's basic data (StateTime, NextState, etc) is ever truly relevant at a time
  • StateMachines have a Blackboard to which the VisualScript can access data from other VisualScripts (States) when necessary
    
  • VisualScripts query the StateMachine and its Blackboard (rather than the State itself) for state-specific data (i.e. StateTime or even an array of mesh verts!)
  • States are a visual flowmap (with VisualScripts following basic rules)
  • The StateMachine is the backbone/workhorse for States' VisualScript behaviors
    
  • VisualScripts (with "stateful" nodes in their graphs) are designed to be as generic and modular as possible, acting as (Lego-like) behavior components
    
    
• StateData is "stateful" data relative to a StateMachine's currently-executing State that is referenced from a VisualScript set to "State" mode by either containing "stateful" VisualScript nodes (such as NextState, PrevState, WaitTime, StateTime, etc.) or being explicitly referenced in a State inside a StateMachine (meaning the StateMachine has a reference to the VisualScript in the context of one of the States in its flowmap)
  • StateData refers to the references a VisualScript makes via "stateful" nodes to the calling StateMachine to get the last-posted "state" data to its own (internal, hidden) Blackboard for the currently-executing State's VisualScript
  • VisualScripts do not contain, nor reference, any "stateful" data directly -- The StateMachine data is posted on its own Blackboard and the VisualScript can get at this data at any moment -- and also write to it (i.e. to "tick" when it is done so that StateTime can increase for the current State in the StateMachine so that the StateMachine can execute the NextState -- or repeat the VisualScript once more)
    
  • With "stateful" data being maintained outside the VisualScript (in the calling system, rather than from the callee), your VisualScripts can remain DOTS-oriented and modular
  • Data considered "stateful" are the small bits that often change and need to be kept track of (i.e. StateTime, NextState, WaitTime) -- and with StateMachines, this often doesn't need to be very much.
  • StateMachines need to keep track of only a single state at a time, so it can reuse the same data container after a transition (since it can simply "reset" the data upon changing to a new State in the StateMachine flow)
    
  • StateData changes only in the StateMachine's own (hidden) Blackboard -- it is not necessary (or ideal) to duplicate this in the VisualScript since both the VisualScript and the StateMachine must remain reusable (see above point)
    
  • There can be only one State executing at a time for a given StateMachine, however StateMachines can be "stacked" (and duplicated!) if necessary -- as this could be handy for DOTS Animation States (i.e. one StateMachine is for the UpperBody, and another StateMachine is for the LowerBody, but both access the same BoneData in a "BoneMask" StateMachine's Blackboard, which would allow one to mask off the legs {but not the hips} for a specific UpperBody movement)
    
  • VisualScript updates the StateMachine's (who executed the script) Blackboard with new StateData (i.e. NextState, WaitTime, etc.) when necessary
  • VisualScript also notifies the StateMachine's Blackboard when it's finished running
    
  • VisualScript generally does not need an explicit reference to the calling State, but it does need a way to reference the calling StateMachine
    
  • VisualScript typically only requires a reference to the calling StateMachine for easy-editing in the UnityEditor -- but this is not needed at runtime
    
  • StateMachine updates its own StateData (i.e. with any changes to NextState or WaitTime) with any new (or different) information provided via one of its VisualScripts notifying it of changes
    
  • StateMachine also handles updates for other StateData (i.e. StateTime) without input from VisualScript
  • StateData is reset when StateMachine sets NextState to a non-null value (i.e. index 0,1,2, etc.)
    
  • StateData can be referenced inside a VisualScript as long as the VisualScript has a calling StateMachine
  • VisualScripts without a StateMachine referencing them cannot reference "stateful" data (aka: StateData) in the UnityEditor
    
  • VisualScripts wanting to reference StateData (but with no StateMachine referencing them) will generate an error upon Save or running the "Test" function to validate the VisualScript
    
• Any States in a StateMachine must be tied to at least one (or more) VisualScripts in order to have any behavior
  • StateMachine executes VisualScripts in order (kind of like a BehaviorTree in NodeCanvas actually)
  • VisualScript determines NextState index (i.e. State node output 0,1,2, etc. in StateMachine), unless the NextState node in the VisualScript is set to "Automatic" -- in this case, the StateMachine handles transition
    
• StateMachine itself acts as a container for state-specific "stateful" data (StateData) for things like the following:
  • StateMachine increments a "StateTime" value every "tick" we are in a State (can also do StateDeltaTime)
    
  • StateMachine resets StateTime to -1 when you leave a state
  • StateTime starts at 0 when you "enter" a State (i.e. so we can setup things at the very start of the state)
  • StateTime set to -1 allows us to clean up anything in the StateMachine before we do anything in the next iteration of the VisualScript
  • VisualScript sees StateTime as 0 and can setup things for the first initial iteration of the VisualScript
• State changes are handled using StateData (aka: stateful data) nodes inside a VisualScript
  • VisualScripts must either relay ContinueState to remain in the current state indefinitely, WaitTime in order to remain in the same state for a particular period of time, or NextState to change states immediately
    
  • NextState can be set to "Automatic" to pull the NextState index in directly from a State at the StateMachine level while in the Unity Editor (at runtime, this is just set as a hardcoded index 0,1,2, etc.)
    
  • "Automatic" setting of the NextState value ensures NextState doesn't have to be manually input (as long as it is the last node in the script paths)
  • QueuedStates are possible too -- these are essentially just a StateList inside a single State node in the StateMachine editor in the UnityEditor
  • StateLists can behave in many ways (PriorityQueues, PushPopLists, NormalQueues, RepeatList etc.)
  • This is essentially just a "stack" of regular States that the VisualScript can request to be modified in the StateData of the StateMachine who called the VisualScript at the StateMachine's current State index
    
  • If no NextState and no WaitTime are set, a list of QueuedStates in the StateMachine are evaluated by the StateMachine (again, not in the VisualScript itself)
    
  • If there is more than one State, the first (essentially second) State in the list is executed
  • Upon completion of the VisualScript execution, the QueuedStates are popped from the State stack in the StateMachine
    
  • If no further States or QueuedStates are available in the stack, and no NextState/WaitTime is set, a big ugly error appears
  • If NextState is set as "Automatic" and no State, EndState, RepeatState, or ReturnState is assigned (in the StateMachine), another big ugly error appears
  • If the next State in a StateMachine is linked to another StateMachine, NextState must be "Automatic" in the VisualScript (otherwise another ugly error appears)

• VisualScript can reference the stateful data (aka: StateData) contained in the State that references it
  • StateTime -- Number of game ticks that have passed since you've entered the State
    
  • WaitTime -- Amount of time (in seconds) to wait until executing the VisualScript again
  • StateDeltaTime -- Number of milliseconds that have passed since you entered the State
    
  • ContinueState -- Stay in this state indefinitely for an unspecified amount of time (warn if no possible next state transition node, possibly throw an error in this case!)
    
  • PreviousState -- The state you've transitioned out of before entering this one
    
  • NextState -- The index (or StateMachine) of the next state you want to enter
    
  • StateList -- Request the StateMachine to add/remove/queue/prioritize/push/pop particular states from a list of possible states.

TL;DR

To put it simply -- This method allows you to have StateMachine behavior with DOTS performance and practices (i.e. immutable, reusable, modular, atomic data that can be easily processed in parallel -- yes, that means blazing-fast parallel StateMachines) while also having the crazy-ease-of-use of a familiar state machine workflow solution (like Playmaker) and have it also be flexible and useful for anything that you could imagine that requires stateful data -- even complex parallel state machines for DOTS Animation!!


For those who love text -- here's some explanation:

Spoiler

In other words, the "StateMachine" should actually be treated as a separate process from the Visual Scripts that drive the State behaviors, allowing all elements to maintain a very "loose" reference to one another. A quick query to the calling StateMachine (that is, the StateMachine that calls the VisualScript attached to one of its States) contains all the state data the state needs (rather than to individual states) to help us find out how long we've been in a state, or if we've just started it. None of this is ever state-specific, and as such, a one-to-many reference is unnecessary. The StateMachine itself handles the transition to/from individual states at edit time, and the nodes setup in an individual state-based script would determine the possible transitions (which could be simple indexes -- 0, 1, 2, etc., similar to how Houdini will handle its node input/output via multi-input/output node dots that correspond to an array).

At design time, you can always see the particular StateMachine / States you're transitioning to via the editor -- At runtime, the logic works, but nobody cares which states you're in -- particularly DOTS -- though this information can be explicitly queried via first querying the state machine itself for an index, then its current node index, and get the name mapped to that state. The important thing, however, is that this data is not tied to anything but the StateMachine itself -- a Visual Script only cares that it is leaving a state, and to which relative node index in its node-output array (i.e. 0,1,2, etc.) --

The StateMachine itself has the names/nodes of these references and the user can only reference in a Visual Script whatever reference (in the EDITOR) the StateMachine data tells it it can reference -- otherwise you get an error. At runtime, there is no concept of what Visual Script belongs to what state (at least in the Visual Script itself) except for what VisualScript the State itself references as its behavior.

The VisualScript itself is passed a list of possible indexes (via a quick query at edit time) mapped by the State Machine (i.e. node output/input index 0,1,2, etc.) and these indexes are what are used at runtime. The VisualScript itself does not care about what StateMachine or what specific State it is in (at runtime) -- it simply performs actions based on the information provided to it at edit time. Things such as state-time or the previous state are all piped-in (one-way) from the StateMachine that executes the VisualScript each moment. This means the VisualScript can get a reference to the StateMachine that executed it if it wants.

 

FWIW, I started out with visual scripting in Max/MSP. I'm a designer/artist and had previously dabbled with some code for site building. My artist brain really liked the 'magic boxes' in Max and how connecting them I could create amazingly complex visuals with very little effort.

Moving on to bigger projects, the spaghetti started to annoy me. Going back into an old Max project I would have no idea how I got it to work and I also wanted to write my own 'magic boxes' but had no idea how. That prompted me to learn proper coding techniques, first with Processing/Java and now C#/Unity.

Currently pretty comfortable in C# and object-oriented workflows, but again, I'm really attracted to the amazing visuals that are possible through the VFX graph and what I am seeing in DOTS. I am willing to go back to nodes, if it means I can do work on the GPU and create multi-threaded jobs that I otherwise would not be able to do safely.

More relevant to this conversation is the concept of simplicity and templates for coders and non-coders alike. I recently dived into UIElements and really liked the template-based approach to create elements. I'm somewhat familiar with relational database design and the concept of making a template, to be re-used elsewhere is a workflow that I can see working well with DOTS and visual scripting in general.

As @awesomedata is also saying, the prefab and nested workflow seems easy to understand. The current gameobject approach of tacking items onto an object is not exactly the best possible way to imagine developing a game. The idea of designing a really good template, and then tweaking it seems more DOTS-like and I would support developing the visual scripting in that direction.

From my point of view, I like the VFX graph OK, but it starts to become spaghetti-code pretty quick. The UIElements/UIBuilder is much cleaner, once you get past the initial learning curve. The way that you can clear overrides in UIBuilder is pretty nice. I find myself using the reset All to the styles quite a bit, just to experiment on the best way to style an element.

The Nested Prefab workflow is also good, it's not quite as clear how and what changes get inherited.