Official Visual scripting roadmap update - September 2020

Hi everyone!

Before we get into the details of our updated roadmap, we’re happy to announce the release of Bolt 1.4.13 on the Asset Store, fixing a number of issues, in particular Mac support and Unity 2020.2 support.

We are pausing the releases of DOTS VS but are still developing and maintaining it, as Bolt is being accelerated to progressively merge with this architecture. More details as part of the roadmap below.

Visual scripting roadmap update
About a month ago, we presented our revised plan to accelerate delivering visual scripting in Unity for all of you. Thank you for your input from across the forum, discord, and in one on one meetings. We’ve used this to refine and adapt our plans to serve the needs of as many of you as possible. It is now time to provide more details about this plan, and address several concerns some of you have raised.

Our ultimate goal with visual scripting is to simplify designing interactive behaviors that are as powerful as a script, in order to:

• Enable more creators, in particular non-programmers, to leverage Unity and achieve their goals.
• Improve team collaboration by giving artists and designers more opportunities to work directly in the engine, closer to developers.
• Maximize user’s productivity, by progressively unifying graph-based tools, regardless of the workflow and regardless of the engine architecture.

Here is our roadmap in a nutshell:


Details of our work in pre-release
Our work in pre-release is the integration of an improved version of Bolt 1.4 into Unity as the starting point for Unity visual scripting workflows. The exact list of features and improvements will be more precise as we begin to release early versions in the upcoming alpha and beta versions of Unity, but here are some highlights:

• Unity visual scripting comes as a core package, meaning no particular download or setup steps would be required to start scripting visually, making it very accessible to everyone.
• The team will have fixed dozens of existing issues, as well as improved speed and reliability of several authoring features.
• Visual scripting will support graphs designed with Bolt from the Asset Store, confirming our intention to support the very fast growing community of users into the next steps.
• The documentation is being consolidated, filling some existing gaps such as custom nodes creation.
• More learning content material is also being produced.

Details about our development work
We have already started reviewing the following topics, and in some cases started their implementation. We cannot commit to the timing yet. This list of improvements might not be released in this order.

• High level nodes for non-programmers:
  • Making visual scripting even more accessible by providing nodes that are simpler to use. High level nodes are also not dependent on the underlying API, reducing migration challenges when upgrading Unity versions, or using different project architectures.
• High performance interpreter:
  • We are preparing an interpreted runtime that would significantly improve graph execution performance, cut down on memory allocation, stabilize platform support, and enable DLC graphs.
• Unified UX and workflows:
  • We are preparing the convergence with Graph Tools Foundation, an independent UX layer coming from DOTS VS that we will leverage to align most of our graph-based tools workflows.
  • Leveraging various elements of Bolt 2, we are bringing large performance improvements in the Graph View and Fuzzy Finder.
  • We’re preparing improvements to variable management, addressing referencing through magic strings, strong typing, in order to consolidate and better align with the Graph Tools Foundation data model.
  • Event support will be improved, making it easier to design event-based logic, and allowing you to leverage other modules or packages across Unity such as the new input system.
  • Serialization replacement for improved graph forward compatibility support and performance.
• Monobehaviour and DOTS
  • Our new runtime interpreter brings us closer to DOTS compatible runtime. Coupled with high level nodes and generic front-end powered by Graph Tools Foundation, we are preparing a unified workflow working across Unity architectures.

How can we provide feedback about this roadmap?
We are inviting you as usual to engage with us in this forum thread, or on the official Discord server. We are also preparing a platform for you to vote and share comments about each aspect of the visual scripting roadmap. More information about this soon.

Why isn’t Bolt 2 or DOTS VS being used as the starting point for visual scripting?
Since the acquisition announcement back in May, the number of Bolt users has dramatically increased, and a huge number of graphs are being designed in it as we speak. We consider our duty to support all users in the evolution of the visual scripting workflow and are taking steps to provide a progressive path forward, regardless of the technologies used under the hood. This means we want to avoid releasing a major breaking feature, but instead incrementally improve visual scripting workflows to a level of production readiness that matches the expectations for all projects’ scale.

For the next steps, we have evaluated using the Bolt 2 alpha technology and the DOTS VS experimental package. Both data models and architectures are very similar in providing significant improvements required to evolve visual scripting, including the needs of performance, better scale management (variables, events…), and more global UX improvements.

Both Bolt 2 and DOTS VS technologies will be used in our next steps. Our architectural mix being developed provides the necessary foundation to support workflows for both monobehaviours and DOTS; it will support Graph Tools Foundation, an independent UX layer that we will leverage to align most of our graph-based tools. This is how we can both help all of you navigate the evolution of visual scripting, while delivering the increasing benefits you are looking for.

When would we get code generation for visual scripting?
As part of our conversations last month, many of you mentioned the importance that code generation represents to them, and there were two separate reasons for it: performance, and learning programming.

From the performance point of view, graph-level code generation is not always mandatory, and might in some cases create restrictions to some of your workflows, or even to performance. We want to provide high performance, but also the convenient flexibility to use the same graphs for both monobehaviour and DOTS, and enable you to consider graph updates at runtime that balance performance and interpretation. As part of our next steps we aim at implementing an interpreted runtime that will save the costs of runtime reflection, increasing already the performance by an order of magnitude. Then we would include snippet-based nodes (pre-implemented nodes at a higher level of abstraction) that will be more optimal than an automatically generated equivalent, and provides optimisation opportunities based on the graph structure.

Regarding code generation preview for learning opportunities, we see the value it provides but consider it lower priority in the short term than other aspects such as performance and data model scalability. Graph-level code generation is still part of our longer term plans, so this topic isn’t closed, and will be discussed again.

Does aiming at enabling non-programmers exclude serving programmers’ needs?
We mentioned the intention to aim at enabling non-programmers, and some of you last month felt it was opposing this to serving programmers, or interpreted it as avoiding to deliver programming concepts in visual scripting to all, including artists.

We want to clarify this point. In fact programmers can work in Unity today, but it is extremely difficult for non-programmers to leverage Unity for their projects. This is why we are taking action in this direction. However many of you pointed out rightfully that programming concepts, such as a more consolidated data model, or better type management, are important to consider larger scale production. It would be useful for non-programmers to better structure their creation in order to be more successful, or even learn programming for those inclined to do so.

Visual scripting next steps will contain such improvements, with a particular attention to making those accessible to non-programmers.

What other graph tools would be unified using Graph Tools Foundation, and would we get access to this as a public API?
Unification of graph-based tools brings several sets of value for different reasons. First it is a question of productivity for you, leveraging your muscle memory across the Unity ecosystem. Second, it makes Unity more approachable to newcomers by consolidating practices across the engine. Finally it forces us to architect our various tools in a componentized way that will help us evolve faster in the future the graph-based tools you use.

The UX layer we intend to use for unifying graph-based tools across Unity is called Graph Tools Foundation. This layer is architectured so that we can share it across tools within Unity, but we also intend to deliver it to you all so that you can benefit from this technology for your projects, to accelerate graph-based tools development, and get a large part of the UX aligned with other tools in Unity that users are familiar with.

Our team is currently working with several other teams across Unity, and some of the migrations projects have already started. Shader Graph and Visual Effects Graph are examples of teams that are already evaluating their migration to Graph Tools Foundation, and the conversation has started for multiple other experimental packages.

Stay tuned for more details for public access.

We hope this clarifies many of the questions you asked, and I invite you to tell us what you think. You will be able to get your hands on the first version of visual scripting in Unity as part of upcoming releases of Unity alpha and beta versions.

As always, thank you for your feedback.

Laurent

 

What about those who bought Bolt 1 specifically to get Bolt 2 as promised but now aren't getting it? Using their technologies in the next step isn't Bolt 2, not even close. I've tried to contact support but it has been WEEKS since and I've not heard anything from them.

EDIT: To me it still seems like you're focusing on existing support instead of fixing the system for the future. Incremental fixes here and there to support all the existing Bolt 1 stuff seems to miss out on a lot of the issues on why Bolt 2 was being made in the first place. I understand that it is tough breaking backwards compatibility, but if there ever was a time it would be now.

What about releasing what exists currently of Bolt 2 to those who wish to do their own branch on it? Or creating some tool to convert from Bolt 1 to Bolt 2?

 

Hi @Stexe, I can poke our support team to find out what's happened with your request. Could you please send me a couple more details in private (date of submission, and if it was with this Unity account or another one)?

Thanks!

 

I think my concerns are largely addressed.

Better docs for custom nodes, considerably better editor and build performance, variables and events system improvements, better fuzzy finder too. I'm also hopeful for the mentioned consolidated data model - graphs really need a closer relationship with object scope variables so they can be reused just as easily as macro graphs.

Sounds good! Looking forward to it.

 

Sounds like you're dedicated to delivering a strong VS foundation in the future. Once all the core issues listed "in development" are addressed I will revisit Unity VS. Until then, all I can say is good luck. I hope everything goes smoothly.

 

Thanks for the update, there is one more argument for code generation, some client projects don't accept visual scripting and want only the source in code.

 

Interesting. Can you elaborate on the reasons they wouldn't accept visual scripting from your experience?

 

Visual scripting is less expandable and understood by most people. I do think visual scripting is going to be the future -- just as programming has evolved over the years, visual scripting could be the next step. But it needs to be done properly. I'd hope that in the future Unity can get it right but still seems it is off focus from a lot of what other people were asking for.

 

While I did had some cases like that, the argument always used was that they would need a license to the VS tool to be able to modify the source, with Bolt being free (and soon enough will be built-in) this is not an issue anymore.

 

Excellent update.

I'd like to suggest that a behavior tree implementation be tucked into the visual scripting roadmap at some point: AI is something most games need and is sorely missing in Unity at the moment. I think it can dovetail nicely with Bolt's integration, and can make AI programming more accessible for content designers since they can keep using the same graph system they will be using in the future.

 

Source control is a big one, and being able to do diffs

 

But for me personally it would not be a big miss, for me high level nodes are important and being able to interface with other tools, ( input, gestures, networking lobby etc )

For example triggering particles / sounds from a collision event, or setting a variable in an asset store plugin or shader.

Those basics are what make most of the game play scripting for me.

 

:O

Yas!

 

Thanks, this addresses my needs (Variable hell + Performance). Thanks for listening.

 

Yes, we're having an active conversation with multiple teams, including state machines and behavior trees. We hope to make them all unified with Graph Tools Foundation, which would both make them look and feel the same, and simplify data interop.

 

Good one. We're considering revamping the serialization to most likely use the Unity main serialization component. This should help with things like adressables and graph DLC, and should open up the possibilities for diff and source control.

 

Nice detailed roadmap update. Looks promising. Thank you!

I wish Bolt brings in vertical flow soon. (IMO, It makes a big difference)

 

This topic is coming back all the time in our conversations. So definitely something we should expand on in a future update. Thanks for reminding me!

 

While I appreciate their candidness -- I too wondered about these 'next-steps'.

This...



...is not a roadmap.

These 'next steps' are the bulk of what the "roadmap" is to me (and clearly other users).


A few more details on how things will be 'addressed' in these steps would be nice.
Maybe a simple bullet-list?
One thing I worry about is the "interpreter" part. -- What does that do to performance / ECS workflows?

Interesting. I'd like to hear more.

I just wonder what this means to me, on the ground level, as far as timescales and tool/workflow dependencies go.
For example, there may be "state machines" and "behavior trees" in 'interpreted' graphs, but what about ECS-style graphs? -- Stateful data in a stateless environment is complicated, but a "tagging" system like I've suggested in previous VS drops would help something like this by bridging these interdependent "systems" and attributing stateful data to stateless systems. Yet, how many years are we looking at for this kind and level of integration?

This is just where I am right now -- no really "new" information besides "Hey, we hear you." (which is still important, but doesn't address the above.)


Either way, it really is great to hear that you guys are planning to integrate the feedback somehow.

 

Can't wait for better event support! ...seriously...can I have it now?

And the Graph Tools Foundation is really exciting. There could be all sorts of great features build off of that. Behavior trees. Dialogue trees. Level streaming setup. GameObject referencing in a scene. Great stuff.

 

Hehe, yes this picture is not a roadmap, just highlighting the topics for quick visualization of the categories. We're preparing a better tool to share the details of the roadmap. Something similar to what the graphics team is doing: https://portal.productboard.com/unity/1-unity-graphics/tabs/3-universal-render-pipeline

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.

 

Yes event support is a hot topic for the team. Investigation and prototyping is ongoing.

 

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.

 

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?

 

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.

 

Ah, also: please give some attention to coroutines. They are great for code that need less frequent updates.

 

Thanks for the feedback and suggestions!

 

Thanks, this is important.

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...

 

Also -- Graph Tools Foundation -- is it going to have all the features found here: https://github.com/alelievr/NodeGraphProcessor

 

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.

 

Does this mean all the class-orientation stuff of Bolt 2 will be back? In the original thread I expressed some concerns over doing so exactly as Bolt 2 does it, under Unity's current Prefab workflows:

I do think this is a very, very important to have feature, but to have it working in isolation to the rest of the ecosystem really sucks. It might be the 198231923th time I ask for something to be done in a "more UE4-like way", but that's only because having the insight of seeing something that works helps a lot to understand something that potentially doesn't.

 

Just for correctness, to have something like UE Blueprints workflow we first would need to be able to extend GameObject class (which is the actual equivalent to UE Actor). Which is an idea I fully support btw, never really understood why GameObject class is sealed anyway. But this starts to go offtopic, so I will limit myself to that.

 

Yeah, that would be ideal, but I assume it would require a little more work than simply adding an optional "main component" and reworking the inspector a little bit to support it. Doesn't make that much of a difference either way, I think. But yes, I'd also prefer inheriting from GameObject over what I said.

About this being offtopic, I do agree it goes a little bit off, but my concern connects it enough for me not to feel it's this bad. Problem on feature A is being aggravated by possible introduction of feature B, so feature A and B should be thought of together in order to minimize problems concerning both.

 

Does this mean that Bolt will always have reflection ? And the interpreter will take out everything that's not needed in the build. ?

 

What's the scope of Unity VS? I just assume that every visual script includes at least an FSM as it is what I use and it just makes sense.

 

I like the news and how you mentioned you were going to expand help info for newer users as the current help info was not helping me figure out some of the most basic things. And searching for c# coding help doesnt really answer my questions either. That, to me, is the thing that makes me the most happy about of this entire announcement.
Remember, you are developing a tool mostly for people who dont know how to code so there really needs to be that helpful documentation there. On a side-note. Anybody know where I can go to ask questions about bolt programming questions. I posted a few things over the last week with no responses.

 

I think you and I are talking about something very similar when I refer to "Tag" Components and "Data" Components when I talk about my take on an OOP-like ECS approach.

In my approach, rather than "class-structure" (like Bolt 2), I use logical (dataless) "Tags" to define both the logical scope and behavioral "subscription" to various systems (i.e. a gameobject with a "Player" tag component 'subscribes' to a system such as "PlayerMovement" by simply having that dataless "Player" tag -- letting the systems who care about "Player" tagged data access all gameobjects that have a "Player" tag component via a single query). This happens only at certain times (i.e. when the gameobject has a "Player" tag on it -- which could just as instantly be removed and replaced with an "Enemy" tag, changing the entire scope of the player's behaviors by adding/removing these dataless 'subscriber' tags at any point -- though these 'tags' act as more than simple 'subscribers', as they define the entire scope of the logic you're drilling down into at any given moment!)
Finally, in the systems themselves, I access the actual (localized) "Data" that is associated with gameobjects/entities that bear the necessary scope of my logic (defined by the dataless "Tags" I specify earlier.) The actual "Data" components I need can then be changed at this level (i.e. "Tags = SuperMario, FireMario, etc." and "Data = FireballSpeed, MovementSpeed, FireballSprite, MoveDirection, etc." or anything else that I want to change in that step in that particular system). Ideally, any widespread changes would happen at the system-wide level, but being able to "drill-down" using the "Pages" concept lets graphs become easier to manage, and be reworked easily and effortlessly.

If you're interested, the way I'm looking at writing my gameplay logic is like the following:

Spoiler

1. In a (global) PlayerSystem (system), I specify a query to define the global scope of my behavior that all player-type characters will have. As an example: The PlayerSystem will search for all gameobjects/entities that have the "Player+FireMario" (dataless) tag components, which finds every gameobject (or entity!) that has that particular tag combination. In the PlayerSystem, I've defined "Player+FireMario" as my "global" scope.
   
   
2. Assuming I want to make FireMario shoot a fireball, I can add an additional "Page" to my system's logic which adds another query-level to my query (i.e. "CanShoot"). This means my query now becomes "Player+FireMario+CanShoot", which ultimately defines my "local" scope.
   
   
3. Now, after defining the global scope of my logic, as well as the local scope in the PlayerSystem, on the "Page" of logic titled "Player+FireMario+CanShoot", I invoke a "PlayerActionMap" data component list (which is just a predefined list of data-components attached to the entity/gameobject that is autogenerated from an InputSystem ActionMap at edit-time), then query the InputSystem's dataless "Tag" components (i.e. "FireMarioActionMapTag") and InputSystem's data-filled "Data" components (called "FireballAttackButtonPressed") to evaluate its value within the current "Page" of logic.
   
   
4. Depending on the value of the "FireballAttackButtonPressed" component data, a Fireball entity/gameobject is created (buffered for the next frame) at a particular transform offset specified by the current "Player"-tagged entity being processed. This gameobject/entity is "primed" with data related to the EntityID of its 'parent' entity.
   
   
5. An "InitializeFireball" dataless "Tag" component sits on the gameobject/entity-type that was spawned, where a ProjectileSystem (with its own respective "Pages" of logic, just like the PlayerSystem) looks to handle initializing the FireballSpeed of the Fireball based on its initial tags for movement/etc. To keep things simple, the entity only gets created at the start of the next frame (with any initial dataless-tags / data-values buffered until the next frame). This fireball's ProjectileSpeed can be set by the PlayerSystem to whatever the entity's "FireballSpeed" was upon being scheduled to be created, and the ProjectileSystem can then use this ProjectileSpeed (set to FireballSpeed by the other system) to initialize and manage any movement/behavior in its own "Pages" of logic.
   
   
6. Finally, the "InitalizeFireball" (dataless) tag is removed (in the next frame) by the ProjectileSystem from Fireballs with that dataless tag, and the "CanShoot" tag is removed from "Player+FireMario+CanShoot" entities because they can no longer shoot during the current frame. A Fireball entity was scheduled to be created (and queued up) in the next frame, but when it is marked with a "Destroyed" tag, the ProjectileSystem gives its 'parent' a new "CanShoot" dataless tag component in the current frame (if that parent still exists, otherwise it does nothing) allowing it to shoot again. The ProjectileSystem has a page of logic that searches for any "Fireball+Destroyed" entities and these are removed from the game at the end of the frame by the ProjectileSystem.

Are you guys looking into doing something like this, @LaurentGibert?


The idea here is that this method separates LOGIC from semantics (or, in other words, from syntax) -- which Unreal tried to do, but ultimately ended up failing to do (as does pretty much everyone who tries this who doesn't understand the key to this workflow.)

And the key to a (performant) artist-friendly Visual Scripting workflow is LANGUAGE.


Rather than going in circles over and over about "who do we copy" for Visual Scripting UX, why not listen to some original ideas about it instead? (See spoiler tags above.)
If you haven't read my (admittedly massive) thread on Data-Oriented Visual Scripting: The Structure of a Language -- you really ought to. Don't just skim over it though. There's a lot there. I mainly sort out my thoughts with that thread, but once I do, I can summarize them much more easily.

Spoiler

Anyone who has taken the time to read it, thank you!

If you think it's worth a look by others (i.e. Unity), please say so here!

Anyway, as you should be able to see in my summary above, this is still compatible with the gameobject-centric workflows you guys want to keep. But it emphasizes the entity-conversion mechanism too. By doing so, it adds the extremely-necessary ability to quickly, easily, and logically define scope, while allowing us to work with ECS-like systems and concepts quickly (while also including faster/better/easier-to-understand OOP-style concepts as I've described here).

If you're interested in learning more, just ask -- but I think I've probably just about covered it.

 

Join Bolt Discord and visit the #help channels with your questions: https://discord.gg/FqEaeVu

 

I don't think it does? I've tried reading some of you ideas on that, but it doesn't look like it has anything to do with what I'm saying. I'm pretty much only talking in terms of Monobehaviour-land here, haven't though that hard about ECS here (although theoretically you could just treat a "main component" as any regular component in a conversion-to-entity and do whatever the hell with it, so, there's that).

I do think I kind of like the idea of separating "tag-like ECS components" and data-containing ones into more direct abstractions, at least in the sense of having the editor showing them separately in the editor or something, but I haven't programmed in Unity ECS much yet, so I don't actually know how much it not being a thing is a problem for me. Haven't read enough of your ideas to know if they go beyond that.

It is important to discuss the relation between ECS (and the rest of the DOTS) and VS in the future, but given that it doesn't seem like Unity has this as an immediate priority, I think we should focus on the MonoBehaviour-land, for the moment, and try to make it as best as possible.

 

This is just more of the same from the locked thread IMO. It gives greater detail on their thoughts, but still doesn't provide a timeline, and from my view still smacks of going back on past promises. Again, Unity knows best, and the community be damned. It's like dealing with Atlassian or something.

Whatever. -shrug-