Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Unity acquires Bolt

Discussion in 'Assets and Asset Store' started by AskCarol, Apr 30, 2020.

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

    AcidArrow

    Joined:
    May 20, 2010
    Posts:
    11,594
    Subscriptions, asset store, premium support, tutorials. I mean, I don't understand how it's a mystery for a company that has so many monetization methods.
     
  2. IllTemperedTunas

    IllTemperedTunas

    Joined:
    Aug 31, 2012
    Posts:
    782
    @AcidArrow the second half of that sentence was the heart of my post. The mystery has been why hasn't Unity figured out long term strategies for pulling in profit while strategically growing their tools internally to align with subscription based funding. I used Amplify Shader as an example of the conundrum.

    My point was few of these revenue streams directly connects with specific parts of the engine, to the contrary right now if we buy something that makes Unity better like Amplify Shader, we are actively encouraging them NOT to improve the core out of the box tools. My post was an attempt at stating I hope Unity is taking it upon themselves to structure future upcoming aspects of their engine to allow the amazing and powerful free environment they are known for, while also finding a way to make more bank so they can continue to make the engine better. Presently there is this chaotic mix of core and external developers and there doesn't seem to be a game plan for making the engine better as a whole.
     
    Last edited: May 6, 2020
  3. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    https://en.wikipedia.org/wiki/Unity_Technologies

    You don't have to worry about engine developers. They have money by the bucket loads. It is the most popular video game engine in the world, after all.
     
  4. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Hi @PanthenEye, Thanks for the thoughts. As mentioned previously, our focus at the moment is to guarantee the continuity while transitioning to the dev team here at Unity. More details will be provided in the future about our intentions around Visual Scripting in general. Thanks again!
     
    PanthenEye likes this.
  5. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    Thank you for clarifying. Can't wait for the future plan announcements. If Bolt becomes a true Unity standard, I'd be the happiest dev on the planet.
     
    TextusGames and LaurentGibert like this.
  6. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    267
    Damn it. I hate being negative, but just when I thought we were getting a decent visual scripting editor, we actually get a blueprints clone spaghetti left to right workflow. PLEASE don't turn your very promising VS editor into the blueprints mess.
    I'm also a coding teacher (15 years now) and I was really digging the Unity VS editor as it flowed and looked as much like C# code as it could. I was looking forward to using it as a transitional tool for beginners (AND for experts to use). Unreal Blueprints is so different to text that they don't see any similarity. eg I really dislike the way Bolt turns normal terms into 'non-programmer' terms, so instead of getting familiar with them, they learn nothing.

    Here's a few points
    - Visual scripting IS programming, stop treating it like it's not. It's just a different editor for the same code.
    - There are good things about blueprint style editors and good things about pure text. They AREN'T competing. Make something unique. Don't 'throw the baby out with the bathwater' when moving to visual editors.

    Text editors
    - Good: You can use the keyboard 100%, which is FAST. Inserting code is easy. Lots of code on screen, compact layout.
    - Bad: It's stupid easy to break code. Rearranging code is incredbily fiddly and bug prone. eg rearrange a few nested if statements.. it's horrible. Feeding data to method parameters can get really messy, forcing creation of a million temp vars to make it readable/debuggable. No realtime visualisation of execution. Constantly jumps around with no way to get an overview of execution flow.

    Visual scripting (with Unreal Blueprints)
    - Good: You can see the running code RUNTIME, you can watch values changing IN the code runtime. This is amazing and makes debugging a thousand times easier for beginners (and me!). Zooming in/out for quick overviews. You can't break the code with syntax errors and crazy bracket syntax. Function nodes show the full name of parameters right there in a list, not hidden. Rearranging code is really easy and doesn't break everything. Super easy to try out different chunks of code without messy commenting. Branches actually branch!
    But the best thing in blueprints? There's some buttons for NEW VARIABLE/FUNCTION etc. You wouldn't believe how hard it is for beginners to need to remember all the fiddly bits about making new stuff from scratch.
    - Bad: Inserting code is insane, slow and frustrating. Zero keyboardability, mouse work is just too slow. Left to right flow with no snapped blocks is HUGE. The code vs screen space is TINY. Having to constanly manually arrange every single node is madness.

    *** Here's the thing, YOU CAN COMBINE THE BEST OF BOTH in a VS editor! There isn't a standard way of programming in text or nodes, it's just people have gotten USED TO IT. Remember 3d modelling organic shapes before ZBrush came out?

    eg
    Yes you can get 100% keyboardability in nodes with easy inserting AND it could be FASTER than C# coding.
    Yes you can still have top to bottom code flow with snapped nodes (look at Scratch) with a CURSOR and have it very similar to typed code without any breaking syntax etc etc

    Unity VS looked like it was the closest I've seen. ie Top to botton snapped nodes, with semi freeform inputs to functions, very nice. Should be easy to add keyboard functionality for 100% keyboard use, it can be done! etc
    But then I find out it's DOTS only (why?) and Bolt is just... being bolted on, confusing the landscape even more and its design is going to push the Unity VS design towards it, because people are used to it, not because it's better.

    Freeform blueprints are a total mess, don't copy a bad idea, just because half of it is pretty cool. They took all the good things about text editors and threw them out. DON'T change your VS layout to copy Unreal/Bolt. Just because people like something, doesn't mean it can't be improved.

    Needless to say I could talk about this for hours, but I'll stop. If you got this far, you're as insane as me :)
     
    Last edited: May 6, 2020
  7. Marc-Saubion

    Marc-Saubion

    Joined:
    Jul 6, 2011
    Posts:
    653
    Thanks for your answer but I think you're missing my point. I don't want more clarity, I need these critical choices not to exist in the first place.

    Currently we're already having issues. I'm unsatisfied because I don't access features like shadergraph because they aren't compatible with the original graphic renderer and at the same time I see companies asking for help because they maneuvered themselves in an impasse working on HDRP. It feels like 2005 when we all had cellphones but nobody had the same charger port.

    We had a short golden age with Unity being the most popular engine with a big community programming with C#. That was good for business because we could say yes to anything.

    With Bolt + Dots, or HDRP+ URP + x , you're dividing that community and create pitfalls. Now we have to say "no" or "yes but" when a client already made the wrong choice before we were there. We're also losing money when we have to maintain assets on multiple renderer.

    Unity definitely need a Visual programming tool, but you have to choose one and it has to be compatible with everybody.
     
    LaurentGibert likes this.
  8. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    Bolt 2 is top to bottom. That is what they actually acquired, Bolt 1 is in maintenance mode and irrelevant. Bolt 2 also has a live C# preview so selecting a node or multiple nodes highlights the corresponding code in the C# preview window. And Bolt 2 also does generate clean, human readable C# code.

    Your rant about top to bottom flow and VS still being coding and what not is misplaced when Bolt 2 has these things.
     
    Last edited: May 6, 2020
    Jwolf, LaurentGibert and corjn like this.
  9. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    I don't really get this line of thinking, OOP monobehaviour and DOTS ECS are not interchangeable. Asking to kill one and push the other won't make things better because the engine will still have the duality of OOP and DOTS existing alongside each other. Having a single VS solution for half the engine doesn't make much sense to me. Especially because DOTS stack is nowhere near production ready by the looks of it. It'll take years for it to properly mature.

    Furthermore, most things don't require top performance DOTS provides and are still way easier to do in OOP. If we take the Pareto principle into consideration, then only about 20% of your code eats up most of the available performance and would (maybe) need the speed DOTS provides. The rest can still be done with monobehaviour like usual. I think that's the ideal scenario - have Bolt rule over monobehaviour part of the engine and DOTS VS handles ECS. Both VS tools would be able to communicate with each other seamlessly. So for performance heavy systems like pathfinding you'd do DOTS, but create the content with Bolt like usual. Use the best tool for the job instead of forcing only one.

    There's no fragmentation because both tools do some things better than the other.
     
    Marc-Saubion and LaurentGibert like this.
  10. Havok_ZA

    Havok_ZA

    Joined:
    Jul 27, 2016
    Posts:
    69


    Top down..structured. Also shows you the code in the Script window




    Also when installing Bolt you can choose if you want Human Naming and Programmer naming.

    So not sure what could be better to teach your students since it does both the things you need SND shows them the code (Bolt 2). :)


    There are three forms of Visual Scripting imho. When talking "Visual Scripting" we often confuse the 3 or dump them all together... perhaps we shouldn't.

    1.) Blueprints....this jus removes the typing and shows you how the code is flowing. It doesnt REALLY make it easier for the non-coder. You need to know the code and the exact logic. You need what function to use etc. It just makes the syntax easier but makes it slower for a traditional coder for a lot of things when scripts gets big.

    Bolt is very much like this but even easier in a way becasue you can switch to the Human Readable way.

    2.) You then have Visual Coders like PlayMaker etc that although State machines also develops their own actions and properties to make the actual functionality straight forward for the non taditional programer. There is still logic but they don't need to know the function name and all the properties etc. It's straight forward to make stuff. Yes it's limited becasue of this..but a lot of things can be done before you hit those limits.

    3.) You get the Visual Coding that is even easier and almost like a tool in itself. The Gameflow's BLox, Scratch, Construct 3, Game Creator type Visual scripting. Where a lot of functionality is exposed from blocks with properties.

    Non-coders want 2.) or 3.) preferably. People who want to discover what an engine can do and dont know syntax and dont want to learn syntax chooses 1.)

    People who want to learn to code....imho it's easier to just start with code. People who want to learn logic of coding...maybe there is a case for 1.).

    Anyway I have Bolt, Playmaker, Gameflow and Game Creator. Love them all for different reasons. What I can't do in Game Creator I use Playmaker or Bolt or just open the script window.

    Each to their own.
    I am still confused about what Unity is doing with the Visual Coding and eager to see - Not to be synical, I love Unity...I chose Unity and am building stuff with Unity and it works for me. Lately, Epic seems to know EXACTLY what their strategy is and conveys it well to their userbase. Unity either doesnt have a clear path to balance existing functionality and still create the new feature sets to modernize it so that can it compete with Unreal OR Unity doesn't know how to properly convey the message of that strategy to the user base. I trust that it's the latter.
     
    Last edited: May 6, 2020
  11. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    Thanks for the write up @Havok_ZA is a very nice summary of the current state of scripting.

    And yes I would love it if unity would also provide a way to use State machines with actions.
    the action could be written in c# or in visual script.

    976ac3bc-dcaf-4c48-b7b1-3a05fdc60881_scaled.jpg
     
    Havok_ZA and LaurentGibert like this.
  12. rz_0lento

    rz_0lento

    Joined:
    Oct 8, 2013
    Posts:
    2,361
    I don't in particular care about visual scripting but I'm quite alarmed what is happening here in terms of the monetization. I already pay Unity a subscription fee to get a) all the tools for the engine Unity offer b) get rid of those few limitations on free version. Now if this trend continues, we still pay for the sub + also pay for bunch of microtransactions to Unity to actually complete the engine/tooling (paying for 3rd parties for this is different as Unity doesn't own those 3rd party assets). It's alarming and if it actually goes to that, I have to reconsider the engine ecosystem on whole.

    Just imagine if Unity did this model to everything they acquired in past, that would take out like dozen tools that are now included on Unity in some form.

    I've seen alarming signals before this even, like when they started selling practically a DLC content for their learning sample. I don't know what's going on with Unity right now but it does worry me a lot. Keeping the engine pricing simple is vital, don't mix it all up. Unite already bumped the subscription prices at the beginning of this year, now microtransactions.. just saying, not a happy camper here.
     
    tcmeric, Starbox, pm007 and 2 others like this.
  13. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    I want people to think about a single scenario: what if you could make your games in bolt 2 right now, and then later, kinda like magic, have that just work in DOTS. I think Unity's hinting this.
     
  14. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    267
    Ah cool, yeah Bolt 1 looks exactly like Blueprints so I was worried, but Bolt 2 looks much nicer. The 'see the code being written' thing is the very nice. I wonder if it will still allow flashing code as it's running, seeing as it's writing actual C#?

    Still confused as to why they didn't just use their visual scripting for non-dots as well, since it seems quite far along? Surely it'll be a major hassle to somehow integrate these as I'd imagine the internal workings would be completely different?

    With any VS give me a smart chunky cursor so I can basically use the keyboard similar to text and it'll be great. A big horizontal line jumping between nodes with arrow keys would be all you need. Then you could press enter, type a few characters for intellisense and snap insert a new node, while pushing the others down etc etc
    Also a default mode of 'nodes are snapped together, unless you specificaly drag them apart' would be the best of text/scratch and wired freeform nodes. Or at least move all children relative to parent movements would help a lot.
     
    Havok_ZA and LaurentGibert like this.
  15. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    Can regular OOP C# code be parsed to DOTS just like that? Sounds a bit like a pipe dream. Bolt 2 also has a bunch of Bolt only features that wouldn't make sense without it. Like Bolt enums that can be renamed and reordered at any time (but you can't access them at runtime via C# scripts, so only used in Bolt graphs and classes). Or Bolt's class assets which are the Bolt version of a scriptable object and inlined macro logic that can have any of the Update, Start or Bolt events in it. The generated C# code still very much relies on core Bolt tech to work, so parsing all that to DOTS seems unlikely.
     
    tcmeric and LaurentGibert like this.
  16. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    6,586
    Are you going to make Bolt and VS for DOTS feel&look the same? That would allow to transition from one to another without having to learn different UI, workflows and tools.
     
  17. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Noted, we'll work on those aspects. Thanks for the feedback.
     
  18. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    I like your bold thinking! There is definitely a lot of technical details that would work against this goal, but it would be amazing to move in this direction. I guess nothing is black and white, but the closer we get to a transparent workflow, the better for all of you.
     
    brunocoimbra, hippocoder and valarnur like this.
  19. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Yes, with Bolt 2 you can generate the code in a preview window, and follow it's execution in sync with the graph. More details to come with the beta coming up: https://forum.unity.com/threads/welcome-to-bolt-2-beta-coming-soon.874729/
     
  20. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Hi @Peter77, this is a little bit too early to say but compelling as an idea. For now we're focusing on making sure we have uninterrupted support for Bolt 1 while landing Bolt 2 asap. While the dev team executes on this, we're are working on the plan for next steps and will communicate on this when we have clarity on our strategy.
     
  21. Marc-Saubion

    Marc-Saubion

    Joined:
    Jul 6, 2011
    Posts:
    653
    Maybe that's just me failing to see the difference between Bolt and Dots then.

    I just want to make sure we avoid scenarios like when we had c# and unity script until it was c# only at the expense of unity script users.
     
  22. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    3,513
    Suggested 7 steps roadmap to success. :)

    1. Rename it so its no longer called Bold but Visual Scripting Graph ( VSG ) in line with Visual Effect Graph
    2. Make it free and downloadable as a package
    3. Make Bold 2 read Bold 1 scripts with auto conversion if something is not a 1 to 1 match
    4. Release Bold 2 as VSG
    5. Integrate DOTS visual scripting into the Bold 2 ( VSG ) design and window.
    6. Release the DOTS add on for Bold 2 (VSG) name this this VSG DOTS
    7. Everybody happy

    Thanks!
     
    Last edited: May 11, 2020
  23. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    Hard to tell right now. I'm not sure if Unity's goal is to push DOTS as a complete replacement to OOP, eventually. Or offer DOTS as a high performance option for those who need it while retaining the OOP functionality of the engine for those who don't.

    But even if it's the former option, I don't see DOTS replacing OOP soon. The tooling just isn't there yet, and DOTS is rapidly changing all the time. It's not fit for production yet. Also, Asset Store is completely OOP based, they're not about to destroy one of their major sources of revenue. It would take years for asset store devs to rewrite their tools to DOTS. That also applies to all the training resources, literally any aspect of Unity. It's all OOP based.

    Furthermore, it wouldn't make sense for Unity to acquire Bolt if they planned to drop OOP for good. So I'm taking this as a positive sign for now. That OPP is staying here for the foreseeable future.

    Someone mentioned a good analogy - Bolt to DOTS VS is like Shader Graph to VFX Graph. Both do similar things, but not the same way, each tool has its strengths and weaknesses and unique functionality not present in the other.
     
    LaurentGibert and Lars-Steenhoff like this.
  24. OLGV

    OLGV

    Joined:
    Oct 4, 2012
    Posts:
    57
    Picking on one point from @Lars-Steenhoff - NAMING.
    Unity might be on the verge of loosing the plot in terms of naming their tools, if not lost it already.
    + slight concern of loosing it in terms of workflows.

    Google totally lost it with Google Drive (Drive File Stream / Backup & Sync / Shared Drives/ ...Drive FS) takes me 15 minutes to explain to a new team member every time - and they still loose files and the Drive app is crashing their machine... and they want back on Dropbox...

    BUT, back to the point.... look now in the Package Manager - was supposed to makes thing easy, and structured and slowly gets messy.

    Indeed, a more uniform naming convention between these tools and synced with workflows will be great.
    Will help not only all of us but also the education sector.
     
    LaurentGibert and Lars-Steenhoff like this.
  25. EmeralLotus

    EmeralLotus

    Joined:
    Aug 10, 2012
    Posts:
    1,459
    Amazing that Bolt will be a part of Unity. Super excited.

    I have a question regarding the inner workings of Bolt and for a particular use case and perhaps someone might be able to shine some light on this.

    I have an app that has multiple mini games inside. I would like to be able to add new minigames with different graphics and logic in the future . Is it possible to make mini-games with bolt and have these mini-games loaded into the main app during runtime with new graphics and logic?
    ( new mini-games are kept on a server and loaded into main game and saved on the user's device)
     
    LaurentGibert likes this.
  26. Metron

    Metron

    Joined:
    Aug 24, 2009
    Posts:
    1,137
    I suppose the best way to achieve this is through addressables (or asset bundles depending on the Unity Version you're using).
     
    LaurentGibert likes this.
  27. lautebos

    lautebos

    Joined:
    Nov 24, 2019
    Posts:
    2
    Is there a way to download the bolt kits - they were removed from the asset store and I assume that they were deprecated because of support issues with newer versions of Bolt, but they still provide an interesting case study on basic game mechanics with Bolt. They were free, cant we download them from the asset store without the assumption that they would work with newer versions of Bolt.
     
    LaurentGibert likes this.
  28. EmeralLotus

    EmeralLotus

    Joined:
    Aug 10, 2012
    Posts:
    1,459
    I believe that both Addressables and Asset bundles do not support Logic or code inside
     
    LaurentGibert likes this.
  29. EmeralLotus

    EmeralLotus

    Joined:
    Aug 10, 2012
    Posts:
    1,459
    Can some clarify the difference between Bolt 1 and 2 in terms of the inner workings. I thought that in Bolt1, the inner mechanics is based on a graph and Bolt2 C# is created. If this is the case, does Bolt2 still support the Graph concept.
     
    LaurentGibert likes this.
  30. VDecker

    VDecker

    Joined:
    Feb 28, 2020
    Posts:
    2
    Hi,
    I am a user of the Unity Student plan. How and when will I recieve my coupon? Will I be able to try Bolt 2 and give some feedback, too?
    Thanks.
     
    LaurentGibert likes this.
  31. RealityDotStop

    RealityDotStop

    Joined:
    Mar 4, 2013
    Posts:
    42
    I think Bolt is a strong acquisition for Unity.

    Bolt has always had it's critics, some because it is too close to C# (and doesn't have the "do it for you" nodes of playmaker), some that it isn't close enough (where's polymorphism?!), and critics of visual scripting in general.

    But the primary strengths of Bolt 1 as a product offering was that it it "did things the Unity way" and that Unity is the dev engine for everyone. Just like professionals and enthusiasts didn't need a 3D modeler or shader editor, they made sense as acquisitions for Unity. Bolt 1 was strong product, and a number of users learned Unity Dev and C# just by using Bolt. But is utterly overshadowed by Bolt 2.

    Bolt 2 has fundamentally the best "graphtech" and OOP architecture, bar none. And that's what Unity is after. They can incorporate some of the graphtech into their DOTS editor and also get a drop-in visual scripting product that works with every asset already on the Asset Store*, natively. And they can get that in a matter of a few months of effort to polish up the existing work.. The day Bolt 2 lands as an offering from Unity, it is a universal solution that works with the existing architecture, editor, and asset market, generates C#, supports live development during playmode, visual breakpoints, refactoring tools with project-wide GUIDS AND accelerate the development of their DOTS scripting editor, hopefully.


    To my understanding, there's a reason the Unity DOTS editor and Bolt 2 look so much alike. From my understanding, there was some discussions between Unity and the creator of Bolt 2 two years ago. Due some differences of opinion in direction (DOTS vs OOP, I imagine), they went their separate ways. So now Unity has returned and just bought the tech outright. Now with control of the editors, there is no reason they can't write in some bridges from Bolt 2 to DOTS and help users move between the two, all while offering an industry competitive visual scripting tool for the existing workflow.


    *caveat: *almost* all. Under the original development plan of Bolt 2, if you need inheritance of third party asset interfaces or classes, you'll have to generate a simple wrapper. Unity devs might devise a way around that, I don't know.
     
  32. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    429
    @LaurentGibert Hello. Do you have any plans to deprecate the vertical layout of bolt 2? (I am worried because of the recent DotsVS drop shifted into left to right layout.)
     
    LaurentGibert likes this.
  33. IllTemperedTunas

    IllTemperedTunas

    Joined:
    Aug 31, 2012
    Posts:
    782
    I'm completely unfamiliar with bolt, so this was an interesting read. It's so crazy how hidden tools and pipelines can be in the modern era. Here's hoping you're right and there's some top tier talent on these teams cooking up something special for visual scripting which has so much potential.

    I still find it so bizzare we are forced to develop in the same cumbersome environments we were decades ago and the only alternatives are hamstrung tools. It's always seemed like an ego thing among old school coders, that the way they have done it for so long and are so tied to is the end all be all. "If you can't put up with the BS I had to to become competent, you don't deserve to be in this industry".

    The technical revolution that would happen if coding were made more modern, agile, and easily approachable to the masses would be insane. It would turn from a laborious chore into an empowering puzzle game. Imagine if instead of seeing code as some cold, uncommunicative block of fragile glass, word gibberish, it was a malleable and dynamic object with a sort of form that fit its purpose. Getting a little carried away, but it's nice to see some ambitious developments on the code usability front that has been so dormant for so long.

    The ideal situation is not the abandonment of classic code, but a new physical layer for it to reside in. It would be so cool to develop the root code that could spiral off into growing complexities in a node based system.
     
    Last edited: May 10, 2020
  34. Havok_ZA

    Havok_ZA

    Joined:
    Jul 27, 2016
    Posts:
    69
    Basically if you can do it in C# it is theoretically possible to do in Bolt.
     
    LaurentGibert likes this.
  35. v_i_m

    v_i_m

    Joined:
    Oct 24, 2018
    Posts:
    1
    This is good news. Bolt needed help with development. I bought Bolt a while ago, was never able to use it for anything more than basic testing. Both Bolt 1 and 2 are young and buggy and unstable. The overall integration into Unity is kinda rough too. I hope you guys will help transition this amazing product, with a ton of potential, to become stable and production-ready!
     
    LaurentGibert likes this.
  36. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Hi @lautebos, we're working on migrating the content and updating the various resources for Bolt. It might take a little while but everything should be available again soon.
     
    Lars-Steenhoff likes this.
  37. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Hi @EmeralLotus, this is something we will have to look into. We can definitely share Bolt macros and bundle them or make them part of addressable, but I am unsure if it is possible to load and execute those. But definitely something that would be powerful.
     
  38. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    The C# generation in Bolt 2 is an additional capability. It doesn't reduce the possibilities but instead allows to collaborate with developers, or to use the code generated to review and debug graphs. You could definitely use Bolt 2 similarly to how you used Bolt 1 and ignore the code generated all together if not useful.
     
  39. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    As soon as possible, this is being worked on.
     
  40. LaurentGibert

    LaurentGibert

    Administrator

    Joined:
    Jan 23, 2020
    Posts:
    171
    Hi @TextusGames, no such plan at the moment. To be honest we are just starting the conversation around possible design alignment between Bolt and DOTS VS. We do not know yet what would be required to change if anything on one side or the other.
     
    PanthenEye and TextusGames like this.
  41. RealityDotStop

    RealityDotStop

    Joined:
    Mar 4, 2013
    Posts:
    42
    Regarding vertical vs horizontal, it is an interesting change at first, but I think the intent was well founded: a separation of control flow (top-bottom) from data flow (left-right). This encourages users into better habits than the horizontal flow did, where both types of flow moved along the same major axis.

    While we have a spaghetti channel on the discord and enjoy a laugh at ourselves and the occasional atrocity we've committed, it is a real problem particularly for new users and people without a background in coding and the code design sense that might bring.

    A quick skim shows where problems in sharing the same axis can lead users astray (for those of you not used to looking at Bolt 1 graphs, the white lines are the program flow. The other colors are colored according to datatype):
    To be clear, this was actually an experienced user working under a time constraint, and was posted with the comment "Gotta organize it while I still remember what all of this does."

    Making the vertical axis "when" and the horizontal axis "what" is a helpful nudge in the right direction, and helps a person visually orient themselves when inspecting a new graph. Is horizontal flow a bad thing? No, we all used it under Bolt 1 and thought it was fine, but I don't know that vertical should be thrown away lightly, either, as it was an attempt at solving a legitimate problem.
     
  42. andyz

    andyz

    Joined:
    Jan 5, 2010
    Posts:
    2,243
    If this is taking over Bolt to make it quicker and better to develop/support in future then great!

    Hopefully it will be worked on faster than other Unity-bought assets that have been slow to mature - Pro Builder was (is?) missing some very common 3d tool functions & Text Mesh Pro has taken forever to be fully integrated (is it the new font system yet?) - though they both remain fine plugins.
     
    LaurentGibert likes this.
  43. darksilence

    darksilence

    Joined:
    Oct 16, 2014
    Posts:
    16
    Hey doesnt it mean slower production for Unity features for non-Bolt users? I really hoped that it was some code you want to use in your other packages.
     
  44. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    There's this age old Ludiq tweet pre-Bolt 2 redesign that somewhat illustrates your point:
     
  45. Cool_Flow

    Cool_Flow

    Joined:
    Apr 14, 2013
    Posts:
    21
    I understand that it's too early to say where your going to go with Bolt, whether you leave it as paid or make it free for everybody. I can program some things but the more complex things I cannot. I've done plenty of research on Bolt and as someone who can program, but not well, it seems like a complex VS where as most people who want VS have very little to no programming experience at all.

    I'm sure most people where hoping that Unity's newest VS was going to be for complete non-programmers but it seems like you went with a more complex VS with this newest acquirement over something like Playmaker. I understand that Bolt 2 will be coming out eventually, so I can't say if that would make it easier on non-programmers or not.

    If you plan on keeping Bolt or Bolt 2 paid, then I'll stick with Playmaker. While it isn't the most updated with Unity's constant updates and it can be limited on some more complex parts on making a game, it is very simple to start with. If Bolt or Bolt 2 ever becomes free, then I'll check it out, but until then I'll stick with Playmaker which I already paid for.
     
    LaurentGibert likes this.
  46. PanthenEye

    PanthenEye

    Joined:
    Oct 14, 2013
    Posts:
    2,036
    I too used to always look for that thing that would let me code games without having to code games. It doesn't exist. Programming is still programming at the end of the day so I learned Bolt and Flow Canvas/Node Canvas which then enabled me to write C# as well.

    Playmaker while very approachable has a lot of issues. A Playmaker action can be a few lines of code or a lot of lines of code - it often obscures the complexity of the code underneath, which can be counterproductive for learning the engine. Bolt 2 shows a real time C# preview, and the syntax is very close to C# itself. So you can easily problem solve via existing C# resources at Unity Answers or Stack Overflow and follow any C# tutorial or course on the internet.

    Furthermore, any 3rd party store asset or tool outside the engine needs a custom-coded Playmaker integration that all have to be kept up to date. Bolt 2 never needs a custom integration - it can access anything automatically via reflection and use it as needed. Integrating your own C# code or any C# code really is effortless.

    Then there's the way Playmaker forces everything into an FSM paradigm - more often than not my logic is not in a state machine, it's just not how games are generally developed. Not to mention Playmaker not having on exit state, so the cleanup of the previous state has to be dealt with in the next state. It can get messy real fast.

    Playmaker was great for its time. The community support for it is incredible, but I can't see it as a viable option for the development I do.

    Also, if you can code, then you can use Bolt. There's nothing inherently complex about Bolt. Instead of having a library of pre-made actions, you have to develop your own actions in the node editor. It might be more work initially, but it offers unrivaled flexibility. You can truly do anything with Bolt 2 and have native performance at the end of it all.

    + I think we all agree it has to be free. Fingers crossed for that.
     
    Last edited: May 12, 2020
  47. Cool_Flow

    Cool_Flow

    Joined:
    Apr 14, 2013
    Posts:
    21
    I do agree. I'm actually sitting here watching Luqid Playmaker/Bolt youtube video. Yes, playmaker is very limited and I can see the Bolt just gets all the info directly from Unity which is a major plus.

    I hope with Unity taking over Bolt they start making in depth tutorials, cause Bolt tutorials are very lacking.

    With Bolt you really need to understand at least some C# or you'll get really lost.

    For complete beginners making a simple game Playmaker can be easier to jump into, but Bolt would be better in the long run.

    Thanks for the reply, I liked how you broke down the pros and cons, and yes fingers crossed that it becomes free at some point. :)

     
    LaurentGibert likes this.
  48. williamian

    williamian

    Joined:
    Dec 31, 2012
    Posts:
    119
    FYI, Bolt 2 has a vertical flow option should you choose to use it.
     
    LaurentGibert likes this.
  49. whoamiimaohw

    whoamiimaohw

    Joined:
    Mar 6, 2015
    Posts:
    5
    Hi, I have question about bolt FSM update.
    My project have only one MainLoop, this mean is I use only one method take the place of MonoBehaviour Update().
    So, I want to update the Bolt FSM by my self in my game loop. how I do this?
    Or I must create some custom event and use CustomEvent.Trigger to trigger it?
     
  50. hippocoder

    hippocoder

    Digital Ape

    Joined:
    Apr 11, 2010
    Posts:
    29,723
    If I can say anything about anything at all, the vertical approach will always be easier to understand and read so I do advocate that Unity support it by default, and document that by default.

    If people want a mess of hard to read blueprints they can switch to it. But Unity's own VFX is vertical, and Unity's own Shader Graph has a vertical alternative in a design phase, so please unify all these with a vertical approach. It's not fashion, it's simply better and as you currently don't have a visual scripting solution you may as well make the best, most logical option the default.

    I actually would be disappointed if you decided to go left to right by default. Essentially I'm asking that the vertical layout be the default because it's intelligent vs copying something that will eventually go vertical industry wide anyway, simply because you can reason about it instead of backtracking.

    If people did what everyone else did we wouldn't have PBR today, we wouldn't have DOTS today. I'd like a strong push for clean vertical graphing as default option but support horizontal as the non-default.

    Horizontal can be the option, rather than default. I mean you could argue "but we'd attract more customers if horizontal" and you'd be 100% wrong because you can flash the horizontal option at them, while simultaneously pushing documentation and users toward far more efficient workflows.

    You will not need to document horizontal workflows as much, they're widely understood but not very efficient.
     
Thread Status:
Not open for further replies.