Official Visual scripting roadmap update - August 2020

Sufficient as a complete comment. --->

 

That makes me think they need to change the new slogan from "Performance by Default" to "The boss said we need completed 'competing' systems asap in order to have a decent IPO, then it's whatever because I am out after that."

 

So Unity chose poor quality but good looks. Sign of 21st century - (Mainstream curse).

 

Well, I would not say Bolt 1 is "poor quality". It is pretty solid for what it is... but what it is, is unperrformant, unscalable, and quite honestly, not what was promised by both Ludiq as well as Unity, to the purchasers of Bolt 1. Really, what it actually is, is finished. They can say "Yes, we do have competing features to Unreal Engine's popular Blueprints"

 

Let's wait for official announcements or messages. Community has had its say, we have communicated our concerns.

Let's not devolve this thread into yet another anti-Unity circlejerk. It's not productive.

 

Understood as well as agreed.

 

I mean, the end result - efficiency is lousy.
Bolt is nice, approachable, and has a lot of users. But such things are obtained at expense of other things, in this case performance.

 

Bolt1 --> Integration with Unity's core functionality
Bolt2 --> Continue development regardless of integration

Please do this!
This is better if Bolt 2 is destroyed.

 

What makes people angry is that they promised to provide a new version of BOLT2.0, but now they have killed it outright, which is treachery.
It makes me feel ridiculous that such a big company makes such a promise but fails to keep it!They don't care about our humble BOLT customers because it doesn't matter to them!
In addition, the official visual Scripting plug-in is not good enough, and their other plug-ins are not good enough. Compared with ASE, their SG is not so good, and the humanization is not so good.

 

I think they were motivated to buy BOLT because they didn't have enough experience developing their own visual Scripting plugins, as you can tell from the plugins they released.
In addition, the market does not allow them to constantly try and make mistakes. UE4 has lowered the bar through blueprint visual Scriptingand is steadily eating into their market share.
So, they bought a Bolt plug-in, and they're looking forward to getting that part of the Bolt user and related development experience.However, as they were integrating, they found that their own plug-ins clashed with some of the ideas of BOLt2.0.
And they don't think they should give up.
So, they killed the plug-in.

 

I think the biggest problem is themselves, they are always trial and error, their development thinking is chaotic.
They wanted to develop visual scripting plug-ins that were different from those already on the market.
So far, however, they have found nothing.Even after buying Bolt, a plug-in with a large user base, they found that their old idea was better.
In fact, it is because they are not close enough to the users, they are opposite to the users, they live in their own world!
Most importantly, they seem to have forgotten who really needs this type of plug-in.
Who is it?Those who are not good at writing code, they may be game artists, game planners, or independent game writers, and this part of the user has already been fixed by the operational thinking of the visual Scripting plug-ins on the market.
So, who are your customers?Where is your future?

 

"providing snippet based nodes." - Do you mean like PlayMaker?

 

https://ludiq.io/blog/bolt-2

From what I see here, bolt2 was amazing, please unity don't kill it.

The codegen looks clean
The UI looks professional
And performance is amazing

There is not a single reason from a user perspective that I can think of to go for bolt 1 instead of bolt 2

 

Take more time to release bolt 2, don't give up. The largest user-base will not come when all the users are in a state of shock and disbelief, It will come when users are listened to and plans are followed trough.

You planned to bring us bolt2, now please stick to it.
Thanks!

 

Again a company that buy someting for close it.
Well Unity will stay behind Unreal.
Unity is not even able with several developers to achieve what one person does.
Maybe it's not Bolt who needs to shut down but fire Unity's staff.

 

I don’t think Unreal has been made by one person since 1998

 

Why not just forget about calling it Bolt 2 but still work on it, that way you can have all the benefits of Bolt 2 without having to go back on the announcement. Call it BoltEd.

Or BoltEn.

Or ReBolt.

Or Boltoo.

My personal favourite, Michael BOLTUn (Un as in Unity).

 

To be fair, I think he _may_ have been referring to Bolt 2? -- (which was being made by two people prior to Unity, if I remember correctly?) Either way -- correct me if I'm wrong. This thread is going insanely fast. D:

 

Ahh, thanks, that's surely what was meant

 

@LaurentGibert, one thing to strongly consider here is if you're doing the right thing, but inverted.

Bolt 2 seems to have many strong points as a visual tool. For one, it looks a hell of a lot better than the current state of DOTS VS. I'm also liking it a lot more than say the look and feel of shader graph.

There's also some shared abstractions. Both Bolt 2, DOTS VS and Shader Graph wants to convert the nodes into code. You gave up on that for DOTS VS (for now), but it'll probably be a requirement longterm, as a DOTS-based product that's slower than it can be is as backwards as anything can be.

Maybe the approach should not be to discard Bolt 2 in order to have something you can unify with DOTS VS, maybe you should discard DOTS VS in order to unify with Bolt 2? Bolt 2 looks so much better than the other solutions you're juggling that I would re-prioritize completely;
- Stop work on DOTS VS
- Focus all VS time on finalizing and shipping Bolt 2 with it's current feature set
- Fix the issues you have with Bolt 2 lacking a proper front/back end separation
- Use the now extracted Bolt 2 frontend for the other VS solutions.

Just make sure that you hide it from whatever people running visual design for Unity these days, as they'll ask you to take out all the colors /s

 

I´m sure they have the numbers, but endorsing your point @Baste, lets not forget most of unity users development happens NOT in DOTS, afaik,...

 

I could not have said it any better. Totally agree. I feel like this would be the best approach and make the most sense.

 

Completly agree, and yes please keep the bolt 2 frontend UI, it looks mature and has nice icons that are made for it.

 

@LaurentGibert I guess the reason for the silence is because the last announcement, as candid and open as it was, caused a huge backlash. I think continuing to listen to the community and commenting further would be a more adequate approach, rather than keeping silent on further plans and letting users speculate endlessly until something new is announced.

 

It really feels like Unity is lacking great visual designers or at least whomever makes all the final calls isn't that good at it. It's not just visual design that is lacking however, I found that developing editor UX for assets is pretty painful. The company I work for eventually implemented the same functionality in their web panel and we simply discarded the editor we made for our Unity asset because it was proving to have too many issues.

I'm a programmer first and foremost but I love the concept of having a visual scrpting tool that is pleasant to work with and look at. Bolt definitely excels in visual design. My initial experience with Bolt 1 wasn't amazing though, but I'm sure a lot of that is resolved in Bolt 2 based on the feedback I've read here and the blog posts from Ludiq I'd read long ago.

 

I hate to say this, but Bolt was still on a10 after 2 years, and he was working on another tool and a game, I doubt it would be any further on than a12 now.

 

Bolt 1 and 2 are so different that I don't see how you'll be able to take features from 2 and port them to 1 without introducing a large amount of breaking changes.

 

Jup. It just seemed like a very refined high-quality tool.

@LaurentGibert
If Unity really doesn't want to develop Bolt 2 or make it open source, maybe you could sell it to another company who can then finish it.
I'm sure that would ease the backlash.

 

Ludiq would, maybe, be interested in finishing it.

 

@LaurentGibert i hope the silence is for you regrouping the team and doing the right thing to announce soon, and not due to ignorance.

 

I'm coming in late to this thread, but I wanted to drop in my $.02.

* A unified VS that handles Monobehaviors and DOTS -- yes please.
* A decoupled frontend and backend VS tool that lets the Unity UX team iterate and make the user experience more unified and easier for newcomers while also being powerful for advanced users, also yes please.
* A VS tool that is friendly to the creative members like the game designers, artist, and sound engineers on my team, also a yes.
* Code gen that can be powerful tool to upskill my jr developers, QA team, and designers -- I need that too.
* Well designed "flows" for logic (including events, inheritance, variable scope) that is reflected across the whole unity Visual toolset -- an absolute must.
* Code gen that gets me huge performance boosts in editor AND in game (over Bolt1) -- this is a given.

TBH, I was also very excited about all of the promises of the product formerly known as Bolt2, but I don't care how we get there. Call it whatever you want to call it, or integrate it directly into Unity as the official Unity Visual Scripting package, doesn't matter much to me, as long as I can get it into my prototype games by q1 of 2021, and it is ready for production products by end of q4 2021.

Names aren't important, and where you get the code (bolt1 source, bolt2 source, refactor it internally), isn't really that important either. Just make sure that you've identified all the fruit/features on the Visual Scripting tree that the community is hungry for, and make sure that those things are on your public roadmap with some tight deadlines for preview releases to keep us engaged in the conversation.

That's my $.02 -- now I'm back to shipping code!

 

Even though unity has proven sometimes you can only get response by getting aggressive, there is no reason to do it this time.

Seems like he is busy preparing some sort of essay for the rest of the team. Let's hope it will actually work and they will give us something that will be satisfying.

 

This is incredibly disappointing. I've been planning on switching from FlowCanvas to Bolt 2 for a year now, and now... well, I'm sticking to FlowCanvas. This massive change in direction right after purchase makes me really wonder if there is any plan at all.

 

The "merge the workflows" thing is where I see a clear _incompatibility_ with DOTS VS (and other tools like Shader Graph. etc.) as it stands right now (at least from a user/gamedev perspective), mainly because the workflows are all entirely different, and each of them speak an entirely different "language".

See here.


DOTS VS should not be diluted by OOP nonsense, and instead should work more like ECS (with subscribing to Systems via Tagged Components for Entities to implement and/or swap out behaviors -- on the fly).

In other words -- a program once, deploy _anywhere_ situation.


If someone wants to develop a "simple" project, I can see _some_ (Bolt 2-style) OOP / Monobehavior practices working for them (i.e. scene-based gameobject references), but I still think that promoting ECS practices (with a Visual Scripting UX integrated into the editor itself) would simplify life for everyone -- saving a HELL of a lot of time/money/headaches for all involved -- especially for the user.
Bringing DOTS VS toward Bolt 2 levels of functionality on the back of Bolt 1's mostly OOP workflow (and still not _quite_ ditching the 1:1 w/C# OOP-coding style which generates project-wide "spaghetti-code-prone" structural complexities) would be a HUGE waste.
Instead, bringing Bolt 2 to DOTS VS (via a tagging system) would be a better ordeal all around, if you _must_ have the Monobehaviour workflow.

In general, C# and OOP (at least in the form of how it is commonly understood these days inside of Unity by default) has never been ideal for game programming.

On the other hand, you guys are on-point with a more fully-integrated VS solution, but there's just a little more that needs to be done than even Bolt 2's current design allows.

The editor integration, for starters, needs to be prioritized over nodes -- and approached holistically.
Also, the UX itself needs to include more workflow considerations beyond just "nodes" -- especially because it is dealing with different "languages". For example, the "Verb" in Shader Graph is not always clear -- usually a OneMinus, etc. is enough to suffice as "logic" or "sentence structure" -- yet it fails to read properly as things are split more and more.
Also, Unity has no "game as a database" concept at all. And if you _ever_ look at any (highly-performant) game in the NES/SNES era, games were "just a database with a fancy interface" (i.e. the character / scrolling tiles). This concept is scalable. And necessary. All users -- even beginners -- need to design databases constantly. Enemies, puzzle pieces, inventory items, different kinds of enemy units, different kinds of players -- we have Prefabs / Variants -- but no database!
And nobody at Unity seems to see this -- or how it can apply to DATA-Oriented Visual Scripting.
There's more, but I'm done for now.

 

But that's like your opinion, man. I bet most devs right now would prefer to stick with their current tooling and experience that has worked for them for years, if not decades. Forcing ECS type workflows on everyone is not a solution. We can't suddenly rewrite all our tooling, migrate our existing projects to the one true way of coding in Unity. And there are plenty of game types made right now which have no need for databases as you describe them.

I don't see DOTS as the answer to everything; I see it as an answer to performance intensive problems like pathfinding or resource constrained platforms like low end mobile. High level scripting in a typical PC/Console game is still done best the OOP way at this point in time. Looks like Unity recognize that so we're getting a tool that's capable of both.

 

Excellently spoken. Not every project needs ECS. ECS may be a great solution for some but for others it may not add anything of value to their project. I like the concept of ECS, but by no means do I think it's the one true way of doing things nor should we force people to use it. Right tool for the job, as they say.

 

This is exactly what we were talking about in the bolt discord earlier today, even if it were integrated, it would not be so easy to implement it because the programming methods of OOP and DOTS are very different from each other.
If they succeed, it will be very cool, but it is still difficult

 

This is why we're going Bolt 1 rather than Bolt 2 -- people are giving Unity mixed messages.

"I want the future cool workflows like Bolt 2 and performance of DOTS and a great project structure and a great UX!"
"...BUT... I want to keep doing things _exactly_ the way I am now..."

:/

This is simply incorrect.

DOTS isn't the answer to everything, but DOTS (with the right interface) is definitely the way to program games.

The problem with "ECS-type workflows" is that they aren't correctly implemented in Unity, nor are any well-designed workflows available. This is what I am pushing for right now -- I am trying to change this.
But I can't do that on Bolt 1, nor can I do that on OOP based around C#.

I may be mistaken, but I think an entire game is a "performance intensive problem" if there ever was one. :/

 

Has anyone actually said that? Almost everyone here is talking so much about how do they want bolt 2 because of the classes, functions and c# generation. It gives them enough performance to make most of the stuff that should be done in visual scripting. I never saw anyone here screaming about dots and for a reason. DOTS currently have too specific target of where we can use it in. No one serious is going to consider writing a whole game in DOTS when they can do the same thing times faster in old, well working mono.

 

Instead I see people asking for "future cool workflow like bolt 2" with performance of "Bolt 2", with project structure and UX of "Bolt 2", and keep doing thins exactly as we do now in "Bolt 2",...

 

I'm not sure how seriously this statement can be taken while looking at other reasons why bolt 2 has been canceled (stuff like "It looks different", "too much programmer stuff" etc.), but this statement actually shows a lack of understanding the feedback users provide. There is nothing wrong with actually creating a new tool instead of developing current one, there is nothing wrong with releasing polished "elements" of the engine that aren't directed to 100% of users (at current time).


But something that is really wrong:
- Advertising features as something they are not (like, "Universal" RP which won't be universal till 2021). This is just lying to your customer.
- Trying to ignore issues or downsides of the engine (or overall being silent about them). Because of this whole #SRPLife exist.
- Rushing releases of the engine "elements" with significant design flaws and pretending they are absolutely ok.


I'm saying all of this because I understand that bolt 2 isn't the solution for everything unity is dreaming of and has some elements that are problematic for the team and aren't as future proof as everyone would want to. But at the same time, we don't have any other, proper solution for VS on the horizon than the bolt 2. Simply give us the best you can, many people here already proposed good solutions on how to approach the current mess of a roadmap. Then, acknowledge the problems and finally design a realistic approach to fix them.

 

There are a number of issues with your post on ECS being the correct way to make games. Comparing OOP and ECS is like comparing apples an oranges.

Regarding encapsulation:

Encapsulation isn't really an aspect of ECS workflows. In OOP languages to encapsulate implies that you are combining data and behaviors into self-contained units. ECS on the other hand deliberately decouples these two elements into components (data units) and systems (behavior units) which is quite contrary to the principles of encapsulation. So encapsulation is not a concept applicable to ECS and claiming it does it better than OOP languages in this regard shows a lack of understanding of such concepts.

Regarding Inheritance:

Similarly to encapsulation, inheritance isn't really applicable to ECS in a proper sense. ECS is more about ownership of data rather inheriting traits from another type. An entity doesn't inherit from a component, it owns/has components that define what the entity is. Because of this entities are quite dynamic and reusable, but that does come at the cost, particularly readability and simplicity.

Regarding Abstraction:

In OOP you will generally be able to derive the data and behavior through the classes and their inherited members, but in ECS you may have a dozen components (or more depending on complexity) and being able to derive what components make up an entity is completely dependent on developers making self contained functions to build/configure entities from start to finish.

Abstraction in OOP is different from abstraction in ECS. This primarily has to do with encapsulation. In OOP you encapsulation helps to keep things self-contained and abstraction helps to make code more reusable in situations where you may have shared data/behaviors. So if you're using abstraction, doing it properly will result in abstracted and encapsulated classes which can be inherited.

In ECS however, this abstraction is a matter of separating data in such a way that you have smaller units of pure data that the systems can then act on. It is a very different method of abstraction that has pros and cons, just like everything else.

Regarding polymorphism:

This ties back into inheritance and abstraction really. Polymorphism really only shines when you can change the behaviors of an objects based on its type. This becomes unnecessarily obscure and difficult to replicate in an ECS, in the proper sense.

Conclusion:

Overall you're trying to apply OOP principles to something that wasn't designed to solve the problems that OOP does. ECS works great in certain situations, but it can just as easily become a mess as an application following OOP principles.

 

This is an extremely disappointing decision and shows that Unity's infighting is at an all time high. This stinks of management making decisions they shouldn't and the complete ignorance of what tools are actually wanted in this space. They smirk thinking they know exactly what their user base needs, without asking. My heartfelt sadness goes out to the ludig team.

 

Sources? From the industry actually using DOTS / ECS in a large AAA game, for example? I'm always a bit suspicious when someone declares that a single tool is just the right choice for a certain thing, in this case... all games?

 

Overwatch

 

See below -- I will get to your points point-by-point when I have time, as I understand not everybody can read a mountain of text. But, for now, I need to put my money where my mouth is, and _show_ my reasoning in a way that is easy to understand. So for now, you'll just have to settle with what's below as a reply. But don't worry -- it won't be long. I'll reply properly.

There is a clear misconception as to what DOTS is and what I mean by ECS and OOP (on _top_ of DOTS -- just to be clear on my end).
DOTS alone is a _terrible_ way to write games. Don't worry -- I totally agree on that front!
However, many AAA games have had a version of ECS (and DOTS) for a long time. For the most detailed example you'll probably find, see below.

Also -- and especially:

@joshcamas, while I can totally understand your caution with my sweeping statements -- trust me, I don't make them lightly. This _is_ the internet after all.

So see the video above and watch carefully.
This is a great, well-explained, source on how AAA games (i.e. Insomniac) uses ECS / DOTS-like technology. Watch until ~8:30 mark so you can see the 'DOTS' part too, but I start right around when he begins discussing his 'ECS' or "concurrent component" technology -- as well as the "Systems" that utilize it.

If you listen carefully when the guy starts discussing "concurrency" and "Concurrent Components", then watch all the way until the "Gameplay Worker Threads" slide -- you will start to think: "Hey... That _does_ sound a lot like ECS! -- And hey!! Look! There's DOTS 'Jobs' too!!" -- and you'd be right.

DOTS is not a "new" technology (in and of itself) -- DOTS is just taking existing (sporadic) technologies and combining and _adapting_ them to fit a more general-purpose solution (i.e. "all games" -- and thus: "performance by default"). Pretty much all digital games have digital graphics in some form, and they also have logic. Building a DOTS backend to handle this for _all_ games is a smart move. DOTS is just a more "general" way to get the performance these guys at Insomniac were trying to get at -- and eventually apply that to _all_ games.
ECS, on the other hand, is a better way to structure component/behavioral data in general. And, yes, that "better way" still applies to _all_ games (despite the extra work Unity itself requires us to do in order to utilize it effectively -- which is because of Unity's specific ECS _implementation_ -- and not the concept of ECS itself.

ECS is just a concept.

ECS can be implemented in _many_ different ways -- and I think many people on here are forgetting that.

The issue (in whether ECS should be used or not) arises in how you _access_ and _change_ that component data -- especially in specific circumstances such as in level-specific obstacles and/or entity-specific behaviors.
And all it takes to handle that kind of thing is a creative approach. The guys at Insomniac games did that (though probably not very creatively) to some extent by using "Jobs" (or "Worker Threads" as they call them). It got them the performance they needed for _that_ specific game project -- but it was still not entirely scalable.

Their purpose, however, was "performance" -- and not "usability" -- and so I imagine that's why their game is so procedural (and has less of that "human touch" to it).
But genius programmers are genius programmers -- not UX designers.
I, on the other hand, happen to be intimately familiar with UX design _and_ the work of genius programmers. So I can say, with certainty, that there _is_ (most definitely) "a better way" to do Visual Scripting than the crusty-old OOP / Monobehavior way. And it's just as easy for small projects as it is for large ones.

Just give me some time -- I'll (graphically) show off the approach I keep pointing at and let _you_ decide.

 

@awesomedata by that point, you should kust try to code a proof of concept yourself, it doesn't have to have the performance, ot just have to illustrates the user experience.

 

No worries -- I'm working out the kinks for something like this. Remember, I'm an artist/designer first, and while I _can_ code extremely complex stuff, I really *hate* to do so (for reasons I've already mentioned), but these mostly just boil down to what drives me nuts about the programming landscape in general. But if I can change that for the better, I'll slog through it again. It's worth it to me. Regarding a proof-of-concept, I _was_ waiting to find out more about the new "Workspace" option Unity has supposedly been working on because how terrible Unity's UI programming situation is, since it has just been salty icing on the already extremely gross cake for me (i.e. I got out of web development for a reason). So I initially just wanted to consider that in my solution first. However, that's a minor detail. The workflow overall is much more important (imo) than the details of how it is implemented.

That being said -- I will definitely make strides toward a proper proof-of-concept. For now, I'll just settle for a quick mockup showing the general workflow. That shouldn't take too long. Then we can debate further, if need be.

 

Isn't anything using burst compiler using dots? While independent aspects can be Dots, it doesn't seem wholly separate. It kinda seems like for a lot of current applications (animation rigging, magica cloth) it's not solely independent.

In my mind, that stuff might be bad for general stuff, but for specific things it's great as others said. Does it really, urgently need a artist friendly option when it's ideal use is large scale or advanced application where an artist/designer capable of that level of programming logic probably wouldn't need a visual coding solution?

Can it just be piecemeal where it makes sense, while general C# generation is left to Bolt 2?

Would a general artist or designer choose DOTS/ECS over standard object oriented C#? Or would the more likely scenario be DOTS/ECS foundation where the artist designer uses C# to work with it like commonly done with Animation Rigging and Magica Cloth?

 

Hi everyone,

I would like to thank you again for this flow of honest and direct feedback.

Our team spent the last 2 days reviewing in details every single one of your posts, ideas, suggestions, and comments. We aggregated all of this together, highlighted the topics for which we need to clarify our intent, in order to get back to you all with a meaningful update that directly address every single one of your concerns.

In the mean time, the dev team has been working at describing in more technical terms various elements of the discussion so that we can get a second round of discussion focused on the technical aspects of visual scripting with more precision.

Coming back to you all soon.

Thanks,

Laurent