As you’ve probably heard by now, Unity will be getting a built-in visual scripting tool in the future. After being an item on Unity’s public roadmap for years, the tool was first teased at the latest Unite, with no official announcement as of yet.
Of course, we’ve been getting a lot of questions from our users about where Bolt stands in this situation. And naturally, with the little information about the tool being publicly available, we had some questions too, so we reached out to the Unity visual scripting team here in Montreal to get some clarifications. This post will be a quick and transparent FAQ to answer any question you might have.
If you’re in a hurry, here’s the tl;dr: Bolt and Unity’s tool have very different visions for visual scripting, and we plan to continue to develop and support Bolt for the foreseeable future. In the mean time, Unity’s visual scripting tool has reportedly been delayed and has no release date. If you want the details, keep on reading!
No. I was approached by Unity in 2018 to work on the Unity visual scripting team, but because of various reasons (timing, vision, etc.), the opportunity wasn’t a good fit at the time. I decided to keep on developing and supporting Bolt for our growing community instead of dropping the tool to go work at Unity.
There is no official release date announced yet, however the latest news is that Unity’s visual scripting tool will be delayed. Because the Unity team has decided to go back to the drawing board with their core architecture (supporting data-oriented design, DOD, instead of object-oriented programming, OOP), the tool is unlikely to be available in the Unity 2019 cycle.
The latest news from GDC 2019 is that experimental preview builds are scheduled to start shipping on the forum in 2020.1. These types of releases are however highly unstable and mostly meant to gather feedback from Unity users.
Yes! We are currently actively working on Bolt 2, a major new version that includes massive overhauls and new features such as C# generation, classes, vertical flow, tweening, generics, a fresh new look, and a lot more. You can read our public design document, or even already download our latest Alpha preview builds!
Because Unity’s vision for visual scripting is so different from ours (more on that in a bit), we believe it can coexist with Bolt on the Asset Store. As long as we have enough users to stay afloat financially (which we do, no worries!), the Ludiq team has the intent to continue to develop and support Bolt.
In the extremely unlikely event that our sales plummet to the ground after the release of Unity’s VS solution, we would make sure that projects built with Bolt can safely benefit from community updates and fixes by open-sourcing the tool.
This would, of course, be a last resort resolution — so far, we have no reason to believe this would happen. Plenty of amazing premium tools are thriving on the Asset Store despite having native counterparts, like Amplify Shader Editor, Gaia Terrain and Odin Inspector, just to name a few.
No! Bolt 2 will be a free upgrade to Bolt 1 users. We also plan for Bolt 1 graphs to be forward-compatible with Bolt 2 after a short migration process, partly automatic and partly manual. It is likely that Bolt 2 will be set at a higher price point than Bolt 1, so now would be a good time to jump on board if you want to start using visual scripting in your project!
As Unity confirmed on the forum, their visual scripting tool will only work with ECS, because they believe existing solutions like Bolt already are already good for the current OOP architecture of Unity. If that sounds like gibberish to you, it basically means that Unity’s visual scripting will not support the current (and well documented) GameObject / Component system that has been around since the beginning of Unity. Instead, it will be part of the long-term, multi-year effort to radically rewrite the engine with multithreading in mind.
Beyond that, we don’t know much about Unity’s tool, so it’s hard to compare it with Bolt. As we learn more, we’ll make sure to update our comparison table.
Not at all! Bolt is a great way to learn core skills about programming in a fun and intuitive way. Bolt 2 also features live C# preview, so you instantly see the code that corresponds to what you’re creating visually, which is a great learning help. If you get comfortable with Bolt’s visual language, you will be well equipped to handle the additional complexity from ECS, if you ever decide to use Unity’s VS tool whenever it releases.
Sure! They will exist as entirely separate tools in your project, so there is no reason why it wouldn’t work. You could, for example, use Unity’s ECS tool for parts of your game that need extreme parallel performance, while still using Bolt’s easier OOP patterns for most other parts of it.
So far, we’ve held off on announcing anything regarding ECS support because the API is still experimental. Once ECS reaches a stable, 1.0 version, we’ll be able to look into how we can make it interact with Bolt.
In the meantime, we are designing our own class system for Bolt 2. We recognize some of the pitfalls of traditional OOP for game development and we will factor it in our design decisions. However, we also think that some parts of OOP are good, because they provide powerful, easy to understand metaphors for beginners and non-programmers. In the end, we do not want to sacrifice ease of use in the name of performance, so we are designing Bolt 2’s classes with a best-of-both-worlds approach in mind.
We don’t have any benchmarks of Unity’s tool yet, so we can’t compare precisely.
What we can say for certain is that Bolt 2 features C# code generation, which makes it literally just as fast as writing traditional C#. In fact, thanks to Unity’s IL2CPP, the C# code generated by Bolt will in turn get converted to C++, so your visual graphs will actually run as native code on all platforms!
Where Unity’s tool will shine is performance for massive scenes. By using ECS, the burst compiler and multithreading, it will be able to handle games with tens of thousands of similar entities really fast. If this is the kind of game you intend to make (for example, large scale strategy and simulation games), ECS can help you gain performance.
However, if you’re making any other type of game that doesn’t have lots of similar objects on screen at once, ECS will probably not give you any noticeable performance improvement over Bolt or C#.
If you plan to ship your game within the next 5 years, you should not worry about deprecation at all. From what we understand, Unity has the long-term plan of rewriting the engine (and all its modules including graphics, audio, etc.) with ECS instead of MonoBehaviour / OOP. This is, unsurprisingly, a massive endeavour that will take years. So far, Unity has not announced any date to deprecate MonoBehaviours.
Another important factor to note is that ECS is still in experimental state and support material such as documentation, examples, videos and courses are far from matching the wealth of knowledge for Unity’s current architecture. If you are already in production or beginning soon, the MonoBehaviour system is likely still a better environment for the time being.
I hope this helped clarify any question you might have had about the future of Bolt and reassure you if you were nervous in any way. Feel free to join our Discord and ping the Ludiq team if you have anything more to ask. If you’re just starting out with visual scripting, our welcoming community of over 2000 members will also be happy to help you as you get your feet wet — also make sure to check out our ever-growing Learn Bolt hub.
On that note, I’ll head back to developing Bolt 2!
— Lazlo Bonin, Lead Developer