Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only. On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live. Read our full announcement for more information and let us know if you have any questions.

Official Visual scripting roadmap update - August 2020

Discussion in 'Visual Scripting' started by LaurentGibert, Aug 14, 2020.

Thread Status:
Not open for further replies.
  1. Szaruga

    Szaruga

    Joined:
    Jan 29, 2016
    Posts:
    403
    Sufficient as a complete comment. --->
    unknown.png
     
  2. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    1,236
    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."
     
  3. Szaruga

    Szaruga

    Joined:
    Jan 29, 2016
    Posts:
    403
    So Unity chose poor quality but good looks. Sign of 21st century - (Mainstream curse).
     
  4. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    1,236
    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"
     
    Mark_01, Favorlock and Lars-Steenhoff like this.
  5. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    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.
     
    Last edited: Aug 18, 2020
  6. MostHated

    MostHated

    Joined:
    Nov 29, 2015
    Posts:
    1,236
    Understood as well as agreed.
     
  7. Szaruga

    Szaruga

    Joined:
    Jan 29, 2016
    Posts:
    403
    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.
     
    Mark_01, Favorlock and MostHated like this.
  8. moyashiking

    moyashiking

    Joined:
    Jul 10, 2018
    Posts:
    35
    Bolt1 --> Integration with Unity's core functionality
    Bolt2 --> Continue development regardless of integration

    Please do this!
    This is better if Bolt 2 is destroyed.
     
    Stexe and Favorlock like this.
  9. steve_zeng

    steve_zeng

    Joined:
    Aug 6, 2019
    Posts:
    22
    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.
     
    Stexe, bugfinders and Favorlock like this.
  10. steve_zeng

    steve_zeng

    Joined:
    Aug 6, 2019
    Posts:
    22
    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.
     
    Favorlock and Thomas-Pasieka like this.
  11. steve_zeng

    steve_zeng

    Joined:
    Aug 6, 2019
    Posts:
    22
    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?
     
    Favorlock and Thomas-Pasieka like this.
  12. bngames

    bngames

    Joined:
    Jul 3, 2012
    Posts:
    67
    "providing snippet based nodes." - Do you mean like PlayMaker?
     
    Lars-Steenhoff likes this.
  13. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,568
    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
     
    Last edited: Aug 18, 2020
    Neonage, Stexe, Mark_01 and 10 others like this.
  14. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,568
    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!
     
    Mark_01, OCASM, vx4 and 4 others like this.
  15. Pytchoun

    Pytchoun

    Joined:
    Apr 12, 2015
    Posts:
    203
    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.
     
    Favorlock and useraccount1 like this.
  16. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    I don’t think Unreal has been made by one person since 1998
     
    vx4, Lab618 and Favorlock like this.
  17. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    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).
     
    awesomedata likes this.
  18. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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:
     
  19. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    Ahh, thanks, that's surely what was meant :D
     
    Favorlock and awesomedata like this.
  20. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,371
    @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
     
    Ryiah, Thimo_, sacb0y and 14 others like this.
  21. AdrianoDeRegino

    AdrianoDeRegino

    Joined:
    Aug 10, 2019
    Posts:
    87
    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,...
     
    Mark_01, Favorlock and Lars-Steenhoff like this.
  22. L82093

    L82093

    Joined:
    Jul 1, 2019
    Posts:
    26
    I could not have said it any better. Totally agree. I feel like this would be the best approach and make the most sense.
     
    Mark_01, Favorlock and Lars-Steenhoff like this.
  23. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,568
    Completly agree, and yes please keep the bolt 2 frontend UI, it looks mature and has nice icons that are made for it.
     
  24. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    @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.
     
    Favorlock likes this.
  25. Favorlock

    Favorlock

    Joined:
    Dec 15, 2016
    Posts:
    13
    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.
     
  26. Zebbi

    Zebbi

    Joined:
    Jan 17, 2017
    Posts:
    521
    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.
     
    Tanner555 and Favorlock like this.
  27. Coroknight

    Coroknight

    Joined:
    Jul 10, 2012
    Posts:
    26
    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.
     
    Stexe, TextusGames, Favorlock and 4 others like this.
  28. UnrealFear

    UnrealFear

    Joined:
    Mar 17, 2018
    Posts:
    4
    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.
     
    Favorlock likes this.
  29. AdrianoDeRegino

    AdrianoDeRegino

    Joined:
    Aug 10, 2019
    Posts:
    87
    Ludiq would, maybe, be interested in finishing it.
     
  30. parrotsgame

    parrotsgame

    Joined:
    Apr 9, 2018
    Posts:
    6
    @LaurentGibert i hope the silence is for you regrouping the team and doing the right thing to announce soon, and not due to ignorance.
     
    Favorlock likes this.
  31. BetaMark

    BetaMark

    Joined:
    Sep 27, 2014
    Posts:
    229
    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!
     
  32. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
    Favorlock likes this.
  33. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,282
    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.
     
    Stexe, zfh2773 and Favorlock like this.
  34. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
    Last edited: Aug 18, 2020
    needyme, OCASM, JesOb and 1 other person like this.
  35. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    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.
     
    Last edited: Aug 19, 2020
    PutridEx, SenseEater, Mark_01 and 5 others like this.
  36. Favorlock

    Favorlock

    Joined:
    Dec 15, 2016
    Posts:
    13
    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.
     
    joshcamas and useraccount1 like this.
  37. FernandoMK

    FernandoMK

    Joined:
    Feb 21, 2017
    Posts:
    178
    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
     
    moyashiking likes this.
  38. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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. :/
     
  39. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
  40. AdrianoDeRegino

    AdrianoDeRegino

    Joined:
    Aug 10, 2019
    Posts:
    87
    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",...
     
  41. useraccount1

    useraccount1

    Joined:
    Mar 31, 2018
    Posts:
    278
    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.
     
    Mark_01 and TextusGames like this.
  42. Favorlock

    Favorlock

    Joined:
    Dec 15, 2016
    Posts:
    13
    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.
     
    bugfinders, Mark_01, Stexe and 4 others like this.
  43. CrazeDevelopment

    CrazeDevelopment

    Joined:
    Nov 26, 2010
    Posts:
    22
    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.
     
    Last edited: Aug 19, 2020
  44. joshcamas

    joshcamas

    Joined:
    Jun 16, 2017
    Posts:
    1,282
    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?
     
    Last edited: Aug 19, 2020
  45. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,111
    Overwatch
     
  46. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
    Last edited: Aug 19, 2020
    JesOb likes this.
  47. neoshaman

    neoshaman

    Joined:
    Feb 11, 2011
    Posts:
    6,493
    @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.
     
  48. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,419
    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.
     
    Last edited: Aug 19, 2020
    Mark_01 and JesOb like this.
  49. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    1,012
    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?
     
    Favorlock likes this.
  50. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    173
    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
     
Thread Status:
Not open for further replies.