Official Visual scripting roadmap update - September 2020

I tried to get a refund or the previous version of Bolt 2 before it was sold to Unity. That's what I bought Bolt 1 for and if they won't at least provide me with a refund they should give me what was left of Bolt 2. Doesn't matter if it is buggy and unfinished -- they should be keeping their promise as stated.

 

There is a add-on that will do a lot, Esp with the new announcements for Bolt going forward.
Ad-on will write c# from Bolt one.. and a lot more is planed.
https://forum.unity.com/threads/fre...to-compiled-c-generation.918518/#post-6231285

 

Can someone with good knowledge tell me more about this sentence ?

Did visual scripting will convert the bolt graph ? Or it will stay the same, with the stability/performance problem or it will correct it ?

I don't have enough experience with bolt2 and neither on the first one, nor the unity visual scripting solution, so i'm curious about the fact that the work on bolt 1 could be used on the new unity visual solution ? could the experience gained on bolt 1 will be usable on it since it will not be really bolt 2? could i use the work i have done on bolt 1 on the new unity system without any loss ? Will i need to "rewrite" some of the bolt visual ?

I use unity 100% as a hobby, and it has been a year since i have started to follow the news around bolt because bolt 2 was looking so promising with the c# generation. So i want to know if it's better to stop now and wait for visual scripting and work with it, or i can keep using bolt 1 ?

 

My guess is that it will probably be supported as a "legacy" workflow eventually.
Unity will probably aim to support its own workflows simultaneously alongside Bolt 1 (i.e. in parallel) using its own nodes or replace the Bolt 1 node functionality entirely (under the hood) -- while letting the nodes themselves remain.
Another option is that both kinds of nodes might have their own respective Graph type (i.e. Monobehavior Workflow Graph vs. DOTS/ECS Graph Workflow) so that the nodes don't link up, but potentially have "conversion" nodes that link to each style of workflow graph (which could be handy for backwards-compatibility), and a "bridge" system, like I sort of describe above (in my previous post) could do the conversion for these graph conversions by way of those sync points I describe.

This is just my take -- but I base this on them being able to change the entire functionality of the underlying code, and just converting it to higher-performance runtime code for execution that is seemingly independent of the nodes themselves. If I remember correctly, they are going to auto-generate the low-level nodes for some higher-level functionality (i.e. probably something like the InputSystem functionality and/or StateMachine / BehaviorTree logic -- which would be fairly standard in a Bolt 1 style workflow.) Doing an ECS workflow for Monobehavour would probably need some restructuring (behind the scenes), but the overall flow of logic would be pretty much the same, and therefore be pretty straightforward in user-land, no matter the backend processing methods used by Unity's interpreter. The only incompatibility would be the underpinned technology constructs that allow this logic to flow -- i.e. is it better processed all-at-once, or one-at-a-time.
This is really the long-and-short of the most optimal solution anyhow.
I need to control "when" my logic is processed more than "what particular bit" is processed. I need to specify whether it is more efficient to defer some parts of my logic to the next frame / CPU cycle, or whether it is better to get it done right now, as fast as possible -- all at once. This is where the ECS workflow breaks down for a lot of people (and the main reason why it seems to be incompatible with Monobehavior.) In general, when dealing with nodes -- timing/step-by-step/dependency functionality is not straightforward.
However, logic itself actually is straightforward -- and our workflow needs to be based on this.

This is why you should be able to say "Do this particular thing with this particular entity at this particular point in time" -- about pretty much anything -- except "this particular thing" simply refers to "doing something with everything that has a particular set of traits (or dataless 'Tags', as I refer to them)", while "this particular entity" refers to the specific thing that HAS all those particular "traits" -- at a "particular point in time" -- i.e. during the current / next CPU cycle, at synchronization points during the next frame, in 10 seconds on the next available CPU cycle, etc. etc.

 

I own unode. i cant get past the UI... still using Nottorus...

but will give it a try again, seems the UI as a bit more updated since last time i used it

 

Does this mean we might see slower maintenance updates for current graph-based tools (i.e. Shader Graph and VFX Graph) as their respective teams focus on migrating to GTF?

Also, should we expect any breaking changes to existing workflows?

 

Hi @BeifongSaeko, thanks for the question. So far everything you do with Bolt 1 will work with the visual scripting integration in Unity, it is one of the foundational elements of our roadmap.

When improvements such as performance increase will begin to get released, you will get access to it automatically with the graphs you are designing today.

In the future as we introduce more high level nodes, you will have new opportunities to build graph faster and in a more flexible way, but existing graphs would still be running as usual.

 

One major theme of the work currently happening toward 2021 is quality and performance. As such I know for a fact that Shader graph and VFX graph teams are investing a lot of effort to fix the issues that had been raised for those tools.

The migration to GTF is not expected to break things, but in fact being a progressive migration in several steps that should increase the overall quality and performance of those tools, by joining our forces on maintaining a shared architectural foundation.

 

Thank!

Thank for the quick answer, glad to have one from the team!

Well so far i was disappointed with the choice not to ship bolt 2, i'm happy about what i read here.

Just one more question, when you say that :

If i understand well, we can still work with bolt 1, alongside some updates who give us more performance and stability until the unity visual scripting come, then everything done with bolt 1 will be compatible with it and we can switch to it and keep all the work done on our projects with bolt.

Will there be an interest in performance/stability to redo some of the graph with the new system once it's out or the compatibility/conversion will maximise it ?


I'm sorry in case my questions dont make any sense, i'm kinda low skilled.

 

The official ShaderGraph of Unity3D has great deficiencies compared with ASE in many aspects of humanization.

For example, to create a simple Texture2D node. I need to first create the Texture2D node in the public panel, then create another Texture2D node in the working panel, and finally Link the two together. Neither ASE nor SF, which is already open source, need to operate so many times.I think it's like pulling your pants off and farting.Also, SG has no shortcuts you can customize.
Why take three more seconds to do something that could be done in one second?

Specific Unity3D official can do a survey on the comparison between ShaderGraph and ASE.


One of my concerns is whether these issues will reappear in the Unity visualization scripts.It would be disappointing if this dehumanized design emerged.

I would also like to suggest that vertical workflow be implemented in the next big release, which is closer to the programming concept.

In addition, there are still too few tutorials and instances.
When will the specific timetable for the road map be announced?

 

@LaurentGibert I understand you may not have direct contact with the Animation team, but would you happen to know if they've considered decoupling the Animator state machine from Mecanim to be used for broader purposes (once GTF has become production-ready, of course)?

 

I feel like I keep getting mixed-messages here.

Is this because of the high-level nodes that our new opportunities to build a graph are "more flexible" -- or is it something else?
As far as I understood it, we wouldn't be roped into a C# specific workflow "in the next steps".
But this statement seems to conflict with that.
Am I to take it that everything is going to be based on a C# OOP-based foundation (as Bolt 1 was) simply with higher-level node constructs built upon it? -- i.e. An "Input + Movement" node rather than just separate "Input" / "Movement" nodes (without ECS-like workflow support?)
Or is the "more flexible way" you're referring to the overall workflow variety, such as a different underlying structure of the workflow (as opposed to just another "layer" of nodes? -- i.e. instead of "Super Units" alone, we will have additions that let our workflow be more ECS-oriented -- such as the "Tag/trait" style system/nodes I've described previously. I ask because it's very possible (and simple) to build "Tag/trait"-based nodes that Systems pick up upon entering playmode that let you structure actual LOGIC (and timing) of your data progression rather than just underlying syntax-flow. This is A LOT more helpful to game design and project structure than simply being able to rearrange the nodes.

To reiterate a bit on how the "Tag/trait" approach I'm referring to will help, see these two bits:

First, the summary:

Then the details:
https://forum.unity.com/threads/vis...ate-september-2020.978732/page-2#post-6377340

 

@LaurentGibert I want to stress how important this is for building projects at scale with more than a few collaborators.

• Dealing with what would otherwise be simple diff, merge, or merge conflict resolution in traditional human readable code becomes a very tedious and manual time consuming process in visual node scripting / programming environments.
• It severely limits how many people can realistically be working on the project at the same time (realistically 1 to 3 that are in constant communication about every change)... so you often end up locking files that only 1 person is allowed to work on at a time, and splitting up functionality into multiple files / graphs for no reason other than to try and reduce the amount of conflict and collaborative blocking.
• Even if the serialized node graph representation is stored in plain text (e.g. JSON describing node edges and properties,) it's more or less incomprehensible compared to human readable code, and manipulating it in text representation can be very risky.
• This is easier said than done to solve this perfectly and satisfy all use cases (i.e. a visual graph and textual code representation that can translate losslessly both ways... it may take an entirely new language for this, see Enso formerly Luna.)
• Regardless, It's fair to at least expect Unity to provide its own integrated visual diff tools for Graph Tools Foundation as a baseline solution. Epic already has this available for Unreal's Blueprints. Without it, many teams would refuse to work with Blueprints visual scripting or greatly discourage and limit its use on projects (much more than it is already) : https://www.unrealengine.com/en-US/blog/diffing-blueprints

 

100 times this. You can't build any sane workflow until this is available.

 

Will this all be available in 2019 LTS? I've read the intention is to develop it with frequent, incremental improvements/releases, but I also see there are large changes being made and, with tighter integration with Unity, I'm starting to doubt it's going to look incremental from where I'm standing.

 

C# cannot be used in conjunction with bolt at all, because their variables are not interoperable at all!

 

? https://docs.unity3d.com/bolt/1.4/manual/bolt-variables-api.html

 

Dear god, please. Please let the graph foundation be run at runtime for game mechanics. It's simplifying a huge amount of potential ideas needing graphs, like letting gamers program a robot boy character. Dear god, please. <3

 

Keep the mix with FSM

 

I understand that the majority of the user in this forum are programmers, some with more experience than others, and pretty sure almost all of you know basically knows how to code, knows about functions, variables, operators, and all sorts of things, and that's awesome. I have tried several times to learn to code, but I have failed miserably I'm pretty bad to memorize words and numbers, it's a condition. As a non-programmer and a very visual learning person, I will like to know if it will be possible for the Unity team to make a Bolt version more non-programmer oriented? something similar to GameCreator or Playmaker where the user can have these pre-configurated functions created as Super-Units or States Machine with related basic game functions listed as character controller, enemy AI, camera types, logic with triggers, UI, etc, and where the user just drop-in this pre-determined actions and build the logic from there, at that level the user doesn't need to understand how the coding language works but from there the user can dig into the inner levels of that Super Unit and maybe this help to learn how basically the flow and functions works and start modifying to their need.
Thanks,

 

I mean, bolt cannot get and set the variables of c# script.

 

Of course it can. Bolt would be nearly unusable without being able to do that.

 

https://docs.unity3d.com/bolt/1.4/manual/bolt-variables-reference.html / https://docs.unity3d.com/bolt/1.4/manual/bolt-variables-api.html

What are you talking about? lol. It has Get/Set stuff from scripts.

 

Go to Tools/Bolt/Unit Options Wizard, add C# scripts there as new types and regenerate units. Bolt will grab all public methods, variables and properties and automatically generate nodes for them. Once units are regenerated, your C# script variables will come up in Bolt's Fuzzy finder like any other node.

An alternate way of doing this is to use [IncludeInSettings(true)] attribute before a class and after compiling the script run Tools/Bolt/Build Unit Options. The attribute lets you skip the Unit Options Wizard GUI step and grabs your types automatically.

This way Bolt can access any C# API, either for store assets or your own code.

 

is bolt the name of unity visual scripting from now and up
and does the next steps be built from bolt 1
i mean does the next step will be a bolt 1 update

 

thanks!

 

Adding some more voices on the disappointment over the direction Unity is going with scrapping Bolt 2 and focusing on Bolt 1 and supporting existing content instead of advancing the visual scripting stuff forward.

Multiple YouTube creators I've talked to have expressed their disappointment, frustration, and anger over it. They either already were working on Bolt 2 videos, had published Bolt 2 videos, or were about to start Bolt 2 videos when all this stuff happened. Really feels like Unity pulled the rug from under the community. This update is a step in the right direction, but it is still 5 steps back and only 1 forward.

 

I still say simply open-sourcing Bolt 2 to the community would do A LOT to alleviate this problem.

 

Now, Bolt 1 feels boring and cumbersome to work with after getting used to Bolt 2 workflow. It was more elegant and so intuitive with classes, variable management, vertical flow, and lot more. I am finding it less fun and demotivated : /

 

(Followup on my love for Bolt 2.0)
I am going to take a break from Unity and Bolt until the next announcement.

For what it's worth, I spent some time comparing the workflow and graph of Bolt 1.0, Bolt 2.0, and Playmaker. Here is the result of it. Bolt 2.0 is a winner for me.



I still adore this old concept mock of Bolt 2.0 released by Ludiq, this still excites me to even look at it
I really hope UNITY makes VS closer to this concept somehow.



I am a designer who cannot code, I found Bolt 2.0 to be promising and that made me spend ~6 months experimenting and learning it. I was totally enjoying the process even though it was on alpha. But now I have reached a point I don't even have the tool and have to wait a while to see if the future of BOLT with Unity is still the right tool for me. I do believe the team at Unity is doing their best to make it a powerful and a great tool for users like me.

 

I thought the Bolt 1.413 was suppose to fix the Mac issues, but it's still broken (Not being able to add any node) on all 2020.x. Still only works up to 2019.x. Did I read the announcement about 1.413 wrong?

Anyway, I was wondering if the general target for the performance updates are for Unity 2021? Does that mean we shouldn't expect too much updates during the 2020.x cycle?

I have not been a big fan of Unity sticking with the Bolt 1 as a base rather than the Bolt 2. However, as long as Unity understands the performance being a really important concern, I will eagerly wait for all the future improvements to the Unity Visual Script. I do have to say the possibility of Tech-agnostic (Monobehavior or DOTS) nodes is exciting.

 

Performance is a big one, but the lack of some features that are core to Bolt 2 are just as important:

• Classes
• Vertical flow
• Generics
• Delegates
• ... and more
  
  

 

I did like the Bolt 2's approach much better of course, and also more extensive feature sets you've mentioned too. But they weren't the reasons why I didn't use Bolt 1 all this time. After all, plenty people use various VS tools like Playmaker without generics and Vertical flows what not but still produce stuffs by getting around the problem. You might have to do it much more cumbersome ways, but If there is a way, people will make games.

I got stuck trying to use Bolt 1 before, and by far the biggest reason was the performance. Even with Playmaker, I was able to make an OK performing casual games and tools. But the Bolt performance was just not workable for me. Especially considering that you do indeed have to do a lot of work-arounds for missing features of course, then the missing performance is even more crucial.
Simply put, if I have to chose Bolt 1 with no change whatsoever but the 10 times the performance, VS Bolt 2 but slower, I'm choosing Bolt 1

BTW, I've been bitching a lot about the Unity team's decision regarding the Bolt 2. Quite a bit I suppose . But I do appreciate their efforts trying to unify the workflow, even though I may disagree with this specific instance of their choice. I really feel like the Unity's problem has been the messiness with all the different features and workflows clashing. The usability had been just really crappy. Don't get me wrong, each individual features' usability had been great. But the overall usability of the whole system had been really messy and chaotic. The fact that there are 3 different rendering work flows and they all work differently (even after 3 years of announcements), is insane to me. And because of these messiness and clashes, that I feel like Unity does take much longer to settle in with features than before. When Unity mentioned "performance by Default" and "Multiplay by default" I was very excited, but even after 4 years, I still don't feel that unity is much improved in performance by magnitudes, and certainly Unity games are not expected to be multiplay games by default... at all.
At the least, now Unity teams recognizing some mess ups, and trying to consolidate and make proper sacrifice for more tight integrations and faster developments, I'm all for it, so I do appreciate their efforts.

 

Sadly it seems it takes years of complaining, and complete dumpster fires for them to address anything whether its visual scripting, renderers, etc. I for one will never let go of the fact they trashed Bolt 2. It's spitting directly in the face of everyone that was supporting Ludiq before hand and helping build Bolt 2 into the product it was / was becoming. It's Unity's right as a business, but outside the fact I am too financially invested to turn elsewhere (for now), I lost all respect for Unity with this move. And they will never win it back.

-N.

 

I'm with a similar mind. I'm trying to reach some of the internal teams to see if there's a possible solution but it has been a couple weeks without much info. We'll see how it goes and I'll update here as I learn more.

 

I feel a lot for th Ludiq team who worked so hard on bolt 2. Sure it wasn’t perfect but they sent their product into the world to be bigger and better, and now it almost feels like it’s in the icu waiting for some form of diagnosis and plan.

While there is a plan bolt will never be the same and right now it doesn’t feel so much in a good way

 

A bit late to the party. I have not read the entire thread yet.

It looks like some of the much discussed issues were taken into consideration.

"Event support will be improved, making it easier to design event-based logic"

I would love to see where that will be going.

Please provide some super easy to use event workflow.

To get a better idea about how this could be useful to everyone, even an architect or a car designer, please look into how VRML interactivity is delivered in 3dsmax. A philosophy so simple and straight forward that even someone who first opens a game engine could figure it out with minimum effort. i.e. see how Touch Sensor or Anchor works.

In 3dsmax, you can create a fully functional world, with transitions, animations, dialogues, AND it includes a basic camera controller too with 2-3 different operation options. You can change materials, swap objects, etc etc etc. just by using these few interaction blocks.

 

Have you tried the discord server?
Some members of the team can often be reached there, and you could talk to them directly.

If you are a paying customer I suppose you could use proper support channels?

 

This is kinda neat in the fact that they include LOD as part of the "base" framework. I've been saying for quite some time that SceneVis and the like should include object-level visibility (terrain editing, open world streaming, etc.)

In fact, let me make it extra-official:


"SceneVis / LOD / Object-level" Visibility (VisualScripting) Team-up Suggestion (Attack!)

@LaurentGibert :

Honestly, ShaderGraph should probably merge a bit with SceneVis (i.e. Scene/GameObject Visibility) in the sense that it handles LOD in a visual script and shader-based editing environment (i.e. scriptable LOD and culling systems, with an interface akin to DOTS VS for example) to handle all of this LOD stuff at the shader and/or object level, respectively. I think you guys should work with them to provide a scripting interface to "plug-in" to the shader/LOD/visibility processing for offsetting scenes (i.e. when transforming streaming worlds via floating origin, for example).

You say you're working with other teams, so this should be an extremely important team-up. Even 3dsMax/VRML in the 90's had LOD processing as one of its most foundational implementations of one's 3d worlds. I think Unity is currently taking hardware power for granted, at least right now. But games are only becoming more geometry-heavy, and simple visibility / LOD / streaming processing is becoming more and more complex. Being able to script LOD is vital, and having as much control over how that LOD is executed is just as critical.

 

Yes, I have. I've approached multiple of them from many different channels. I got some feedback but haven't gotten all the issues resolved yet.

 

Following up on this after the abandonment of Bolt2, I'm still pretty disappointed with this roadmap. I hope you can really deliver a well-integrated and performant visual scripting during the 2021 cycle.

I'm an engineer, but I support many developers that are not engineers (designers, animators, artists, etc.). To me visual scripting allows for a decent way for designers to perform logic (primarily if/else) to check against conditional logic as well as calling specific methods to drive the gamestate. As well as potentially a way to drive things like cutscenes or animation states changes with behavior trees.

From what I understand (there isn't a lot of good documentation for custom units), there isn't a good way to drive custom inspectors for these custom units. I'd like to be able to reuse UIToolkit/IMGUI behavior from the editor inspector for these units. This would allow us to reuse custom property drawers and pickers for data values on custom units.

For example, we have our own global variable system that I would want to create a custom node for designer to pick a global value for example. There isn't really a great way to support this currently in bolt if it is not a direct 1:1 mapping of a Unity object or to have the user type in strings. Neither of these options are preferable. Our data is all GUID-driven and is not based on scriptable objects so we have a custom picker and property drawer for our data currently for inspector purposes that serializes the picker down to a GUID. We'd like to keep this type of behavior in a custom unit that would pick a global and serialize the value has a GUID that we can then feed into a script call.

I think having a clear custom unit base class, and having a property on the class that defines the UIToolkit node layout could be very powerful and I hope you're considering it.

 

I only realized this the other day, but the thing about UI Toolkit is -- it has a hell of a lot in common with my (dataless) "Tags/Traits" concept:





@LaurentGibert and @theor-unity:

I again want to apologize.
I was having a difficult time trying to find an analog to what I was trying to convey in earlier posts. However, I just happened to realize (thanks to @Ferazel's post) that CSS selectors were the best analogy to the behavior I was trying to describe with my "Tags" system.


In other words -- UI Toolkit has a concept of a "selector" (which, essentially, defines the "scope" for the code / visual elements to act upon). This is pretty close to the equivalent of my "Tag" concept, which can be seen used above to "select" the behavior and/or type of entities/gameobjects.

The behavior, as with ECS systems, can simply be written elsewhere (i.e. a node network) and then enabled/disabled via a simple click.



PS:

Unlike a straight 1:1 copy of the CSS selector concept, my "Tags" concept works (conceptually) like USS does (to some extent) with its "binding" concept, which also lets you define "Traits" as well as "Behavior" by loosely "binding" them together with dataless "Tag" components (rather than directly with a script), which lets ECS-like Systems remain separate. This fact is extremely important for a highly scalable codebase.

This fact is also precisely what C# missed when it tried to implement its own version of an OOP-style language -- and was the reason why I stated in my thread that ECS-OOP was a better OOP language than C#.

 

@LaurentGibert , @theor-unity, etc.

Also, adding to my above post -- compiling an object/entity "Tagging" / (CSS/USS) "selector" style system (like the one I explain above) allows one to easily make diffs, merges, etc. -- as all data is essentially still "text-based" references, and the modularity it affords also affords some really nice tricks in how you visualize those merges!
The binary / editor-only "Tag" or "selector" references allow systems to point to them (rather than them point to systems) -- These ECS-like Systems built from selector (and timing-based) small, concrete, text-based, parallel processed ECS-like data blocks that change over time, rather than per-node (with all timing based on lockstep, bridge-systems, tagging, and the Unity "API-to-data-block" conversion process) -- rather than abstract, unknowable, nodes.
I could get deeper into this and explain it better with visual diagrams, but I'm not sure you're listening yet.

---

This process keeps you (and us) from having to do some fancy interpreter-specific garbage for every possible custom node / DOTS-specific difference there is from the existing Monobehaviour approach. It would also enable you to keep using some Monobehaviour stuff, and change it out more slowly over time (when you're ready) -- while keeping that particular transition part as frictionless as possible. And in that process, you would do nothing else besides simply converting Monobehavior stuff to DOTS mindlessly -- and you could even do Monobehavior conversion with VISUAL SCRIPTING (gasp!) -- since it would be the equivalent of code to the underlying interpreter already. The only change from what you are doing now would be the (basic) structure of your language.

Now where have I heard that before...? -- Hmm...


Besides...

Not only is the custom node "snippet-based" approach NOT as scalable (or as diff/merge-friendly) as a selector-style approach (i.e. the "Tags" I keep mentioning), it pretty much MANDATES an interpreter-specific solution for every possibility, which means every possible custom node will also need an interpreted version (likely made by Unity in an invisible/automatic/limited way) to send that new node "snippet" to the compiler. This limits the overall capabilities of the nodes themselves!! -- (i.e. no UI Toolkit nodes? whaaaaaatt?? -- types of threads).
Beyond this -- the approach is also not artist/designer-friendly either.
Have you ever heard of something called "flow"?
Why yank us out of our visual scripting FLOW to drop in some compiler-centric text in here and there?
Who the hell wants that??
Many artists/designers are terrified of text-based "programming-looking" stuff -- and rightfully so.
Look at any Assembly or C++ programs -- that S*** looks terrifying.
Plus, not only that -- as said above, it would put undue work on you guys to ensure you've made special "behind-the-scenes" nodes that work with EVERY possible scenario (due to the MANDATE of the interpreter "snippet" solution).

Sorry, but as far as I can see -- the current approach is simply NOT future-proof.
Please -- correct me if I'm wrong, but I've looked into the design for a Visual Scripting solution quite heavily since the 90's. What it sounds like you are doing is passing-the-buck on design to the next group of people who will eventually have to redo most of this system from the ground-up -- all because the foundational 'design' is faulty and short-sighted.

Look -- I don't mean to be hard on anyone (seriously, I think you dudes and dudettes are awesome!), and I know this stuff is still experimental -- but there are some very clear constants here that don't have good solutions with the roadmap you've presented.
People like @Ferazel are pointing out glaring issues -- as are others. And "we'll get to them eventually" isn't a good enough answer for people -- especially after S***ting on people's hopes so hard by trashing Bolt 2 so suddenly.
There are glaring issues here.
Issues you (or someone higher-up?) clearly doesn't want to look at.

However, these issues are foundational. -- and even Bolt 2 didn't solve them.
I don't want to laugh to myself two years from now and say "I told you so!" -- but if you don't hear me out now, that IS what's going to happen.
And everyone, including me, will be the poorer for it.
What I am trying to offer you is the key to the very solution to most of these glaring issues. A solution that I KNOW will work -- and be future-proof too! -- IF these solutions are considered (and implemented) into the foundational bedrock of the work itself. But I digress...



Keep me in mind when you ultimately realize Unity needs a less-broken (and less error-prone) system than the current one you're developing -- I just hope you don't go too far in the current (short-sighted) direction before you do.

 

Generally, nagging and boasting like that isn't a good way to get a job offer.

I do think Unity has a lot of fundamental issues with their goals and they really are just looking at the short term instead of the long term, especially now that they are a public company. But at this rate I don't think they are going to change much, even when given the opportunity to really create a Visual Scripting tool that could change the entire game dev industry.

 

That's fair -- but I wasn't particularly looking for a job-offer.
It was more along the lines of -- "look, take me seriously -- or face the consequences -- and then I say 'I told you so' after everybody suffers because of your short-sightedness."

Sorry if I sounded like I was boasting -- but I promise I have no reason to boast.
It just frustrates me that nobody at Unity seems to be assigned to making sure the product as a whole works. :/

 

Can we then call you out if you brag so much about being right and then you're wrong? The whole "face the consequences" is silly, it is like you think you're some expert authority on the subject above everyone else.

How many games have you shipped with Unity? How many classes have you taught in Unity? How many industry conferences have you been to that featured Unity?

Like, we get it, you think you're right. Just like we all have opinions, but the way you're presenting them turns people off since you're stating things like they are fact with little to no evidence to back it up and basically no way to validate it after the fact. Just trying to explain to you the whole thing.

I understand Unity's position on this stuff after talking to them. Suffice to say they value backwards compatibility above all else and anything that doesn't allow that is basically dismissed. Thus the whole reason they are favoring Bolt 1 over Bolt 2. If you can come up with some way to convert from Bolt 1 to Bolt 2 and keep functionality between them compatible then I think Unity might listen. But until then you're acting like the "idea guy" in game dev... the person who wants to do an MMO RPG with all the bells and whistles but wants to just tell others how to do it instead of actually doing it themselves.

That's all. I'd say come up with a solution to backwards compatibility with current Bolt users to transition to Bolt 2, and prove the solution works, and then Unity might listen.

 

Thank you for your well-explained suggestions.
These are really great, and I'll do my best to take them to heart.

TL;DR -- I'm really sorry if I've offended anybody.


-----

Absolutely! -- Please call me out when I am wrong!
If I am never called-out, how else can I know when I'm being biased or when I've overlooked something?

As much as I validate and verify my notions / ideals in regard to truth and fact -- I am only human.

That's absolutely fair too. And for this, I apologize.

However, if I state something like it's fact -- it's because I've verified it myself before stating it (i.e. via experimentation, practical experience, know-how, workflow-testing, logistics, ergonomics, procedural and dynamic workflows, etc). And if you really want evidence, then all you have to do is ask. So far, nobody has asked.
Whether I state something like it is fact (or not) has nothing to do with whether I'm right or wrong, however. The issue with original thinking is that there is little "existing" evidence at the fingertips to point at and say "See?" -- However "evidence" not being readily available "at-the-ready" does not mean something is unverifiable. Evidence is still available with testing, if one chooses to do so (and reproduce the process themselves). This is science at its finest. That is not to say the thought process behind my statement-as-fact (as well as any experimentation/etc.) cannot still reference "existing" evidence indirectly (and therefore ultimately be stated as fact) -- just as long as no evidence (or line of thinking) to the contrary exists that can disprove it. This is what's called scientific integrity -- and I have plenty of it.
So when I state a thing as fact -- I am (unconsciously) in a sense, actually trying to provoke someone to refute me. After all - how do I 'know' I'm right if I can actually be contradicted? This is science -- the search for truth -- as it should be practiced. So if someone hates me or my ideas enough to contradict what I say, and they come up with something even better -- I will gracefully bow out, happy to be one-upped, as that means we (as a whole) are closer to the truth.

To deem me as unworthy to be an "expert" simply because of the number of industry conferences I have been to, or whether I have shipped a certain number of games, or taught a certain number of classes, is to be as short-sighted as I condemn @Unity for being sometimes.

The one thing I am not is short-sighted.

Any and all "experts" who have been to x number of industry conferences, shipped x number of games, etc. etc. can refute any and all of my points if they wish to do so.
However -- I do not see anyone doing so.
Just like anyone else whose points have not been refuted -- I would "think" I have the right to "think" I am right -- until I am told I am wrong and then am provided clear, irrefutable, reasons for their assessment.
The internet is a pretty vicious place. Stating something as fact gets a lot of backlash when it is easily disproven. So I am not quick to state something "as fact" that I am not convinced at least 98% of the way is fact.
Besides, "fact" (based on evidence) is always tentative, and can only be proven (or disproven) when new evidence to the contrary has been presented and considered.

So the only way to 'know' I am speaking "fact" is when nobody else is capable of presenting evidence or reasoning that disproves it.

However, when you get to this level of verification -- it's hard to find anyone to has tread a different path than you have in your rigors. Thus is why I am trying to get someone at Unity to refute me on my methods so profusely. If they have found a different way -- it is because they have found some fundamental perspective I am missing. If I am wrong (or if they are seeing something in a different way than I am) -- I want to know what and why.

My "knowing" tone can be painful to some -- but it isn't intentional.
Nobody is perfect, and I do not believe I am "above" anyone else. Unity has a lot of really smart and decent people working for them. I, however, have a lot of confidence in my know-how and experience, and can point to any number of reasons why I am right -- because it comes from direct experience.
Unity, on the other hand, is a corporate entity -- and it lacks much of this direct experience. Its goals are different than the would-be game developer (and even AAA developers) across the board.

And if my "direct" tone comes across in a "know it all" way -- I truly am sorry. Again, this isn't intentional. Why would I want people to dislike me just because I am confident in what I know to be true?
While I believe in modesty -- I don't care for false modesty.
I am not going to pretend that what I know is not as true or accurate as I believe it to be when I can explain (in detail) the reasoning and evidence behind it with my experience and know-how (which can be reproduced and refuted by others) -- IF anyone cares to try.

So, while I agree that my tone can be a problem to some -- I am also a bit at a loss of what to do about it.

The confidence in my "know-how" tone only tends to come out when I am frustrated about the subject in question precisely because of that very "know-how", and therefore I feel the need to push my point a bit further (than it clearly seems to be going with Unity.)
So far, all of my "technical-talk" with Unity was met with "I'm afraid I can't speak to this. I hope someone from the tech team will respond to this."
In general, I tend to attribute that need to push my point further to the fact that Unity has not responded.
Sometimes I feel that I have not explained it clearly enough (or deeply enough) -- but I'm finding out (thanks to cool people like @Kennth) that it really is just a lack of others being able to visualize what I'm saying. So that needs work from me for sure.

As frustrated as I get at myself for not being able to convey ideas well -- I don't need the additional bit of "know-it-all" on top of that ruining the rest of my chance at getting my point across. So I will just need to practice more (and get beat-up on) until I get the hang of not sounding like an asshole. Sorry for the inconvenience. Although I really do appreciate you pointing out how you feel. I will take it to heart either way.

Ouch -- I was waiting for that one. But it's true -- for now.

To be fair though, I have the knowledge and commitment to make this stuff. I'm just trying to figure out which way to go with this "idea" -- Do I want to share it freely with Unity (so I can share its fruits with others freely?), or do I want to just make it myself -- and profit from the hard work? I don't really believe in a cutthroat gamedev world -- I think the gamedev community would be better-off with people in it who really work together. But I'm not entirely sure that's what everyone else wants, so I'm having quite a number of second-thoughts. I don't think it's right to put something so fundamental to making games behind a paywall -- but I don't really agree that Bolt 1 is the right direction either. I think it's a cop-out.

I value backwards-compatibility too. :/

This is my problem with their direction -- it IS possible to make Bolt 1 backwards-compatible. And rather easily too. Unity just lacks the damn vision to DO SO.

The technology is already there!

The problem is the "basically dismissed" part -- Just because Unity doesn't have anyone with the kind of vision to see past their own nose doesn't make me wrong.

I have described methods that converge to exactly THIS.

If you want details -- just ask.

I've offered anyone @Unity the opportunity to hear my well-rounded solution to this.
However, nobody (with any technical knowledge) has agreed to hear me out.


Either way, I don't mean to be a pain in the ass to anyone -- or to seem to act like I'm some "super smart" person who just magically knows stuff but really doesn't, nor do I want to be perceived as the dreaded "idea guy" who would rather rely on others to do stuff for him since he can't do it himself. These things are simply not true in my case.
However, I do expect to be acknowledged or refuted (or at least asked to clarify my thinking if it's hard to understand), before being told I simply "think" I know I'm right.

That's all.

 

Do it. Make a vertical slice to show it and then present it. People will then listen.

Also, you can chat about this on the Discord with more technical people too. Join #acquisition-chat on the Bolt Discord server and talk there.

You also should work on condensing your thoughts. It is a huge amount of text and isn't succinct at all. I think more people would respond if it was quick and to the point. But I have a hard time parsing your rambling.

 

This is already in progress. But not necessarily "for people to listen" -- I honestly couldn't care less about that. What I am after is to prove that this goes all the way to the roots of Unity, both in terms of current behavior -- and future scalability.

Right now, Bolt (and Unity workflows) are not scalable in general -- and this is editor-wide.

The time is now to improve those "roots" -- and make Unity future-proof (while also being performant). This is my motivation above all else right now.

That's a fair point -- but this "not succinct at all" is exactly why I can think at a lower-level than many other people can, and still move about and analyze my own thoughts clearly and objectively. It's terrible for conversation -- but it makes for a great "idea-guy" skillset. ;/


All kidding aside -- I am working on this though.
However, not because I'm "looking for responses".
I tend to find people who can't take the time to read into what another person is saying to not be worth my time either.
There is a lot behind what I say -- this is why it is not "succinct" at all.

That being said -- I do value being understood, so I am definitely motivated to improve my ability to help others visualize what I am trying to convey. It just happens to be difficult when dealing with loads of abstract / low-level concepts.
And that just happens to be where my interest lies. D:

I appreciate the suggestion. Thanks.