The interpreter is all about skipping the costs of reflection, while keeping a very flexible approach at runtime for potential graph DLC. I’ll ask the team to explain in more details how those things would be working in a future update.
Thanks for the update. Could you clarify what Graph Tools Foundation does better/different than GraphView? Is it “just” GraphView + serialization and graph processing, or a “competitor/successor” to it?
I looked at the preview package for GTF and it seems to be tied very closely to visual scripting (just recently being renamed), so curious what the steps are there and where this is going.
We will expand on this in a future update for sure. I’ll try to get a member of the team to come by and comment for the technical aspects, but in a nutshell, Graph Tools Foundation has been extracted from visual scripting, and was historically branched out of graphview, and evolved faster. So now progressively graphview based tools are considering upgrading to graph tools foundation to take benefit from the architectural and quality evolution.
Awesome stuff. I’m pleased and most of my questions have been addressed in one way or another. Will we see a return of generics/delegates/actions support? That really blew everything wide open as far as no longer needing to use code for interfacing with third party.
Yes, that’s part of the investigation/prototyping going on for events support. We need to provide a built-in mechanism to invoke a visual scripting graph with various entry points not available out of the box in the current Bolt 1.4.
I’m a programmer that was pretty disappointed with Bolt 1, in terms of both performance and flexibility (object model, largely). We wanted to use Bolt 1 so our artists could actually design interactions, but found it vastly too slow and too cumbersome for mobile.
I appreciate the desire to build a fast interpreter. However, we also found that Unreal Engine’s blueprint interpreter was vastly too slow on mobile, especially when you talk about making entire games in visual scripting. Interpreters on mobile platforms tend to be pretty slow, by orders of magnitude, because of the Arm architecture.
So that’s all to say that a ‘fast interpreter’ is something that lots of programming languages have attempted, but at some point they eventually just implement a JIT compiler or full native code generation. You might consider simply starting with a JIT (like C#) rather than building a slower interpreter that will need to be retro-fitted.
Edit: If you’re building a custom interpreter, why not just output .NET IL directly? Then you could take advantage of IL2CPP, C#'s object model, and even things like Burst.
We hope that having a single graph able to both work for monobehaviour and DOTS will make things productive while adding another weapon to runtime performance, especially on mobile.
Regarding JIT, that’s not always an option depending on the platform you want to publish to, and the type of app. We’ll try to make the tool flexible so you can tune it for the most efficient scenario for each project.
@fherbst Graph Tools Foundation is based on GraphView. It was first developed by the Visual Scripting team but we are working on removing all VS specific code to make it an autonomous graph UI framework. The main differences with GraphView are:
more flexible UI definition (no more using UQuery/tree walking to alter the UI)
UI is expected to be backed by a model (GV did not care and sometimes tried to do the model job)
a extensible mechanism for updating the UI from the model and sending changes from he UI to the model, with undo/redo support
The plan is to support all graph based tool in Unity, so you can expect common functionalities to be provided by GTF.
Thanks @patrickf . Is there a dedicated forum post for GTF? - if not, could you create one so this thread can stay about VS and I can ask more questions?
JIT is not an option on mobile - that’s one of the reasons IL2CPP exists.
Codegen is great in standalone builds, but implies rough workflows in the editor (domain reloads and all) ; we’ll need a (faster than the existing one) interpreter anyway for editor builds and code-less updates. Also, codegen is not trivial to implement or iterate on, but it’s easier to do once you have a reference implementation (in that case an interpreter used across dots and gameobject land). That makes it a reasonable starting point in my opinion.
I think a good interpreter can go a long way - just look at all the AAA games shipped with one. Now we’ll see once we have numbers to show.
Right, my point is more that all of these other languages (including Blueprints) were so slow that they needed to add a JIT or compilation step. For example, the vast majority of Unreal projects I’ve seen that are heavily blueprint have a very time-consuming “re-implement everything in C++” phase of development, where the engineers have to go rewrite all of the blueprints in C++. I’m worried this will be the case here.
I’m happy to talk more in a 1-1 about some of the experiences I’ve had with blueprints/bolt, if it’s helpful.
If you’re building a custom interpreter, why not just output .NET IL directly? Then you could take advantage of IL2CPP, C#'s object model, and even things like Burst. Edit: I see the point about avoiding domain reloads, though.
It would be great if you could make the graph optionally accessible to the player so they can mod exposed part of our game. Currently exposing modding is a lua dance.
Also fast graph evaluation makes me think of behavior trees. Is there a way that we’ll be able to make nodes such as sequence, utility decorators and prevent graph cycles within boundaries (begin/endBT node)? A unified graph for all things script and low level AI would be amazing.
Modding is a very good point. We’ll take note to clarify this aspect.
Performance-wise we do have a conversation going with teams building simulated agents for ML use cases, we’ll see how much they need to make the usage of visual scripting worth it.
Can I say I find your link “DON’T CLICK THIS” very clever
Potential user studying migrating a game under development to Unity here, watching videos and following tutorials, so my feedback will mostly be based on the docs and videos I’ve watched these days about Bolt, and also Shader Graph etc)… and as a user comfortable with blueprints node graphs. So my thoughts:
It’s great to see this design vision of unifying node-based tools in Unity, so that all have the same visual cues, shortcuts, workflows etc. As said, spares a lot of muscle memory, and also makes the program feel more unified, simpler. After all, node based scripting is a general paradigm, so why not generalize the implementation ‘layer’ of it?
I like a lot node-based tools for fast prototyping. But also scripts have a strong appeal because of their simplicity and the feel of ‘seeing the guts’ of the gameplay. Simplicity will always be elegant in design. And I agree that the terms be equivalent to programming terms, to better educate non-programmers and act as a starting point for those wanting to learn to program by typing later on. Because this way one will only transpose the practice/approach but retain the mindset (variables, functions, methods, coroutines etc etc).
This the topic mentions of code snippets is what I was about to suggest - ‘custom nodes’ in the graph where you can type C# code, and its declared variables become node input pins… return type becomes ouput pin etc. This can be great to make graphs tidy also, if possible to have.
My two cents (if you’re not already working on things like these):
keep and invest in Bolt’s feature of being able to create graphs during play. Maybe also an option to keep the changes in the clipboard and apply after stopping play mode. Also some sort of cheat code console, for testing (teleporting player, spawning, changing character stats etc).
a tool to, for example, marquee select some nodes in a graph, during play, and press say Ctrl+Enter to execute only them. Like you would do in maya’s script editor (but with the game loop running, of course). This would be great for learning and quick tests while trying out nodes available.
also, related to the above, a tab in the node graph to act like a scratchpad. To keep those temporary node graph sketches at hand. Again, like in maya’s script editor lower pane.
The look of a node graph implementation also is important to appeal to artists. Shader Graph for me, personally, look slick, cool. Hope it will go in that direction.
If actually migrating to Unity, I intend to use a mix of C# scripts and node graphs. I like both, so I will test both to see.
Thanks for the news, roadmap update.
An “interpreter” would be at build time (by default) and used only optionally at runtime (for DLC, etc.) right?
DOTS as the basis of everything else seems to give an opportunity for this (unlike in other packages), doesn’t it?
Coroutines are essentially just ECS systems – Why not just simply build-in the ECS workflow?
Speaking of the ECS workflow – DOTS VS drop 6 actually had a few users doing videos on how to do ML with that build. It seems to have been before your time on this side of the fence, but it was pretty darn cool and had me really excited for the possibilities of using an ECS-based workflow. I hope this is still being looked into. I see no mention of it above…
It is a little early to expose the details of Graph Tools Foundation, the short term goal is to drive the convergence of workflows for Unity teams, and then make it available to all. So more info to come in the beginning of next year I believe.