Official Visual scripting roadmap update - August 2020

I really hope the constructive parts of this topic will be of use to you going forwards; obviously there is some vitriol, some jokes (by me) and some people issuing their letters of resignation, but honestly, I think all most of us ever want is someone to listen to us... otherwise we wouldn't be so passionate about the tools we use.

 

As stated above, I am an artist/designer -- and I _hate_ to code.

But that's not just because code is "not visual enough" either. In fact, in my early days as a game designer, I worked in Game Maker. I spent 98% of my time in the script/code actions to create these code "snippets" that Unity seems to be pushing.

However, after working on a _real_ project, that I needed to one day scale, I realized I simply couldn't do that. I had "snippets" of code _everywhere_ -- and now, no matter what I did, I'd have to go in to EVERY SINGLE OBJECT in my game to remove those inline "snippets" (code actions) and upgrade them to "scripts" that could take arguments and become more general-purpose. However, I later found that, in some cases, I still _needed_ specific (object-based) functionality, and so I found myself copy/pasting code bits over and over to follow up scripts, which sometimes led me back to my original situation to where I needed to "globalize" the systems again into yet _another_ script -- but one that was different than the first, which could _also_ take different (kinds of) arguments for different reasons (to make them easier to use). This is essentially OOP in C# when you turn a code snippet into a method -- just in-line, and without any deep-seated dependencies (which was great!) -- but when you had to DIG for the code snippet, and when you forgot what you wrote in it and realized that not _all_ snippets could be globalized (because some were level/object-specific), you suddenly got a taste of agony -- especially when you realized there were lots of these scattered everywhere out of convenience!

As you can probably tell, this complex "rinse-and-repeat" cycle got old FAST.

Yet EVERY artist/designer who doesn't have a programming background runs into this trap at one point or another in some capacity -- no matter their situation.
What's worse is handling this in Game Maker was arguably _easier_ than what it sounds like Unity is planning with their VS solution, if it's meant to line up with C# OOP practices (which has dependency hell, whereas gamemaker had a global/local scale dependency, and that's it.) This was a tedious and nightmarish process to handle even with that simplification, and with C# classes, you can throw that "easy" factor away -- so don't get me wrong, when I say "easier", I don't mean "easy" in any form. Just easier than with C# OOP nightmare spaghetti-code dependencies, which requires heavy efforts on your part for designing and management of your dependencies across your entire codebase. Does this sound like fun? -- No? Then I'd better point you to ECS where you can avoid that hellish situation.
After that nightmare project, I would have taken up ECS in a heartbeat -- and then modified it to work for an OOP-style system (without explicit dependencies) via a "tagging" concept, using a bridge system to handle "dependencies" for things that really do need to depend on one another -- whether that's all the time or not.
Again, ECS is just a _concept_ -- and a _concept_ requires implementation. The devil is in the details of implementation, and that implementation can help (or harm) your project structure at the end of the day, if the right mindset was not being considered when designing the implementation.


In summary:

While programming a simple game in Game Maker in the early days really was "easy" (i.e. I could go from one action to the next and script each independently right there in the object) -- I paid for this "ease" not only in performance, but also in every single (similar) action being a huge pain in the ass to later combine into a system that I could modify from a single place in code. Had I started scripting my actions with ECS-like systems and used "tagged" components on my objects to begin with (rather than relying on in-line "snippet" actions), my problem would've never occurred, and my game would have been just as "easy" to program (actually moreso), regardless whether I was coding in a "system" or a "script-component" or even an inline action/node "snippet" -- because the behavior would still be the same.

So yeah -- I would have traded coding in a heartbeat for ECS, if I could've back then. There are too many problems with "concurrency" that even AAA studios (like Insomniac in the video above) struggle with. And indies, artists/designers, and even programmers _still_ struggle with this problem everyday -- BUT that's because it has never been solved properly.
ECS is a great first step to solving this problem -- but it relies on "tagging" components being implemented in a way that doesn't tie them to "data" (the way Unity does now, which makes scripting in ECS too tedious).
I'll show how this small change solves the problem mentioned above and subsequently makes games _much_ easier to make when I get a bit more time.

 

To respond to this:

That is true -- in this thread.
But prior to THIS thread, everybody was asking for Unity to return DOTS VS back to where it was in drop 6 (i.e. Data-Oriented Scripting + Performance of DOTS + Vertical Flow, etc.) -- but apparently a lot of people have forgotten about that.
Since people have noticed Bolt 2 doing a lot of similar things as drop 6, and realized that Unity is hemming and hawing about which direction it's taking DOTS VS, people have realized "Bolt 2 is something we can have much sooner!" -- So only now has the story changed. And only now have some people become more "modest" in their requirements for Visual Scripting.
After all, if Unity isn't going to give us what we _want_, then we might as well ask for what we can "realistically" expect.

So yeah -- "mixed messages" definitely still stands.

 

If I understood correctly the aim is to go with Bolt 1.0 and then gradually shoehorn every good bit from Bolt 2 & DOTS Visual scripting into it over time?
To me this sounds counter intuitive, both renderpipelines were redesigned from the ground up to avoid this kind of task, similarly every bit of DOTS outside of this is pretty much built from scratch to avoid basing work on something outdated and antiquated.

On a different note "too programmer centric" was also cited; besides the community's disagreement here, could we get some clearer examples of what this really means? I'd like to understand unity's decision or thought process, @LaurentGibert, I really appreciated the communication but given visual scripting is well visual, it would be nice to see some either mockups or examples from other existing technologies to get a clearer understanding.

The original preview unity showed which afaik bolt2 based upon looked head and shoulders better and clearer than anything else I've seen on the market(including bolt2). I personally don't see why this cant co-exist alongside higher function nodes/macros that encapsulate repetitive things. But if it cant, I'd like to know more that explains the why.

 

I hope Unity dont want to create playmaker out of bolt. We want visual scripting solution which can compete and be hopefully better than unreals blueprint. If they want to ship visual scripting for non programmers only thats crazy mistake and nobody will use it on serious work, and it will be a toy only for beginers. So please take your time to decypher bolt 2 architecture and integrate it but dont ship something nobody will use in serious work

 

It's been months since that notice has been made. Plans can change anytime - that's dev life.

Laurent atleast listens to us and is open for discussions, which is good.

.

 

Yes its great, its very welcome that he is all ears to the community. It can't be an easy task to take into account all the technical aspects as well as the wishes of everyone and to continue building the tool on the code of someone else who no longer works on it, so hats of on the effort and I'm confident that it will come to the right result in the end.

 

I think Bolt 2 came first, but to be honest, looking back at this, the design they showcased there actually does look incredibly tidy.

 

Sorry about my dramatic post on page 4, I was upset when I got the news and wanted you to know it. But it's not constructive. Though, I still think it was dishonest to promise Bolt 2 and scrap it 3 months later. It's borderline false advertising.

A lot has been said, I think you are already aware of Bolt 1 issues. I just would like to insist that getting rid of pure C# generation is a huge mistake. It could be Unity's killer feature, really.

It's extremely good for performances, but it's also the best code learning software you could have, in a production environment.

Bolt 1 learnt me how to read C#. Bolt 2 could have learn me how to write it. It's incredibly valuable. Just think about what the adoption would be in video game schools all around the world.

 

Really agreed.

 

As an artist, I was really looking forward to Bolt 2. In fact, I bought Bolt 1 about a year ago explicitly for Bolt 2. Bolt 2's ability to spit out code and act more like code was highly attractive as a visual scripting tool compared to other options. So I can see "Ohhhhh, so THAT'S what the code looks like if I make this graph!". That realization now makes you more valuable and more likely to interop with the programming team as a result. Or at least start to vaguely understand some of the things they talk about. Less disconnect.

It was mentioned more than a few times in this thread that you felt this was dividing and leading to more siloed tech stacks? I can't help but think it is exactly the opposite.

 

Fully Agree

 

Plus 1 on this, seems like a very good idea. AFAIK the colors had purpose other then just looking great and coming off
as a very professional UI going forward. Lest if I am reading some of the replies right.

It says something when as Unity you have many, many people that were willing to signup for beta testing, still many others would give their time free, if they could help. That is good to know.

 

thank you for hearing us

I’m more than capable of coding without a visual tool. So in a way bolt is optional for me. But I like watching it work and bolt 2 had so much to offer and it was heartbreaking to hear it was being thrown away. I have plans on a teach yourself to code course but bolt 2 is was much more in line due to its closer mapping to reality.

I hope as part of your discussions that your team reconsider how it’s future looks. Clearly many of us really wanted the bolt 2 that was on the cards and it was looking very viable a product.

We are a passionate lot.

 

One thing I got to say, Laurent is the incarnation of the etiquette and politeness, hehe.

 

I do wonder if part of this is Unity is considering what people want before they even really start.

Like to me, starting out with no understanding of game programming initially I felt I wanted something more simple. But that said I tried bolt first mostly cause it integrated with any C# script. But over time I came to understand I needed a tool that was as versatile as possible and while Bolt 1 was very close, Bolt 2 was the full form of that idea.

And a year into my project I was capable of and needed to move a large chunk of my code to written C#, because my needs expanded. A large undertaking for me as a non-programmer but a critical one I needed to make to continue development. Thats how big this change can be for some one who started out wanting nothing to do with full code.

I had also watched videos from youtubers like One Wheel Studio who explain this process is actually very common and why it's common.

Unity should be focusing on the mentality that forms after you've been using these VS tools for a long time. What is the end result rather than what people might want when they initially know next to nothing. That builds a more long term product that people who may start with something like fungus or playmaker will switch to as they learn more, gain experience, and realize what they truly need.

 

Follow up video

Edit the truth is that beginners in code have 3 majors focus fighting for attention with traditional coding:
- the lingo
- the logic
- the syntax

By being self documented lingo get absorbed organically faster than with text, the interface is generally the reference with node based visual coding, the process of looking for a specific node also makes you discover others, and the nature of navigation also tells you a lot. You end up being familiarized with features through immersion.

Visual coding makes the logic front and center, you directly manipulate the concept and their relation, it expose and allow understanding by visualizing directly the logic structure.

But more importantly it remove distractions from the syntax, if you mistype something that's not immediately detected by the error checking you are left wondering if the error is logic based, and you spend a lot of time on what is basically a misdirection.

This last part is why artists and designers favor mostly visual scripting. That's what they mean when they say it makes coding easier, the second is that expose the structure and manipulation of the logic to be made hassle free.

Artists and designers have two main concerns, what and how.

What is basically just get stuff done as soon as possible. When making games, we need to test endless permutations of gameplay to choose the best variant, we need limitless possibilities, that's the what, building features. Snippets by being black boxes hinder that. The what can be build messily.

How comes when the what is define, and we want to turn it into something efficient and integrated into the whole efficiently, we took away the mess and refine it. Which mean we need legibility and flexibility, we need to be able to fine comb at low level, yet see how the part integrate into the whole at the same time.

That's why people want bolt 2 so much, it accompanies you from the what to the how, o to each phases and it specific focus, and keep the distractions away while you transition.

Visual scripting is an interface problem, ie it's legibility and usability, it's not about making coding simpler or easier, just more practical.

 

Yeah thats a big thing for me, bolt made experimentation easier, so when something was wrong I could mess with it until it worked focusing only on the logic.

When I had to move my bolt nodes to C# I did so knowing exactly what I wanted and how the logic worked. And Visual Studio really helps with syntax now days.

I still don't understand setting up stuff like custom events and coroutines though...bolt made that one click . So i had to hire a programmer for that (which was the point of moving to C# in the first place).

 

From what I know, c# code generation definitely isn't going to be a part of any VS unity is making. This feature is too big of a hassle for them and doesn't align with the way they want to create other tools that would work alongside VS.

Instead, they want to copy - paste blueprints, but I feel like they don't see what they are getting into. The solution epic made is so great, but not because of the architecture of nodes, neither look, it actually is the opposite. Blueprints are always single threaded, hard to learn when you have a very little programmer background (names aren’t very obvious to guess) and the biggest task for every designer isn't to make something with their system, but to make it look clean, be easy to adapt and expand as the project grows (It's much harder to do than with code).

So far unity hasn't even tried to prove they know how to overcome these issues.

However, the biggest reason why the blueprint system is so great are high level nodes. Epic through the years has made dozens, if not even over hundred of high level nodes made out of hundreds lines. All of this while unity can't even provide something like the most basic character controller. On the other side, Epic managed it to be made out of two nodes, one for wasda movement and the second one for jumping. And the killer feature, it can be easily adapted with a lot of basic features such as sprint, double jump, controller support, swimming within minutes and doesn't have bugs unlike standard models.

And the worse part is yet to come - unity will need multiple years to even reach similar product value as blueprints does have right now. Bolt 2 at least made a bit of sense because it truly brought something different with c# generation and many possibilities with it. The dream of "bringing a good VS in 2021" won't happen, we are going to get another "production ready" feature like HDRP, and both are going to be worse than what ue4 does have (However, for HDRP it's partly understandable).

 

why unity didnt bought just bolt1 if they so need it.

so lazlo could make his bolt2 for people.im so sad about this situation when you just throw in the bin few years of hard work /

who need spagetty fabric bolt1 -its a past era of visual scripting.

 

Unity behavior around this matter is absolutely not innocent. They could release bolt 2 and keep the work on their tool afterwards. Sorry but I don’t buy it, it doesn’t seems like you truly care about us and not on the company revenue. I wonder how Ludic founder feel about this right now..

RIP Bolt 2

 

I'm sure they do consider that, it's just their consideration first and foremost is for AAA studio pipelines where a tool like this is meant mainly for artists and designers. Studios where designers and artists don’t have the need or time for learning low level API because of time constraints and programmers covering custom node implementation. And where more complex VS designs when completed can be rewritten in native code, so C# generation is not that relevant.

Bolt 2 was not easily extendable with custom nodes because you also had to write C# generators that would ensure they work in Generated mode and in builds. I assume this is one major reason for not going the C# gen route because AAA studios don’t really care for it; they care for having a high level node library and for custom implementing their own nodes per project basis.

Bolt 2’s philosophy was to eliminate the need for high level custom nodes, eventually. Reflected nodes already offered a lot of access to C# without custom implementing it, but it had its limits like only one input and output flow and no fancy drop-down selectors or things like that. We briefly discussed things like an attribute system to achieve the full power of Bolt 2 in reflected nodes. But there were no concrete plans. It was a far off future thing.

Unity's philosophy is instead to focus on high level custom implemented nodes Blueprints style. Much simpler to write custom node implementations without C# generation getting in the way. Unlike Bolt 1’s reflected nodes, these can scale much better. Especially in big games where Bolt 2’s Live mode would be just as slow as Bolt 1’s Live mode due to reflection. Implemented snippet nodes also enable the DLC graphs they mention in the announcement - the ability to ship new functionality over the web, in asset bundles, etc. Something that is not possible in either C#, Bolt 1 or Bolt 2. This is extremely attractive to mobile game developers especially but would also apply to any other game that’s frequently updated, the games as a service model, etc.

A lot of the arguments for C# gen have been mentioned here and elsewhere, but most of them are pretty weak. Profit for Unity is where big, successful games are made. So if you want C# gen because it’s easier to follow tutorials or learn C#, it doesn’t register as a blip on their radar. If you’re going through tutorials, you’re not making money for either yourself or them. Their goal is not a learning tool for newbies, the goal is a production tool that works on AAA level of development.

The true power of Bolt 2’s C# gen was in smaller teams where we don’t have the resources to rewrite complex VS designs to native code and where we don’t have resources to write custom nodes per project basis. It offered performance by default for VS based systems and mechanics.

Well, that's my speculation, anyway. Gotta wait for the official post that'll go more in detail on their decision making.

 

Smaller teams are the bread and butter of unity last time I checked, maybe things have changed but I would not cross out the need for C# code generation for a large group of people.

 

I guess my question is why do you need a "custom node" when a function reference works basically the same?

Make a function, plug in the relevant values, not much else changed.

 

Reflected functions can't have more than one input/output flow and can't do fancy stuff like the configurators on these units:


Reflected units (unless they're static functions) also need a target since it's essentially an automatically generated bridge to a C# script - it's not a self-contained piece of logic. You also can't categorize reflected units in dedicated fuzzy finder categories as far as I know.

Although some of these could be achieved with additional development.

The DLC graph thing seems to be a big focus for them and that also is not possible with reflected units.

 

The problem with low hanging fruits profit seeking, is that you eventually run out of them, on top of having to compete with everybody else. Running to stay at the same place isn't sustainable in the long terms. It looks like unity is content with only being at the same level than competitors. In this case why not just stick with a competing product? Unreal already have decent blueprint, unity having it too doesn't make it more attractive, it only make it the same.

Now risky ambition might fail, but if you succeed you make all the money. Unity is where it is today because they got on every platform, which allowed them to caught the nascent mobile wave and disrupt the market. Then they capitalize on that by bringing innovative features that allowed mobile to punch above their weight, like tetrahedral lightprobe volume and found solution to address the hardware fragmentation like surface shaders. On top of that the component system allowed slightly technically minded people to lego their way to making games, which attracted an audience of technical artist, designers and lapse web designer (unityscript being gateway drug due to similarities with actionscript and javascript), which then prompted programmer to follow through by helping their friends.

Problem is now the competition is adapting and mobile are reaching a level where unreal was design for, and thus became a viable alternative, all while the low end mobile are being phase out, which mean unity lead is eroding and its weakness showing.

My issue is that most interactions with unity teams serms devoid of ambition, as they are content to only catch up. I have been told once "there is no paper about it" when i ask for a useful features people have expermenting eith and implementing, while there is probably good arguments to shut down my demand, this specific answer was kinda damming and illustrates a mentality of defeat. That's how i perceive unity nowaday, aside from DOTS and burst.

 

This. 100% this. I'm fairly certain that small teams and individuals make up the bulk of Unity's active subscriber-base. They aren't designing all of these tools with just AAA in mind because supporting indie developers is critical to Unity. If the forsake indie developers for a handful of AAA developers then they put themselves at risk.

 

Even in big companies, there are juniors, and the amount of time needed to babysit someone on entry level to become pro level has always been important. Gamedev has a lot of people wanting to join the industry and because of this, requirements are already not that low for designers and artists, at least in the world of ue4. My point is, having a lot of juniors with "basic understanding of c#" would be pretty awesome because that's around 1-2 years earlier than you can expect ue4 designers to get on that level with c++. Also, code generation is always mainly about performance, the visibility of the code is a nice feature and in my opinion, the future of the VS tools, but the truth is, Unity is around 6-7 behind Epic.

I agree on many of other points, c# generation, while definitely worth and important, have to be done after proper R&D. Right now I just hope once I'm going to finish my current game we are going to have something worth checking, something with at least similar performance to blueprints and/ or at least as high level nodes and/or even something that fixes easy to notice the flaws of Epic's solution. In short, some value proposition over competition.

Because programming at the low level of bolt 2/ 1 / flowcanvas / Unode and at the same time getting similar performance as blueprints (or even worse, they generate code during compilation) doesn't sound interesting at all.

 

I assume that " AAA studio's " have a lot of $$$ and that they can write off a lot as expenses.
One would assume for sure they would have programmer's and artists and designers
that are experts in their own fields. Also, I have no true idea about this, but I would think
that a big AAA studio would make their own models for about everything, so my question would be how much money would they spend in the asset store ? ( excluding asset seats ) I have no idea. But for sure they can pay the pro prices and have access to all of unity's systems for any little bump they come across. But this is all speculation on my part.

I have seen many mobile dev's complain about all the work and end up making the game free.
The problem in part is ( for me at least ) You buy all these different assets that you need, like a water system,
sky, weather, AI, etc. But the problem is making them talk together the way you want.
So, when bolt came around it was a god send, because you could make all these different assets
talk to each other as you needed. Then the idea that you could do this with Bolt 2 output the
code gen instead to make these different packages talk to each other, would automatically make
your game much faster. Making something like VS for big game studios that have or can get the
talent they need for anything I don't understand, but in any case, this seems to be saying,
this is for AAA studios since they end up with huge levels that need to be highly efficient.
I assume that DOT, ECS burst is for the big studios, and that the VS is aimed more for them.

Open up ue4, you see right away the graphics.To me well if there is no nice graphics to look at, then you don't have a game at all. Seems obvious, but the point is good graphics, then comes the programing.

Maybe this is just me, but the reason I do not leave for ue4 ( like a few of my kind have done )
The problem for me is ... I hate graphs and blueprints right out the gate. I love making
levels the best, I love doing textures as well. But after a time, you need or want to make more of
your world then just a level you walk around in first person. My point is that even Bolt for me is blueprints but,if you want to do anything more then level build then you soon see that you have to have coding or some kind of VS/Bolt, to put your logic together. The transition from Bolt1 to Bolt 2 would have been for many of us, much less painful.

A lot of this is way over my head.. DOTS, ECS, Burst, I have no clue what is going on. I guess my point is that for all the people that want bolt 2, is because maybe many of us are at this same level like ( hobby or are hoping to be able to put out a decent game for themselves, otherwise playmaker would not still be as popular as it still is. )
Sorry if this comes across as a rant, but I still feel that many still very much want bolt 2 for this reason.

Oh the last thing I was going to say, for this thread, is that the other reason ( besides ue4 being
all blueprints for most things ) ... I like Unity's interface way better

My real opinion is that if bolt 2 is possible, that might make / give Unity a Huge entry level draw for many more users', and that could mean far more $$$ for the store developers as well, imho. I have pretty much said everything I think I can say.

Thank you, Unity, for being willing to listen.

 

Hmmm, I guess I can see that, but I feel it's something that could be compensated for.

It is possible to categorize the code, and i don't think the target issue is too big a deal. But i do get more advanced interfacing could be useful.

 

News flash and if needed I will delete this post. Bolt will soon be able to output C# with
an add-on called UAlive

For All those that really were looking forward to the Code gen of bolt 2
One of the users of Bolt has started a new asset that will output c# from Bolt 1.

The plan is even better " Our generated scripts do not rely on UAlive or Bolt being in the project. "

While I hope Unity will not kill Bolt 2 still.... because I really feel that Bolt 2 as promised
will bring many new people to the world of game making and keep them engaged with
Unity for good.

How ever this guy has cared and helped me with the most stupid
stuff I asked when bolt came out, and he really cares about the Bolt community.

Here is the post >>> https://forum.unity.com/threads/fre...to-compiled-c-generation.918518/#post-6231285

 

This is going to be a long one -- so bear with me -- it's worth reading.

To be clear to all the naysayers (who probably didn't read all my long posts), I have never "compared ECS to OOP" in any direct way -- however, I have "compared ECS (using OOP concepts)" specifically to C# (and how it uses OOP concepts), in an attempt to illustrate the clear contrast in workflow and understanding the details of the implementation and the implications on game programming (in particular) the details an implementation in OOP would bring to light.

In other words, this was done in order to establish exactly how badass ECS (+ OOP) could be in contrast to C# OOP (by highlighting the differences between the two via contrasting two approaches) -- and not to rip on OOP itself.

Not understanding this (very clear) distinction in the post I linked to shows an inherent lack of understanding of what I wrote, much less what I was trying to convey both here as well as in that post.
But to respectfully prove the truth of what I said before (and to clarify a few things I might have missed in my longer post) to those who are reading this and still fuming that I would be so audacious as to state that "ECS is the way to program games", I will address all your points (as promised) -- and I will (visually) describe a concrete workflow that corresponds to my claims here -- so just bear with me, yeah?


Regarding ECS vs OOP commentary:

While you're correct that vanilla ECS decouples "self-contained units" on one level -- that does not automatically mean those "self-contained units" cannot be re-coupled later -- using a slightly different method than simply coupling "data."

Enter the "Tag" Component.

While we already have a "Component" concept in Unity's ECS implementation, I will refer to this existing "style" of a "Component" as a "Data" Component -- but I want to introduce a new "style" of a "Component" whose purpose is not to handle "Data" -- but instead to funnel the "scope" of the entity itself, which is useful when a System requires a very particular scope. This scope is defined via creatively "Tagging" the Entity in a specific way.

In other words, the ECS "Component" I already use for 'tagging' my ultra-generic objects (or, when put another way -- my ultra-generic "self-contained units") is already used to establish behavior in a "System", which, to some extent, already allows "Data" Components to have "Tags" that double as a method to "encapsulate" these "self-contained units" (or objects) you speak of. However, dedicated "Tag" Components can be arranged in memory to reduce the need for performance-critical queries to call for data when all you really need to know is the scope of an object while calling for a particular behavior in a System (i.e. all Animals that are Bears). Even in C#, one must have "instances" of objects -- but with ECS, you're removing that need entirely with entities, and working on all (or even specific) objects at once. All you need to do is to be able to "Tag" entities that meet particular conditions at-will (i.e. all Animals who have a "Data" Component tagged as "Age" which has an Int that is over 18 gets tagged as Adults) -- and let the System do the rest. If there is only one entity who "Ages" (say, the player), then that System only applies to the player while he has, perhaps, an Aging "Tag" Component.
However, ECS allows for one extra 'trick' traditional "encapsulation" doesn't have -- you can "de-couple" and "re-couple" your "self-contained units" AT WILL.
A strongly-typed encapsulation would never allow this (so you're forced to jump through MAJOR fiery hoops to get this 'complex' behavior -- but ECS + OOP-style encapsulation allows this through the "Tag" Component by default.
A slightly modified "Component" implementation (i.e. a "Tag" Component whose "tags" are not tied to "data") allows for on-the-fly "de-coupling" and "re-coupling" of your data -- with next to ZERO impact on performance, if implemented properly.
In other words -- a temporary coupling/decoupling of behavior (i.e. a "giant" enemy that "flies" that can be decoupled to be regular-sized and/or unable to fly) -- leads to some amazing possibilities, which are ideal for programming some extremely complex games (think BaBa is You or Super Mario Maker). These kinds of games are really popular -- and for good reason. They're currently hard as hell to make -- and that is ALL due to syntax-heavy garbage, not the logic of the game itself -- which is usually pretty damn simple.

For example, in ECS (with a "Tag" Component concept), just remove the "Flight" tag to have a player who can't fly. Yes. It really IS that simple.


But to respond to your actual comments, "Encapsulation isn't really an aspect of ECS workflows" + "as they are generally-understood now." would actually make that (at least partially) a true statement.
However, I am a person of the general population, and as such, I "understand" ECS a little differently -- and as such, I have been able to devise a workflow that enables (useful!) Encapsulation behavior in ECS with a slight modification to how the "Component" concept, as it is implemented in Unity, is currently understood, and have therefore requested a different implementation which makes ECS work a HELL of a lot better for the end-goal programming games more easily -- and all because of that slight shifting of a concept to a slightly new understanding, which makes Encapsulation using ECS a hell of a lot nicer/easier/better than the same concept implemented in C# OOP -- by miles.

Besides, you've got to remember, my tweaked ECS "workflow" and your generally-understood ECS "workflow" are both still valid "workflows" for ECS -- but mine is just lots more intuitive and easier to work with, and is built for Visual Scripting at its core. So, yes, my encapsulation workflow is just as "applicable" to being an ECS workflow as yours is.

In ECS, depending on what components you add/remove, you "tag" the entity in a particular way. As explained above, these "tags" allow you to encapsulate into a "self-contained unit" -- but one that can also be _extremely_ dynamic (in contrast to C# OOP, which is "strongly-typed" -- which is just another way of saying "inflexible as HELL for making anything!")
"Tagging" your entity with a modified (dataless) "tag" component allows you to create a hierarchy that can be changed at-will. You are essentially 'marking' your entity for dynamic "behaviors" when you tag it this way. This is because any global System first queries for all entities with a particular set of "tags" on them, and if it finds any, it defines behavior for these entities. This means, a System can query a "Animal" tag, a "Bear" tag, and a "Adult" tag to have an "Adult" Bear do something entirely different than a "Child" Bear, but have all "Animals" -- even Adults and Children -- perform other types of behaviors.
This is "Inheritance" in the broadest sense of the word -- The "scope" of your behavior is inherited from your entity's current "Tag" Component assortment (via the Systems that implement those Tags into actual behaviors.)

And since these "Tags" are dynamic and not "linked" to any particular Entity or System, you can instantly change a "Child" Bear into an "Adult" Bear -- all without having to worry about whether it's a Giraffe or a Human, or even if it's got Claws or not. No other behaviors or tags matter. You simply tag a entity (say all entities with an Age "Tag" Component) which also have an Age "Data" Component (an Int) that is >= 18 (if you want to associate data with a normal "Tag" Component so that, behind the scenes, it just acts like a regular/standard "Data" Component when no data is being explicitly requested) -- Doing this ensures your "Child" entities remove their Child "tag" and 'become' the "Adult" entities at the proper time (just by adding the "Adult" tag at the right time in your script), and no matter what kind of Animal they are, this one change allows them to "Inherit" the behaviors of any "Adult" Animal -- as well as behaviors that are specific to the kind of Animal they already are (i.e. Bear). Again, ECS 'inheritance' is much more flexible and badass than standard C# 'inheritance' -- and ECS, like you said, wasn't even designed for OOP.

And to respond to the technical side of your comments specifically:

Spoiler

(FYI -- since this is really technical, I chose to put it in spoiler tags to save everybody's wrists during scrolling.)

ECS is nothing about "ownership" of data. In fact, Entities inherently try to do the exact opposite -- they want to be as loosely-connected to data as possible (for performance reasons).
The only place data actually _matters_ to an entity is when a System _queries_ the entity for its data payload (during a hidden foreach loop) to change that data -- and even then, only the System cares about the data -- not the entity itself. The entity is just an index -- a dumb ID -- used as a handle for the System to have some memory location to alter. Neither side cares where that memory location is, nor who or what it belongs to -- or even what size it is.
You could literally have "stacks" of dependent entities -- i.e. entity with regular data who also has a (preferably invisible) "Data" Component that literally references a companion entity with "tag" indexes as its data payload (Tags that might exist in a Tag "Database" as particular binary indexes of a database of a particular size -- i.e. the size of the Tag Database in bytes). This allows for freeform scope _and_ data -- and you can make it as "readable" as your game's logic (and the scripting interface) dictates. The only performance impact is at the moment you increase the size of the Tag Database -- which, ideally, would be when loading or (more commonly) when applying a patch to the binary.

If you've read what I've written above, you should already understand that "tagged" (dataless) entities are the method in which encapsulation is handled, which, in an unexpected way, prevents the need to have explicit inheritance as well. This also has the added benefit of greatly reducing the need to "abstract away" everything, which is mostly done for readability / understandability of complex code.

That being said, in some cases, abstraction is still necessary in ECS (+OOP), but it still happens on the logic layer.


In fact, contrary to the (clearly) popular belief:

code-syntax != script logic

ECS (w/OOP) dominates C# OOP (as well as many other languages that claim to be OOP) because its "abstraction" is done in its "encapsulation" phase via the logic one uses to write the script logic itself.
Two steps -- for the price of one.

Abstraction is essentially a moot point in ECS in most cases, as it is already taken care of for you when you design your high-level game logic.
Abstraction in ECS (with an implementation of dataless "Tag" components of course) relies on how abstract your logic is -- and therefore, if you only need to know its an Animal, the type of Animal, and the Age of those animals to define your gameplay, your abstraction is --done-- right there, via inheritance. You can further define your behavior for the different "tag" combinations (i.e. by masking certain tags during the component Query), but it is not necessary (or really even possible) to break down your base script logic further, as script logic is the essence of script behavior -- there is nothing further to break your code down to. There are no "higher-level" concepts to jump back and forth from other than the exact concepts you are trying to model with your ECS "Tag" Component + System Script logic flow.

Again -- see above. Particularly the bit before "BaBa is You" and "Super Mario Maker".

This bit explains how ECS can implement Polymorphism in the finest -- and most flexible -- way possible. This, again, requires a slight modification in how ECS tagging is implemented (i.e. an extra Component type outside of just a "data" component, which was originally envisioned in ECS.) Again, a dataless "Tag" component takes that "Component" system a HUGE step forward for games, as you gain the extremely important ability to (very easily) change the entire behavior of entire gameobjects -- in real-time.

And games are real-time.

You don't need complex chains of inheritance and instancing and variables and arguments to do this like you do with C# OOP -- You simply need a set of "tag" components that encapsulate "a self-contained unit" -- and then change that "unit" to anything else you want. For example, you want to turn a Bear into a Giraffe? -- Sure, remove the Bear "tag" and add the Giraffe "tag" instead. It will now act as a Giraffe, as any System that implements Giraffe behaviors will now see it.
Maybe Giraffes don't have a Claws "tag" -- so if there's any entity with a Giraffe "tag" but has any "tag" other than the ones you say are okay for Giraffes (perhaps you make a "tag" mask -- i.e. " x -> Alive -> Animal -> Giraffe -> Age -> x ), then a System can remove all tags after "Giraffe -> Age" and before "Alive -> Animal", meaning that anything after the Age (which should be in that farthest-most component slot) or before whether the Animal is Alive/Dead (which should be in the first-most component slot) would be "chopped off" -- letting you preserve other "masked" components (i.e. if the Animal has a "status" tag such as Status -> Eating, you'd add a mask like " x -> Animal -> ** -> Status -> ** -> x " (to ensure any tags marked * or ** aren't removed when removing all other tags with x). Perhaps a Bear has a special component _after_ their Status -- i.e. Claws (which determine whether the Animal has claws or not) -- and as such, you can simply search for any Animals with Claws in your System (without any need for a mask) and let the System create an attack collision-box or whatever when an "Attacking" tag is present on the entity (and then simply remove the collision box via another global "AttackHandler" System when the Attacking tag no longer exists).

As you can (hopefully) see now -- there is plenty of the "Polymorphism" happening with ECS -- but in realtime -- when ECS is both implemented (and used) in this way.



In Conclusion:

As you can (hopefully) see by now, with the right approach, this statement is only true when considering the "commonly-understood" approach to ECS, which is rooted in increasing computing power -- not designing games.

However, can't these two concepts co-exist?

ECS only needs a small (extremely small) tweak to its implementation (i.e. adding an additional type of "component" to the "component" style Unity already uses), enabling it to do a TON more than anything Bolt 2 can do -- and it works for beginners as well.

This approach requires less thinking and less planning overall, cleaning up a project that might have driven the author mad.
For example BaBa is You.
This is a great example of where this kind of programming flexibility necessary in the realm of games (and the kind of flexibility that my approach provides btw.)
If you don't believe me, look at the video from GMTookit I link below -- there's an excerpt from the guy who made BaBa is You in the video. Feel free to listen to how he explains how HARD it was to make that last "sticking" feature he really wanted to add. Yet, sadly, this feature ultimately didn't make it into the game because of its difficulty to program in-tandem with the other logic features -- BUT -- ECS (with this "tag" implementation), would have made that feature trivial, saving him TONS of man-hours and tedium (especially in a Visual Scripting tool) -- and would have allowed him to get such a "trivial" feature into the game as well. How? -- Because his neat/fun game was dealing heavily in logic, not code syntax or invented/contrived scripting concepts / semantics or lingo -- as @neoshaman puts it.

In fact, @neoshaman puts it really well here:

Using the ECS(+OOP) approach I describe above, the "lingo" or "semantics" he describes is distilled down to being pure "logic" -- and the "syntax" becomes how that "logic" is strung together into actual usable concepts rather than into simple (heavily-abstracted) semantics with no inherent value.
In other words -- instead of saying "When deriving from blah blah and blah object structures, I can do this, but I need to derive from this other blah (or override it with blah) if I want to do this other thing, so I just use blah method to handle this restructuring of my data's 'behavior' for me. Easy as pie, right??", you can say "When I am tagged as an Animal, with Claws, I do a certain thing when the Attack button is pressed, but when I am just an Animal, I do something else."
I don't know about you, but this infinitely superior "syntax" and "logic" (sans semantics) works a little better to me.

This problem is increased tenfold when you get into the realm of Visual Scripting (especially with the "snippet-based" nodes Unity is trying to implement) because tracking down "logic" in an OCEAN of "syntax" (and worse -- semantics) gets more and more tedious with all the physical clicking/dragging/scrolling you'll have to do to inspect the flow of your semantic-laden "logic" with something like Bolt (and even Bolt 2 -- because, after all 1:1 with code means you still have its downsides too -- mainly being that "complexity" / "spaghetti-code" thing I discuss heavily in my topic.)

But, the slightly modified ECS implementation (and approach) I described avoids semantics entirely, as the problem is _always_ in the logic. Since the way tags are strung together and evaluated (i.e. via queries for a particular set of tags), one defines both the concepts and the understanding simultaneously, meaning your chances at misdirection are minimal -- You evaluate your own thinking, and you've solved your "bug" -- even without a fancy syntax highlighter.
Even we ("dumb" artists/designers) can do that. No chance to 'finger-fudge' your variables or class names or other nonsense -- pick the right tags, mask them properly for searching, perhaps with a mask (predefined in the editor, which can be indexed rather than evaluated at runtime, thus increasing performance), then just go and make a game.


In Summary (of everything said above):

Remember -- Bolt 2, as nice as it appears on the surface, is still not immune to spaghetti-code.
For example, just imagine what BaBa is You or (gasp!) a Super Mario Maker project would look like in Bolt 2.

But hey -- if people want games with really clear logic (like the one linked above) to keep being extremely hard to make -- please, ignore this post.

BUT -- if you really want something easy-to-use (that avoids the pitfalls of code, while also being extremely performant and extremely easy to understand -- and write), then take the time to read my post and understand all the possibilities my approach implies.

(More to come on that later! -- Stay tuned!)

 

Baba was made in Clickteam Fusion, and was released pre-child events, so I imagine it already looks like a complete mess.

Also, I think you might need to get someone to edit your posts for readability

 

Probably -- Anyone want to volunteer?

 

Unless written by a professional -- it would probably be a mess to write no matter what engine it was written in.


Either way, that's interesting! -- I thought that was just the gamejam prototype!
I always assumed the final game was written in Unity. (After all, everything else is these days! -- so why not?)

Thankfully, it still serves its purpose as a low-end "indie" example game to sit alongside a high-end "AAA" game (Super Mario Maker) in terms of illustrating the contrast in scalability of a logic-based ruleset for gameplay.

While it's still relatively simple (and perfectly doable via existing code methods) -- it's also deceptively complex to scale.
Super Mario Maker would be the equivalent of what this would become (on the backend) if you scaled its design.
The architecture would have to already be in place, but even then, that architecture would still mimic (on some level) the ECS(+OOP) architecture I've described above -- just a lot more complicated (and unnecessary) as you change things around later.

 

Also -- I was told this exact same thing.

It definitely made me question my decision to support Unity as much as I do, as I had hoped it was just that one guy who had no imagination... but now I'm starting to get concerned... D:

 

Except you did... Your words, not mine: "including how it is better at "Object Oriented Programming" (OOP) than any other language in existence today!".

Anyways, I fundamentally don't agree with your stance that ECS is better at OOP. What you're describing is data oriented programming (DOP), not OOP. I'm not claiming that your workflow is bad or that it can't work well, it may very well work, but if there is one things I've learned is that proof is in the results, and so far all you've done is describe your ECS and claim it's better at OOP, not shown us results of using your ECS.

To avoid derailing this thread even further I'm going to refrain from continuing this line of conversation however as the real focus should be on Bolt 2 and visual scripting rather than OOP and ECS's.

 

What exactly are high-level nodes in comparison to what Bolt does? I've never found Bolt to be difficult to understand and I don't write code but I can read it, so I can understand it may be hard for some people to understand how to structure things.

 

Bolt 1/2 have very little nodes unique to the asset. Most Bolt nodes are grabbed directly from Unity's API via reflection, so generally Bolt is low level where one node is a public or static method or a property. Let’s take Transform component, for example. If you look at Property and Public/Static Method lists, each of those entries ends up being automatically generated as a Bolt node. And you search for them using the same syntax - the first property "childCount” can be found in Bolt by searching for “transform childCount”. So working in Bolt and working in C# is actually pretty similar. And you can combine these low level nodes into superunits, which then become high level nodes. Basically, a low level node is typically a single, very specific instruction, while a high level node is a series of instructions.

A high level node as Unity describes in the announcement is a node that is directly implemented in C# and can contain any number of code lines. It could be 20 lines of code or it could 500. Basically, the Playmaker approach. A node is a black box and obscures the complexity underneath it to the end user while offering functionality that’s not possible with a single low level node. For example, a high level node could contain the implementation of a basic character controller with configurable options on the node itself and it would be aptly named "Character Controller Node" or something like that. So all you have to do to make your character move is drop this node inside the graph and configure it.

The benefit is that anyone can use high level nodes without learning Unity's API. There are also performance benefits, it's C# after all. The downside of the high level only approach is that eventually you run into limitations - you have some problem that is not covered by an existing high level node so you either need a programmer code one for you, code one yourself or you need access to low level API via automatically generated nodes Bolt does now. The announcement mentions we'll have both though.

 

High level nodes aren't necessary about how it is easy to understand scripting (in my opinion It's the exact opposite). High level nodes are about making the same stuff but times and times faster (in case of blueprints, overhead and general slowness comes from the amount of connections, so the less low level nodes the better).

I have already mentioned in that previous post, there are two nodes for a basic character controller which isn't true, I don't work on ue4 anymore so that's a stupid mistake. CC has a bit over 10 nodes. However, If you look at the picture below, you can just see how big and feature packed it is even though It offers only wasda movement and jump (this is only small part of it).


.

Node on the left, apply radial damage. Self explanatory what It does.



Event which exist by default in blueprints



From what I have heard , user can send up to 3 pictures in one post. I'm not going to make several posts in this thread, that is pointless but I also remember few more nice nodes:

- Cast to, very basic node, as the description goes "attempt to check if the object you are casting from is the specific object you casted to."
- you can create a sort of "scriptable object" without opening a visual studio and immediately iterate with blueprints. The possibilities with it are much smaller but still a great feature.
- there is a possibility to write nodes in python, they are supposed to be used to connect other tools with ue4.
- a lot of high level raycast nodes, for example one which casts ray and on hit instantiates collider, the node outputs all items found in an array.
- Nodes for stuff unity is still working on, for example VR and networking. Unity will probably add their own solutions in the future but no one really knows exactly when.
- Many basic nodes which, as far as I remember, don't exist in flowcanvas (I never used Bolt 1 because I never needed it), loading and unloading subscenes, freezing player movement, doing stuff with cameras like switching and blending, disabling character rotation, turning on cursor, all require an event and one node.
- There is a whole AI behaviour system in blueprints, unity is working on something like this but we have to see If It's good or like with ue4, mostly for prototyping (because performance sucks too much).


And again, the blueprint system does have many flaws I have pointed out earlier. I just hope Unity will do some proper R&D and will fix all of them. For now it looks like they are pointlessly trying to copy-paste the solution epic made. Unity needs some sort of product value If they want to compete but also have something good ready in 2021, bolt 2, while with many significant flaws, at least clearly had some idea for product value.

 

That's exactly where I am right now. I have the prototype working well in Bolt but it's slow, the editor is struggling to keep up and my framerates are plummeting.

I was looking forward to Bolt 2 so it could translate all of my flows to C# since I'm not a coder. I can script a bit, so I figure I could fix the problems that would arise but I have no idea how to manually translate the whole thing.

This is a huge setback for me.

 

Since I'm in a middle of a massive migraine and I can't function normally, I did some benchmarks of my own to compare C# with Bolt 1, Bolt 2 and Flow Canvas.

• 100 rotating cube test C# vs Bolt1 vs Bolt 2 vs Flow Canvas
• Built In Renderer
• i7 6700k, 16GB RAM, RTX2060
• Unity 2019.4.8

Measurements taken in the Editor. Performance in Builds is better.

PlayerLoop:
C# - 0.60ms
Bolt 2 C# gen - 0.60ms
Flow Canvas - 1ms
Bolt 1 - 3.50ms

Update():
C# - 0.08ms
Bolt 2 C# gen - 0.10ms
Flow Canvas - 0.30ms
Bolt 1 - 2.50ms

So Bolt 1 isn't as bad as I thought it was based on the image I posted earlier. That 100 rotating cube image was posted by Ludiq a year or two ago.

 

It still has a much lower performance ... (That's why the C # generator request is so strong by the community) and this is something that makes me think about how it will work in DOTS, because all the 20% to 50% performance gain that DOTS can provide will be taken down the drain by Unity Visual Script ...

or not, thanks to the burts compiler, but this is something that can only be tested in practice

 

If I remember correctly, the burst converts the created code into a low-level machine code more optimized for the target platform.

This means that any code created or generated by the unity visual script will be exactly the same (or at least similar) in terms of performance, because at low level, both would have the same structure.

Of course, this is an assumption, I don't understand much about the structure of DOTS, but it seems too good if it is true.

 

Was not supporting Bolt 1 on Unity 2020 part of the plan? You announce the official launch of 2020 and the acquisition of Bolt almost in the same post but forget to check if it works? This is just plain incompetence! The original developer (one-man army) would fix Bolt bugs this critical within days but Unity with its manpower can't? Let me be skeptical about what comes next from this particular team.

 

Bolt 1 is compatible with both 2020 and 2019

 

2020.1 compatible update is not out yet. There are issues, especially on Mac. Like this one: https://issuetracker.unity3d.com/is...-appearing-inside-the-bold-macro-graph-window It is fixed but not released yet.

Latest 2019.4.8 works fine on my end, though.

 

No, unfortunately it is not working on MacOS since 2020.0 and many people are having the same bug on Windows. It worked fine until 2019.