Search Unity

  1. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  2. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  3. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Unity Visual scripting roadmap update - September 2020

Discussion in 'Visual Scripting' started by LaurentGibert, Sep 28, 2020.

  1. landonth

    landonth

    Joined:
    Dec 3, 2018
    Posts:
    92
    @Stexe and @awesomedata I don't want to get too meta here but I just want to say I am impressed by both of your ability to have a constructive and respectful discourse. You both have valuable points, and it's a great example of people on the forum being aware of the limitations of a text forum (lack of speech tone) and be open to honest criticism, hear each other out, and respond in kind. :)

    Perhaps I will see you on the Unity or Bolt discord chat, as well. Take care!
     
    Kennth, Mark_01, awesomedata and 5 others like this.
  2. davincilab

    davincilab

    Joined:
    Aug 8, 2017
    Posts:
    14
    I am doubting if this is the right mindset to drive this project. Right now the product is going through a lot of changes and decisions, The consensus of what I have heard from users, everyone is looking for a great tool better than Bolt 1 and I don't think they will be so much disappointed at this point if Unity announces it is not going to be backward compatible. I also don't think there will be a huge backlash for that sort of a compromise while getting introduced to a new better Bolt (at least for the first time).

    Again, my thoughts are only based on my personal opinion and what I have heard from these forums, I haven't been in other places of discussion. I could probably be wrong.

    I really wonder if it is so important to give so much importance to the backward compatibility and compromise on things that could potentially make a great product.
     
    awesomedata likes this.
  3. L82093

    L82093

    Joined:
    Jul 1, 2019
    Posts:
    20
    I agree 100% and was thinking the exact same thing. Couldn't have said it better myself.
     
    bugfinders and landonth like this.
  4. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    Yeah, I agree that I think it is the wrong decision. I'd rather have something advanced and robust enough to ship entire games with like UE's Blueprints than something to just learn programming with compatibility for existing work. Instead of focusing on production capability that can work to introduce people to programming and be used by programmers alike, it seems they are focused on just making it a stepping stone and having a lot of pre-created things for people to use. Overall though, it seems like a poor decision, but at least I can understand where Unity is coming from -- even if I and most people here don't seem to agree with the direction.

    Doubt anything people here say or do at this point will change their path though. I'm just hoping to get a refund and/or what was left of Bolt 2 at this point, since I only bought Bolt 1 for Bolt 2.
     
    davincilab likes this.
  5. Coroknight

    Coroknight

    Joined:
    Jul 10, 2012
    Posts:
    26
    I was at least hoping for a plan to get from Bolt 1 to Bolt 2. Honestly pretty disappointed with the visual scripting story so far. Seems a bit tone-deaf if I'm being brutally honest.
     
  6. SonicBloomEric

    SonicBloomEric

    Joined:
    Sep 11, 2014
    Posts:
    892
    @LaurentGibert I have a rather specific request. Our asset's (Koreographer) integration with Bolt is currently restricted by the fact that Bolt does not have first-class support for Delegate callbacks. This was something that Ludiq added a task for and even seems to have completed in Bolt 2 Alpha 4.

    I understand that the current plan is to scrap Bolt 2 and continue improving Bolt 1 instead. Are there plans to backport the Delegate support work into Bolt 1? Do you have an ETA?


    Edit: I understand that it is possible to write our own custom Event units. However, there is zero documentation on the internal Bolt API and I fear touching it as I have no idea what you plan on doing with the codebase.

    The best we have to go on for building our own custom units are a few uncommented or no longer functional forum posts (which will also disappear once Ludiq takes down their Bolt forums) or videos. Given the lack of documentation, inaccessibility of the current Bolt development team, and zero clue as to what changes are coming, we're feeling... a bit lost on how to properly support this.
     
    Last edited: Oct 29, 2020
    Mark_01, banan1234, Stexe and 3 others like this.
  7. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,289
    Or really ANY truly "class-like" behaviors/structures that can be translated into performant code?


    No offense to the developers, but if I'm being brutally honest, this whole visual-scripting thing seems like a slowly raging garbage-fire that has only just begun to catch on.
    The more I think about it, the more I think the whole idea of dropping DOTS VS and ECS-like systems in favor of sh*tty Bolt 1 nodes/structure (in lieu of a class-like structure -- i.e. for data) is a TERRIBLE idea -- with loads of terrible consequences for the end-user --
    -- like the above concerns with C# code structure and/or other lower-level system requirements.
    To half-ass the transition to future technology because someone is scared of losing "backwards-compatibility" only to clearly cause "backwards compatibility" issues with actual C# code -- the thing that people actually CARE ABOUT -- is just hard to believe. Logically, "Bolt 1" == "backwards compatibility w/C# code" simply isn't true, and just seems like a totally moronic idea / notion altogether.
    So, I'm wondering where "backwards compatibility" really "fits in" with anything at all.


    Sorry -- but can anyone @Unity speak to my concerns on this? -- I'm really not buying the "backwards compatibility" bit. :/
     
    Last edited: Oct 30, 2020
    TextusGames and toomasio like this.
  8. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    Backward compatibility is a big plus for me and my team... Having designers being able to work with Bolt right now in long term projects without being afraid of needing to re-do everything again in 1 year was a requirement to add it to the project.

    If Unity was going into Bolt 2 direction (or exclusively focus on DOTS-VS) then we would need to wait a couple of years until we have an officially supported VS tool, so yeah, I am one of the few who are happy with that decision.
     
    Kennth, Mark_01, TextusGames and 3 others like this.
  9. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,289
    That's a fair point. I get you.
    While it is nice to be able to work with Bolt 1 now and expect better (future) performance (also in a couple of years -- whenever DOTS is considered 'ready'), is it really worth the cost of ALL future Unity projects being forced to accept the same (extremely limited) structural and performance weaknesses as the base foundation of the way we develop games? Is it worth sacrificing the potential of all future scripting technologies in Unity?

    For me, this is a clear hell no.

    This short-sighted mindset is scary -- and the fact that people don't see this (or just don't care?) is beyond me. For such small short-term gains (at the price of extremely long-term pains), it just seems like a selfish and/or simple-minded move to me. :(


    I'm really not convinced this move is practical enough for full-scale (i.e. AAA) projects. Bolt 1 simply doesn't scale well (in a performant way at least), and supporting C# constructs would be better-served on a bedrock of something more like Bolt 2 -- which would make C# things (i.e. like delegates, editor-scripting, Jobified code, etc.) easier to construct.
    And while I think Bolt 1 is great to have for now (for "backwards compatibility" with Monobehaviour-based workflows), Unity themselves aren't even using Bolt in their own open projects, so I'm not even confident that "just for now" attitude is really all that justified, especially when considering performance, stability, and scalability are all still considered "future cases" (especially when the very foundation of the design still needs to be determined, and there is no clear way to combine Bolt 1 and Bolt 2's structure without a lower-level approach). Judging Unity on their past performance in delivering on their performance promises, if you really want something functional "right now" as many say they do, Bolt 1 isn't it.
    The timeframe before true performance boost in Bolt 1 versus just buying something like Node/Flow Canvas off the Asset Store that already works well is kind of a no-brainer. :(
    As I currently understand it, if they are still going to have Bolt 1 nodes co-exist alongside DOTS VS nodes later, it could probably still work (with some messed-up UX/UI limitations if you want to get lower-level with those nodes and script based on scheduling node execution based around timings of CPU cycles / Frames like AAA developers tend to do), I think the overall flow and/or process is going to be a mess in the UI and UX department if trying to base something like this off of Bolt 1 and trying to fit in DOTS VS and lower-level CPU "Job" execution later on.

    Anyone @Unity care to chime in? -- I would really like some clarification here.
     
    Last edited: Oct 30, 2020
    Kennth and stuksgens like this.
  10. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    You are assuming that Bolt will never be in the future as good as Bolt 2 promised to be, which is something that you can't prove in any way and that the Unity staff already stated the opposite (not that it will be the same but that it will be improved with many ideas being migrated from bolt 2 - and possibly other new ideas).

    The price is not "extremely long-term pain". Actually, it is pretty much the opposite, as it allows us to use Bolt right now and receive basically free performance boost in the long-term.

    Between a tool that can't even generate a build (Bolt 2 was only "working" inside the editor in the latest alpha), a tool working on top of an unfinished preview technology (DOTS VS) and a tool that is proven to work with a full supported workflow (even if it has its own downsides like the performance you pointed out), I would take many times more the last choice. ;)

    About performance, currently Bolt is totally ok to be used as a total replacement for coding with smaller games, and for bigger games it is also totally ok to be used if most of the core logic is done in C# and leave just the high level part for the designer (be it by coding the critical paths in C# and exposing as nodes or by having the designer use it only to do the final polishment in the game).

    All that performance criticism being made is on top of "but what if I wanted to make a full game with VS without performance limitations?". Well, guess what, you can't do that with DOTS-VS right now either as it is missing many feature, and neither you could with Bolt 2 as we were not being able to generate a player build out of it. So why is that a downside of Bolt 1 and not for the other options? Meanwhile, Bolt 1 is stable, has access to the existing Unity stable features and also has close to no cost of integration with the majority of the asset store. Better performance will come with time.

    About using other VS solutions like Playmaker, FlowCanvas, GameCreator... well, you can go ahead and do that, it will most likely be the best option to create a medium-size or even big-size project right now using only VS and no one will be stopping you.
     
    Last edited: Oct 30, 2020
    Ofx360, Kennth, Mark_01 and 1 other person like this.
  11. Oxeren

    Oxeren

    Joined:
    Aug 14, 2013
    Posts:
    95
    Just wanted to chime in with a little point. People in these threads sometimes say something like "most people are unhappy with Unity's approach to Bolt" or think Unity ignores community's opinions on that matter, but keep in mind that most people here are those who were explicitly waiting for Bolt 2. And while I totally understand their unhappiness and frustration, this is only a fraction of the community with very specific expectations, and opinions and expectations of the community as a whole are not necessarily the same.
     
    Pecek, landonth, Stexe and 5 others like this.
  12. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    That's not my impression. They're improving just about every aspect of Bolt 1 going forward. And they've mentioned things like interfaces which are very much C# and Blueprint like. The data consolidation they talk about should better tie object scope variables to graphs and while they might not be classes in essence, it'll largely achieve the same results if I understand it correctly.

    While Bolt 2 was great for my needs, I can recognize that it wouldn't be a good fit for larger studios. And Unity's audience is not just indies and educators. Arguably, supporting AAA workflows is more important for Unity as a company. And there was also the issue of Bolt 2's front end and backend tech being incompatible with other Unity graph based tools. But they've made a great effort to communicate both here and on Discord. And they've listened and addressed most of our feedback.

    As someone who's worked with Bolt 1 for three years, tested every Bolt 2 alpha version, reported and documented more than a 100 bugs for both versions of the asset, I think that Unity's decision making overall is solid. Consolidating most Unity's graph based tools into a single tool with the same UI/UX paradigms makes sense. Not doing C# gen the way Bolt 2 did it also makes sense, especially seeing how unstable and error prone it still was after two years of development.

    So I don't see how Unity are making Bolt a stepping stone with pre-created high-level nodes. They're adding them, sure. But it's not at the cost of low level scripting, which will still be present as it is today. They're replacing Bolt 1 runtime so it'll be much faster (by an order of magnitude if I recall correctly) and they're fixing variables, events systems, fixing editor performance and common quality of life issues. C# gen was never the killer feature of Bolt 2 for me since the C# it output was still very much Bolt 2 dependent and wouldn't work independently. I cared about performance improvement and that is still being done. Not to the same degree, but I hope it'll be good enough. Bolt 1 is very much usable for many game types right now, even with its rather high performance cost.
     
    Last edited: Oct 30, 2020
    JoNax97 likes this.
  13. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    2,977
    Good point
    Good points, one question comes up:
    I'm pretty sure that bold 1 also is not compatible with the graph backend?
     
  14. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,289
    The basic structural foundation of the Bolt 2 project's UI and functional layout is all the proof I need that the tool had the beginnings of a strong foundational design structure that could uphold a project of any scope or size. The same is not true about Bolt 1's design foundation. Sure it was flexible, but that flexibility had an engineering cost for the level of "abstraction" it touted. The fundamental logic was still heavily-influenced by C#'s structural requirements, which caused a big issue with the ECS methodology -- again, this is foundational-level design. Compared to the design of Bolt 2 or DOTS VS, there was no contest.
    This type of structural design was gone over extensively in my Data-Oriented Visual Scripting -- The Structure of a Language thread (not in regards to Bolt 2 being "better" than Bolt 1, but in what makes a Visual Scripting tool's structure -- or, in other words, language -- fundamentally "better" to begin with -- and this is not just "theory" either, as these methods have been put to use elsewhere -- including AAA titles).

    Feel free to cherry-pick and argue with my points, but if you know anything about basic design -- affordance is key. And Bolt's original design is way too random to provide the visual affordances that serious systems actually require.

    And going a bit further...

    Common-sense should be enough to tell you that while you CAN (metaphorically) simply weld a flathead at a right-angle to a phillips-head screwdriver and get some semblance of the functionality of both tools (which is what it sounds like Unity is trying to do with Bolt), it is clearly NOT ergonomic enough to actually use in a real-world situation, since a screwdriver is designed to twist at the handle -- and not at some arbitrary point on the shaft.
    Excuse the pun, but you cannot simply "Bolt" the most important features of Bolt 2 onto the "Bolt 1" design -- it simply will not produce the kind of ergonomic tool you seem to be expecting it will.


    Again -- if you've read my previous points, you should have seen that I was referring to the past timeframes that it took for Unity to promise -- and then to eventually DELIVER -- said promises.
    You are assuming the "Bolt 1" experience of your dreams will actually be delivered.
    However, I have been around long enough to know the timescale between promise and 'delivery' has never been a reasonable experience for the end-user. Teams often change midway through the process, and the whole project itself tends to change scope and devolve, and then everything gets scrapped. Then a new project is started that has an entirely different scope (just like what happened with Bolt 2 being scrapped and DOTS VS getting rolled-up into Bolt 1's terrible design sensibilities). However, this (too) will eventually get abandoned and restarted again. Why? Because Unity really, truly does (deep down) want to deliver a strong user experience -- however, deep down, it also usually lacks the design know-how (and practical experience) to actually be able to do so.

    You clearly haven't been around long enough to know Unity like I do -- but mark my words -- Bolt 1 + DOTS VS isn't the final "design" iteration. Even if it somehow reaches 1.0, there are too many fundamental flaws in it for @Unity to actually be okay with it being "standardized" -- which is what pains me so deeply that Bolt 1 is still the direction Unity is taking this.


    I think I wasn't being clear enough.

    Just to be clear -- I'm not promoting Bolt 2 or DOTS VS over "Bolt 1" in any way.​

    I am only promoting aspects of the DESIGN that these two employed (circa Drop 6 in DOTS VS), and the similarities to DOTS VS employed by Bolt 2's design -- for example: a systems-based approach [i.e. Bolt 2 classes and ECS-style system hubs, which were great in DOTS VS drop 6], or vertical flow, since it promotes the ability to separate subject, verb, and main ideas in its data sentences more easily).


    This kind of defeats the purpose of calling it "Visual" scripting, doesn't it? -- Nobody (and I imagine this also includes you) really wants to fight two completely different ways of coding in larger projects for the unforeseeable future. I'd think that most would rather just code in a text editor than add that level of complexity to their projects -- especially if the entire solution shifts or changes direction (resulting in a hell of a lot of code rewrites). After all -- that kind of "shift" and "change of direction" was exactly what happened with Bolt 2.

    Remember "Bolt 2 is DEFINITELY going to be completed!" when Unity took it over? -- I do. :/

    Sorry -- I just can't have as much faith as you do that your "future performance" is actually going to materialize -- at least in the way you envision it. You will most likely get something functionally-limited and feature-incomplete (i.e. ShaderGraph), rather than some huge performance boost "for free".
    Trust me man -- nothing in this world is "free" -- You pay for it in one way or another -- and oftentimes, what seems "free" is actually at the expense of others. So promoting this is your way of saying "screw you" to others who actually want/need a better solution -- which would still benefit you too -- just not as immediately. But hey -- gotta have that "instant gratification" right?


    Again, by no means am I saying the performance limitations were all that holds Bolt 1 back -- The design of Bolt 1 is simply (foundationally) broken, whereas Bolt 2 and DOTS VS actually had a better foundation for effortlessly building a (performant) game application to scale. Clearly the technology wasn't functional (because it was incomplete) -- but as a whole, UX-wise, (and regardless of what technology was under the hood) -- they were both the better design.

    And when you base your entire technology on an inferior design -- you get to rewrite the whole thing later! :)


    And what does that mean? -- Well, you can't have your design become a universal "standard" yet.
    And what does that matter? -- Actually it matters in a few important ways:
    • First off, "standards" are one thing we have relatively few of in Unity -- and we need them.
    • When you don't have any "standards", then third-party applications (i.e. games / tools) cannot trust your methods/code/workflows to stay relatively unchanged
    • This means that, since there is no "standard" way, everyone does everything in every way
    • While better methods/workflows arise, unless they are widely advertised these aren't "standardized" and are quickly forgotten to other (more loudly-spoken) methods that are often less efficient
      (Think Tesla versus Edison).
    • Without standards, NOTHING is compatible -- or compatibility is very limited
    • Therefore you are stuck writing the same systems and technology over and OVER again -- forever.
    • And until some "standard" finally gains traction -- it never ends.

    This is the problem with @Unity's technology as a whole -- and also happens to be the problem I have with the future of Visual Scripting as it stands right now.



    This is arguable -- I've seen plenty of reports on the forums, etc. saying the exact opposite.
    But I'm not going to push my point on this because -- on paper -- you are right -- IF things stay on the same path they seem to be taking, your path is the ideal one. But as said before -- I've been burned by Unity taking a sharp right-turn when we were sure they were either going straight or maybe just veering to the left a little, so I find it hard to trust what I'm seeing for this reason. Bolt 2 was what it was -- and I'm not as concerned that they're ditching it as I am that they're potentially mandating a workflow standard that is subpar that doesn't work for low-level systems. Until I get some kind of confirmation on what methods/direction they're taking on the low-level approach, I can't be at ease just yet.


    ---


    This is something I agree with -- tentatively.
    As long as the consolidation is toward a system that is both low-enough-level and as flexible as C# and supports the ECS workflow within Unity's own ecosystem (i.e. editor scripting, etc.), I am 1000% okay with this.
    I, however, haven't seen any confirmation of this anywhere. :(


    This is something I'm not so sure about -- Would you be able to elaborate on what you mean by this part?

    As far as I understand it, Bolt 1's version of "low-level" scripting has to do with tons of reflection magic. I might be misinterpreting this, but are you saying that this method will be unchanged and that all low-level scripting will still rely on reflection, etc.?

    Low-level scripting is where my bread-and-butter is, and having that all remain reflection-based terrifies me. If there is simply a way to use reflection initially (and grab references only once), then I'd be okay with that. But what about if you need to update those later? -- Is it taking the multicore CPU / threaded / jobified / ECS updating approach, or plain old vanilla reflection? -- Have you heard any details about this?
     
    Last edited: Oct 30, 2020
  15. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    Bolt 1 is a lot more malleable, it's simpler on front and backend. And more importantly, stable. Bolt 1 is basically Unity's C# scripting API interpreter, there are very few nodes truly unique to Bolt 1. Hence why graph forward compatibility is possible in the future even though the backend will completely change.

    Bolt 2 had a lot more features that had no direct C# equivalent such as Bolt 2 enums that would work only in Bolt 2 graphs and wouldn't be accessible via C# scripts and Macro graph type which was something like in-lining classes in other classes - C# can't do that. And lastly, codegen was made only with Bolt 2 in mind, and Bolt 2 could only run from that generated C#. So anything else that would integrate with Bolt 2 would have to adapt the same style of codegen, which was not stable at any point of development.

    At least, that's my speculation from what I know.
     
  16. stuksgens

    stuksgens

    Joined:
    Feb 21, 2017
    Posts:
    128
    This week I downloaded the 2020.2 beta to see what's new and test the SRP10



    SHADER GRAPH is now a little different, and in a way it reminded me of Visual Script a little. surely Unity Visual Script will look like the shadergraph afterwards (I hope you have icons in the entrances, please:D), but I would like to know how all the windows inside it will be organized. this is a very important design point, because having a consistent workflow helps a lot in the workflow. I think using the same style of interface would be really good...:)

    And as we get closer to the integrated version of BOLT, when will we have this new look in Unity visual Script? will it now be in 2021.1 or 2021.2?o_O

    Edit: I'm referring to the interface style, not the nodes style...
    But in a way, this matches the drop6 of the DOTS VS mentioned above, or even the VFX graph...:rolleyes: I just don't know how it would look in the general organization, the idea is to support the old graphso_O
     
    Last edited: Oct 30, 2020
    awesomedata likes this.
  17. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    They're talking about a new interpreted runtime with automatically generated API endpoints (using Roslyn codegen). So as far as I can tell, the current reflection based runtime is going away in favor of this new interpreted runtime, which is supposed to be a lot faster (but not as fast as native C# code).

    And that's for Monobehaviour based graphs. I've got no clue what's happening with the DOTS side of it.
     
    Last edited: Oct 30, 2020
    awesomedata likes this.
  18. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    I am no designer to argue with you about that specifically, but Bolt follows the same pattern as UE Blueprints which is proven to work (worked on the last 6 years at least) while your idea about the ideal Visual Scripting is just theory for now.

    I don't want to sound rude, but it is kind of annoying that you keep re-posting about that same thread of yours in every forum thread about visual scripting. My personal advice for you is to create a POC of it to show that it actually works and maybe convince Unity about using it or create your own asset and make money out of it.
     
    Neonlyte and JoNax97 like this.
  19. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,289
    Not trying to be annoying, but the lack of information on this subject is concerning. I was only linking you to the bits where I talk about the particular ideas that I reference in my posts (in case you want to actually know more or understand what I'm talking about), but if that's the case, feel free to keep ignoring them.
    I link that thread because these particular ideas very likely don't have an analogue anywhere else on the internet (aside from that thread). And while I know it is a long read, I do think it is really worth the time to read and understand its contents as best as possible -- even as a programmer. But I'm not forcing you -- only pointing out where (and when) I am referencing these ideas (as sometimes I assume knowledge of these ideas because I cant type thousands of words to explain what I mean every single time I reference these ideas in a Visual Scripting thread. Annoying or not -- a link is all I have to inform others on such a dense and nuanced topic that isn't well-covered at all.


    No worries -- I am in the process of this. I am beginning to recognize that freely sharing my "knowledge/expertise" /s is getting me nowhere lol. -- Thanks for the advice though. :)



    True, I'm not saying Bolt 1 won't "work" or anything. There's nothing to argue about there. I am simply pushing for a better, simpler, (more fundamental) solution to Visual Scripting (for everyone) that works for low-level programming while also remaining extremely flexible on the high-end as well. If they wanted to implement the whole system in Bolt 1, they probably could (and still get the performance gains later for the standard nodes -- and in a lot less time!)
    And while UE4 already has a decent system that "works well enough" -- it just isn't as "ergonomic" as my solution is, and Bolt 1 currently suffers from the same fundamental design flaws as UE4. So, like you said, a POC is inevitable (and imminent, since the weekend is coming up -- I might be able to chisel out time to polish a more 'formal' design).


    That said...

    What @Ex-Crow said above about even the "performant" version of Bolt 1 being "slower" than regular code bothers me a lot. My design makes this concern about needing an interpreter practically non-existent. You simply have a CPU-level scheduler system that handles your timing, etc., rather than complex networks of node inputs (which themselves need processing across multiple ports) ultimately processing your timing for you (which, in itself, requires even heavier processing for more 'complex' timing of course). So this is something I would like to fix for @Unity before they get too far in with their "interpreter" design. This just seems like a lot of work for no clear reason. :(
     
    Last edited: Oct 30, 2020
    Kennth, Mark_01 and brunocoimbra like this.
  20. Coroknight

    Coroknight

    Joined:
    Jul 10, 2012
    Posts:
    26
    No, your ego, and inability to communicate effectively is getting you nowhere. It’s one thing to force people to scroll past your ramblings but it’s another thing to approach it with this narcissistic attitude. Like we are all idiots who just don’t understand your genius.

    You’d think that after all the negative responses you’ve received that you’d take a hint but clearly your ego is too large for that. This isn’t your personal blog and it’s getting old having you dominate these visual scripting threads. In fact, why don’t you start a blog if you need more space to express your ideas? Heck, I saw some screenshots of your idea so why not make a visual prototype if you don’t have time to build a functional prototype.

    I’m not saying you don’t have good ideas but what I am saying is why not try a different approach if this approach is clearly not working? And also maybe don’t blame other people when you’re having trouble getting your ideas across.
     
    Mark_01, JoNax97 and awesomedata like this.
  21. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    1,289
    Fair enough. -- That part of my message was actually sarcasm. I happened to forget the " /s " though, so your lashing-out at me was probably quite justified -- It's fixed now.



    While your thoughts about my large ego/narcissistic tendencies are wrong (which are based on my mistake of not putting the /s where it belonged and therefore not effectively communicating clearly), I also don't think anyone here is an "idiot" at all.
    Even those who vehemently disagree with me (and/or my tone) still offer valuable input -- and I take that to heart. As said before, I really don't mind being wrong -- I embrace it, in fact.
    However, sometimes I am actually NOT wrong.
    For example, I'm not "dominating" anything -- I actively _don't_ post here on purpose (except to reply). In the rare cases I do, I'm simply sharing my current thoughts and questions on Visual Scripting, like anyone else here, and rarely, I poke at (and await a response from) Unity once and awhile, mostly to clarify the things I've brought up in the past that haven't gotten addressed well enough to satisfy my curiosity and/or fears -- just like anyone else posting here.
    Also, to respond to the blog suggestion -- I've actually already got a thread where I'm writing the thoughts / ideas I want to share (though, out of respect I won't be linking it -- lol) so no need for a blog. However, I appreciate the suggestion. -- And again, sorry for your wrists.



    All that being said -- I don't know which part of anything I've said is me "blaming" anyone -- you're welcome to clarify that for me if you wish, as I don't ever recall thinking anyone is at fault for me being unable to express my ideas in a way that others can easily understand and/or interpret.

    My frustration with this is directed entirely at myself -- No worries.



    And like I said above in a previous post -- I'm already doing this. But again, thank you for the suggestion.
    And responding to your earlier bit -- I'm no "genius" by far -- I just happen to see something others apparently don't, and it frustrates me to not be able to express it clearly enough without drawing out a huge map to everyone every single time (which gets boring fast -- it's like documentation). Though, clearly words are not enough though. So I've just got to deal with it. This is nobody else's problem though, so please forgive me if I sound in any way like I'm making it out to be.

    That's all I've got.
     
    Last edited: Oct 30, 2020
    Mark_01 likes this.
  22. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    How is Bolt 1 designed for AAA support over Bolt 2? That's the complete opposite impression I got from the roadmap. Bolt 1 simplifies so many things and doesn't have the advanced functionality of things like Classes, Delegates, Generics, etc.

    They claim these will eventually come to Bolt, but they are very nebulous about it. I just don't see how you can say Bolt 1 is better for large companies and for advanced things compared to Bolt 1 which is much more geared towards individuals and learning coding in general.
     
    Kennth, Mark_01 and stuksgens like this.
  23. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    They're working on replacing both the front and backend. The features you mention besides classes will be implemented, eventually. With interfaces and the new consolidated data model, you'll be able to do anything you could do with Bolt 2 classes in theory. I'm sure both delegates and generics will be supported - why wouldn't they? Bolt 1 is not the final design, it's a launch pad.
    What else can they do besides announce that these features are coming and then work on them? What is a less nebulous way of going about it?
    I didn’t claim Bolt 1 as it is right now is better, that’s not the point. I’m saying Unity Visual Scripting (assuming the roadmap features are in) will be better for large studios than Bolt 2.
     
    landonth likes this.
  24. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    Your argument is "well, it will be X in the future!" But that could have been said for starting with Bolt 2 and continuing its development too.

    My argument is why say "we'll get to X point in the future with Bolt 1" when Bolt 2 was already closer to that vision? What makes you think that Bolt 1 will be better for large studios in the future that Bolt 2 being developed and advanced with similar goals wouldn't have been able to reach?
     
    Kennth, Mark_01 and JoNax97 like this.
  25. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    Bolt 2 was "closer to that vision", but was farther from having a stable build (which Bolt 1 already had), not to mention the other issues it had by design (like requiring converting everything to C# to run on builds).

    I understand why people are upset with the decision regarding Bolt 2 (I was too in the beginning), but we need to remember that Bolt 2 was doing a lot of promises for 2 years but was still on alpha after all that time.

    I think that the time to get Bolt 2 into a stable release (which would still require to fix some core design issues) is probably about the same (if not bigger) than getting Bolt 1 issues to be solved, but the major plus here is that Bolt is production-ready now and future Bolt version will be backward compatible with the current state.
     
    awesomedata, Kennth, Mark_01 and 5 others like this.
  26. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    I think you're just not aware that Bolt 2 was at least 6 to 12 months away from the first stable release. That's assuming no new bugs were discovered and added to the already long bug list, and that no major refactors or rewrites would be necessary to fix parts of design.

    There were a lot of unknowns about Bolt 2, especially the C# gen part that never was stable and able to output a working build at any point in development. No one really knew how long it'd take to finish Bolt 2, but it could easily take a year or more. And that's without editor integration, or the DOTS merge, or any other of their goals that are already underway with Bolt 1.

    As brunocoimbra mentioned, forcing all Unity's graph tools to output C# the same way Bolt 2 does is not viable for unifying all VS tools under a single banner. Nor it is desirable for larger studios where programmers write custom nodes for their designers. With Bolt 2's C# generation, devs would have to write C# generators for custom nodes, so Bolt 2 would know how to generate C# for them. This considerably slows down new custom node output and limits functionality like DLC graphs that can extend a game's functionality via content delivery pipelines like asset bundles. That currently isn't possible with any visual scripting tool or C#. Bolt 2's C# gen was great performance wise but it was also limiting in some ways.

    So I don't really see how Bolt 2 is a better starting point when it required an unknown development resource and time investment. And it had limited, incompatible design with their goals for Visual Scripting. Bolt 1 is stable so it can be integrated right now and doesn't go against their goals design wise.
     
    Last edited: Oct 31, 2020
    Mark_01 and landonth like this.
  27. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    Yes, it was still in alpha, but it was feature complete. Multiple creators were already using it and creating tutorials and other videos for it.

    Getting Bolt 2 into a stable release might have taken longer, but it would have been much more useful in the long run. Maybe not to you, but definitely to a huge number of people who were waiting for it.

    The least Unity could do is release what was done with Bolt 2 and let the community decide if they want to continue creating with it or not.

    And Bolt 1 isn't really production ready now. Have there been any notable games shipped using just Bolt 1? There have been games released using just UE Blueprints.

    Oh, I am aware. Although I wouldn't say 6-12 months for a stable release, as you said they aren't sure how long it would take.

    They could have scrapped C# generation for now and focused on the other Bolt 2 parts, specifically Classes / Generics / Delegates. All these were feature complete in February, just not stable or production ready.

     
    Mark_01 likes this.
  28. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    Original developer was concerned about calling it Bolt 2 beta (even though it technically was) and feature complete at the time because people would misunderstand that it's ready for production and near release. You're demonstrating his point. Feature complete =/= production ready.

    Was there anyone besides One Wheel Studio who did Bolt 2 vids? And even then they focused entirely on the in-editor Live runtime's non-bugged features. Just because some parts of the tool ran in the editor via reflection, doesn't mean you could get functional C# gen builds working with Bolt 2. It also doesn't mean that the editor didn't have many bugs, the videos in question just didn't touch those bugged features.

    It sounds like you're basing your argument entirely on "feature complete" statement and on some Youtubers making a video or two on an early alpha build of Bolt 2.

    In what ways exactly it would be more useful in the long run? We're still getting most of Bolt 2 features back ported or reimplemented in Bolt 1 except classes and C# gen.

    I'm all for open sourcing Bolt 2, but the community can't create anything with it. It's not anywhere near functional. I can't see an experienced team of Unity tools developers suddenly popping up and spending a year on finishing it. I'd love to be proven wrong though.

    I partly agree. Bolt 1 doesn't scale well for medium to large projects. But with some workflow adjustments, like holding most variables in C# scripts, Bolt works fine for mid-sized projects as well. And it is production ready and stable, it's just not very scalable mostly due to lack of QoL features like graph search, variable organization, custom events organization, lacking debugging and refactoring features and of course performance.

    But Bolt 1 is very much functional. I wouldn't use it for new games personally in its current state, but my client's 2-year-old project is nearing its end and will launch on Steam with core logic largely driven by Bolt. Long story short, Bolt 1 works now and has worked for a long time, even if it doesn't scale well.

    That would mean complete redesign from ground up. You can't just pull out a core part of the tool and expect everything else to still work. If it was that simple, they would've done it. They also mentioned that they didn't want to force classes on every workflow, which when you integrate all the other VS tools into one makes sense. Interfaces should cover most of the Bolt 2 class like functionality, it's arguably even better than classes.
     
    Last edited: Oct 31, 2020
  29. cpberi

    cpberi

    Joined:
    Jul 30, 2012
    Posts:
    11
    Wow, I just checked in after a while. I see this topic is still hotly debated, interesting :O
    Ultimately the Bolt1 was chosen, so shouldn't we wait for Unity to improve it ASAP now? We should have a full list of improvement wish lists and debate those rather, I'm not sure if it's constructive if we keep holding on to something that has already been decided.

    I disliked their choice, but at the same time am really glad that they made a useful action for sure. What I can't stand isn't if something was the right choice or wrong choice. Of course that's important and all, but even more important factor is the Unity's Inaction and taking forever for useful features to be completed. The fact that Bolt2 took almost two years in development, the fact that we had 3 different VS solutions being developed, but in reality, none were really production-ready for ... really long time, now that's insane. Yes, I'm calling the Bolt1 as not production ready, due to its ridiculously slow performance.

    So at some point, the argument has to be "Give us something that we can work with" and have a timer on it to be production-ready. I for one, have moved on from Bolt2. Bolt1 is the chosen one?, fine. Please then make the Bolt 1 useful ASAP, so we can use it to make games soon, rather than waiting for more months, just making some cute tutorials. Please. Just fixing up variables and the severe performances issues alone, I'll be fine, I'll use it already. What WOULD BE deeply disappointing is if we have to wait for much longer again... Insane...

    And I hope they make the same type of actions regarding SRP. Please consolidate the workflow, and end the insanity. it should be just the URP as the default with optional HDRP functions to extend, instead of 3 different pipelines to choose from with all independent, and all different workflows...

    Ever since 3~4 years ago, Unity had been slowly resembling old 3D programs, like Maya, Blender, etc. Cluster f*** of individual features, without the clean migration of how they all work together or simple UX...
     
    OCASM, awesomedata and brunocoimbra like this.
  30. stuksgens

    stuksgens

    Joined:
    Feb 21, 2017
    Posts:
    128
    They already have a list of features that will probably be implemented soon, but it would be good to solve the biggest problems first and then include the new features ... And I believe that the biggest one is the variables, this is certainly something extremely problematic for any developer. of bolt, but from what I saw here on the forum, this is linked to GTF, so maybe it will take a while...:(

    Other things like the fuzzy Finder, or even the replacement of the interface by the Graph Tools Foundation are not extremely important, but would be much appreciated if they were already included soon.
    From what I see, we will have many new features in Unity Visual Script.:)

    As Laurent already said in one of the previous messages

    "... The work on variable management, including addressing referencing through magic strings, strong typing, or scoping, as well as the work on delegates and events, are all fitting in our consolidation of the data model similarly to the concept of classes. This is work in progress to finalize the model, so more details to come."
     
    brunocoimbra likes this.
  31. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    Yes, it wasn't production ready. But neither is Bolt 1 or Unity's Bolt either. Again, can you name any games that were published with just Bolt? I can name plenty that use just Unreal's Blueprints. Even some big name games.

    Yes, there were others. A quick Google search would show you that... but you didn't even want to invest that much time and just felt like commenting and dismissing stuff instead? Seriously, if you're going to not take this seriously and actually do a little research on this stuff why argue about it?

    Those two things are HUGE. Literally the main reason I wanted Bolt 2 was for classes and C# gen.

    You underestimate the community. Look at what has already been done with other VS tools.

    There are tons of other visual scripting tools out there that they could use. The point was to have something that COULD scale well like Blueprints. Something that people could learn and use from project to project, company to company. Just like someone who is a master in Blueprints can easily hop from Unreal project to Unreal project.

    You can... C# gen isn't something that is intrinsically tied to everything in the engine from anything I've seen.

    Ultimately, it just seems like you're making a lot of wild assumptions and just speculating that "this will be everything Bolt 2 was and more" without any evidence to back that up. What Unity has said doesn't inspire much hope considering they were favoring backwards compatibility above everything else. Including advanced functionality, scalability, C# gen, and more. While that might be important to some people -- I don't know why those who wanted a VS tool that has been proven to work couldn't just go for something like FlowCanvas + NodeCanvas right now.

    What I wanted was Unity to embrace something and advance all visual scripting going forward into something that would be on par with Unreal's Blueprints. Now it seems like Unity's Bolt is just going to be a visual scripting toy instead of something that can ship entire games.

    That's the point I'm trying to make. There are already visual scripting tools out there that work. Unity just adding Bolt as it is now isn't going to advance visual scripting or create something that can compete with Blueprints. It is just going to be "another visual scripting tool except by Unity." Unless I'm missing something -- how is what Unity doing with Bolt different than what anyone else has already done? Answer me that.
     
  32. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    @Stexe I think it is time to stop making assumptions and start doing requests.

    If you had Bolt 2 access at any given point when it was from Ludiq, you know how C# gen-dependant the core of Bolt 2 was. If you want to compare with Unreal's blueprint, you will also know that they started with huge performance issues that were improved with time. You want so badly the C# gen but you didn't took in consideration all the points given about that so far, not to mention the time waste of getting it to work properly for 1.0 instead of focusing in the important core functionalities. About classes.... Not much to mention here, it is a feature I would want, probably by the same reasons as you, but I get that they have higher priorities right now so I can wait for that one.

    So.. be more specific about your needs and why. I am sure you will find others supporting your ideas and Unity will end up listening and implementing some of those. If you just keep saying that you want Bolt 2 back or that you just want something like Unreal's Blueprint it will get you (and this thread) nowhere.
     
    Ex-Crow and JoNax97 like this.
  33. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    Bolt 1 runs, is stable and anyone can make games with it. It's production ready. Comparing a paid $70 Unity asset released 3 years ago with Blueprints which came out 6 years ago as an engine standard for free is like comparing apples to oranges.
    I cannot see what some random Bolt 2 Youtube videos that show how to create a class and rotate a cube prove. Yes, you could do some basic stuff in Bolt 2 alpha reflected Live mode. So what? I had an inventory system completely working in editor's Live mode, but there's no point to it since it doesn't work in Generated mode or in builds.

    And why would I research these videos when I've used Bolt 2 for the past two years myself? I know exactly in what state Bolt 2 is from firsthand experience. If all your information comes from these Youtube videos, then it's no wonder why you think Bolt 2 was usable or was close to release before cancellation.

    They were huge; I was excited for them too. That's why I tested every alpha version for two years, reported bugs, and took part in discussions on Discord. Some of my requests ended up in the asset, such as the "Is" unit. You'll have a hard time finding someone else who was more invested in Bolt 2 than me.

    But Bolt 2 is not happening in any shape or form. They made the decision. Throwing a fit for not getting classes or C# gen is not productive. What's productive is working with Unity to shape Unity Visual scripting into a tool we need.
    What does that even mean? I can count active community members that would be knowledgeable enough to finish Bolt 2 on one hand. And they all have their own stuff they're working on. The notion that some experienced developer/s will just drop all their responsibilities and their own projects to work on finishing Bolt 2 with no budget is not realistic. It’s a pleasant dream, but that’s all it is.
    And Unity Visual Scripting will scale once it's done. That's what the roadmap is about. Why do you keep comparing Bolt 1 as it is now with what Bolt 2 could've been? They're fixing all main Bolt 1 issues. Interfaces will cover most of Bolt 2 class like functionality. And they're better than classes because Bolt 2 classes never had and never would have inheritance or method overrides, but a graph can implement multiple interfaces.
    Again, if it was that simple, they would've done it. C# gen was not something tacked on at the end, it was the only way to run Bolt 2 builds, the very core of the asset. Reiterating this point just shows you're not informed on how Bolt 2 is structured and works.

    EDIT: Here's what the original author of Bolt wrote when asked if reflection based live mode in builds is possible:

    My evidence is the official roadmap and discussions I've had on the Discord server with developers of Unity Visual Scripting. I was upset at first too, but then I dealt with it like an adult and talked with people who're working on the tool. ie I base my assumptions on official, publicly available resources.
    Backwards compatibility is important when the tool has a user base of tens of thousands of people. And you can still go for FlowCanvas + NodeCanvas, they're great, proven in production tools.
    What does that even mean? You keep throwing out these really vague, general statements without backing them up with any reasoning. If they fix Bolt 1's shortcoming's, implement interfaces and improve the data structure it'll be Blueprint like. Probably more Blueprint like than Bolt 2 could be since Blueprints is largely driven by directly implemented high-level nodes. That's exactly what Unity are doing now!
    Unity are working on completely replacing Bolt 1's front and backend. They're working on a new custom node API. They're working on a new events system. They're working on a new high performance interpreted runtime that'll replace Bolt 1's reflection. They're working on many things. Bolt as it is now will not remain like that for long. They are creating something that will compete with Blueprints. You just refuse to see it because you wanted C# gen and classes. I wanted them too, but they aren’t be-all and end-all of visual scripting. They’ve also talked about doing C# gen eventually as an optimization, it’s just not the focus now.
    They're combining Monobehaviour, DOTS, animation graphs and more (like behaviour trees) down the road into a singular tool with all of them accessible in the same graph under the same UI/UX paradigms. No other Unity VS tool covers this wide an array of features. This also opens room for performance intensive games that might not be possible with just Monobehaviour based VS tools since DOTS is multithreaded and highly performant. And that's something Blueprints which runs on a single thread doesn't have and likely won't have based on Sweeney's statements so far.

    They're also working on supporting 1st party tools like the new Input System natively. In other Unity VS tools, you need custom nodes for that. ie Unity Visual Scripting will have a lot deeper engine and official package integration than other tools on the asset store.

    DLC graphs. If you want to ship Bolt or any other VS tool graphs or C# scripts as small updates to your player base, that's currently not possible on a lot of platforms. You have to rebuild the entire game and include the new graphs/scripts in that build for them to work properly on the target platform. With the changes Unity proposes that'll change and you'll be able to ship graphs in, for example, Asset Bundles to add new game functionality with tiny updates. This also opens room for community modding.

    But I don't require them to be different for the sake of being different. I want a production ready, scalable tool that I can use with confidence and that will remain supported and updated for years to come. I want it to be a standard for all Unity users so I can build upon the base they provide with my own custom nodes/tooling to better serve the needs my clients have. And they're working on it. That's good enough for me.
     
    Last edited: Nov 1, 2020
    toomasio, stuksgens and banan1234 like this.
  34. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    119
    That's not really true. While it is possible to ship entire (simple) game on a pc (won't work on other platforms, especially on mobiles), blueprints are primarly made for level scripting. Once you try to expand this toolkit for something more, you will start playing with workarounds instead of making a game.

    Things like memory management, gameplay mechanics or automated tests are pure pain in blueprints. It is possible to do them well, but sooner or later you will come into conclusion "Why am I wasting hours to manage simple things while I can do them in minutes with c++".

    Also, because of various limitations of blueprints, sometimes user can write few lines of code to replace hundrets of nodes (and save many hours).

    There is a reason to why most of the games made only in bleprints are either buggy and laggy mess or the simplest walking simulators (sometimes also the simplest shooters). Yes, even these games can sell good enough for the single developer but no one should ever pretend that blueprints is great for everything.

    Bolt 1, while is unusable for something as basic as level scripting, I think there is no reason to believe the team won't fix the biggest issues with this toolkit so that the unity will have their own version of blueprints.

    The real problem here is that visual scripting could be useful in more cases than just level scripting, cutscenes, animations etc. I think users want to use the tool in runtime for stuff that could be called either every frame or very often. Stuff like procedural world generations, gameplay mechanics, AI, or even smarter game balancing. But for that we need high performance in runtime.
     
  35. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    Now you're making assumptions here. C# gen wasn't the key thing for me. Blueprints doesn't do C++ gen.

    I've stated my reasons both here and on the Discord. Visual scripting could be huge and Unity could push it forward, but instead they are taking many steps back in favor of backwards compatibility over scalability and advanced functionality.

    Who said I was "throwing a fit"? You're really making wild assumptions again. I'm just explaining why Unity's goal is short sighted. As others have said here and in the other thread.

    Yikes. Sadly, you're not dealing with this conversation like an adult.

    I've backed up my stuff with reasoning before. You can go check the comments both here, in the previous thread, and on Discord. I mean, Lazlo broke it down pretty well in the Bolt 2 roadmap and why he was making it in the first place.

    Supraland is made entirely in Unreal Blueprints. It is a fairly intricate game with a lot going on. It also has a Nintendo Switch version. So... yeah, I don't know what you're talking about.

    Regardless, we'll just agree to disagree at this point it seems. I wanted something closer to C# code in a visual format, which is what Bolt 2 was going for. Maybe Unity will get there someday, but it seems like a step backwards in so many ways.
     
  36. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    I’m not sure what you're trying to achieve here besides endlessly repeating - Bolt 1 bad, bring back Bolt 2. You keep ignoring the planned improvements for Bolt 1, most of which will be on par with what Bolt 2 had (and call them my wild assumptions even when it's all based on the roadmap in this very thread and what lead dev Adam has written on Discord to you no less - can't get any more official than that). And you don't present any constructive suggestions on how to course correct in your opinion (besides bringing Bolt 2 back, which is not happening).

    You're also being vague about what made Bolt 2 so much better than what Unity is planning Unity Visual Scripting to be. Backwards compatibility and feature support is not a 0 sum game, you can have both. You seem to confuse backwards compatibility with asset's design (and features) staying as is which is not true. Both the frontend and backend tech will completely change with time.

    Lazlo's outlined Bolt 1 problems in Bolt 2's design doc are the same problems the community informed Unity devs about after Bolt 2's cancellation in previous thread. This roadmap is a response to those exact problems, just with different solutions (which you apparently don't like). But many designs can be valid at the same time based on context.

    In Unity's use case Lazlo's design is not fitting as anything that integrates with Bolt 2 would have to do the same style of C# gen and adhere to the same class based structure which might not apply to tools like animation graphs, behaviour trees and other tools that will integrate into Unity VS in the future. Hence why they're going forward with other solutions like interfaces and a new data model that will tie variables closer with graphs that will cover most class like functionality but won't obstruct the unification of all graph based tools.



    If the lead Unity VS dev can't get through your Bolt 2 bias, then I probably have no hope either. Not that it's my goal. I'd simply prefer if this thread went in a more constructive direction.
     
    Last edited: Nov 2, 2020
    banan1234, stuksgens and Mauri like this.
  37. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    119
    Well, about that Nintendo switch release, they posted this on their blog.


    And note that the nintendo switch version still stutters a lot and drops below 30 fps.
     
  38. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    Well...
    But I made my point, I am not going to take part in that endless loop.
     
    Ex-Crow likes this.
  39. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    I'm trying to bring clarity and the weight of other opinions into the discussion. Imagine if no one spoke up before where we'd be. But instead of offering suggestions, you just lash out. Funny, how just a few sentences ago people were commenting about awesomedata and I handling our discussion... and then you jump in and go for the opposite. Sad to see you're a moderator on the Discord and you're acting like this. Not very professional at all.

    Yes, what Unity did is a great first step. But I, and others here, don't think it is the final step.

    I was trying to keep this thread towards being highly constructive, but then you completely derailed it. Adam's posts, while good, are still very vague and broad. What exact improvements classes brought will be reflected in Unity VS? What exactly is going to be sacrificed to maintain backwards compatibility? They haven't given specifics on these, just a general direction of where they are going.

    Yes, there are issues, but the fact it was possible at all says a lot considering it was done entirely in Blueprints. It still proves my point that a hugely successful game was made entirely from Blueprints. Have we seen anything like that with any Unity game with any visual scripting tool?

    It isn't an endless loop. Classes are the main thing I wanted and C# gen, while still important, was secondary. I'd be fine with no C# gen if that meant we got Classes.

    I'm still curious on how Unity's VS is going to approach classes since we've heard a lot of nebulous things on ways that it will be similar, but how exactly will it be? Again, what are the trade offs specifically that Unity is making?
     
  40. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    119
    The status of a successful compilation of the game doesn't say anything interesting. Neither does spending $100 and clicking some sort of "release" button.

    Also, we don't discuss here sales and marketing but technicals & workflow of games made only in blueprints. Don't try to imply that sales on one platform are somehow an excuse for the problems of the same game on other platforms, especially If it does have a lot of problems and they exist because of the technology. Plus supraland only proves my point.

    If you try to make a game, only in blueprints (even basic asset flip, like supraland) It will work on PC, If you try this on other platforms, like mobile you will end up with a bad looking, badly working, stuttering mess.
     
  41. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    Obviously, Blueprints does have flaws. But it has still resulted in shipped and successful products (not just sales, but also reviews). Can you point to a similar game done in Unity using any visual scripting tool, let alone Bolt? That's my point -- not the technical issues that Blueprints has currently, just the fact it has been used for a polished and published game at all.
     
  42. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    119
    No, there probably are some, but the thing is. I never disagreed with you with this statement. I think unity just showcased with what happened to the bolt how mismanaged the company is (again). Whoever was behind the decision of buying bolt instead of something like flow canvas clearly doesn't have a clue about the product unity is making, neither about the community and doesn't understand the needs of the user base.

    But the thing is, that's the past we can't change. We will have to live with that bolt 1 and look at how it slowly improves.
     
    awesomedata and L82093 like this.
  43. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    4,862
    Stutter caused by using blueprint?
     
  44. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    I know we can't change the past, but we can try to inform and help steer Unity's ship into a better port. That's the whole idea of this thread and the previous one. If no one speaks up then nothing changes.
     
    Kennth, awesomedata and L82093 like this.
  45. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    Instead of attacking my arguments, you've now resorted to assassinating my character while claiming I'm the one derailing this thread. You've demonstrated your lack of knowledge on the subject matter, contradicted yourself on several key points and you're still unable to explain your stance or why classes are so great and why having the same or similar functionality achieved with different solutions like interfaces is worse than having classes. This argument is pointless.
     
    stuksgens likes this.
  46. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    185
    You've done that yourself. You continually post in response to derail the conversation, which speaks volumes. You could have stopped but you kept going. If it was a pointless argument why do you keep responding?

    I've explained why Classes are great before, but Lazlo explained it much better than I could: https://www.notion.so/Classes-WIP-dd3766d4fad649b2ba042bd896e7d081

    And Unity reps have said only, "a lot of the improvements classes brought to Bolt will also be reflected in UnityVS." Talk about nebulous. What exactly is "a lot of the improvements" and what improvements will not be reflected, 'a lot' doesn't mean 'all.'
     
  47. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    I admit that was out of line, but you started it by attempting to devalue what I'm saying by accusing me of making "wild assumptions" when all I'm writing is based on the official roadmap and public dev statements on Discord. Those are not just some wild assumptions and speculation.

    The argument didn't seem pointless at the time because it seemed there's room for discussion to develop ideas and criticism further. To arrive at something more concrete than just - Bolt 1 bad, bring back Bolt 2. You claim you've explained why classes are great before, but I haven't seen that in this thread, so where is that constructive feedback for Unity's roadmap this thread is about?

    Lazlo's design was great more than 2 years ago when it was written and when he only had to consider Bolt 2 design in a vacuum with no consideration for other tool integration - DOTS VS, animations graphs, etc. Unity have to consider Bolt as part of a larger Unity ecosystem. Design requirements have changed. This new roadmap addresses the same problems Lazlo outlines for Bolt 1, just with different solutions. Linking an old design that doesn't fit current design requirements is pointless. The context is completely different.

    I can't speak for Unity, but I'm sure the design will be clarified as we go forward. They've been at it only for two or three months.
     
    stuksgens likes this.
  48. landonth

    landonth

    Joined:
    Dec 3, 2018
    Posts:
    92
  49. laurentlavigne

    laurentlavigne

    Joined:
    Aug 16, 2012
    Posts:
    4,862
  50. parrotsgame

    parrotsgame

    Joined:
    Apr 9, 2018
    Posts:
    6
    well the least they can do is add a page to https://portal.productboard.com/unity
    they promised that weeks ago, and yet still vacuum. do you know something that the rest off us dont, cause from what i understand, they still dont have a clear vision of what the hell their doing. honestly if Rohit didnt post his UNOFFICIAL weekly worklog, we would still be in dark of what the hell is happening. while your right, the design requirements have changed, there is no actual technical breakdown of what their doing, beside the same GTF (Graph Tools Foundation). i guess thats better than nothing but its not an excuse for keeping everyone in the dark either. as stexe said :
    yeah what is happening with that stuff. its a complete silence.
     
    Kennth and Stexe like this.
unityunity