Feedback The State of Unity & Packages in 2020

@Murgilod

What are some of the major things you found in 2019.3 that would worry you about the LTS version? Are you using the beta much? I'm curious for those that are on the beta releases is there much of a difference or do you see a difference over time with the beta's leading up to a tech release?

Ouch... not a strong point for us on that front then. Any suggestions or requests on how we can turn this around so you feel more confident in the releases?

So Preview for you is basically a two year timeline until it's ready? And is that something you look at as feature complete end-to-end? Using UIElements as an example, if that came out of preview without a grid system but we were able to add it in say a 1.1.0 release, how helpful is that for you to get these quick iterations through packages?

Fair point. It seems our documentation, or lack thereof is a very common thread across the package feedback I'm seeing.

Ah, yeah. So there's a few things in there from the early package days like that which we need to do a pass on. That was a core modification we made in the importer which should check if the package exists and then show the button. Noted and will pass that on to our 2D team. Thanks!

 

@DreamingImLatios

Appreciate you willing to ride the lightning with us

Yes, that was always our intent with packages was to develop in the open with our users and use the feedback to drive iterative development. We certainly see the engagement with the Burst and QuickSearch teams as prime examples of this working well. Handling that well at scale is where we'd really like to get to.

Yeah, definitely with SRP it has been a challenge and there have been lots of changes such as internalizing a lot of API's that were once external to help stabilize things. We opened up a lot of API's early on that then needed changing/refactoring and we realized we'd made a bit of a mistake opening them up so early. Lesson learned there. Any insights or thoughts on how we might be able to improve this and make it less painful for asset store developers to keep pace or stay synchronized with our SRP ecosystem?

Regarding LTS, it sounds like the rollercoaster ride that was mentioned a bit further up. Because our tech releases weave into the LTS there isn't this improving stability over LTS releases because as we start to weave features in from the tech releases it resets some of the stability from older LTS releases. Is that accurate here? Would it make sense for us to take a more Ubuntu oriented approach where LTS has this very focused quality thread and LTS versions only get stamped when they meet the maximum criteria for an LTS release possibly even omitting some features/functionality if it risks breaking stability?

Four years would actually be interesting. I'm curious to hear how others would feel about this? Would you expect bug fixes to taper off after two or have a fully supported LTS with bug fixes for the four years? Also interested in how this aligns with everyone's release cadence on their projects and studios.

Thanks!

 

@remembadaname
Yeah, this is something I've talked to our Asset Store team a few times about. We've batted a few ideas around how we might be able to do better testing and integration tests using some internal infrastructure we have but they're just discussions at this point. I'd be curious if there's value in us externalizing some of our testing infrastructure so asset store developers could run the validation suite against asset store packages being submitted for compatibility? i.e. run the HDRP validation suite and know if your asset pack is compatible with HDRP or needs some fixes/changes.

It's a good question and generally breaks down to hardware optimizations and platform needs. To have a single render pipeline handle all cases introduces a lot of feature bloat and overhead that would detract from the performance and functionality we can provide. Splitting into HDRP and URP gives us much more fine-grained control to optimize and evolve over time with new graphics API's and hardware rollouts. One thing we realize would be nicer though is to at least have data compatible between the pipelines so switching between them wasn't so hard.

To answer your last question, there is no solution right now but the data pipeline between SRP's we're looking into how we might be able to address that problem. For the asset store packages, we're engaged with our graphics and asset store teams to see how we can make it less problematic for people using asset store packages with render pipelines. Definitely open to hear how you would want to better understand if asset store packages are compatible or incompatible with certain render pipelines.

 

Through discussions like this. On the product side, we do a lot of customer interaction to funnel the data back into our respective teams. This all gets funnelled into an internal system we use to link feedback against ideas or things we're working on and helps drive a lot of decisions on what and why we're going to build something. We then work the engineering team to help scope out what needs to be built and then validate that with our customers. Surveys are just one tool in our toolbox we use

 

@Deozaan
Alright... got my full pot of coffee ready for this one. Let's roll!

Your analysis of Tech vs LTS seems to track with what others are saying in this thread. Your expectations align with where we'd like to see both streams at as well - Tech being a stable and quality release of their latest features while LTS serves as a stable foundation for those that need the utmost stability. You propose an interesting concept with the two branches and is similar to how we've seen other SaaS products defined with Beta releases and then the stable production releases. Beta is where people can try the new stuff, might be buggy, probably crashes, shouldn't use it for production work and then eventually those features find their way into the stable branches and the next major product updates. Is that similar to what you're describing here? Locking down on LTS from the stable branch would also be interesting, though if we keep the production version as pristine and stable as possible where only vetted features migrate to is LTS still required here? Would we need three versions here (Experimental, Preview, Released) in your opinion or would the original proposal of two (Experimental, Released) suffice? We've toyed with the concept of nightlies before but it's been mixed feedback if our customers really want to be on nightly builds of the editor.

Regarding versioning - what if it was just a steady stream similar to Chrome? Does using the year number mean much to you if we're moving to a constantly releasable state? I imagine if we're talking LTS versions it might. And from the sounds of it, we'd follow the semantic versioning standard where major versions would be the releases to introduce breaking changes/non-backwards compatible changes while minor and patches could be non-disruptive, is that accurate?

What's your stance on removing things between phases? For example if something isn't quite there in the Alpha phases, do you expect it to solidify more in Beta or just be deferred? Similarly, if something isn't quite as solid in the late beta phases would you still expect to see it in the final released version? Agreed on known issues, at my last company we ran Agile where we couldn't close out a story until we had addresses all of the known issues - we knew we'd probably have bugs after lunch but we'd never be able to say Feature X was "done" until all the outstanding issues were fixed.

Lots to digest here and a ton of really interesting ideas and concepts to explore around this. Thanks for such a detailed response and in-depth analysis of your proposal!

 

@transat

What would you include the text input box for each for? Other thoughts per question? Curious to know.

Regarding Package Manager, yeah, there's a few rough edges around the usability that our design team is currently working on. We've got an awesome global design team that's actively looking at ways to constantly improve the user experience in Unity. If you or @Lars-Steenhoff are interested, I'd suggest taking a look at the careers page and putting in an application as we've got a few design positions open.

Convoluted from the naming perspective? Marketing perspective? Given that we also run Alpha and Beta programs, how would that drive the naming of our public releases in your eyes? Are you saying you'd rather we just have 2020 Alpha and 2020 Beta as public releases?

Interesting note about 2020.0.1a25 being the most stable version so far.

When you say opposite, you mean the motivation has been to be more on the bleeding edge than on the LTS releases as a serious hobbyist? Sounds like the driver there is to keep up to date on the latest technology and trends but that's been met with a lot of instability and frustration.

Unfortunate to hear that you feel the feedback provided is not heard through the Preview cycle. Are the development teams actively engaging with you on the feedback? Which means are you using to drive the feedback? Forums? GitHub? Other?

Yeah, the My Assets in the Package Manager is still a work in progress. Would be keen to get some raw feedback from you on that so we can funnel it back to the asset store and package manager teams. Feel free to drop me a DM with all the details if you'd like and I'll make sure it gets captured in our feedback system and passed onto the teams. I've captured your ideal notes into the system already but in case more come to mind do send them over.

Cheers!

 

When you say packages in the LTS cycle, do you mean having the ability to do more backwards compatible fixes? i.e. ensure that as many of the minor or patch releases for packages can safely be integrated into packages compatible with the current or previous LTS versions?

 

I don't think you're getting very much value out of simultaneously having an Alpha and a Beta and preview packages. For end users, the value of an alpha and a beta are the same - give feedback on the state of the product, report bugs. The downside is the same - the product is not supposed to be bug-free yet. Having to merge bug fixes into five different streams (nightly, alpha, beta, tech, LTS) must be a nightmare of complexity. At the same time, people who want to test the bleeding edge and give feedback doesn't know which stream they should opt into.

When you're reducing Tech from 3 to 2 versions each year, I think you could skip having a simultaneous alpha and beta. Simply have 2020.1 alpha -> 2020.1 beta -> launch 2020.1, and then ship the 2020.2 alpha.


Unrelated:
One thing that strikes me is that while the whole Tech stream thing is supposed to allow you to deprecate things, remove them, and generally make breaking changes to the product. But you seem exceedingly unwilling to do just that.

The other day we ran into a bug where AssetDatabase.IsSubAsset returns false for sub assets that are hidden. There was a bunch of related bugs as well, all which had tangible problems that we had to work around.

The answer to the bug report was "we're going to not fix this and update the docs, to preserve backwards compatibility": Which is... what? I'd completely get not fixing it for 2018.4. I'd almost get not fixing it for 2019, since that's in LTS soonish. But not fixing it for 2020, which has big red "this is not backwards compatible" flags all over it seems strange.

In essence, it seems like parts of Unity is still in the old headspace of the engine having to be backwards compatible at all costs, to the length of having methods not do what they say they do in their name because some code might depend on it.

 

I was looking what Unity version and rendering tech to use for our next project. My idea was to use 2019.4 LTS once it's available and UniversalRP.

However, missing URP features, such as SpotLight Shadows? just to name a random one, do not get implemented in the "URP for Unity 2019.3 package". These get implemented for Unity 2020 instead.

If I would pick URP, there is no point to use Unity 2019 at all, because it's lacking features the entire 2019 LTS cycle.

Perhaps packages should receive these new features for LTS releases too, otherwise you're locked out and have to rely on TECH. Perhaps packages should be released as LTS/TECH for a LTS Unity version too? I don't know, the problem is basically that I would like like to have the opportunity, if I commit to a two year LTS, to not be completely locked out from packages that are incomplete at the time LTS is released.

 

There are 46 packages verified for 2019.3. There are 8 verified for 2018.4. That means that your package teams are mostly targeting the bleeding edge rather than LTS.

The whole value proposition of packages is that we can opt into features we need without opting into updating the entire engine. When you're targeting the latest version of the engine, that all falls away, and we might as well not have packages.

I get that for some packages, there has to be engine updates, but I think that you should prefer spending the time on work-arounds so the packages can work on LTS rather than getting a "better" version by adding to the core engine.

 

With my game design, I'm focused mainly on the LTS cycle. It's what we needed back in the 4.x-5.x days, but couldn't get. My game's plan is designed to work with the 2018 LTS, and if it would be worthwhile to upgrade it to the next LTS, I would do that, and I would in theory keep upgrading the game year after year.

It would also be great if each year's LTS could be delivered around year's end, so the upgrade process can be more easily planned for.

Another benefit to the LTS version: asset store stuff works with it. It used to be very difficult to get even a small group of plugins all working properly with a particular point release. The LTS version is the answer for that. Generally speaking, it all works and is as stable as it is going to get.

I don't have a whole lot of input on the packages, previews, or tech cycle. Packages are helpful when they bring things like bug fixes without having to download a new Unity version.

Preview packages and the tech cycle are pretty much the same thing to me: the cutting edge. It's good for Unity users to be able to get hands-on experience with the new tech as soon as it is available. They can find bugs and provide valuable feedback.

 

Node system for shader graph is very slow when adding, deleting and rerouting nodes.
I want this nodes system to be upgraded at some point in LTS. If you leave it as it is then user is stuck with it through whole production with frustration in complex graphs.

Another are dependencies. If I use something in this version of SRP, chances are this implementation will be deprecated in next 2021LTS.

 

I expect known issues to be handled within one or two minor point releases...

 

The problem is that there is now 3 incompatible pipelines, which makes Unity generally extremely complex and error prone, plus is not Unity anymore, is 3 fragmented platforms each with its own sub categories like VR, mobile etc for near infinite complexity.

So first thing would be to discard all those pipelines an re-unify Unity to a single system and automate all complexity behind a single platform.

 

Yeah, if fixes to packages can be backported to LTS versions that would improve the lifetime of the LTS. Of course if it's a preview package, I get that's not feasible. But if it's a verified package I don't want to have to upgrade from an LTS to a Tech release to get package fixes.

 

On point I wanted to touch on in my previous post but ended up deciding against:

When reading the forums or otherwise interacting with Unity staff, it feels that most teams are understaffed. Now, a quick google search says that there are like 2000-3000 employees in the company. When you deduct marketing, sales, evangelist, lawyers, etc etc. Just how big is the engineering team? Including devs, QA, project managers, etc.

Because it seems, either it's disproportionately small, or it's spread too thin. I understand there's people working in thing we don't see and/or are internal tools, but It's kinda worrying that every other team looks like it needs like 50% more people.

In the lasts 3 years Unity's been spinning new features like crazy. And that's good, specially in a situation where the engine needs to come up to speed to the competition in many aspects. But has that come at the cost of not having enough workforce to solidify what's already in progress?

I don't know, maybe I'm completely off, but that's what I perceive from outside.

PS: I completely agree with this:

 

@Baste - It can be a huge challenge, yes. Interesting point about moving away from the parallel development model. It's something we've bounced around a lot on how to do effectively do less, but better. One thing I'm really curious to understand more is what's the value/impact you look for when we say "a new version of Unity is available!"? Are features the value driver? Stability? Mix of both? What else?

There are indeed lots of challenges and trade-offs when evaluating bug fixes that need a backport. To help better understand this situation, was the request on your end to simply have this fixed in 2020 and not backported? I can see why they might be concerned about making the change and potentially breaking pipelines/scripts though that's more of a communication issue than a technical one. Can dig into this more with the team if you would like?

 

@Peter77
So this raises a really interesting question - should LTS streams be able to take features? Internally we have a policy that only bug fixes and patches can go into an LTS but in this case to add SpotLight Shadows, we would need to likely to a feature into the package and likely some changes into the core editor to land this.

 

Just want to call out that the 2018 cycle was relatively light on packages and then began to increase rapidly as teams shifted over to packages through the end of 2018 and into 2019. What you're seeing there in the data is likely an effect of the adoption rate of package development internally that an indicator of development practices. That said, yes, it's definitely easier to keep moving in a backwards compatible manner (targeting new releases) than it is to be forwards compatible (targeting previous releases).

Excellent points here.

 

I think the main problem is that some packages rely on hard-coded Unity editor/core features, therefore you can only ship a certain package on a certain editor version. We see this and it counteracts the purpose of packages for me.

Packages should be decoupled from the core in a sense that you don't need to change Unity core to make package XYZ work. Otherwise packages don't have a big benefit.

If packages don't need core changes, it would allow packages to add features without Unity core being changed. This should be your goal.

 

I'm curious how many other folks share this view? As outlined above, having one monolithic rendering pipeline means a lot of trade-offs for those building across different devices. As a mobile developer, you're faced with having to deal with the additional overhead and API's required to support higher-end devices and functionality. At the same time, for the higher end platforms you're dealing with duplicate functionality and complexity having to abstract multiple ways of handling things. We learned a lot from the original design of the built-in renderer that informed how we approached render pipelines but the one thing we haven't gotten right is the data pipeline between them. That's something we would like to solve to make it less painful and bridge the compatibility between them.

 

Right now without surface shaders, it doesnt matter about the tradeoffs. Right now its 3 pipelines that are harder to use than 1 pipeline ever was. Thats coming right from the top from people like @jbooth , not just shader newbies.

Until surface shaders are created (which unity havent even confirmed will be made at all) then the new approach is bat**** crazy in terms of tradeoffs anyway.

 

For me as both a game and asset developer is clearly a question why we need a new version, moving so fast to new versions only means that previous were not good to work with, which makes everyone at this point wonder if should go with Unity at all.

So best approach would be to freeze releasing new versions and finalize the previous ones, as long time as it takes, to restore faith that Unity actually works and not need to move to a new version that will probably break everything one more time.

 

I agree with having different render pipeline for mobile device and higher end platforms. I dun like other unnecessary thing putting into render pipeline of mobile device and slow down the performance just like bloatware. About data pipeline, are you referring to transition to DOTS technology to make it easier? I heard there is plan to develop full pure DOTS renderer. Does Hybrid renderer first step to slowly getting there?

 

It's hard to apply a single response to this other than it varies based on team. As far as people... I'd have to actually take a look again but off the top of my head R&D is ~900 or so? It's crazy typing that as when I joined the entire company across the globe was just 1100 people.

The rapid pace of development is something we've definitely struggled to find a balance with keeping pace on innovation and the things our customers need while also balancing the quality and stability of it all. In the past 6-12 months we've definitely been drinking from the firehose of user feedback that maybe we've hit a tipping point where our feature development is at too fast of a pace and starting to have negative effects on the product. Hence, this forum post to dig deeper into all of that and understand how we can balance our users needs better.

 

Yep, we're aware of this one and it's quite painful. The issue lies in async shader compilation not working properly and the shader graph team is aware of it and investigating. Not sure it's an LTS thing but let me check with the team and get back to you on that.

 

I agree too that is best to have two pipelines, but the execution should be in a non destructive way, so if you use one cant use the other etc. A unified library should handle all that extra complexity put to user end, plus would enable to actually use the pipelines feature, as currently making a custom pipleines means you cant use absolutely anything else, rendering the whole effort to have a scriptable pipeline useless.

 

What would you include the text input box for each for? Other thoughts per question? Curious to know.
Yes. When you're doing a survey like this, it's to gather information. So you should not forego the opportunity of respondents going into more detail if they wish to explain their choice. Otherwise you're left with interpretations of their choices and these might actually be incorrect.

Convoluted from the naming perspective? Marketing perspective? Given that we also run Alpha and Beta programs, how would that drive the naming of our public releases in your eyes? Are you saying you'd rather we just have 2020 Alpha and 2020 Beta as public releases?

The TECH stream has recently changed from 3 to 2 releases. So Unity will only see 2020.1 and 2020.2 before going to 2020 LTS (in early 2021). This is a definite improvement over the 3 streams. The naming of the 2 streams doesn't imply that one is more stable than the other however. Just like iOS 9.1 is not necessarily more stable than iOS 9.2 (the difference might simply be that new emojis have been added). In Unity's case, it really is about improved stability though. So take it further and switch to only 1 stream. Then name this stream "2020 alpha", "2020 beta" and "2020 LTS" instead, according to its development cycle. This clearly signifies something to users, including to new users.

In other words, I don't want to hear that you will be releasing a new terrain system in 2020.2 Instead, I want to hear that you are hoping to release a new terrain system in April 2020. And that terrain system should appear in the form of a package. First as a preview package and then as a verified package, working on the latest, most stable version of Unity 2020 (with backwards compatibility to the previous LTS whenever possible).

I'll answer the other questions in a DM.

 

Having 3 renderpipelines also has a lot of tradeoffs building across different devices.
( and missing features )

And there is also forward and deferred.

Making it easier to target different pipelines and devices in a single project is very high on my wish list.

I don't want to get stuck in a single pipeline. ( I would not mind if the single one has all the features )

 

I think you fall into that monolithic rendering pipeline all over again, seeing all the things URP is supposed to handle.

I'm personally fine with different RP's and I'm also fine that these are incompatible with each other. I don't need to run the same project with different RP's.

I think mostly asset store developers run into this problem, as they have to support everything and Unity make this very hard at the moment.

 

And people who target mobile and next gen from a single project, using only different shaders per target device.

 

Not at all. The HDRP/URP split is super-meaningful since it allows us to chose away all of the garbage you stuff into HDRP that will never run on half the devices we target
No, but for real, the SRP stuff is a great idea, and it'll provide us a good way of selecting what to build our game around. The problem is execution.

If the future is SRP-based, and URP and HDRP is "ready for production", why does the default way of creating a 2020 project use built-in?

What I gather from people using those pipelines is that they're not quite ready yet, as in they don't cover everything that built-in does. That's bad! I think you should at least aim to get rid of built-in as default asap, so we have two modern, functioning pipelines instead of 2 modern, half-finished ones and 1 finished but outdated one.

 

Different pipelines are fine as long as they don't slow down general development at your end. Many here think that surface shaders are the answer for us to be able to manage the complexity at our end. But there seems to be a wilful desire from UT to avoid talking to us about why this is or isn't on the agenda.

I totally agree with @Baste saying get rid of the Standard pipeline, but I guess you've already done that in a development sense anyway. What has indeed upset everyone is that URP still lacks lots of things from the Standard pipeline. We didn't think "production ready" meant "minimum viable product lacking lots of the basics".

 

You can't get rid of build in yet because there is no feature parity
( and no easy way to convert custom shaders to URP )

Point light shadows require unity 2020 in URP.
Same for deferred.. etc

2020 LTS is the first version that could have feature parity.

 

One thing I want to ask for long time. It seems like each new Unity version somehow will have regression to the current working feature like currently 2020 alpha animator has regression. Why it always happen? Is that relate to the new changes core of engine or other issue? From what I understand, Unity moves to DOTS and no new feature to the current available classic Unity feature. What I imagine is the current available classic Unity feature should not have regression anymore but seems like it's not the case.

 

Probably one reason because the core is being stripped apart to move to packages, and another:
the way it became harder to test all the possible combinations with packages

 

You mean "will require Unity 2020" ! We still don't have point light shadows, deferred lighting, shadowmasks, ambient occlusion, etc. in the latest release: 2020.1.0a25. Yes these are all meant to be around the corner but Unity corners sometimes seem to just go on and on.

 

Not at all. In fact I agree that URP is trying to become too many things at once again. It's true that the original LWRP/HDRP left a hole in the middle of the spectrum, but if URP starts getting more and more stuff, it kinda defeats the point? For example, and I would love if you could forward this question to the relevant team: what is the rationale behind making 2D rendering stuff part of URP instead of creating a dedicated 2DRP?

 

SRP's are a great idea, but a very flawed execution. It's clear there wasn't much communication between the two separate teams in two separate locations building the current pipelines, and the combination with package based delivery has made it a living hell for people like myself. Let's take an example:

On the asset store I can ship versions of things tied to Unity versions. So I can have a separate version of my asset for Unity 2019.2 and 2019.3. I try to avoid this, but the asset store requires a working demo for every asset, and since every version of the LWRP/URP has changes something and there is no surface shader abstraction layer to work with, I have to ship a version of my asset for each version of the SRP. But I can't, because the asset store doesn't work that way. So I basically choose a version to support in each version of Unity and go with that.

So a user downloads my latest URP adapter, which happens to be written for URP 7.2.1. Between URP 7.1.8 and 7.2.1, Unity changed how the shadow cascade's work, a completely undocumented change that requires diffing through Untiy's source to figure out. If you are running Unity 2019.3.f6, the initial release version, it will download URP 7.1.8 when you create a new URP based project. However, if you're running Unity 2019.3.3, for instance, it will download URP 7.2.1.

So fine, my user upgrades to 7.2.1 and everything works. But now the water shader he's using stops working because it's targeting 7.1.8. So he goes and writes a 1 star review for that asset. Meanwhile, the developer of that asset is doing his shader in ASE- and ASE hasn't updated to support 7.2.1 yet, so even if he wants to add support for 7.2.1, he can't.

There's also a button on the Asset store upload tools which says "Include dependencies". I can't get any clarification on how this is supposed to work from Unity - because, hey, why document, right? But apparently what happens is that if I upload my asset requiring URP 7.2.1 it will cause the system to update the URP to that version. But then when a user installs an asset requiring URP 7.1.8, what happens? I have a report where a user was downgraded to 7.1.8 because of that dependency, breaking my asset.

Unity has created an impossible mess here, and the combination of SRP's lack of shader abstraction and package releases is a total nightmare. Package managers are great when features are orthogonal to each other- being able to update the renderer but leave the old physics system in because it feels different than the new one. But when you have a tanged web of dependencies and everything requires different dependencies to even work, they make everything a configuration nightmare.

Gone are the days of having any single version of Unity which will just work, especially if you use anything that Unity did not create themselves. Also gone are the days of being able to safely update Unity. Unity has basically shat on their own goal of "Democratizing game development" here - making sure their engine is going to be too hard for most of their users to deal with. They need to double down on that core company goal and ask themselves to rewrite these sub-goals to serve that top level goal. Right now, most of the new tech stack is fighting against it, hard. DOTS should sacrifice 10% of the performance for ease of use (it's only like 100 times faster, so fine, lets settle for 90 times faster and have it be easy to work with). Render pipelines should be like switching between deferred and forward (shaders are compatible via an abstraction, can still be completely separate code paths with different visual fidelity though).

John Riccitiello, Unity's own CTO, was once quoted at EA as saying (paraphrasing) "If the projects vision changes, kill the project", and we've watched Unity's vision, along with the vision for its features, slide all over the place over the last few years. URP is sliding from a low end pipeline focused on mobile to a one size fits all pipeline, for instance. These might be the right moves, but the overall vision and ramifications of these changes need to be better thought out and accounted for.
,

 

I am pretty sure @jbooth even wrote his own surface shader style abstraction for SRP at one point, but because of constant API changes and design u-turns I dont think it was something he could have kept up with as it basically meant having to rewrite it for every single package release.

Which begs the question, why not just support one yourselves? if a big portion of user pain is coming from no shader abstraction layer, then add said layer and be done with it?

At least that way for the meantime while you constantly chop and change what the SRPs are and where they are headed, people can still have things work instead of having every package update be a time of sifting through sourcecode to actually work out what has happened and then go about rewriting everything just so what was working continues to.

 

To answer the original thread's questions:

What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?

The goals, or the reality? My understand of the goals was that non-LTE releases would introduce new features in a non-beta form, with LTS versions being only bug fixing. The reality seems to be much different- where package versions change across patch releases, features get pulled back into LTE breaking things, packages being able to be installed in multiple versions of Unity making it impossible to provide a single working version of something for a Unity version, etc.

When you see a new Unity release, what is your expectation of quality?

My expectation is that I'll need to stop working and fix my assets. There was a time when things just magically updated and I only had to see what was new and maybe fix a few warnings. Now it's anything from that to a full re-write.

Do you expect different levels of quality or completeness based on the release distinction?

Yes, I would expect a major dot release to be reasonably stable and well tested with the new features, and that its feature spec remains stable through patch releases. Packages are being used as a way for the developers to break this paradigm, upgrading and re-writing who features mid version release. I would expect LTS releases to be extremely stable, not introduce new features or supporting more than one version of a package.

When we say something is in Preview, what does that mean to you? Why do you feel that way?

I expect that many of the people using Unity will not listen to that label, will download my assets, and expect them to work on those versions and give me a 1 star review if not. I expect that I'll be pulled through a long list of undocumented changes trying to support things as they happen.

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 it to be unfinished and have issues, but the problem is that I'm constantly forced to manage other people's expectations because your rating system on the asset store is royally flawed. Personally I'd only use preview things to check out new features, or if the feature was going to be something core to my project and I was willing to take the risk - but I'm forced into using preview stuff all the time because I'm an asset store developer. Further, Unity pushing SRP as being production ready when it's clearly not doesn't help.

 

@smcclelland An idea... Start an invite-only conversation with some of the top developers from your asset store. They are at the frontline of these changes and in many ways they have been Unity's lifeblood until now. People like @larsbertram1 @jbooth @jimmikaelkael @tatoforever @LennartJohansen @LouskRad @nasos_333 @Amplify_Ricardo @NatureManufacture @AdamGoodrich @DenisLemos @jjxtra @raphick @Fewes @Thrawn75 @Vondox and other big hitters. Ask them what Unity could do to reduce complexity. The assets these guys develop help polish the engine's rough edges. Pick their brains and reward them with countless free assets, free Unity Pro, cash. Reduce their pain and they will help you reduce ours.

 

I did, actually - and that's basically what MicroSplat's URP/HDRP adapters are, but only for what I need to do in MicroSplat. They consume most of my development time these days, meaning it's hard for me to spend time doing anything but keeping up with unity changes. I just finished fixing all the URP bugs from 7.2.1 last week, and 8.0 has just released.

Because it's more efficient for them to have every asset store developer and company that uses SRPs do it themselves? The whole situation is just so silly at this point, and the defining silence from Unity on it, having never said a word about it publicly, says a lot. I highly doubt they are going to comment on it in this thread either- the best that has ever happened is that after a large blow up on Twitter they said "Hey, the forums would be a better place for this - can we have the discussion there?" and proceeded to never talk about it on the forums.

This situation is basically like if when Unity releases their new Visual Scripting System, they said "Ok, we're dropping this whole C# thing- instead, if you want to write code instead of using the graph, you'll have to use a different API for everything on each platform you want to support; On OSX, it's GetComponent(), but on windows it's CanIHazComponent()".

 

On the whole asset store thing - we try to avoid the store because dealing with it is a bit painful. One of the main reasons is that it's hard to know if the assets are supported on our Unity version and package combination.

 

With packages, it is possible for a user like me to diff each released version using git or other tools. Rapidly changing codebases are much easier to deal with in this manner. I do this with DOTS to great success.

What I would like to see is packages adopt an experimental namespace exposure layer that could be enabled with a scripting define and would just be public wrappers around internal code and a promise that such API will change. This will open up the dialog between package developers and asset developers to shape and refine the API. In addition, at the LTS, this API, as rough or polished as it is, will get locked down and drop the scripting define requirement. This allows asset developers to choose their battles, innovate, and provide helpful feedback rather than always complain that they can't do what they want to do. Both shader graph and Entities codegen would benefit a lot from this. I'd expect the entire shader codebase to be considered under this experimental namespace, even though it will lack the C# features to specify as such. In addition, having a developer spend a day writing up docs introducing the shader codebase as if they were onboarding a new team member and point out the mutable areas and the infrastructural areas would be invaluable for kickstarting asset devs.

I don't think you need to match the Ubuntu approach. I think with the drop to two tech releases per year, an LTS should start off on a little more stable footing. What is important is that it is locked down long enough for a large project to be built on it before it stops being capable of building for target platforms.

I only expect bug fixes for two years, unless they are security or platform related. This would save development man-hours for the other two years and give people more confidence that a bug fix won't break their project because there are no more bugfixes (which should be fine because after two years the LTS should be pretty robust). Of source you could always make rare exception.

If you can't already tell, I'm trying to propose solutions that require the least amount of effort on your part.

 

A big reason I'm worried about the LTS version is the fact that I remember what state the engine was in when it extremely prematurely left beta. The only thing it seemed like the beta fixed before the release version was a major performance regression, but that says nothing of the stability of working with the engine itself. I still get routine crashes that I can't even really file as meaningful bug reports because I can not reliably reproduce them.

These crashes do not occur in 2019.2.x or 2018's LTS.

The beta for 2019.3 was so severely unstable and loaded with performance issues that I basically had to give up on the idea of testing it, because I found I was doing that more than I was working on my actual game.

The switch to two major releases a year might help, but honestly? I'm thinking that the current release model might not be any good at all. It looks good from a marketing perspective, I'm sure, with major version getting Big New Features™, but as somebody who has been working in Unity for a while, those Big New Features™ often come out in states that aren't exactly good.

I can point to things like UGUI and Enlighten for this. Both of these features launched like they were, for lack of a cleaner analogy, a wet fart coming after a drumroll. UGUI had performance issues for ages when it came to resizing elements with children, there's still loads of workflow issues (which UIElements is purported to solve), and really just working with it is a pain unless you've managed to hit a sweet spot in specializing in it. I've had to implement my own UI system because UGUI is a bit of a slog. Enlighten had so many baking speed issues for so long that I just gave up on using it entirely back in 2017.

If you want me to feel more confident in engine releases and their new features? The simple fact of the matter is that everything needs more robust testing to ensure that both performance and UX are up to snuff. Unity has had increasing issues with the former and has had long standing issues with the latter.

Not even feature complete, but just having the kind of features you would expect. If UIElements came out of preview without grid support, something that people have been asking for pretty much since UIElements first became available? That'd kinda prove my point. If you're making a UI, being able to plonk down a 3x3 without having to write your own system can be a godsend. Grid support should be a part of the preview package, even, because at least then we can make sure it actually works.

I simply can't trust Unity package releases because they feel so incomplete and suffering from stability issues. I don't need fast iteration, I need to make sure I'm not going to have to dedicate significant evaluation time out of my dev schedule to see if I can actually use the new UI system to actually build a UI.

I've mentioned this in other threads back when 2019.3 was in beta, but it is increasingly difficult for me to trust Unity as an engine, and that's a problem when Unity is where I'm making my games.

 

I'm what might be called an "advanced beginner" with a very narrow focus, so my experience with Unity is with some specific things and not much else (no 3d stuff, terrain, multiplayer etc)

What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
Tech release is for new features and bug fixes, LTS is bugfixes only, with LTS being more stable, and Tech being where the fun is. I'm always on the absolute bleeding edge of whatever I can be, but I'm also a hobbyist with no consequences/deadlines.

When you see a new Unity release, what is your expectation of quality?
7.5/10
For Alpha versions, 7/10. In other words, I feel like stuff marked as alpha or preview is usually pretty reliable. Code might change, but the vast majority of the time it'll do what its supposed to and not break immediately. But sometimes it does. I've gotten used to a certain number of console warnings just as a fact of life. For example, starting a new project with ECS dumps three Warnings in the console. It makes me wonder whether the package developers don't care, or they're required to conform to a package spec ("it must have an editor tests assembly definition file, even if theres no tests in it!"). Or maybe they have Warnings hidden in the console and don't know there's a problem. It does make me feel like Unity is a living ecosystem written by fellow Human developers, versus an enterprise software product. Sometimes its a little "organic" and messy, but thats how you get responsiveness/agility, right? If it was more "organizational" and polished, stable and locked down, we wouldn't have the freedom to do half the things we need for our specific projects. I turned the Editor invisible once... thats power!

When we say something is in Preview, what does that mean to you? Why do you feel that way?
Features could change, stuff could be deprecated, etc. On paper its "use at your own risk" but in reality I've had good experiences. I can create content based on the package, and when the package updates, the content won't be lost (but might be rendered obsolete).

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?
When I see something is in preview, it's exciting because it might be a huge new feature or functionality. The "risk" of using it is way outweighed by how useful it might be. Browsing the packages is like shopping at a toy store, each package lets me fantasize about what I could do with it or what kind of projects I could make.

I guess overall I used to feel core Unity was moderately buggy until around early 2018 (much better since then in my limited experience). Now any bugs I encounter I usually tolerate because its a bug in a package, not Unity per se. Maybe its just an academic distinction but I'm more tolerant of bugs in packages, because of how fast they can be updated. I feel like Unity has gotten much better in the past two years, both in features and stability. But again, I'm not doing a bunch of high performance/professional development.

With that said, it does feel kind of magical when Unity crashes. Magic in the sense that I don't know what caused it, but it was "probably" something I did, rather than Unity itself being buggy.

 

I forgot about foliage, terrain painting layers and treess in HDRP. Please add proper support in 19.3.

 

Have one version that keeps incrementing. The end. Other software can do it. When new versions of modo release I don't wonder "will the GUI even work in this version?". Sure stuff break from time to time, but they eventually get fixed.

Right now you have LTS, and I should stay on LTS, unless of course I need to do one of the gazillion of things that the current LTS in unable to do (like port my game to Stadia), then I can't be on LTS. So what good is the LTS?

Is this changelog the changelog of an actively worked on feature?
https://docs.unity3d.com/Packages/com.unity.formats.fbx@2.0/changelog/CHANGELOG.html

It's not.

Also the changelog is missing the latest version of it, version 3.x which came out recently and completely broke it.

This used to be an asset, then it became a package and got the PREVIEW label. As soon as that happened, development on it almost stopped and the first big update completely broke it.

It's an FBX Exporter...

This gives to me the impression that PREVIEW packages are a dumping ground for dead code. Also an excuse for things being buggy, but that doesn't stop you from promoting said feature.

Unity keeps releasing and marketing features in a not ready state (URP/LWRP, Timeline, Mecanim/Animator, UGUI, Enlighten, New Input) then they stay in that state for years, while older features are deprecated/abandoned before the new ones are ready and without an upgrade path, and yet you somehow want me to be able to take PREVIEW features seriously? I only see them as your marketing tool currently and for material to have to show on Unite while everyone in the crowd groans in unison while muttering ("I bet that won't work properly for at least a couple of years").

LWRP was until very recently (and I'm only saying that because I'm giving you the benefit of the doubt, because I haven't done any testing recently), slower on mobile than Built-in, while also supporting far less stuff than built-in. Also still has weird issues that we got past in built-in (like an extra blit at the end). And yet it has been out of preview for almost a year.

(And here is me wondering, what would the state of built-in would be today, if you hadn't abandoned and instead continued to clean it up and improve it?)

 

I don't have much to say that hasn't already been said but I just wanted to mention -
Even if Unity was (usably) stable, and URP had the features we need, and UGUI didn't be so awful, and what not, Unity's editor workflows are still among the worst I've ever used.

4 years with Unity (since 5.4). 4 years! And not once have I ever had a sense of flow in the editor. So much inspector scrolling, hierarchy searching, waiting for play mode to start, losing object focus, and so, so much more. We only got viewport camera speed, like, what, 2 versions ago? Insane. And still no way to save play mode changes officially. If I could work efficiently in the Unity editor then I could stomach all the uncertainty around packages and their stability. But compounded... this is just egregious, honestly. (I understand this isn't particularly valuable feedback.)

More related to the thread - UT wants so called "verified" packages to have widespread adoption but not have the feature set to support such scale. I know that in magical wonderland URP and other packages would be properly feature complete and amazing, but the real world is messy. I know that things that seem like they could take weeks can take years. But you must understand I don't want to make great games in 3 years or whenever any of this stuff becomes something beyond a minimum viable product (if that), I want to make great games now. I can't accept the state of the engine as it is now.

But I will give credit where credit is due - the new input system is great and Quick Search is excellent and is actually a meaningful addition to my workflow. Major, outstanding applause to those teams. Also happens that said teams are not just among the most communicative, but actually implement and tweak according to feedback. I've seen features be implemented in Quick Search 2 days after some rando requests it. I understand that it's a smaller scale project but, such a juxtaposition from other parts of UT.