DOTS Visual Scripting Experimental Drop 10

Thanks for your answers!

 

codegen not as a backend but as a feature (like shader graph, visual effects graph) should be available

 

thank you for your answers

 

I think interpreter has potential performance benefits and the reason for thinking this is 1) each node can be burst compiled individually imagine if we write a large burst compatible c# script and at some point we need to fetch some data from a gameobject or maybe vertices of mesh from rendermesh then the whole script would be burst-incompatible then we would need to pass the data to code externally for burst compilation but some times data is unpredictable to pass but with each node burst-compiled individually this wouldn't be a problem only incompatible node would be slow 2) all nodes can run in parallel starting from independent nodes and converge to an output like so


reason 1 alone should be a huge plus for programmer!!. I want to know is something like point no 2 planned.

 

Well...

- We have this slow language, let's make it fast!
- Okay, make sure we compile everything, remove most the indirections, it will be awesome, let's call it DOTS.
- Great!

- Let's make visual scripting for this new thing, because people are too lazy to learn the real thing.
- Okay...
- Let's make it interpreted and put back the indirections, people don't need that performance...
- Sounds cool. 1.0. Ship it!

--- What?

If Unity 1.0 would came out nowadays, it wouldn't include the player. Games can be played in the editor and it's complicated, so why bother with game building and stuff...

 

1)They might make codegen backend for release time builds but for editor interpreter is best thing to do like burst does jit compilation for editor and aot for builds
2) VS is still ecs you can set or remove components and we have entities as GOs too and now task-specific code is packed in to nodes before it was just c# syntax nodes.
Current approach has benefits 1) its easy to use like really easy 2) consise code imagine with old approach when doing netcode you know how much boilerplate code there is that wouldve been a pain.
Downside is that nodes need to be written in c#.
3) remember VS is VSDOTS not VSECS and ecs doesnt solve everything. Other data oriented designs are comming like Data Flow Graph. VS has to account for them too.

 

I hope you only work with non lazy programmers (in game development) that managed to learn zbrush, maya, substance designer & painter, speedtree, photoshop, drawing, painting, sound design and finally animating to the best possible, professional level.
I also hope you don't (potentially plan to) hire programmers that never decided to learn such things, but rather keep true to your ideas of hiring only people that aren't lazy. You know, It would sound very arrogant If you wouldn't know these things yourself and at the same time expect from everyone to know your field of knowledge like one is somehow superior.

VS is a natural evolution of Lua, a high level scripting language that was bought into the game development because it’s speeding up the development, put less pressure on the programmers (with unnecessary tasks) and overall manage to bring better workflow in teams, because even If it’s hard to imagine. Some people were too busy learning everything but programming (because they simply would never need that knowledge), and since this is a problem for the team, someone thought of providing toolkit which these people can learn ASAP. Since then time moved forward, Vs has become a standard thing every big game developer does have and put huge focus on, and here we are in this thread.


Also, about codegen and interpreter. By default, we assume that the interpreter is the slower solution thus worse, right? Then the problem with doing code generation only during compilation is one - there is no possible way to test your game (profile) in the editor. I know that the game will always work worse in the editor, but something else we always assume (and base our analysys on), the proportions are right. With having codegen only on compiled project we will have to change the way of profiling the games.

Ue4 did this by providing a lot of profiling tools in the "development build", they are visible on the screen while playing. It's nowhere as good as the profiler in unity editor, but I believe this was the fastest solution they thought of around this problem.

 

I'm trying.

Why? I pay those people who learned them.

I know, what they said. I actually read it. They will do the interpreter so they can provide "test builds" inside the editor. And they will ship it for real as 1.0. According to the plans. If you were reading my obviously picky and sarcastic comment properly, I haven't mentioned that we don't need this. I mainly made fun of the "1.0" - you know "you get the test build for production, we may improve it later. Or not, who knows".

 

I know and I understand, however, rather than posting empty complaints, let's better say what's wrong with bringing "early access alpha" products and naming them 1.0/ production ready. Especially when unity corporation can't understand them or doesn't want to change to fix these issues.

I can understand that code generation is harder to implement and maintain, but I hope unity does understand this is the "old", inconvenient solution from previous "generation" of VS. The fact alone our nodes are going to be transferred to the code (preferably in real time) implies they are as fast as code (just a bit badly written). We can't be sure of that with the interpreter, especially since there are a lot of examples of badly interpreters and thus terrible VS. If unity seriously will go this way, they will have a lot of more serious problems later, like proving to everyone “our VS is as good as concurrency even though their does do the transmission to code”.

I was responding to this

Whether serious or sarcastic, I even heard some lead of unity said that (from what I remember, during their roadmap talk). This statement is completely wrong in almost every single way (for a few reasons why, look at my previous post). This is the sort of thing that comic "Boomer" says whenever he notices anything outside his way of thinking about how the world should function.

The only reasonable and short answer to this sort of statement is "ok, programmer".

 

I have never ever made it a secret that I despise VS in general. I'm curious though, what they can make of it, maybe this time someone makes it right. You know, we always can have faith that this is the year of the linux desktop as well.

"Programming" through VS as a non-developer is "programmer art"-level thing. Interesting, and it has a place. In prototypes.
And yeah, if the "programmer" supposed to be an insult, you (or whoever started to use it) need to work on that a bit.

 

The point of it was never a word "boomer" neither "programmer". The point of this saying is something more along "You aren't going to listen anyway, and I don't care enough to explain any more". It's a more direct way to say that someone is short minded person than a simple categorization to the "bad group".

And this is also wrong, at least in game development. Both Lua and VS can go through to the final stages of development, even when they are times slower than actual code. Why? For the same reason why we are programming in c# and not in c++/ c/ assembly and the exact same reason unity is moving to dots.

Computers are getting faster and today ones are fast enough for not perfectly optimizing every task because human isn't going to notice anyway. At the same time sooner or later everyone comes into realization that If human isn't going to notice, then let's better to this in as fast (thus cheaply) as possible. This direction has skyrocketed and continue today because of many purely economical and management reasons.

Today's trend in game development is VS. It grew to the point where companies are doing more of VS (because most of the stuff always were oriented on providing good art in the final product) than through programming which is focusing more and more towards the greatest performance people can achieve.

Lately unity bought out bolt 2, recently they also stated they want to bundle it with the core engine and tight with the environment. They also released some poll to fill and asked this fantastic question.



Most of the stuff in this list is actual, true purpose of the VS (maybe besides build efficient code or collaboration with peers which can't be really called purposes) and at the same time most of the stuff from this list can be done fast enough by the computer so it doesn't matter if the computer will do the job in 0.01 ms (with good code) or five times slower (with badly implemented VS).

 

There are plenty of solo artists, and small teams of artists who have found commercial success making their games almost entirely in visual script. Games like The First Tree wouldn't exist otherwise. Those are not prototypes, those are complete games. End user doesn't see and doesn't care how the game is made as long as it works.

So this programmer elitism is misplaced. Why would anyone despise something that doesn't affect them in any way? Just don't use it if you don't want to use it. Spreading your negativity here is not productive in any way.

 

Hello everyone, a new drop of DOTS Visual Scripting is now available, please join the conversation in this new thread: https://forum.unity.com/threads/dots-visual-scripting-experimental-drop-11.944793/

Laurent