For Rider - it is early release vs. product. I don’t mess with early-releases on other tools. Only with Unity because some packages are compatible with this release or that release and another package may not be compatible - way too complex. A package I am using now required me to load a patch to work on 2019.3 and then had a link to go the experimental play mode option - just to get things to work. Heaven forbid I add another package to this project.
I think alpha/beta/release would cover it better. And instead of a “verified” label, treating the editor version as just another dependency would be much more consistent. If, let’s say, Entities 1.2.0 package depends on Math 1.4+ and Editor 2019.2+, I immediately know what to expect.
I would answer the same I said before for packages. Initial public alpha that shows the offering as devised by the devs, alpha period for users to steer the development with their feedback, then beta period focused on stability/performance/UX/usability/docs.
Make clear what the goals are for each pre-release version you give to the users. What are the devs focusing on? What feedback do you expect at this point in time? What issues should be taken care of before moving on to the next phase?
I wanted to thank you for opening this kind of channel. It’s the kind of transparent communication I would love to see in general.
I really appreciate having a candid conversation with users about the current state of Unity. That said it’s tough when different people are doing different things with the engine, so I’ll start with context as to what I am doing and give me feedback.
I run a small studio and work on small to mid sized games. We work on our own internal projects as well as co-development with other studios. This is often tools, optimization, and, most often, porting services to mobile and console. Every so often we will also handle all the development of a client project though we have moved away from that type of service, generally.
We don’t tie too heavily into third party tech: much of what we build uses features of Unity but a lot is also in house code/tools that we’ve built over the past six or so years.
I’ve split the questions into two sections: core Unity and packages.
Core Unity
I have a different view from some of the people who have already posted but I’ll keep it brief. The point of tech is to bring the latest features out and LTS exists so that you can support your game near and post launch on various platforms where you must release on the latest SDK (iOS, consoles).
I do not view LTS as the stable branch and Tech as the less stable option. Ideally, they are both stable (though tech is less so due to the nature of getting fresh releases). LTS is specifically so I can update my game and know that it will be allowed on the platform by the platform holder.
In a perfect world, everything would be stable. I understand that between tech releases there may be API changes to allow for new features or a different workflow than originally planned, but it should all work. For the most part, this has been happening (talking purely about the core engine and not packages). I haven’t had any of the crashes that others mention but I also keep our internal projects quite clean and optimized for the editor. Client projects can be less optimized (I get quite a few editor stalls in some of them) but no crashes.
To a certain degree, yes. I would assume that LTS is getting much more thorough testing as a regression could be disastrous for a project close to submission. The last thing I want is to have to update to a new revision of an LTS release to be able to port a game and then have that revision have some issue that can’t be solved. I’m often updating client projects from a non-LTS to LTS branch to prep for release so I expect issues in those cases. But once the move to LTS has happened I’m of the mind that future updates to that release should be 100% painless and working.
In practice, I usually move to the LTS branch, find an SDK version that won’t be deprecated before launch, and then avoid updates unless I absolutely have to.
Continues platform support without having to worry about an update breaking our project. If I’m close to launch(six months to a year), we will jump to LTS so that the team can be certain that we won’t need to update to a minor/major release of Unity again, regardless of SDK updates from target platforms.
Packages
To start, I want to say I love the package manager. Decoupling non-essential feature updates from engine updates is a very smart move. Allowing users to tie their own packages into the package manager is a very appreciated bonus. The ability to constantly deliver updates for a feature set is wonderful but it also introduces issues.
When a package is dependent on some part of the engine and forces an update to have access to it, it’s no different from the old update cycle of Unity: wait for a new release. That rapid release cycle becomes hindered and the ability to quickly push out hot fixes goes away.
I have some issues with how third party packages are treated but I feel like that may be separate from the conversation here so I will keep those to myself for now.
Stable enough to learn and play with, but not to ship. Preview to me, which has been echoes before, means that the API is basically in beta. It’s not going to change drastically and is, to the best of Unity’s ability, working as intended. If anything is missing, it is fully missing. What I mean is that if a feature isn’t complete or has some known issues, it shouldn’t be in the preview until it is done and tested.
In practice, I normally mess around with a preview package but don’t invest heavily into learning the API, let alone integrating them into a project, because they always seem to be released way too early. The APIs can change or the feature sure is incomplete or there are just bugs. It’s just too risky to bring into a project. Being a professional and not a hobbyist, I often don’t have time to just “play around” with preview packages when I have real projects to get done.
Packages have absolutely terrible documentation and API pages. Nothing should be getting released until documentation is written, reviewed, and edited. And that documentation should be on an official, Unity style API page, not a shared document.
Packages clearly aren’t held to the same standards as what is included in the core engine and that needs to change.
I’ll only download a preview package if it’s something that’s really going to add value to my workflow. The only packages I have ever downloaded in preview have been
- The new Input system as I currently rely on third party assets (InControl, mainly) for controller support. A built in input system that meets the standard set by existing assets from the store would be amazing, if for nothing more than needing the jump through hoops with third party providers when dealing with NDA’d platforms.
- Scriptable render pipelines for the sake of experimenting with a lightweight deferred renderer for lower end platforms, namely the Switch. This has been abandoned for the time being but I spent quite a bit of effort learning the API so that, at the very least, I would have the knowledge needed to edit the provided pipelines for optimization purposes.
Everything else, even when I think it might add a nice tool to our workflow, I usually ignore until I have to use it or it’s out of preview and the general consensus is that it’s a good tool to use.
TECH releases are somewhat bleeding edge versions, from which I expect new features, and more bugs than an LTS release. If you can wait for the features, you should hold out for the LTS version for improved stability.
I fully expect it to be buggy compared to earlier tech releases, and very buggy compared to LTS releases. I don’t bother moving to a new TECH release until it’s had a few patch releases to fix major issues. With 2019.2, I remember holding off a full two months until the HDRP team finally fixed a one-liner null reference exception that was holding me back from upgrading.
In that LTS is essentially the last TECH release plus a bunch of big fixes, I expect LTS to be more stable than a TECH release, if only because of the time it has had to shake out issues.
Historically, I’ve used TECH releases within a week or two of them becoming available. Starting around 2019.1, though, I’ve been very wary of the stability and completeness of the TECH releases. It’s frustrating to see bugs in the “Known Issues” section of the patch notes for 2019.3 remain there week after week.
I don’t think much about it. It seems like most of the packages I’ve been using have had a “preview” label on them. Mainly, I understand that it means things can change down the road that will require me to rework some of my code. But in general, the “preview” label hasn’t (for me, at least) meant that a package is very unstable.
Again, I don’t think much of it. I would be hesitant about building a whole API around some preview package, but as a general consumer of a package, I don’t think the preview label matters too much to me.
Final Thoughts:
Two TECH releases per year seems fine. I’m with most of the above in desiring performance and stability of the interface more than most else right now.
I’m disappointed in the way some packages are simply pinned to major Unity releases. HDRP, for example, get a new version with each Unity engine release. That’s not at all how I expected the package system to work. It’s especially bad when it’s not feasible for me to update to a new Unity version for some reason. It means I won’t see any more improvements to the package. The total fiasco around 2019.3 being both the first Unity version in which HDRP is “Verified”, and the last Unity version in which Realtime GI is supported in HDRP is a slap in the face that has been addressed elsewhere. My project will be stuck on 2019.3/4 for the foreseeable future, while the HDRP 7.X package stagnates, as development has shifted to HDRP 8 on Unity 2020. So, it’s frustrating that HDRP 7 feels like a deadend.
Unity should really pay more attention to LTS releases. This bug was reported on October 16. Still not fixed on LTS branch almost 5 month later. Not even “In Review” state. Thank’s god we found some wacky workarounds. And that is 2018.4. I can’t even image how 2017.4 users are forgotten.
- What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
My understanding is that the non LTS releases are for the bold of heart, willing to help Unity as unpaid QA staff on their core engine. I expect that each and every minor or patch update outside LTS contains a possibly breaking change to my existing codebase.
I expect that LTS minor updates not carry a high risk of breaking existing code. More importantly I expect that every supported LTS will always allow me to publish to every platform offered during the editor’s support lifetime.
I also expect that in an ideal world, bugs discovered in LTS be quickly resolved in the LTS release ahead of features in the tech releases.
- When you see a new Unity release, what is your expectation of quality?
Minimal expectations of quality for any release that isn’t an LTS. I find them to be high risk, especially in 2019.
- Do you expect different levels of quality or completeness based on the release distinction?
I expect that all features included in a .0 or .1 release to be usable if not complete, with the provision that any new feature is used at your own risk. By LTS it should be sufficiently complete as to be usable with the confidence that Unity will in fact actually support it.
- What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?
Stability and a guarantee that the editor will be able to publish to all platforms that are supported.
- When we say something is in Preview, what does that mean to you? Why do you feel that way?
It means that it we use it at our own risk, and that we acknowledge that we are unpaid QA for the feature.
That said, it also means that we as users have a direct effect on the active development of the feature. This to me is a good thing.
- Does the expectation of quality change when you see something in Preview? What drives you towards using something in Preview? What keeps you away from using something in Preview?
I expect that it may have serious usability issues and bugs that could prove to be showstoppers, and which may or may not be addressed in a timely manner.
Other thoughts:
I LOVE the package manager for its ability to allow us to reasonably and sensibly share our own code and 3rd party code amongst out own projects. It has been an absolute game changer in workflow for the better. Simply amazing. It is one of my favorite innovations just for how much improved this is from how we had to manage code in the past.
However I have to echo others sentiments when it comes to how Unity uses it’s own package manager to distribute code to its customers. Packages should either:
- Support all officially supported Unity releases back to the oldest LTS
- Not be available for installation on unsupported Unity versions at all.
Also it should not be released without adequate documentation.
Wow. First off, thank you for such a detailed response!
Is the tradeoff of LTS being the stable branch and Tech as the less stable option an acceptable tradeoff for you? Interesting point about LTS and the correlation with platform providers. Do you find pressure to be on LTS for that reason or is it more the long-term stability aspect knowing you can update your game safely on the LTS version? When you get those stalls, do you send us any profiles or bug reports when those arise?
Makes sense regarding future updates to LTS being painless and working. Curious if that view is also shared with packages you install alongside the LTS version? Do you mostly stick to Released/Verified or dabble into Preview packages with an LTS version of the editor?
Interesting point about the coupling of packages with the editor. If a package forces you to migrate to a new Unity version, is that a potential blocker for you? It sounds like the ability to update a package easily without having to migrate to a new editor version unless absolutely necessary would always be the ideal for you?
For Preview, what would complete be for you? For example, if we said the new Input System was in the very first iteration of Preview and only supported Mac/PC, how would you feel trying that out? If we continued to iterate and add new platform support while in Preview (through new package versions) would you still continue to use it or wait until it had everything you needed and was officially released? It sounds like for you in a professional capacity it’s about integrating something when it’s done and ready, not so much to be on the bleeding edge and try things. Another question is what helps you understand the value a package provides? Your Input System example was great as far as simplifying the NDA’d platforms and not being reliant on third-parties. Wondering if there’s other key things you look for when evaluating the impact a package will have on your work.
Made a note of the documentation that I will pass along to our documentation team. This is something we’ve heard quite a few times when it comes to packages and docs.
What are some things you would have us do to hold packages to higher standards like the core engine?
Again, thank you so much for the detailed response here! If you haven’t taken the survey, I’d also encourage you to fill that out and help us get an idea of some thoughts we have on improving the package experience.
If the tech releases became much more solid and stable, how would you feel? When you see “Known Issues” in the release notes section, what’s the expected timeline for those to be addressed for you?
Interesting note on the preview label. Have you noticed any difference between a preview package and the verified/released packages in your experience? Does the label offer any significant value?
Yes, because of the nature of the render pipelines being tied to the core engine this is an unfortunate side effect. Ideally, what would you expect in this situation? Quality of life improvements, enhancements, and patches based on the compatible versions of HDRP 7.X over its lifecycle? What would the ideal situation be for major versions like HDRP 7.X → 8.X that might require new API’s or core changes?
Do you personally stick to the LTS releases primarily? Having a standard expectation that every minor or patch release on the non-LTS will break you doesn’t sound like an ideal situation for our users to express.
Interesting point about the platform support. Have you been stuck in situations where you lost the ability on an LTS version to publish to a specific platform?
What would be the ideal turnaround time for bugs found in an LTS release?
For packages, you mention the direct effect on development is a good thing for you. What are some of the primary motivators there? Developing in the open with the community? Being able to provide direct feedback and help guide the feature towards a successful release?
What would the ideal timeline be for bugs found in a preview version of a package?
In situations where we can’t guarantee forwards compatibility (to the oldest LTS) what would you expect package manager to show you? If HDRP 7.X is not currently supported in the version of the editor that you’re running, what would you expect to see in Package Manager?
Thanks for your feedback!
I’m generally okay with working with TECH releases. I take stability issues more or less in stride. I will say that my attitude towards stability is probably strongly related to the fact that I have a “Save on entering Play Mode” editor tool running, otherwise I’d probably have lost it long ago. Sure, people don’t like crashes that cause Unity to have to restart, but they sure hate crashes that cause them to lose work. Any reason Unity doesn’t have that as an option natively. The majority of the crashes I experience are on entering play mode.
I generally hope for Known Issues to get some attention within another couple of patch releases after appearing in the notes. I realize that’s not always the possible. But it was a full two months after 2019.2 was released that one of the known issues at release was fixed, at which point I was able to upgrade my project to 2019.2.
I don’t think I’ve noticed any real difference between preview and verified. Mainly, as I said, I think of it as whether the API will contain future breaking changes, and I don’t really think of it as a question of the package’s quality. It doesn’t seem to me that “preview” packages are full of bugs that suddenly get resolved for the verified release. It seems like steady march towards functionality and reliability that finally concludes at release.
In an ideal world, I would hope that HDRP features would continue to be added to some 2019.3-compatible stream of HDRP. It’s not at all clear to me what future features in HDRP will be dependent on new engine functionality that doesn’t yet exist in 2019.3. However, I assume that a fair number of features aren’t in HDRP 7 not because of missing engine support, but just because those features haven’t been prioritized yet. For example, I had hoped that by this point, we’d have full support for UI shaders in screen-space canvases. That didn’t make it into 2019.3. I don’t know if that’s waiting on any new engine features, but I’d assume it’s more of a priority thing. Assuming it’s just about prioritization, I assume those features will never make it onto a 7.X HDRP branch, even if 2019.3 would support it. That’s the disappointing part. I understand that backporting things dramatically increases the complexity of the package. But it’s unfortunate if every new feature is exclusively implemented only as part of the upcoming alpha’s development cycle.
Tech is Beta, LTS is usable (at least a few releases in LTS). But in the end it’s pointless, since the bug I find in LTS will probably get fixed in a non LTS version (I’m sure there are valid reasons, but…) making LTS pointless.
My expectation for a new Tech version is that it’s broken in obvious ways and all introduced features are barely usable.
Since after every LTS you basically “reset” on stability my expectation is that every Tech is a beta that can’t be used, and LTS is “fine”. Since you keep resetting the cycle every year, I can’t see you ever releasing anything that will be considered good. (especially since certain bug fixes are dubbed “features” and are never ported back to LTS).
I don’t know how feasible it is, but I wish you could have gone with some model, where over time, there is an overall improvement to Unity (with ups and downs of course), and we didn’t have to go back to square one every year.
Right now what happens I constantly have to make the choice between staying on 2018.4 and have our game not crash all the time on Android vs being able to bake light probes that don’t look like ass, thanks to features and bug fixes that only landed on 2019.3, but having to sacrifice everything else for that (editor stability, built game stability, performance).
Whether I want to work or fool around.
It means it either:
-Doesn’t work at all.
-It has been deprecated/abandoned, you just haven’t announced it.
-Might not be there tomorrow.
I don’t consider preview and early releases to be that different. I still expect:
-It might not work at all.
-It might be abandoned (you have a history of releases undercooked features and then doing nothing with them until you replace them).
-Might not be there tomorrow because. Liberally paraphrasing: “We heard your feedback that feature X (which we’ve been working on for 4 years) totally sucks so to fix that we will spend another 4 years to make a similar feature that will also suck but in new ways!”.
-I should not any installed because they will be used as excuses for lack of stability. Liberally paraphrasing: “The editor is crashing? Oh wait, you use a PREVIEW package, you should be expecting crashes then”
If you ask people what they want, they will say “faster horses” and they would right 100% of the time.
But let’s take a step back and look at the bigger picture: unity communicates and present all versions with the same level of focus. A new incremental version comes out, a big blog post boast about all the new cool toys you could play with, and you download all of them on the same place. Practically they are indistinct and functionally they are too. That mean that whatever responsibility they supposed to have bleed into each other. Worse is that people not privy of the lore of the community and don’t read blog, just assume the last versions is just the best, tech and lts don’t stand out. That’s a communication problem.
Contrast to how other software are presented often with faster and more broken experimental released, as fast as nightly build. They have a clear separation of concern, bug incremental number are meaningful and first class, they have the bombastic blog full of features, with day one documentation, a download section that emphasize the last version and a secondary call to action for older release and tertiary separate one, for experimental. The last version is guaranteed to be complete, and stable, and it create in the community an atmosphere of town fest. Experimental features do have their blog post, but the tone and presentation are distinct, they have the theme of exploration contrasting the various question arising from the journey and how the team is fighting around to discover the new features we will soon be able to play with, ie creating anticipation without actually announcing anything.
This sense of adventure use to be in old unity post, Aras blog was pretty much like that, in his epic quest to kill shader, up to conceptualizing surfaces, it was aspirational without making would be unkept promise. We add a sense of the challenge he faced and the solution only made then practical sense, engaging into a discussion, without having to unveil a silver bullet to be criticized after the fact, ie it prevented unnecessary expectations.
So while i haven’t took the time to verify jetbrain’s alpha vs released, when the answer was “i don’t mess with jet’s alpha”, I’m sure the communication between the two states is much stronger than unity’s.
The Tech releases are hastily relabeled Beta releases. They are notoriously unstable for almost all of my projects and I’m not sure I can even trust the LTS release of 2019 given how bad 2019.3 has been so far.
Were they any lower at this point, I could use them to tap into geothermal energy and power my apartment. I only touch YEAR.2.X releases if absolutely necessary, but for the time being I am sticking with 2018.4 with a branch on the latest version of 2019.2 for testing purposes and maintaining compatibility for internal tools.
I feel that this is answered by my last two responses.
Stability, both in terms of stability in the engine and stability in the API itself.
It means it’s a fun toy I can mess about with, but won’t be ready for use in production for at least two years. I feel this way because of the absolute state SRP/LWRP/HDRP/URP have been in for the last year, the new input system being extremely similar, same with UIElements (why isn’t there a simple grid system STILL?)
As stated, my expectations for preview packages are that they are a toy mixed with a trailer for coming attractions. I’ll use them to get a general idea of where the engine is headed, but I won’t use them for any significant amount of time because things like constant API changes and the like mean that I’m constantly playing catch-up. It’s not even worth using things that have come out of preview for at least six months sometimes because all the reference material (both from Unity and from third parties) is notoriously out of date.
Also, just as an aside: why on earth is there a button in the default installation of Unity that claims to gives me access to the sprite editor, but I have to install the 2d sprite package to actually use it? If there is an explicit link in the editor, I should not have to install a package. Either the link should be removed until I install the package, or the package should be installed by default.
Largely we stick to 2018.4. The specific minor release within this depends on how critically we might need a particular bug fix or update. We dare not update to 2019.4 yet for any in-progress projects.
Not in quite a long time. The last time that was the case, Unity had just begun to use the 2017.X notation and projects I’d created in Unity 4 could not be safely updated to 2017 but yet also could not be published any longer to the platforms they were created for from within Unity 4. That does predate the LTS concept, though.
It’s less about the turnaround time for specific bugs, so much as it is what other people have mentioned in various posts in this topic. Rather than continue to build out newer and newer features that will end up with questionable quality and support, a commitment to prioritizing existing released features would be helpful. It’s like AcidArrow says :
With elegance, it solves the problem that the old-fashioned “Export Unity Package” → SomeFile.unitypackage process tried to solve, but never truly did. We can simply edit a manifest to reference shared code, shared prefabs, shared assets. It’s a huge boon. It enables us to create advanced workflows that allows us to not only share our work with each other but share relevant work with each other. It allows us to keep concerns separate while also allowing us to blend them when necessary by declaring dependencies. The requirements to properly namespace and create assembly definitions enforce very disciplined coding patterns that are an overall boon to us.
Regarding Unity’s packages, it allows us to more directly modify and extend the code that Unity ships. It allows us to more easily diagnose bugs in that code and offer bug fixes for them, whether or not those fixes end up integrated into the package when we file our reports.
Possibly a few different options:
- The version simply doesn’t appear in the list of versions availble.
- The version appears in the list of versions available but is never selected by default.
- The version appears in the list of versions, and if it is selected a warning appears in the editor window.
On that last one, I would generally prefer that Unity still allows the package to be downloaded, in the event that we want to try to bring the package into shape on our own, but I would also be fine if the Install/Download button were simply disabled.
Hi @smcclelland . I would like to ask what’s the ETA of shipping avoid reload whole domain feature? It means each time when I change one line of code, it will not domain reload all the dlls of the packages from Package Manager. That’s the feature I really I hope it can ship at Unity 2020 release cycle. Currently with more features introduce as packages it continuously slow down Editor further and further. It really needs this kind of feature to really solve this problem. From what I know last year, the feature has been working on but this year I didn’t hear any new update yet.
Somebody posted this in a chat group recently, and I think it kinda sums up why you’re getting so much push back now:
In essence, you have a bunch of packages and new things that are “going to be great we promise”, and a bunch of old stuff that’s just… there, lingering.
Unity’s actually pretty great now when you use 2018.4 LTS and don’t include any major preview packages. It’s the most stable it’s been in a very long time. I expect 2019.4 will be decent once it’s hardened, and I don’t expect that to be when you ship it. At all.
I’m generally happy with the situation, but the only reason I think that I can be is that I’m regularly on the forums and am aware of all the stuff you do. Whenever I talk to my coworkers about the state of Unity, and everything it contains, their eyes blank over real quick, because there’s so much stuff, and so much uncertainty.
The only real large problem you have, as far as I see it, is that your package developers keep chasing the bleeding edge. If almost all packages “has to target Unity 2020 due to engine changes”, then you’re not really making packages that are independent of the engine. You should probably try harder on this front - I’d be fine with the packages having smaller feature sets if they targeted hardened versions of the engine. That way we can actually use them for real things.
Ugh, all of your surveys are confusing and messy, but this is the worst one yet.
What is the total number of employees in your company at this mailing address?
That’s strangely formulated! Drop “at this mailing address”, it’s not a disaster if the person answers for one of the companies they work for instead of the other.
If you have the ability to install features with packages in Unity, how would you feel? *
I do. I do have that ability. Why are you asking as if it’s a hypotetical?
If you do not have the ability to install features with packages in Unity, how would you feel? *
That’s the same question as the last one, with a not in front of it. Waht?
How important is it for you to install features with packages in Unity?
That’s the same question again!
If you have the ability to install preview packages in Unity, how would you feel? *
I do, though! What’s up? Did you make this questionnaire before Packman launched and forget to update it?
If you do not have the ability to install preview packages in Unity, how would you feel? *
That’s the same question as the last one!
How important is it for you to install preview packages in Unity? *
You have asked me three questions. Why are you rephrasing questions?
I could keep going on. The absurdity of having to answer each question three times just makes me not answer the thing. I can’t understand how you’d possibly get any value out of this mess.
Heh, yeah that image has definitely made its way around the internal networks 
Point taken on the compatibility and having packages that can move independent of the engine. We have some discussions going on now about how we deal with packages much closer to the core (SRP, DOTS, etc) going forward vs other leaf packages that don’t rely as much on the core editor.
I really should have added more clarity to the original post about the survey as I realize not being able to bold the key differences or explain them might be causing the head scratching. The point of “at this mailing address” was to understand if the person was writing representing themselves, or a company. The first question isn’t a hypothetical so much as it is what’s the value for you in adding packages - it’s not the best wording but the survey format we’re using requires this type of format:
- Functional Question - How would you feel if this functionality existed (or does exist).
- Dysfunctional Question - How would you feel if this functionality did not exist.
- Importance - How important is it for you to have this functionality in Unity.
1 and 2 are extremely subtle differences while 3 helps us understand how important something is to someone.
There’s actually a ton of value we get from a survey like this as it breaks things into a few key categories and metrics we can track against. Apologies if this one is the most confusing one and pretty painful for you. That absolutely wasn’t the intent behind this one!
I’ll look into this one with the dev team and get back to you.
First off, thank you for opening up this topic to discussion. It really shows promise.
I don’t normally get involved in these discussions, because I’m a hardcore hobbyist riding the bleeding edge DOTS tech, but I do watch many of the other threads and I have a pretty good grasp of the root causes of frustration.
Before I get into that, one thing I will say is that packages, when done right, are a very good thing. The key is that the team behind a package needs to be active in the community for the Preview/Release/Verified workflow to make sense. Burst and QuickSearch are two excellent examples of packages done right. Preview is very much “Hey! We are developing this! Try it out and let us know if we are on the right track!” Release is what the team decides is a proper release. And Verified is when the Release was vetted against everything else. There are plenty of other benefits to packages. They just need to be handled well.
About 60% of the frustration I have seen with Unity’s forward development stem from one of two issues.
Issue 1: SRP
Because packages are whitebox, marketing went ahead and advertised them as “Extendable”. That was misleading. Sure, a team could go in and modify a package for their own needs, which will help medium to large studios out, but modifying packages is not an option for asset developers. I don’t know why, but Unity has always written shaders in a spaghetti style. And so it becomes difficult for someone to go in and understand what is going on. In combination with that, ShaderGraph is completely closed off from extensions, so people cannot even use it with their own SRPs without forking it. And at the same time, marketing is advertising the exact opposite about the technology which is frustrating. Heck, even the Snaps HD team hasn’t bothered to keep up!
Issue 2: LTS
As soon as 2019.4 rolls out, 2017.4 will stop being supported. Therefore, bug fixes that are being made to 2017.4 right now are kinda worthless because everyone is trying to get their projects up to 2018.4 which is less stable and more riddled with bugs because it hasn’t been in LTS as long. I understand that Unity is in a state of transition and that it is difficult for them to stabilize things quickly. The problem is that people are having to ride these less-stable changes because the stable versions aren’t going to be supported long enough.
There’s a simple solution to the LTS issue that I’m surprised I haven’t seen discussed more. Increase LTS to 4 years. That seems extreme and a lot of work, but add in this: LTS versions older than 2 years DO NOT receive bug fixes, only platform updates and security fixes. The platforms Unity supports update their toolchains too frequently for an unsupported Unity version to be useful. But after two years, any remaining bugs will be bugs the Unity community will learn workarounds for.
Personally i think HDRP looks amazing BUT these separate Render Pipelines have made all my purchased assets unusable unless i basically buy the entire asset again with “HDRP Support” I am not a rich man and am not a skilled software engineer capable to convert every asset I have bought to work. Unity is unusable now due to these iterations.
Why could we not have had 1 pipeline capable of doing it all like previously? Now i have to make a hard choice if i want to use one of 3 pipelines. 1 being the standard, which i assume you will soon no longer support and will be replaced by the Universal Render pipeline(Which i also have to rebuy all my assets) or the HDRP and rebuy all my assets.
Is there a solution to this problem? Id like to not have to convert 100 pages of code and not like have to rebuy everything.