DOTS Visual Scripting Experimental Drop 10

Will this system be integrated with Bolt at all or will they be separate?

 

Props for getting documentation out this early! The project is coming along really nicely!

 

Look at this beauty Data portals really help to get rid of spaghetti Code



Wondering does blueprints have data portals too? I mean data portals for triggers/execution flows

 

No, and from what I know, they don't want portals. Honestly, there is no surprise, blueprints have specified way to work with and lack of portals force and teach you to set blueprints the way epic designed them to.

Honestly, this would look way better with the old idea of the more vertical approach to the visual scripting, and would be done faster.

 

I agree so I hope there is a possibility to change current verical scripting to some nice vertical flow.

I tried to mindlessly copy an example created in this thread and turn It into vertical flow and I already found many issues with the current way of scripting (overall). There is really a lot of waste even now and lack of clear "flow" will make visual scripting harder to use once there is a lot of nodes in there. From what I see you don't even use a word flow in documentation, but "Trigger" which makes It's even more confusing.




Another problem, current approach to portals is limited to small flowcharts. One of the big difference between current approach and something that epic does is "cast to" node. It is like a portal used to transfer data between separate flowcharts, but paired with If statement. In unreal engine you are supposed to do small and middle-sized flowcharts that are paired together with a cast to node. This way unreal allows for a really complicated logic with their visual scripting. I don't see this now with unity approach. I mean, some sort of complicated puzzle made by level designer, or even something like game "marbles on stream" which is 100% done with unreal's VS, and not only because there are no nodes for that, this can be done later. I think there is no proper workflow done yet.

 

@banan1234 Vertical flow can be kinda simulated in this drop and horizontal flow (with data portals of-course) offers strong separation of code(unlike vertical flow) but I think there should be a hybrid of both like bringing together two nodes with triggers should create a Stacked node I think that would be ideal and would have benefits of both worlds horizontal(proven by ue4) and vertical(potential benefits). I hope unity guys will investigate 'Stack Node' in future drops.

 

I know this is experimental, which is the reason I'm sending my feedback.

I think with I/O triggers besides changing name there is a bigger problem with visibility which I will talk about first. In UE4 you have to send data to the previously defined blueprint. This is limiting solution but at least you can see what is going on. I think unity team have to research on how to tell exactly what is going on. My proposition is to do It with some mix of macros, another thing ue4 does something like that too.

A program called world machine done this in a nice, visual way.



With this solution, you can create separate flowchart, then set It up as a macro and bundle It with whatever you want.

About the naming of this. The word trigger is wrong because the user can't link that word to anything visible on the screen. I was talking about flow because this is actually good name. You can explain what flow is in one sentence (to non programmer) in a way they will understand and at the same time you can represent flow port in the node with an icon that is a synonym of the word flow.

 

Just proposed my idea of hybrid flows to you and people.

 

Are'nt macros as same as smart objects?

 

@JakHussain @theor-unity @willgoldstone et al

The progress on Visual Scripting Graph and active, iterative communication with the community has been really exceptional so I want to acknowledge that and not lessen the much deserved accolades here. And I'm not complaining of the fact that there is early documentation so this is not a direct criticism to the visual scripting team or anyone applauding documentation.

I just want to take the opportunity to outline a reminder to all following these developments that a ream of documentation is not necessarily something to strive towards for experimental or alpha software that is subject to change and render those docs inaccurate or in need of constant edits and re-writes. Even with a dedicated team writing and maintaining docs, there is close and constant communication needed with the developers to keep everything in sync.. which in practice can be very challenging to maintain. Especially for software meant to be visually intuitive as a core reason for it to exist... Too much focus on documentation, or too early, instead of core functionality / usability, reliability can be (and has been) a detriment in many software projects.

If anything, this is speaking to anyone that's ever been expectant of exhaustive documentation for software that should / could have an intuitive UI/UX instead. Visual programming tools, (directed node graph, block, etc) fall at an interesting intersection where they definitely need some technical documentation / reference... but their visual elements need not be documented like a code framework or API, or it may miss valuable opportunities in usability because "it's in the documentation" or the old saying of "RTFM" as it's known . So, there may be a schism in how people view this, and... both views are correct, just slanted towards different use cases of visual programming tools.

Shader Graph as an example has had some of these issues where the documentation / reference describes certain functionality of nodes for swizzling / splitting / joining that 1. should be for 9/10 cases self explanatory / discoverable and not need documentation... 2. has features documented that to my knowledge never worked properly (dynamic component output) and the Shader Graph team has (indirectly through support channels) refused to address the issue or update the documentation to reflect the actual functionality, noting there is an (un-intuitive) workaround to the dynamic vector output size bug, and noting will be a major redesign & refactor someday soon anyway that will address this with a different approach. That said, it's been leaving a bad taste in my mouth and anyone learning or using Shader Graph that's come across these usability issues ever since it was declared production ready. Then there are other sections of the Shader Graph documentation like the master node reference that has been incomplete and out of date for a year at least and should just be removed if they won't be maintained. Again... why we even need exhaustive documentation for a visual tool that should document itself in its own UI is beyond me. Old standards and expectations die hard I guess. I don't mean to single anyone involved with Shader Graph team out anyway and I know they have plans to address all this. Unity strongly acknowledged on the 2020 roadmap talk that the development pace the last few years was overly rushed / crunched and I presume this was a significant factor to projects like this falling into default minimum viable product territory as such.

This is in contrast to the Visual Effect Graph team which has focused on usability, intuitive UI like vector component swizzling / split / join that is built into every operator node with a simple and self-explanatory expand/collapse widget. It saves the user from (in Shader Graph's case) needing to peruse out of date documentation of a Swizzle node to inaccurately describe its already stilted design usability using drop down menus. And then find a tutorial / example to find out about the Split and Join nodes that seem to be the way that the majority of Shader Graphs actually swizzle vectors. Interestingly, There was actually a previous version of the Visual Effect Graph documentation that contained an attempt at an exhaustive node reference which was later removed and instead replaced with cursor hover tool-tips in the graph UI on the nodes themselves. Leaving the Visual Effect Graph docs to focus mostly on the philosophy and visual language to onboard users into an intuitive flow with the UI/UX... so that they can hopefully not need to return to the documentation again... (unless it's for say, about writing code for a customization API.) While not a perfect or complete solution, this pivot was a bold but wise move that is inline with visual programming paradigms and modern UI/UX. (To be fair, I'm going to guess the Visual Effect Graph team probably had less pressure and other packages depending on their results than the Shader Graph team did, which may have let them explore and hone Visual Effect Graph in from a usability point of view like this.)

As such, I hope and expect that all visual programming packages underway at Unity continue in this direction, lessons learned. The expectations surrounding their documentation takes a significant backseat from the developers and the users perspective, with a firm focus on the product's functionality and usability. At least until the package is significantly mature or at least production ready, etc.

I might be preaching to the choir here as they say, I have shared similar sentiments on other threads before. Anyway, I'm sure someone may benefit from these ideas even if it's redundant in the context of Visual Scripting Graph's development goals, so, thanks for hearing me out.

 

I've been long waiting for this feature, I'm quite anxious to say the least. So... I wanted to ask: Is It still planned for 2020.1?

Also, Is it usable for 3D or only for 2D for the time being?

 

Too bad we can't use it now in 2020.1 as a preview

I'm definitely looking forward to using DOTS VS and bolt2, both tools in production, but while it’s not ready, let’s go helping, giving feedback

But what can we expect from the next DROP 11?

 

I just opened up the example scene, and although I am quite a few days late, it looks amazing!
This is probably just my fault, but adding that line to the manifest document makes me unable to open the project. I am running Unity 2019.4.3f1 so maybe that is the problem?
Should it work in that version or should I install Unity 2019.4.0f1

Thanks in advance!

 

I had this issue @skiwee if you looks closely the quote characters aren't correct if you copy them from this page. Delete them and type them yourself so that unity can resolve it as valid json and you're in.

 

I can see nothing under light theme,the words are light,background also light.I donot know how to fix it.

 

Is it really on you and your team, though, @theor-unity ? You're doing an excellent job, and I know that this package is nowhere near release and you will address it, but It's worth noting that light/dark UI / UX issues are common even in production ready packages and core Unity UI. (Not to mention countless issues with 3rd party editor packages / assets.) I mean, technically none of the GraphView based packages even truly support a light mode, it's this hideous hybrid of dark UI embedded in light UI. I'd argue that whoever at Unity keeps this light / dark theme paywall schism part of Unity, yet (seemingly) not allocating or managing resources to keep both themes easily, fully and properly maintained is largely responsible. It gives prospective new customers or converts, who may have a LOT of money but just have not yet purchased a license... a bad user experience taste in their mouth. But it seems to be far and away from being the fault of you, a developer at Unity.

I don't think you, you as a Unity developer should be responsible or even have to think about this.. there should either be a seamless UI theming system you rarely think about when implementing UI, or If it's not really feasible for Unity to do that right now, just cut your losses and let there be one theme, the dark theme (massively preferred among programmers, artists, designers alike) that always looks / works how you expect it to. Kind of like that other big engine out there people use that doesn't even have a light theme (and never needs to deal with these issues .)

Also cc'ing @willgoldstone as this turned into a mini essay relating to workflow, design, usability

 

So you're proposing a worse usability to cope with an issue... That's not too clever.
You know there are people here who prefer the light theme instead of the eyesore-ing dark one. Even with proper subscription.

 

Yes, of course. The ideal situation is by far to have both themes, just as the major operating systems have adopted now as well. I'm not against having a light theme. I'm just saying i'd rather have one theme (light or dark or yellow or plaid, etc) that all users can access and consistently works, instead of two themes that regularly have issues like this crop up. Whatever theme most people want (if we had to choose hypothetically to avoid these issues) If there were to a be a poll right now from all Unity users dark theme would most likely win, that's just what the data shows. Countless polls can be found such as this: https://hashnode.com/post/which-col...in-your-code-editor-ciq9e3wbn1avb0053p48nozw0
and this: https://getpolarized.io/2019/11/25/...95-Percent-Preferring-it-Over-Light-Mode.html

If light theme was more popular instead I'd be fine with that, too. (Call it "Democratizing" the Unity Editor UI ) Hopefully we don't have to choose, I really don't think Unity will actually get rid of the light theme. Discord even added a light theme recently. Just a thought experiment to prove a point and make a direct comparison to a major competing engine (Unreal) without this problem. If Unity is going to keep the light theme around, they should support it 100%, including in GraphView packages and get rid of the paywall so that if there is by chance some UI issue like this, users can at least switch themes as a workaround until it's resolved. But the current situation is untenable, no matter what theme you prefer.

So I'm not here to start a dark vs light argument, I don't mean to bring this thread too off topic since it's not even in a preview state yet, I'm just noticing the same cross theme UI issues that Shader Graph and Visual Effect Graph have had and continue to have, as GraphView doesn't seem to actually have a light theme at all and requires undue extra work from the developers to implement an ultimately terrible looking half light / half dark theme. If it was properly / fully light themed and that was easy to implement I don't think this would have come up.

 

Well, then you disguise your intentions very well.

I don't want to overwhelm you with facts, but you were the one, who injected this thread with this completely unnecessary argument and you are wrong on so many levels.
Among other things: maybe dark theme is popular among people, but in reality people don't need it (they want it, but that is a different problem). If a theme has problems which requires fixing, the answer is never that we get rid of it completely. If we follow your twisted logic, computer software wouldn't exist, we already would got rid of all of them almost completely (if it has bug, let's remove it in entirety).
Unreal has abysmal UI and UX, I wouldn't put it up as an example.

The current situation isn't "untenable". It is quite an exaggeration.
The fact that the dark theme is only available with subscription has nothing to do with this situation. Releasing it for free won't solve the problem, so it is completely irrelevant.

 

Totally agree! But if the dark theme is behind a paywall, I think that the main focus should always be on light theme first, which I think that is the @landonth 's main point here (I am a dark theme user, but I have a bunch of team mates that are are not and I can see their struggle with situations like that).

 

Dots visual script may be coming in 2021.1?

I'm very anxious to use it in production

 

ROUND 2 -- FIGHT!!


(just kidding!)




I did have a few bits of (hopefully neutral and unbiased!) feedback / input!



1) First, I just wanted @theor-unity and the rest of the VS team to know they are definitely doing a great job listening to feedback!
Our 'differences', all boiled down to the hard-and-fast "cater to _designers_" mandate Unity team had to stick to before releasing 1.0 and my "listen to ME, dammit! -- I _am_ a visual _designer_ who was simply _FORCED_ to program!!!", leading to sense of duty where I felt _I_ had to speak the hell up and point out the facts from both "sides" if I ever wanted a proper Data-Oriented Visual Scripting package. So I did. And so did others.
Now, after some thinking and watching the forums, and giving other users a chance to speak up freely without any influence from me, I have come to the conclusion that we all are _trying_ to speak the same language, but it is very hard on both sides. In my case, I am flexible in how these guys implement the solution (aside from certain basic and unwavering requirements to keep DATA flow VISUAL, minimizing spaghetti-code and keeping the architecture CLEAN and straightforward [without a lot of jumping around between scripts for simple functionality], while also keeping things be understandable "at-a-glance") -- but in @theor-unity's case (for example), he can't afford to be too flexible or worry about too many seemingly "smaller" subtleties if they ever want to _actually_ get anything done for all of us who are ravenously awaiting their progress. And so, as a developer, I understand their plight.

This is a HARD problem. So I salute these guys for listening anyway and giving my feedback a second-look (and therefore a fighting chance), despite how demanding that feedback is.
In short -- You guys ROCK.



2) Second -- This:



...is also kinda this:


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


Which makes me a little happy.


But...

Now we need automatic (custom -- or -- maybe-not-so-orange) outlines (for visual separation of subject/verb/main ideas) like the above. Automatic (horizontal) "regions" of a specific default pixel width would be nice too, so you can put two or more of these "triplet" columns of vertical functionality side-by-side (perhaps with a "Pages" concept?), so we can make some nice data "PARAGRAPHS" -- This is the one thing that would separate Unity from UE5 in terms of "easy-to-read" scripts.

Though, there is one thing I want to point out in the above image:

See the gray zig-zag / squiggly areas on the side?

This is where the "main idea" is actually defined by the "verb" portion itself while within a node. This should be possible (as it does lead to slightly cleaner code), but I'm split as to whether I think there needs to be some visual indication for the lack of an explicit "main idea" (perhaps the "sides" of the boxes or lines could be clicked to have the automatically generated vertical line separator generate an icon on the right side of the separator (where the squiggly zig-zag is). The reason this should be visually indicated is that there is no clear data "flow" to portal "output" (and this allows a fast, visual, "flow"). The "stacks" of boxes (which, actually really do suffice in this very simple script) are probably enough -- but I still think polish would be nice. Either way -- if Unity really is going the way of Unreal's Blueprints (god, I hope not) -- I really do suggest looking at this thread to see what to avoid when things get more and more complex...

This is definitely a great start -- One request though -- please make the automated vertical separation lines possible!! I need to be able to (instantly) visually separate (at-a-glance!) the subject, verb, and main-idea of my data-flow without any need for visual interpretation or brainpower, and that orange line (preferably custom-colored) could handle separation of different 'regions' (and therefore "data sentences" -- i.e. the horizontal flow of data) to make "paragraphs" (the vertical flow of data) -- so that sentences could be written vertically, but laid out horizontally (or vice-versa, if desired by the user). But either way, I REALLY believe you guys should consider the "sentence structure" data flow, for both horizontal and vertical layouts.

And an unrelated (but still fun!) note:

3) I just wanted to chime in on this, since I was absent in the drop 9 thread:

I really like the approach. Thank you so much for listening.





4) DOTS itself is getting to be very limiting in how the VS team can approach their design -- And this is due to the current implementation structure of the ECS "component" mechanism.

As @theor-unity (sort of) hinted at in his and my exchange about the multiple alarms, with multiple timers, across multiple entities in the Drop 8 thread, this is kind of a tricky situation to be in with the underlying API of DOTS.

In fact, some of my concerns with such heavy "ordering" and "dependency" were voiced by someone completely independent of me here, which led me to point out my thoughts on a solution to this dependency and ordering problem that @theor-unity (and the rest of the development team) is clearly struggling with. The buffer element isn't enough, and not all nodes need separate "jobification" just to change data in particular ways. This is the WHOLE PURPOSE of using a data-driven system, and also why there was so much tension between Unity's VS devs and I (at least before I delved into the API limitations they were [and we _will_ be] facing on the backend!)

So my proposed solution I will detail (when I have time) by putting it into a clear, easy-to-read, visual diagram.

But to summarize for now -- Let's just suffice it to say that Unity needs a better (non-convoluted) "component" system that doesn't rely on direct job-processing (or explicit order) for its entities. I have mentioned this before, but I will provide some better details later when I have time. The whole idea centers around the LabelComponent, which allows one to do processing just one time -- and forever be able to access that portion of memory instantly, without overhead of any complex (and context-dependent) ordering systems.

LabelComponent, DataComponent, ArrayComponent

Are the main component elements. Aside from what I described in the post I linked to, I need to give a few more details for them to make sense in regards to memory/processing speed/technique (and how that applies to VS). But suffice it to say, I will.

In the meantime, I wonder -- is an "Array" component or a "Label" component already in the works? -- It just seems like a no-brainer, considering the issues you guys are having.

Anyway -- Stay tuned!

 

Haha! -- That it IS!

And that is very interesting!

I hadn't realized they were two separate things! -- I can definitely see this being potentially useful for array-like structures!
There is a LOT of merit to using a hybrid of both systems (i.e. table + graph-based approach). Maybe once I share my thoughts on the alternative "components" usage, it might give you guys some ideas.

But I will definitely be pondering this new knowledge! -- Thanks for the heads-up!


And have a great weekend! ^___^

 

Was looking for the feature to view the script output created from the visual scripting graphs to help learn DOTS/ECS. That feature seems to have been removed? Any simple way to view the output of the visual scripts?

Cheers,

Alex

 

How does the release of https://blogs.unity3d.com/2020/07/22/bolt-visual-scripting-is-now-included-in-all-unity-plans/ affect the future plans for the DOTS/ECS visual scripting system?

Having another separate parallel official visual scripting tool is... an unusual decision.

> Will this acquisition change Unity’s own visual scripting tool development?
> Unity remains committed to providing a core experience of visual scripting in Unity for all types of projects, regardless of the architecture. We are actively working on refining the synergy between our various node-based tools so that visual programming gets progressively unified across the engine.

Is politely and completely ambiguous as to what this means.

 

^ am also interested in this. From what I've gathered on the experimental scripting preview forums, the Bolt team strives for DOTS compatibility but not as a priority right now.

 

It means that they will provide a Visual Scripting Tool (DOTS Visual Scripting or Bolt) to the users "for all types of projects, regardless of the architecture" meaning (DOTS/ECS or Monobehavior) based projects.

Node-based tools will become more tightly integrated into the different parts of the editor for a more seamless workflow.

 

Is actually an interesting question, in regards of what to test/learn and what to give feedback on.

 

Yea, since there are two tools now it comes down to which one you want to use moving forward. This one is for those looking forward to moving to DOTS or already using DOTS and want this Visual Scripting tool in their workflow. Those who want to stick to monobehavior will have Bolt and then Bolt 2 sometime in the future (if they get access to the alpha) or a little earlier.

I'm looking to move to DOTS when it's in a pretty good state because that's where things are headed, all the new tools are being made for it and current ones being transitioned to it.

 

Maybe they only wanted the manpower of the BOLT developers and they are now working for Unity Technologies and as a "meanwhile workaround" they give us BOLT until the "real thing" is production ready?...
However I was also wondering much when I´'ve seen that big yellow banner on the Assetstore

 

I think they haven't acquired the team behind bolt, but just the source of the plugin. So I guess they had to create a new Bolt team within Unity, with either new hires or pulling from other teams.

 

That is correct. Unity acquired only the asset itself. Lazlo, the original creator and developer, who made Bolt single-handedly has stayed independent. He owns Ludiq and develops Peek amongst other things, like running his own video game company.

As far as we know, Unity have assigned two full-time developers on both Bolt 1 support and Bolt 2 development. As well as a product manager, a community manager, and a handful of QA testers.

 

DOTS might be the future, but it's a far off future.

Let's take your average game studio as an example. If they start a game now, it's monobehaviour based. It'll take 2-4 years to finish that game. And once it's done, DOTS likely will be production ready.

But DOTS is a completely different architecture which means studios now have to completely rewrite their in-house tooling and re-train staff. All of that is incredibly expensive. So I can't see that happening in one go. Studios will probably partly transition some more performance intensive systems to DOTS, but everything else will stay monobehaviour based at least for another game or two.

That's on top of the fact that many developers don’t even need the speed of DOTS and do just fine with monobehaviour. There are many people who do not want to be forced to switch as it incurs needless costs.

So mass adaption of DOTS is like 5-8 years away, at least if not longer. And from what I’ve talked with Unity people working on Bolt, there are no plans to deprecate monobehaviour (at least currently). And it’s likely that Bolt 2 will be integrated in Unity core and shipped with engine releases (not confirmed yet).

That means it’s a choice of which architecture to use or even combine both rather than DOTS being the only correct answer. Both will coexist for many years to come and likely will communicate directly with Bolt nodes that'll trigger DOTS VS graphs and the other way around. Best of both worlds.

 

I already love it!
There are still some stuff that I don't understand but I'll figure it out.

I just wanted to know: will there be the option to use it vertically?

Also:

Does this mean that it will not be possible in the final released or is it temporary?

 

It should be available in the future as a feature.

 

This will actually happen, and it will be a difficult time ...

I wonder why unity did not create DOTS on a separate line? It would be so much simpler to migrate from one end to another ... Until today there is no ready template in the unity hub with only DOTS (Probably will have at some point) But it would be much better than having to import all the resources.

I'm not sure how VS DOTS works at a low level, but when I tested Bolt, I had no performance problems, even though I know it uses reflection and has losses

And when I was testing it, I felt that VS DOTS was going in the same direction as bolt 1 (it would be better if it was in the direction of bolt 2, vertical workflow like drop6 ), but it was still really cool to know that people who using bolt 1 or 2 will have a very small learning curve when migrating to VS DOTS, and this is very important for the strength that DOTS will have in the future. (After all, not everyone I know knows how to program in DOTS, but everyone who knows how to use bolt can easily migrate to VS DOTS)

VS DOTS has matured a lot since its first drop, and follows a line that actually helps in the development of a game, it is not a "complete game creator" like bolt, but it already has a lot of interesting content to play with