Unity is looking to understand your priorities for Visual Scripting

Could we have Burst for EntityCommandBuffer, editable EntityDebugger, proper multiple Worlds support, and stable API without deprecation?

Would be nice instead of visual scripting. Thanks.

 

"Integrating nodes with Lua"? Never realized that Lua was an option. I wouldn't mind

 

More interested in performance really, I mean if it's only as performant as regular C# then not much point since can use existing nodes from asset store or whatever. It has to be generally faster than monobehaviour land.

I'd like to be able to - with some function nodes - quickly replace my entire monobehaviour C# game with a VS solution that runs on dots without having to be bogged down trying to code everything in dots which is a bit of a chore for some.

And being able to have deterministic settings so we can do networked stuff within Unity visual scripting would be very nice. Basically, can we make full games in it, with better performance than mono land? if not....then try harder

 

it'd be nice if the survey let you go back - some of the options are pretty lengthy and i'd get to the end and realize 'crap, i don't really want half of these options but after trying to order them i can think of at least couple more i do want'.

 

Would also be nice to have some indicator like 1/10 on the questions so you'd know how long it's going to take.
There's also typo here I think: "Please look through following proposed actions you can perform in Visual Studio." (or test if anyone notice different VS used here).

 

Performance I believe should be priority.
Then using nodes, as way to generate up to date performant DOTS samples and templates.

Btw. I have completed survey.

 

This is how I imagine DOTSG, but very rough quick idea, does (not includes everything).
But once generated, should be editable via script, to expand functionality, if that required by devs.

Add Main Components node
with Data / Buffers components etc. and their respective fields, as sub nodes.
and add Tag Component.

Add Main System node
Add OnCreateManager, OnUpdate etc Internal Nodes, and allow add logic to them.
Optional of adding Entities groups.
Add Jobs selection, with input components when applicable, and burst drop down selection.
- Add internal job logic sub nodes.
- If added command buffer (at least until not supported by burst), disable automatically burst option.

Allow chain jobs in a system with JobHandle.

This way, I imagine, is hard to make mistake, with creating fairly simplistic and more complex systems, enforcing one way of coding. Also style of coding will be give, making whole scripts looking more unified.

 

I only want to use a graph to define, group and visualize the order of execution of my systems instead of using [UpdateAfter<PreviousSystem], and then see where it stalls / wait at runtime.

 

Things I forgot to mention in the survey:

Having a process for moving visual scripts to code is incredibly important for iteration and the maintenance of systems (possibly even allowing C# to call into visual scripts).

I can't overstate how important it is for visual scripting solutions to work well version control management. Having undiffable binary files would be a massive productivity drag.