So, are you guys livestreaming anything? Certainly not the roadmap session…
There are some bits on Twitch Twitch
2 Likes
Overview here:
Specific details on the Twitch Schedule (As Schubkraft already shared!)
Ill be doing a Twitch Stream on Thursday 24th March on the new Sample Game. 
11 Likes
When can we expect Roadmap video?
So cool to see Jason Weiman pop up! Some really good off the cuff insights into all these development discussions. It’s great to see the sort of people you guys are bringing on board who have a wealth of experience to share and draw on to make Unity better in the coming years.
I was most looking forward to the visual scripting session, my oldest is really starting to want to get into game design and his school is just wrapping up and i’m looking for the best place for him to learn coding and game design and I think this could be a great entry point for him considering I can help him with Unity stuff. I was disappointed to see that visual scripting is mostly just an integrated bolt solution, there were talks on here a year or more back to really elevate visual scripting and maybe even integrate custom C# scripts into our own custom nodes. I’m curious what you guys have in mind for the end goal of visual scripting and what the timeline you have envisioned is.
While I understand the want to make these tutorials flashy with custom assets and custom animations, I’m not sure the current visual scripting solution really benefits from this being a central tutorial in terms of opening up gamedev to creators not familiar with code. The kind of person wanting to make a game, or level designer wanting to create custom quests or mechanics isn’t generally going to be able to iterate their own animation setups with custom meshes, rigs, and Mecanim setups with custom triggers and such. Sure you could provide them a premade level with an asset that has everything set up… but does that empower the actual end user to start making their own things?
You guys might consider a sort of “Marble Madness” clone, and you could even create a dog and cat face for the marbles using simple primitives in Unity. This would be FAR more accessible and give new developers an entry point that they can use to create some really fun games with custom, simple environments with cubes, sphere, terrain and such. You could make custom movement using both physics rigid bodies as well as direct positional transforms tied to simple sin functions and really explore some powerful but surfice level game logic. Or provide a fully fledged movable character, but focus on simply making a quest system and dynamic level elements, that would be fun and useful too.
REALLY hoping you guys expand the visual scripting to allow the creation of custom nodes, it just opens up so many doors for people poking at game design with visual scripting to ascend to that next level, or for people who want to stick with visual scripting to ask for functionality and to have an ever expanding toolset to make cool things. I could even see you guys selling bundles on the asset store with a chunk of custom visual scripts for a given type a game.
As for Gigaya, I’m so glad you guys are “feeling our pain” so to speak with a few things within the engine, and seeing the sprawling world u guys are throwing together. Fun presentation, I was hoping to hear a bit more talk about what sorts of kinks you guys were finding in Unity and what you guys have in store to fix those things, but I mean, I’m also not expecting you guys to ream your own engine live at GDC. Some great art and design on display here, and I really liked the atmospherics, tastefully placed dust effects and god rays. I’d be curious to hear how you guys are opening channels of communication between those of you using the actual mecanim setups, prototyping new stuff, and how feasible it is to improve on the existing tools or if you have “Mecanim 2.0” that’s running on DOTS that is going to benefit from this internal development.
More than anything I’m hoping you guys will brainstorm some scene management stuff that make adding things to the world, and keeping them organized becomes a bit less tedious. If I had 1 big gripe with Unity that’s plagued it for a decade now it would be that the entirety of the engine still organizes things in one huge list, and there is no disconnect between organizing things such that they’re easy kept track of, and the game mechanics between parents and children, no matter what you do some tiny pebble has as much real estate as your player asset in the heirarchy, and if you try to tuck it away, but accidnetly click it, you’ve now rolled up a huge rabbit how of assets now exposed in your inspector. You can break that list into smaller lists, but until there is more ergonomic hiding of stuff, you enevitably end up with this sprawling mass of things you have to scroll through if you want to have any sanity while you work on things in a scene.
It’s always such a pain to try to get things placed with the right part assets, to keep certain things collapse as you accidently click other things, and move various stuff to where they belong amidst prefabs and other transparent plans that seem ot always want to jump in front of your cursor clicks. It would be so nice if there was contextual elements like pressing “Control + Shift + N” wouldn’t just create a new empty game object, but placed a new empty game object childed to the current selected object, exactly at its current location. If dragging and dropping an asset into the scene would automatically obtain the same scene hierarchy as the object it is dropped onto. Maybe some secondary movement tools to be able to move a parent object without moving it’s child objects. And the ability to automatically move all selected objects in the scene hierarchy to the current hierarchy location as it’s kind of a pain to finagle that pixel difference area where you’re either dropping an asset to be childed under another asset, or to be just above in the hierarchy, if you guys made that 1 pixel area 2 pixels it would be so much easier to get the right placement of objects.
Like the guys on the panel inquired, I’d also be so interested to see a tutorial video on how you guys structure multiple scenes and make that beneficial to keeping thing organized, and what ideas you guys have for the future. What would be AWESOME, is if you guys added a “locked” state for assets, which would make them totally invisible in the inspector hierarchy, essentially making it so you could still select the asset, move it, scale it, even clone it, but in a locked state, it could never pollute your hierarchy with visual noise. This would be perfect for assets like rocks, or a table. Some environment asset without any fancy bells and whistles, that you’ve added to the correct hierarchy level never need move about within the hierarchy window for any reason, and have no urge to ever see or manipulate within the inspector hierarchy, then you could simply have a toggle “show locked assets”. This addition would probably cut down on 80% of my current scene clutter in the main inspector window.
Small suggestion, if you guys add dynamic lights for impact effects and for charge up attacks, it would pump up those abilities and attacks and really bring the scene together.
Overall really impressive demo, I’ve been really enjoying the quality of life improvements the past year and looking forward to all the goodies that will come from you guys gasp actually making your own game!
Qiuck suggestion on the screencap lag you guys had at the start: Not sure if this will help you guys in the future with streams, but Windows has a “game mode” that you can disable from the start menu by searching “game mode” and this may help with streaming framerates in the future.
Their plans for Visual Scripting are laid out here . As far as I’m aware, that’s still the plan - i.e. the unification of all graph based tools of Unity under the same UI/UX provided by the new Graph Tools Foundation framework. At the current pace, it’ll be a good 2-4 years before the plan is complete. And you can see what they’re currently working on in the Roadmap.
Unity documented the basics of creating a custom node in their new docs after the acquisition. Or do you mean something else?
2 Likes
Yeah this is exactly what I was looking for! That first forum thread was quite a journey. At first I was like, OMG this sounds great! And the unity staff was super knowledgeable and seemed to have a solid game plan, then i dug a little and saw these guys were all involved with getting dots up and running and their universal graph system working, and the posts fell off and I started to think, “oh boy, here we go again.”
Seems like any singular thing you want to learn about sends you down some huge rabbit hole for unity, where every feature is dependent on another and no one seems to have ownership of any given system.
More than anything I think an overarching problem if I can highlight anything from this experience, is that in a word, the communication for resources for Unity is…
and this may result from overarching internal issues as well. Like core talent is divided on too many things going on at once, and in a high stress environment when you give people many tasks, you end up with people disappearing and reappearing and working on various things, and it’s impossible to keep tabs on actual tangible progress being made. And when a great many people are having their workflows disrupted, and there are plausible outs for not getting things done because “oh I’m working on this other thing”, productivity can fall off a cliff. I don’t want to assume to much here, but it seems like there’s way too much chaos going on internally and work gets lost in all that madness.
In my quick journey to try to find the future of Visual Scripting I went down rabbit holes on DOTS, Universal graph functionality, and I learned about all sorts of stuff tertiary to UVS and frankly I’m not sure how many more Acronyms my brain can hold as Unity developer in 2022!
I even read someone talking about some part of the webpage we can make suggestions to specific teams within unity to improve the engine, but I can’t even remember where that was, so I’m going to post it here:
You guys need central communication points stickied in logical places, pinned at the top for your planned feature and where you plan to go with them. The way GDC has flowed this year and the way everything feels so up in the air and resources from years ago are more up to date than recent presentations really highlights this. It’s hard to get excited for features and stay excited for them, when we don’t even know where to find information about them, or for you guys to give us exciting updates about said things. Amidst all this chaos I think everyone misses out, we miss out on chances to hear the cool things comes, and you guys end up posting in random places that get buried over time or the message just doesn’t reach that many people.
New GDC talk on some feature? Link it on the feature post. New blog post? Link it on the feature post. Did someone make a post in some otehr forum? Link that to the feature post. It wouldn’t be an exact science but it would be better than nothing, and people could post below with new relevant info and from time to time information could be consolidated.
If you guys found some means of creating a sort of “living” blog post for each feature that could be updated a bit to be mostly up to date of the goings ons of things, this would be so useful for people wondering WTF is going on with the features they’re looking forward to, or for you guys to give us that information without it falling off the front page.
I’m excited for DOTS to finally be nearing production (supposedly), hoping the universal graph systems are going to follow soon after, but at the same time seeing the various plans of action mismanaged and executed out of order so poorly you have to wonder if you guys want to get things done or if people are making excuses at this point.
There’s a certain momentum that affects your internal progress of things, if things aren’t getting done, if people hop around from project to project and results aren’t expected or demanded, then things begin to slide and it can be a really bad downward spiral that affects the overall work environment.
We can only make assumptions, and sometimes that makes an ass of u and me, but at this point we’re just calling it as we see it.
Truly hope these bottle necks holding everything back open up the floodgates soon as dots and other foundational systems come online.
1 Like
This was actually remarkably relevant.
It’s so weird how we can use a piece of software, and it can do these incredibly complex things so well and it’s a testament to the genius of the designers behind the project, and you can wonder, “How the hell do they do this?” but when you start zooming out the insanity of social structures and our humanity starts to show, often times there is no logic to them, or they do not align with the quality of the project and you just start getting abject terrible design decisions, that anyone can tell is bad from a surface level, but there is no solution to within the confines of the company, because the alignment of interests of us monkeys in a corporate machine is an entirely different kind of puzzle, infinitely more complex with solutions that cannot be solved through sheer logic.
Company culture and team confidence is elusive and an impossible to fix problem with inherent biases, tribalism, favoritism, laziness, stress, hubris, burnout compounded by lies, back scratching, and office politics. The solution is going to look different from various vantage points from members of different disciplines. But there seems to be an inherent lack of people within Unity who are able to stand up, point at any number of galring issues or poor plans and say. “Guys, we need to change how we’re approaching this.”
It can be a damned if you do, damned if you dont’ scenario. Push to hard and you might inadvertently break someone who’s actually working their ass off working on a lynchpin of a problem. Don’t push at all and the culture slowly shifts towards coasting along and finger pointing. Interact with the user base online and you get frustrated, don’t interact and everyone loses interest in the platform.
You really just need to promote the idea of reaching down an making the engine amazing, and you can’t force it, you need to do it in a way that doesn’t burn trust, or throw people under the bus. Maintaining and building team confidence is such a complicated thing.
The thing that felt lacking the most from the GDC talks to me was conviction. No one seemed to have a fire under their asses. I don’t know, maybe I’m too old-school, but I kinda wish there was more gumption and pride in the tools and this sense of “We can’t wait to get this sh*t up and running for you guys, it’s going to be awesome, we know we’ve had some missteps, but we’re learning, and we’re getting close and this is going to be worth the wait.”
Both the product manager (first thread’s author) and the main DOTS VS guy have already moved on from UnityVS to something else. And Graph Tools Foundation manager was initially open to communication late last year but has gone completely radio silent since then. So I’m guessing we’re nowhere close to this grand plan succeeding.
And while the overall plan sounds solid on paper, in reality, it’s been nearly 2 years since the acquisition and no new features have been shipped for Unity Visual Scripting. They’ve spent all that time on engine integration, bug fixing, editor performance optimization and the new high performance runtime, which is far from production ready and in some kind of pre-pre-preview state.
The frequent backend refactors also have impacted AOT stability and migration often failed between earlier versions of the package. I’m thinking there are many more refactors like that ahead, so I’m not sure if the tool is even usable in production for the next couple of years unless you commit to locking in the version and pray there are no show-stopping bugs.
The promises of leveraging Bolt 2 tech haven’t materialized either. They’re basically rewriting the tool from ground up at this point while also trying to honor backwards compatibility for the existing user base. Hence why progress is glacial.
4 Likes
“Perfection is the enemy of progress” is a quote that comes to mind. At times I’m absolutely floored by Unity’s commitment to backward compatibility. But more often I just wish they’d tear things apart and get them done. When they were trying to push the prefab system I felt this way. But something in the minds of the project managers needs to change, this quest for perfection combined with backwards compatibility is churning developers to pulp. I know it sounds nice to want to give the customer EXACTLY what they want, I know the allure of wanting to be the “Perfect Boss” by trying to avoid every theoretical issue, but there is no perfect plan.
Being a good project manager is about managing the risk/rewards of imperfect solutions to imperfect problems. “To make an omelet, you gotta crack a few eggs.” It feels like you guys at Unity are so paranoid of upsetting ANYONE, that no one stands up and makes the tough calls to get shit done.
People aren’t robots, code can’t be perfect, you can’t force people into writing a perfectly standardized code, you need to give them breathing room to create the best systems the way they know how, and even the best coder is going to break at some point if they are asked to create the perfect gamedev tool, then add on top of that things like adopting DOTS perfectly and backwards compatibility.
You can demand top tier work on specific systems, but you have to realize that work is finite as you grind people for perfection over and over with the interconnected nodes and DOTs stifling progress, It’s no wonder developers are losing their mojo.
Would it be the end of the world if we have a working Visual Scripting solution now, but it wasn’t set up for DOTS, and when DOTS was ready you guys put together a strike team to go from module to module to revamp the main bottlenecks that affect performance the most? This would be the perfect time to create resources to teach us how to migrate DOTS as well.
It seems there are a few VERY GOOD coders who run things, but they are very particular, rather than working to make Unity truly modular, they have this perfect vision for how all the code that’s going to fit together to make up the main engine. It’s going to be perfectly optimized, perfectly expandable, perfectly neat and tidy.
And this mindset is GOOD! For some things. Package managers, lighting systems, DOTS, etc. Things that will bottleneck THOUSANDS of projects at runtime.
But visual scripting? This was supposed to be nearing a wrap right now. Now we don’t even know wtf is going on with this system…
Guys, you’re trying to do a very complex bit of work, and sometimes you just gotta get it done one way or another, screw backwards compatibility, screw the hyper optimization, just get the workflow working and make the darned thing functional with custom code nodes, we can sweat hyper performance later.
I used to have the same mindset. “I could use this system here and here and here, and if I do that, I can work to make it perfect! And then my entire project will be better!”
What you don’t realize that you end up doing, is you start making it exponentially more complex than it has to be, you start thinking how it has to now be inheritable and dynamic, and all these factors start to make you stressed and something that SHOULD HAVE BEEN SIMPLE AND DOABLE, now feels like this massive ordeal that has everything riding on it.
There are 2 paradigms in development, and I think this is something you guys at Unity need to start internalizing. You can strive to make it perfect, or you can strive to make it good enough that you call it done.
Here’s a secret: NOTHING is perfect, you have to let go of that notion of perfection in your head and embrace a little bit of chaos and sloppiness. There’s something wonderful about a system that “just works”. Maybe you open the hood and you look at it and you shudder a little at how it’s wired, but who cares? It does everything it’s supposed to do, and it does it so well that you never have to think of it ever again. In that sloppiness, in that imperfect code is iteration, is a story of old systems gutted and refactored to make something better, that imperfection IS BETTER than something that was coded from the start in a stale environment where experimentation and iteration cannot happen, or happens with extra overhead that stifles lateral movement and consistent, passionate work in the long term.
This notion of perfection plagues game design as well. You have this NOTION of the perfect game, then you make it and what do you know? It’s not as good as you thought it would be! In the imagination of your head where we conjure things out of thin air, we see this ideal, and we see it as being great, we see it as wonderful and we KNOW BEYOND A SHOWDOW OF DOUBT, that if we obtain that ideal, it will be amazing! But what we do not realize is that notion of perfection was a figment of our imagination as well. We simply thought this alternative pipeline we hadn’t done before, must surely be better. Why rough things in? Why iterate? Why finagle things together? Just do it perfect out of the gate! This thirst for perfection is poisoning all pipelines at Unity, and we are seeing the fruits of that. The thing is, you don’t see the shortcomings and downfalls until you make these idealized pipelines a reality.
It’s important to have enough standards that someone can go back to these systems and refactor them if something breaks or some new feature is needed, but it really feels as if the quest for “perfection” has led to absolutely no progress whatsoever, and it’s poisoned the workflow of this engine.
Take the prefab system we have now for example. AWESOME, absolutely hats off to Unity for making this incredible system. But how much stress and pain did they go through to get that working without breaking people’s projects? to make it backwards compatible? How many cool features did we miss out on because they had to ensure the prior system seamlessly ported?
Imagine a world where they didn’t sweat the backwards compatibility and simply focused on making the tool as robust as possible, and getting it out in a reasonable timeframe with even more bells and whistles. Now imagine they added a tool that could copy the overall values of every component of an asset to another, or easily make an asset an inherited prefab of an existing prefab, while automatically detecting which components are inherited and which are unique to a given prefab.
Treating the customer with kids gloves combined with these notions of perfect foundations has killed all the cool things that should be coming out right now for this engine. Gamedev is a little messy, it’s a little sloppy, and if you force your devs to adhere to perfect plans “because I said so” a lot of the magic and high end unique talents and work ethic of creators gets churned to pulp and people burn out and word gets round and then no one wants to reach deep within to make cool crap any more.
Captain hindsight I know, but damn guys, what the hell is going on with all that cool stuff we were so excited for?
2 Likes
Bolt 2 was incredible two years ago. Sure, it was a little bit more complex than Bolt 1 and needed some streamlining to make it more palatable to non-coding designers who are Unity’s main intended audience. But the UI/UX was leagues ahead of what Unity Visual Scripting has now. It was incredible to work with even in alpha.
Now Unity are coming upon issues Bolt 2 already had solved, but they’re reiventing the wheel and coming up with their own solutions. Sometimes these solutions are good. Other times their focus on backwards compatiblity forces them to stick to bad design decisions a solo developer made 6-7 years ago. Bolt 1 really isn’t the peak of Visual Scripting tool design but Unity are treating it almost like some religious text all in the name of backwards compatibility above all else.
They don’t have a vision for what Visual Scripting should be. The vision was bought in the form of Bolt 1 and it’s what we’re getting. They’re replacing the runtime for a more performant one and they will replace the UI layer with GTF but at the core it’ll remain at the Bolt 1’s level. Which is unfortunate.
From a users perspective, this acquistion has brought me 0 value. Bolt 2 was plain better at everyting and it got cancelled. I stopped using Bolt/UVS because it’s not fit for production - Bolt 1 is not developed anymore and UVS gets too many backend changes that impact stability on AOT platforms between minor versions of the package that also force me to upgrade to new tech stream releases to even update the package. At the same time, we can go months without any hotfix releases that would address the AOT prebuild stability issues. I can’t rely on a tool like that.
To me it seems like they took the package manager feedback about the high degree of fragmentation and incompatiblities and overcorrected. Now everything has to be rated for certain Unity releases and near infinitely backwards compatible and also seamlessly integrate across all Unity tools. Sounds good on paper, but the progress is so damn slow I’m not sure I’ll be using Unity when all these grand plans finally come together.
5 Likes
By the way, I had some exposure to the ShaderGraph tools, and I’m not really happy with how they work. Very cumbersome, and many things require awkward typing.
I was surprised to discover that plain old shaders work fine in shadergraph environment (unlit ones, anyway), but this is not exactly documented anywhere.
Also, interaction between code and graphs is a huge mess.
All their new graphs tools are riddled with UX issues. One can only hope Graph Tools Foundation will address that in a couple of years.
It’s gotta be so frustrating for you guys that got invested in the future of visual scripting, I was pretty excited for it too a while back.
Maybe you guys could explain this, I always wondered why visual scripting wasn’t a direct visual representation of actual, raw C# displayed in a graph environment. Like there was absolutely no difference between the two, just how it was displayed on screen. If i’m understanding most all visual scripting systems, they’re simplified representations of what’s giong on behind the scenes. Why isn’t it simply a direct representation of its raw code?
I made an absolutely horrid mock up, but I hope this at least KINDA communicates the concept of visual scripting being raw C#:
Essentially the code on the right is EXACTLY the same as the code on the left, it just has a little secondary data for node locations to generate the graph, but this shitty bit of code IS raw C#, just displayed as nodes. And all your functions would be separate nodes that you could toggle between the IDE view, or the node view with all the complexity you could ever want with C#.
This wouldn’t be immediately friendly for people new to code as this keeps all the complexities, but special nodes could be created as a “set” for people new to gamedev that streamlined things for people to help them get started with hidden and complex things like event management and singletons hidden in the background so people new to gamedev could block together their own games without advanced knowledge of various concepts required to get various entities talking to each other. These massive code chunks could be collapsed into clean little nodes with only basic inputs sticking out for green developers not to get lost in. (I know the code is crappy, but I was just trying to get the rough idea in that would sorta mirror the logic in a quick visual script mockup from Amplify Shader.)
It’s pretty late and I’m not sure this is making sense, maybe the idea of adding ANOTHER layer on top of the code isn’t a great idea, as so much coding is handled by an IDE and this system would require you to essentially have your IDE open, write the code there, then paste it into nodes that are ideally supposed to replace the old coding environment in the first place.
This starts to get messy when you actually start to conceptualize it, and pushing it forward to be useful would require a revamping of code from its base level and how we interact with it and I’m not sure that it’s suited to a secondary feature of a game engine, but it might be… It’s really does come down to making the nodes themselves robust and contextual based on the code within, and giving the creator of the nodes power to customize them without having to interface with the code within, that would jsut overcomplicate the code and that would defeat teh purpose.
I dunno, it just seems weird to me that we have the custom node system for shaders that’s able to generate actual code from that, but for whatever reason, we don’t have a node based system that exists for general C#… I guess I don’t understand what’s stopping us from simply turning variables and functions that exists in scripts to reside instead in nodes? Instead of having all the tabs at the top of your IDE, you would have all these collapsed nodes, maybe sorted based on functionality in a 2d space, all your character controller scripts sitting next to each other for easy acces and you can find them very easily, not by doing a search accessing their name, but because you physically remember where you clumped stuff related to movement in an area.
Each script that exists as these nodes you could expand and see the raw code text within, or you could toggle the visual script version and see that code as it exists in the node based system, and you could edit it that way. Numbers could have secondary identifiers like cogs with the # of rivets denoting #'s around a phsyical manifestation of a number. The contextual outputs of nodes showing a single line for floats, and 3 lines for vector 3’s and 4 lines for colors with an alpha channel is just so nice as we already have in shader graphs.
These visual cues could be expanded in so many ways to denote things like inheritances, or if something is a local or global variable or to visualize clearly the scope of things. There’s so much potential for code to be more concrete and have a form so when something isn’t working you’re not pulling your hair out reading over letters and words, but more looking at a house with a wall missing you can very easily say "aha! This visual machine is missing this very obvious “thing” that should visually be right here!
At a glance if you see something with a ton of wires coming out of it, your brain immediately recognizes the logical form of that structure, and it can be an obvious sign that something needs tidying up within that logic. Visual Scripting doesn’t have to be some kind of training wheels system, it could be an expanded paradigm of code where all the lines of syntax and randomly named variables are given a tangible form that would allow us to code not just in an expansive 2d space, but possibly even 3d, or to give functions and formulas visual representations.
You could almost envision the code visual scripting revolution potential like the difference between reading a book, laid out in words on a flat page, limited by syntax to say a video game, where concepts exist in a space with dimension where our brains ability to so forms and systems actually working in “space” take shape.
I’ve been blathering a lot in this thread (I promised myself I’d make this short, but here we go again) and I’m a little worried this all sounds wishy washy, I’m sure some of you guys who have been pushing for visual scripting will “get it”. But this is one of those far reaching things that’s so insanely complex when you’re trying to keep in mind how people new to code view things, how the base C# functions, how we port that to a working game node and how do we display that logic in a way that makes this all worthwhile? How do we even start to go about making something dynamic like code exist within a game engine? You need the code to generate the game engine, then that engine generates a knew synthesized version of code in a node based space, then that code feeds into a new game? You start getting into an existential crisis and this was all supposed to be fun building blocks of code meant to help people mostly new to gamedev.
And when you get down to it, all those concepts and ideas of entities and components, those exist in our head… mostly as words. So at the end of the day how much does that tangible environment really help us? Maybe this should be a broader and larger scope endevor we take on as a people than gamedevs. Reimagining math, reimagining language, reimagining conceptualizing logic in a 3d space. We might be putting the cart before the horse, because there is so much we do that we haven’t even begun to construct in a new way to make things easier for us. It’s kind of silly we still use the same mathematical structures and notations created by people who used pen and ink to write on paper and we have done NOTHING to innovate those base methods, and becaues of that, the notion of bringing those systems that still exist on paper to code and then to a game engine, just feels like they’re incompatible.
But that’s where we’re still at, we still teach people to read, we teach them to do math out of a textbook, we eventually teach them to code, and by the time they’re old enough and have enough influence to innovate anything, theyr’e locked into these archaic systems, and everyone is used to them and we just go one using this stupid crap. I’m typing this on a keyboard that was designed to slow down typists to prevent them from breaking machines, using numbers that are based 10 simply because we have 10 digits, not because that best suits our mental faculties.
So the notion that Unity is going to somehow standardize this super complex open ended system of scripting in their spare time when so many other pressing issues requires their complete attention is looking a lot like a pipe dream.
The inherent problem is anyone capable of handling this visual scripting system is the least likely to benefit from it. They already have conceptual mastery of coding in the traditional IDE space so we may never get that paradigm shift that deep dives into the potential of VS.
1 Like
They used to think about and solve these pipe dream incrementally, shaderlab (which unify shader writing) and surface (which decouple the light part of the shader as an extra pass on teh same level than fragment and vertex) are concept that both simplify and increase expressiveness of regular shader, without going through boiler plate, we expected a continuation of that line of thought. But the culture as changed.
New shader graph did away with surface and reduce expressiveness until the community yelled and they had to awkwardly patch it back.
There are so many questions that come from these sorts of decisions. Were they gutting this functionality because they had a greater vision? Or did they just not want to deal with these features?
If they came out and said “We have huge plans elsewhere and visual scripting as we envisioned it was bottlenecking the whole of our endeavors, and as such we’ve put them on hold, we’re developing tools to hold you guys over in the meantime, and we plan on revisiting visual scripting in the future when our internal tools are ready for them. You will NOT be disappointed.” We could respect that, we could see there’s a plan, they’re making regrettable but understandable decisions and there is a method to what they’re doing. Silence and abandoning your promises without facing those you told them to is weak.
Is there anyone on this team involved with visual scripting who genuinely want to see it through to completion? Do they have the technical resources to adequately walk this path such that it’s relevant moving into the future? How much are these global systems of DOTS and visual node systems derailing development within the company? How does creating a node take more than 4 months for a company with the resources of Unity whose job it is to generate UI elements at runtime, it may even be the #1 thing they do.
The lack of a dialogue is getting to be very telling. This is nearing YEARS of radio silence. What sort of ship are they running? Kinda shameful really. Features aside, progress aside, does anyone at Unity have any accountability whatsoever? Or is it just the standard fair of passing the buck ad nauseum? Pretty normal behavior for these sorts of companies that have a reliable revenue stream and no hard incentive to execute tertiary features, or any feature at all at this point.
It’s a crazy world we live in that often times stifles progress because of inane corporate politics and not wanting to rock the boat. It’s a lot safer to sit quietly in the corner knowing everything is going to crap and not say a peep and collect your paycheck. Pretty common problem these days.
Edit: This is pure speculation, I don’t know what’s going on in Unity (obviously), for all I know they have lots of things coming together. But their communication leaves a lot to be desired and there are many red flags popping up all over.
1 Like
We can only guess, but I think it’s a mix of things.
The culture of shipping a minimum viable product which typically gets done in a somewhat timely manner (for Unity) but the followup of getting the thing further developed up to industry standards then takes many, many years or sometimes just fizzles out completely. No idea why.
Is it because package team rosters often undergo major changes? There seems to be a small collection of highly productive developers who get the MVPs out and then move or are moved to the next best thing. Rinse and repeat. The remaining code monkeys then are left to support and develop the thing.
Perhaps it’s the corporate culture of large companies - to get the big promotion, you need to develop new stuff. There’s likely less incentive to support a thing long term, doesn’t contribute as much to a performance review.
Someone somewhere also called it a marketing driven development. Get the MVP out with a big marketing splash and move to the next big thing. Not sure for whom this works - perhaps for shareholders and non-gamedev industries looking into real-time general purpose engines? Unity is growing the fastest outside gaming right now.
Unity’s also grown fat - there are many geographically scattered teams around the globe working on various parts of the engine which introduces a lot of overhead. These teams have to communicate, often with major delays due to time zones. In case of Visual Scripting, there’s UnityVS team, Unity Serialization team, GraphToolsFoundation team as the three major ones. But the GraphToolsFoundation team has to communicate with UnityVS team, Shadergrapgh team and also VFX Graph team, likely also the serialization team and possibly more since Graph Tools Foundation will be used by all of these tools.
On top of that, everything is getting planned about 6 months ahead. So if you request a feature now and get the community to rally behind it, no action will be taken on it for at least half a year besides maybe noting it down somewhere. And if it doesn’t align with Unity’s plans, it’s not happening, anyway. The point is, Unity can’t course correct because of corporate decision making and tight deadlines for new Unity versions that have to be validated and handed to QA months before the actual release.
TL;DR: Likely a mixed bag of corporate culture, bad management, Unity growing too big for its own good, modern developer trends like the MVP without followthrough which could be attributed to bad management or marketing driven development.
Either way, using any of these new Unity features which are announced as “production ready” but actually need another 5+ years to get feature parity with the old, not developed thing they decided to cancel is getting old.
4 Likes
Cannot really argue about the details you are thinking of, but sacrificing backwards compatibility, especially of a core component like prefabs would be a really bad idea.
That would break a massive amount of work on the asset store. That would not just “upset” some people. That would be a death sentence! Unity, especially for indie devs lives off the asset store.
Just yesterday I was pleasantly surprised to see how a fairly sizable project from Unity 5 loaded and ran in 2022. That is useful.
1 Like
Bad idea.
The likely outcome is that you’ll tear apart and get nothing done, meanwhile your competitors will keep improving.
First you build the new, and only when you’re done, you can destroy the old.
2 Likes
This is one of those things that’s hard to weigh the pros and cons for, if they had created a brand new prefab system without backwards compatibility, it would have caused a huge disconnect in the Unity store on top of requiring all current projects looking to stay current to migrate, I wasn’t thinking about the Unity store, but we don’t know the alternative scenario. We don’t know how much sooner an alternative system without backwards compatibility would have taken to come out, we don’t know what sorted added bells and whistles it could have had, and we don’t know how much less burnout it would have been on the people creating this system and what other cool additions they could have done with their time in the meantime, or what sort of additional features could have been brought on if they started with a clean slate. We dont’ know how tough it would have been to fix broken reference issues in a given asset.
You’re right though, the asset store would be a lot more complex if half the assets were “legacy” and the other half were current, and there were compatibility issues. I’m starting to get why new feature are so slow to be implemented in Unity, everything is on the verge of breaking across so many projects.
I hope my crazed ramblings haven’t detracted too much from what I think is some level of valid criticism and feedback.