Feedback The State of Unity & Packages in 2020

I've noticed this in a lot of the scattered documentation or responses in the forums to bugs in LTS versions. I've aways looked at the LTS versions as the ones where bug fixing is the core focus, the most important aspect. It's completely useless to tell a 2018.4 LTS user that their bug fix is now in the 2019.3 version of the editor and that upgrading the entire editor is their solution to a single bug.

 

I was thinking about breaking URP and HDRP into smaller network modules similar what Houdini is having.
In network project manager user can tailor his project however he wants. He can bring choose forward or deferred rendeing, URP, shader graph, HDRP module ...

If he has URP project, he can bring in HDRP module, tailor it and make HDRP build.
If he disconnects HDRP module, he can make URP build.
This would require HDRP and URP to change. Only one postprocessing stack should be used for whatever rendering you want. HDRP and SRP should interchange with each other.

Terrain would be as node template where you could create trees, foliage, material layers and preview it in preview renderer. Material would be simple with albedo, mettalic, specular, normal, AO. Then you can connect it to URP or HDRP.

 

Boy, you really fire away without putting too much thought into things, don't you?

Upgrading from 2017.4 to 2019.3 is no joke. I am one of the poor souls who had to go through that experience and I wouldn't wish it on my worst enemy, specially if said enemy's project used a ton of asset store plugins. Took two engineers a solid month, including scrambling to optimize some things that actually became slower compared to 2017.4 and figuring out replacements for assets that never got updated to 2019. It was hell.

 

These are the least of the problems in 2019.3. No, it is not "a month away from LTS or so," not even in the slightest. I'm genuinely at a loss as to how you could possibly believe this.

 

I just think that a product with "Long-Term Support" in its name should... you know... receive Support over the Long-Term.

"LTS" brings certain expectations with it. Those expectations lead me to try to contribute in making it a better product for everyone by spending time sending in bug reports as helpfully as I can (which I admit isn't always very helpful).

If it was called Unity 2017 EOL then I wouldn't expect bugs to be fixed. Consequently, I wouldn't waste my time sending in bug reports.

 

Isn’t 2017.LTS going to become 2017.EOL when 2019.LTS hits the shelves? As far as I know there will only ever be 2 LTS versions at once.
That’s not to say that upgrading from one LTS to another should be painful. But it’s sort of expected that it won’t be painless either.

 

I think that with all the new tech being implemented some upgrades we'll face in the coming years are just going to be somewhat painful. Knowing that's coming the effort definitely needs to be on making them as painless as possible. Clearer communication, better labeling of what's stable and what's only half finished, etc, etc.

 

I almost forgot.

If anybody wants to draw conclusions about the quality from the number of issues, I've tracked the Public Issue Tracker for more than a year already and have those numbers in an Excel spreadsheet:

https://docs.google.com/spreadsheets/d/1jOju0jhGrWa21ZtOKgZPy0DZo7vVTfiACvIvE1AUEfQ/edit#gid=0

The numbers represent the pages found in the Public Issue Tracker at that specific point in time. To get the number of issues, do "pages * 10", because 10 issues per page.

Let's see if we have a data analyst here who can transform this into something useful

 

Yes, 2017 LTS is nearing EOL. But it's not there yet. And 2018 LTS still has about a year left. In my opinion, these LTS versions should still be receiving bugfixes until they have reached EOL. But it seems Unity QA just want to fix things in the latest version and call it good.

The problem was that Unity's choice in nomenclature did not set my expectations properly. Now that I know that LTS means EOL and TECH means beta, I can move forward with proper expectations. But that won't stop me from pining for a stable version of Unity that is still receiving support and bugfixes.

 

1. What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
2. When you see a new Unity release, what is your expectation of quality?
3. Do you expect different levels of quality or completeness based on the release distinction?
4. What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?

1. Too many cooks spoil the broth. Why Unreal has only one release, and no one even bother about that?
2. Stability, and free of bugs. Bugs floating from release to release, from version to version, but you bother about support over 9000 versions of unity. Better make the one, but good.
3. -_-
4. I don't know why is it someone ever need it. Exept you make something before, and don't want to use new version, where all your code will broken.

And more package specific questions we would like feedback on:

1. When we say something is in Preview, what does that mean to you? Why do you feel that way?
2. 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?

HDRP has been in preview for about 2 years, and when you said it was out of preview, nothing changed at all. The same bugs, the same problems. I took it when it was in deep alpha, and I have to say - this is the best thing that happened to Unity. Of course, this does not mean that everything is fine with him. Many things are buggy, many things just don't exist (Where is the Terrain grass?!!)

And so it can be said about everything that was released. Nothing has been completed, everything is raw, and it is unknown when everything will be stable, and whether it will be at all.

And I'm not talking about the new input system, which has been in development for several years, it is not at all clear why.

 

Glad to see people being clear-thinking and proving the best feedback they can to unity while not quite allowing their emotions to run wild, it's hard I have to do the same thing when Unity does something that affects my hard work and passion.

GJ all so far

 

Just to close the loop here - this is the thread where we're looking for feedback on surface shader needs: https://forum.unity.com/threads/srp-surface-shaders.847999/

 

Annnddd back here to follow up on some of this. Been processing a lot of the feedback and survey results so good to loop back and get some more.

@Lars-Steenhoff regarding tags that’s an interesting idea. What sort of tags would you expect to see displayed in package manager?

@unitedone3D thanks for the extensive input and feedback! It sounds like you’re trying to juggle staying up to date with the latest features while maintaining stability? How can we help build up that confidence for you in delivering new features you feel are production ready? Also, is there some way in your opinion we can bring these preview features to you without the stability risk?

@AdamGoodrich thank you for the detailed feedback. As an Asset Store developer, are there things we could do to make your life a bit easier dealing with a modular engine?

You mention consolidating to a single release per release for Render Pipelines. To clarify, are you asking that we move the render pipelines in sync with the core Unity editor so there are only updates with major editor versions and not out of band updates?

When updating your packages, is the request here the ability to do incremental updates through package manager and only pulling the diffs?

Regarding the scripted package installation it was mentioned a while back about having #defines that would allow querying of installed packages. Would this be of help?

Regarding compatibility, how are you currently handling testing of compatibility? Are there systems or things that we could provide you with that would improve the experience and workflow for you?

@transat I’ve noted your requests for the My Assets section under Package Manager into our insights system and will pass that over to the Asset Store team as well. Thanks!

@jbooth I’ve noted the scripted defines and ability to check for a packages existence as well as version identifiers to our insights. Will discuss with our internal teams on this one.

@Amplify_Paulo if we had the ability to check against all dependencies and inform users of compatibility conflicts how much would that help your situation? Something where you could specify min/max version compatibility and package manager could check that before updating?

Made a note regarding versioning of shaders as well as digging into why some aspects were closed off such as the diffusion profile.

@RecursiveFrog would have to look into what specifically happened here but yes, there have been issues where breaking API changes were made without the proper sermver rules applied which have caused breakages. We’re working towards that now to define and enforce proper use of semantic versioning so our users have a better understanding of what to expect in an update.

@SonicBloomEric follow-ups are always helpful. Yep, definitely see the issue and flaw in the upgrade path there and something we’re discussing internally right now.

Noted regarding the Preview moniker. This is another discussion going on internally. Yes, fully understand that Experimental, Preview, Released is extremely confusing. What would the Prototype moniker serve as in your example? Any need for an RC (Release Candidate) version?

Interesting notes on compatibility. Have jotted those down especially the Hub compatibility one.

Forwards compatibility is mostly challenging due to the sheer size of the Unity product and every time it moves forward there’s a significant amount of changes. Some could be compatible with older versions while most might not. Now whether that’s the right call or not we’re trying to understand that through interactions like this.

@Edy

To answer the upgrade question - mostly about packages updates are available. There may be situations where a project moves large editor versions and that package version is no longer supported or compatible with the version the user is upgrading to. Right now, it would simply fail to compile and offer no reasonable upgrade path to migrate.

Noted regarding the release cadence and updates as well as the stable vs beta branch idea. Thanks for the feedback as well on the naming monikers. That’s a current discussion we’re having now so more data points on this are great.

@Lorash what would you have preferred the survey structure to be?

 

I'm struggling, still why you would ever expect a developer worth any salt to think prototype was *ever* any form of thing other an a fleeting experiment. Why would a developer ever see "experimental" "preview" or "prototype" as anything other than a toy?

And I'm serious, yeah.



Issue here is that if Unity still expects customer feedback to direct packages like this to maturity, the wording alone is causing actually decent developers to avoid even testing them. So you will get generally, bad feedback.

The wording alone implies that it won't stay or is a quick thing. Alpha, Beta, Release are very good things, otherwise you're basically still making the huge mistake of making half finished tools that will be led by people who don't even fear what prototype or experimental actually mean. Experienced developers know experimental, preview and prototype might not even ever be finished. Why would they then, use it as anything except a toy if that?

This sentiment is echoed by experienced developers of Unity even in the latest MCV mag. IMHO it's well past time Unity committed to their actions. Alpha means it will eventually get to release. Preview when it technically was beta (Say URP) was ridiculous for the longest time.

Use alpha, beta and release or expect packages to keep communicating they will be unfinished or remain experimental and cost developers money replacing them later, or even having to just not risk it. Therefore expect feedback on these packages in kind.

So it really matters to stop messing about with unfamiliar phrasing. Prototype to me means you will never actually finish that. It's just a test, at cost of dev time.

 

Because they took the FBX Exporter that was released on the Asset Store from Unity and was not experimental/preview, and made it a package and now suddenly it's *preview*, without anything changed (well, it changed in the latest version where they decided to break it, but anyway).

The quality and reliability and... *stayability* of preview packages varies WILDLY to the point where the "preview" label means absolutely nothing.

For some it means "here is some code we dumped that might not even be there tomorrow".

For others it's "well this is more or less ready, but we don't want to support it, so we'll mark it as preview so we have more excuses when people find problems".

Unity hyping them up more when they release as preview, and almost not at all when they actually release, also creates weird expectations.

"Hey a package just became an actual release and whatever, BUT HERE'S A SHINY NEW PREVIEW PACKAGE FOR YOU TO PLAY WITH WOOOH".

 

Don't get me wrong, I should clarify:

Unity needs to use Alpha, Beta, Release for packages they've designed already and will see to the end with a fixed release date in sight. This is industry standard, accepted, and trusted.

They can use ONE of the following (prototype/experimental/preview) ONLY for packages that are not designed yet or otherwise without a plan for release. Otherwise it is an Alpha, obviously.

Because common sense dictates that Alpha will progress to Beta which will progress to Release and everyone knows that.


But where is experimental/preview/prototype leading in English? Will Unity try to explain their custom meanings to every customer, every time?


I want to use animation rigging package on package manager but I have absolutely no idea what Unity really plans there. What if the solo dev on that decides to move house and has to leave Unity? Anything can happen.

If it was Alpha, I would know Unity committed to it and a replacement staff member would keep it trucking and I could build code against it, even give feedback because I'm building code against it.

It's that simple.

 

Agreed 100%.

 

@hippocoder this is why I ask these types of questions. They seem silly, then three responses later we've got a much more crystal clear picture from a few folks. Jedi mind tricks

 

Oh you sneaky devil

 

Just to clear up something. People in this thread is hammering QA a lot for what bugs gets fixed an when. It should be clear that QA doesn't fix bugs. QA handles bug reports and keeps track of known bugs. The actual decisions about what to do falls to project managers and engineers.

So if a bug isn't backported to 2017 or 2018, that's not QA's decision. QA is often the messenger, but you know, don't shoot them.


@smcclelland, I think there's something in this whole "bugfixes only lands in beta" attitude. From what I'm seeing in the issue tracker, it seems like your way of handling bugs is to first fix them in the latest internal nightly, then to land it in the current alpha/beta, and then to start backporting it, first to tech and then to LTS.

That makes some sense, since the attitude for LTS is that it should be stable, so you're doing extra diligence about checking that the bug fixes won't have side-effects, and not really landing them if they're not seen as important enough.

The problem there is that it's taking way too long for the bug fixes to land. even Tech, which is supposed to be where you're doing active work, has bugs backported rather than just fixed. I haven't done a proper analysis, but when I click through bugs fixed in 2020.1b, there seems to be very many that's listed in the issue tracker as present in 2019 and 2020, but only fixed in 2020.

In sum, I think it makes sense to be a bit careful about backporting bug fixes to LTS, but you're being too careful, and taking too long. The value of "LTS will only get bugfixes" isn't very high if the bug fixes doesn't appear.

 

Unity Technologies published a blog-post regarding the "State of Unity 2020":
https://blogs.unity3d.com/2020/03/19/state-of-unity-2020-in-this-together/

 

And here's the abridged version for those who don't have time for the whole thing or want to skip all the marketing chitchat (which is like 3/4 of the text):

Spoiler

2020 will be focused on stable releases, more intuitive workflows, and more capabilities, all validated with real-world productions.

Key areas of focus:

• Reliability and Performance
• Creative Workflows
• Scalable Quality
• Reaching Your Audience

You can learn more about this in the following roadmap sessions on YouTube:

• Wednesday, March 25 – Core technology and workflows
• Wednesday, April 1 – Cloud services for operating games

After the roadmap sessions, Unity product experts will be holding a Q&A on the Forum.
These are just the first of many pieces of on-demand content planned.

Commitments:
Increasing stability:

• Assessment of feedback: "you want fewer major releases, but more timely package updates that improve the stability and quality of our tools. "
  
• Unity moving to two TECH stream releases per year
  
• The default download from the Hub will be the (LTS) version

Improving quality of life:

• Modernizing Unity to be more flexible for your needs
• Effort in subtracting as many seconds of idle time as possible
• Planning to provide even more capabilities

Listening

• Planned revamp of the Beta Program, focus on a direct path to the Engineering team
• Higher priority on sourcing actionable feedback -> more transparency
• More information is coming soon

Miscellaneous stuff:

• Unity Game Simulation releases in beta later this month
• ML-Agents 1.0 coming soon
• Major progress in the new multiplayer stack: Cooperation with devs of Shadowgun War Games to pressure-test the new Transport Layer and Matchmaker. Coming later this year.
• Due to the health situation, Unity's giving complimentary access to Unity Learn Premium starting today through June 20.
  
• Create with Code Live: live virtual classes by Unity on coding basics, starting on March 23

 

Emphatically Yes! With the caveat that if you do release out of band updates, then they are bug fixes / performance improvements and no API's change. This allows asset publishers limit releases to 4 times per year, and for our customers to know that any asset compatible with that Unity version will also most likely be compatible with all other assets that support that version.

Yes. Would save us and our customers a lot of time, and Unity a lot of money. We have done over 2.8 terabytes of asset downloads from the asset store this month alone.

Hugely! We do this with our products and it allows us to deliver dependencies safe in the knowledge that if something is missing, then it will compile out without delivering errors in the console. We could then pop up a dialog asking our customers to install it.

Slowly and manually. We would be keen to explore ways of testing for compatibility across versions. Some things like obscure visual glitches due to shader issues would be harder to deal with I think.

 

According to the “State of Unity” post emphasis will be placed on stability instead of new features. Question that spring to my mind is, does stability mean finishing the current preview package like ESC, Hybrid Renderer etc. I feels like every avenue is blocked by missing key features or package being incompatible with each other.

 

It seems that going forward this might be less of an issue as the latest blog entry claims that the suggested version of Unity will in fact be an LTS:

... starting with our next release, the default version of Unity you download from the Hub will be the Long-Term Support (LTS) version. That way you can be sure that you are downloading the most stable version for projects in production. You will still be able to opt in to downloading our beta and alpha releases should you wish to give us feedback on them.​

That last sentence makes it seem that TECH releases will effectively be treated as "alphas/betas", which is nice because it's not very far off from how they're treated today.

The Prototype moniker would indicate that the team/individual working on the feature is truly in an experimental phase. People understand that a "prototype" is a specific experimental implementation. I would expect a Prototype feature to operate as follows:

• The package is available as a package only by adding the GitHub url (or whatever) to the package manager directly - it does not show up in the main packages list.
• The package can have its own versioning. A "prototype" package at v1 is a specific attempt at the feature implementation. A "prototype" package at v2 is an entirely different approach at implementing the same feature and I can expect it to be very different (and also better, as presumably the implementors used learnings from the v1 prototype as a starting point for v2).
• When the team decides "Oooh, we like where this is going! Let's bless it as an actual feature!" it will effectively get forked as an "Alpha" with a version set to 0.0.1-alpha or 1.0.0-alpha1 or something. The package will then appear in the Package Manager's official "list", albeit only behind the "Show Alpha Packages" flag.

Does this answer the question for you?

I don't think I'm in a position to say if this is necessary. I think it should definitely be an option in whatever release system you develop. My guess is that fringe and/or less-frequently modified packages would be unlikely to benefit from an RC release, but mainline core packages would (see. SRPs).

Not every major release of the Unity Editor goes through an RC phase, right? But some do? That never felt strange and I suspect that making a similar decision for an individual feature wouldn't be all that different from the core engine releases...

I mean... welcome to life as an Asset maintainer? Anyone who has done any actual development for tools that exist in the Asset Store know this very well. (I emphasized "actual" there because I do not count Unity Technologies assets as being "actual". That publisher has historically taken a "pump-and-dump" approach to the Asset Store: many assets land and might receive an update or two over time if you're lucky.) Most Asset Store tools developers download betas/alphas as soon as they're available to see what Unity broke for them. Then they set to working around (or with) the issues. Why is Unity somehow exempt from this?

In many cases, it is possible to add forwards-compatibility without destroying backwards-compatibility. Generic C# scripts can already do this with preprocessor directives. Much of the feedback here from the graphics folks are asking for this very type of thing with shaders in the SRPs. If Unity makes the decision to actually support package features for a reasonable amount of time (see my notes on providing LTS-style support for packages), then I think you'll very quickly develop the tools that let you do so in a much easier, more streamlined way. And, of course, the rest of us would benefit from that as well.

 

One more to reiterate:

Please have all packages' sources on GitHub!

Crucial packages like burst, SBP, and Addressables are sitll MIA from Unity's GitHub page, and they should be receiving pull requests and allow people to inspect commits in more detail.

 

Yes. This should be enforced as a company-wide policy. If you're already giving us source access, finish the job and create an ecosystem where we can see the work as it's being done, the issues raised, etc. etc.

Oh, and another thing that I forgot to mention earlier: If you decide to keep the year-based version numbering, please consider skipping 1 year, so that the latest LTS version aligns with the current year and the TECHs are 1 year forward. That can help cement the idea that LTS is what you want to normally use, and that TECH is more experimental in nature. I've talked with devs that frown upon the LTS version because they look at the name and think it's outdated.

 

Less laser-focused on the ability to install features through packages so the answers can reflect sentiments like "why do I need to bother with packages to begin with". Hence me not finishing the survey (the questions really felt pointless) and instead coming over here to vent about the regressions and apparent lack of end-user benefits of this package business in free text.

EDIT: I understand the theoretical, academic benefits of packages. In practice it doesn't seem to work out due to poor execution. There are many inderdependencies and incompatibilities between official packages, and they usually get updated at the same time a new engine version releases and/or hard depend on an updated engine version anyway. So we got most of the drawbacks, get an extra chore of dealing with packages, for virtually no benefits.

 

Please make packages live longer than few months.

Current packages live for few months, get semi ready features andthen just create new major version where those features become ready and then yet another major version where those feature get documented.

This looks bad.

Make packages compatible for at last few LTS Unity versions, make it more fundamental.
When new Unity version released they deprecate support for ios/android versions very slowly, only when it really make sense. AssetStore Authors make their packages in the same manner, then support all versions of Unity from Unity 5.6 to Unity 2019.3 because it still make sense.
But Unity Packages lost thier support 4 times a year drop support for every TEACH release of Unity.

This is bad practice. As people already mentioned we forced to update to new package and new Unity and new dependant package just because Unity drop support of package so often and new bug fixes with ready features done in new major package versions.

I wish every package to support at last 2 last released LTS versions of Unity unless it solely created for new Introduced features on UnityCore.

so URP, HDRP, ECS,Burst,Mathematics, etc packages all need to be version 1.x.x or at least 2.x.x and both have support for Unity 2018 LTS and 2019 LTS just not all features of package ca be used in 2019 LTS and even less in Unity 2018 LTS but all features that version independat and all bugfixes will be available for at least 2 LTS Unity verisons.

With this rule to be rule of asset store and UPM so authors of assets (including Unity) can not break compatibility of packages so often.

For now we already in place where unity about to deprecate URP 7.xx and land new features and most bagfixes only for Unity 2020.1, and part of it already only for 2020.2. I personally very dislike this package management.

p.s. like idea of prototype/alpha/beta/release where:
prototype - everything can be changed from ground up
alpha - fundamental things is solid but very unstable (stabilizing, minor changes)
beta - mostly stable and usable lack of docs (stabilizing, writing docs)
release/stable - stable version with documentation supported for 2 years (features and bugfixes) or 2 Unity LTS releases

New major version must be created only if package was recreated from ground up with new architecture in mind, see EasyRoads3D v3 vs EasyRoads3D v2 as good sample. Package v3 first released Jan 26th 2018 and support Unity 5.6 and still v3 supporting Unity 2019.3. URP/LWRP just fully released and already version 7 and we already know about version 9 and all features that we never see in current Unity LTS.

I'am sure that most of new features in URP roadmap have no dependency on new UnityCore like DebugWindow, Documentation, BoxProjection, ShaderStripping, ShadowMask (they have already PR for it)... but the not lad for Unity 2019LTS. Very sad

 

To add to this, URP and HDRP were only recently released "for real" but their version numbers are already 7.something. Again, Unity package versions don't really mean anything.

 

Feedbacks for some packages:

1. NavMeshComponents
Why this components is still missing in Package Manager? is there any technical issue for that? The official documentation says "go to github and install it manually.". NavMeshComponents is most package-manager-suitable library I think, or just merge to main engine code please.

2. Unity Transports (with other DOTS packages)
Of course I know that it is preview. But it has too slow update cycle (the latest update has 2 month terms between its previous). This makes that I can't test other latest DOTS libraries due to its old dependency hell. No one test a single package with empty project, so please release update more often, even it has only changes in package.json.

3. Make public for hidden dependencies
Roslyn, Newtonsoft.Json and so on... These sudden dependencies break existing project. Make public and user can prepare for it.

4. github (or other well-proven public issue tracking system)
Please make the central space for discussion/searching/reporting issue of specific packages or Unity engine itself. Public source code is more welcome. Unity forum is not suitable for that, it has terrible UI and trash searching feature and too many topics in single place. I want to know what happen in specific packages, find existing hotfix or share my solution easily. Unity's public issue tracker is meaningless. You can't find what you want by using existing public issue tracker. It doesn't provide good search/sort options.

I like Unity so much and used several years, and released games successfully. I hope that next Unity be more stable and comfortable, not fear of bug.

 

And is Entities going to be ready when Beta's over?Along with Netcode and Transport?

 

1. What is your understanding of the Unity tech releases (eg 19.1, 19.2…) vs Unity LTS releases?
   I do not like the idea that any of these releases is not meant for production.
   You said that about version 19.3 and I find it odd. (To put it politely)
   
   
2. When you see a new Unity release, what is your expectation of quality?
   I expect it to be production ready and to offer at least one benefit for each verified package over the previous release. .
   i.e. either stability, or performance, or new feature.
   
   
3. Do you expect different levels of quality or completeness based on the release distinction?
   No never.
   Else stop calling them releases and make it a very long Beta towards an annual release. Stop trying to convince yourselves that you are following an agile approach. having daily scrums and retrospectives does not make your release schedule agile if only the LTS is meant to be production ready.
   
   
4. What is the primary motivation for you to use the LTS vs the non-LTS version of Unity?
   I do not care about LTS. It's still buggy anyway. I need production ready stable releases with bleeding edge tools that work, (i.e. you are still struggling with Raytrace. You are a year off and it makes me look bad to suggest Unity for cutting edge projects. ) tools that allow me to produce the best quality/performance possible out there. I do not want to lose projects from studios that use Unreal. SRP is a mess.

And more package specific questions we would like feedback on:

1. When we say something is in Preview, what does that mean to you? Why do you feel that way?
   
   In Preview it means usable with bugs, but close to final. Not broken and not pointless. I am neither a hobbyist nor a child to feel happy with a toy. If it is not meant for production it should not be preview, it should be called, tech demo or something like that. So perhaps you need a new package tier for early feedback versions.
   
2. Does the expectation of quality change when you see something in Preview?
   Only slightly.
   
   What drives you towards using something in Preview?
   Bleeding edge tools that help me stay competitive with Unity and not using a different engine. That should be in your interests after all. Else close shop, call Unity a hobbyist tool and lets all those who want to do trully next gen projects use Unreal.
   
   What keeps you away from using something in Preview?
   In early preview, it is having to throw away all my work. You really disappointed and even damaged the business of many people with LWRP breaking from 2018 to 2019. Or the feature being nothing more than a pointless tech demo.
   
   In late preview I usually go ahead and use it but one really needs to follow closely the progress of a package to know when to use it because even then you may break it. Not nice although usually at that point the re-work is small. I suggest if it is going to break , do not show it in the Package Manager . Or as I mentioned, create a "Tech Demo" tier in package manager. Not "Preview".
   
   Also, I feel lately you have become a bit careless with packages. Your validation has somehow relaxed.
   
   i.e. "GUID [232ab27f257e8524eacc2e73daf536f5] for asset 'Packages/com.unity.render-pipelines.high-definition/Runtime/RenderPipelineResources/Mesh/UnityBall_Base.FBX' conflicts with:
   'Assets/HDRP Sample Content/Shader Graph/Meshes/UnityBall_Base.FBX' (current owner)
   We can't assign a new GUID because the asset is in an immutable folder. The asset will be ignored."
   Or other problems with latest Entities using an older package while a newer one is installed.
   
   I understand this is minor but it has no business in a professional tool. Hire Perfectionists!
   
   In the asset store, you need to add a few more filters.
   UPR/HDRP ready. DOTS Ready.
   Help those who are supporting your latest efforts and do the hard work to help us be productive on the bleeding edge. Else not many will care to create tools compatible with your new features.

 

Absolutely right about iterating.
Not just for him. For many if not most users.
Few Unity features really listen and provide based on user feedback.
For many users Unity is growing big and arrogant.


And the second account about communication you do that a lot.
In my previous post I mention the need for a new package tier. i.e. "Tech Demo" or something like that. Something in Preview for two years or more is a joke. 6 month preview something like Beta is ok. But two years it means the feature wasn't even anything more than a hack when you advertised it as a new upcoming feature. Not sure who thought it makes sense or that it looks professional. It sends the wrong message and after a long while and repetition, raises suspicion that you are trying to mislead about your current state and capabilities with false advertising.



AAAAND let me repost this image because really, this is what you have done!
(2019.x and part of 2018 too.) I feel 2017 was probably the peak in usability. You nearly touched perfection.
Since then it is a painful downhill...with some happy hype moments sprinkled in between.

 

@Dear smcclelland, Thank you for your response!

''@unitedone3D thanks for the extensive input and feedback! It sounds like you’re trying to juggle staying up to date with the latest features while maintaining stability? How can we help build up that confidence for you in delivering new features you feel are production ready? Also, is there some way in your opinion we can bring these preview features to you without the stability risk?''

Yes, exactly. But, I think there really is a point that we have to stick to something. I think I have reached this maximal point and continuously updating to new can jeopardize more compared to new features (benefit vs risk). The news features (at this point) would not offset to possible problems with updating engine. Only because I am quite high in the number (Unity 2019) and thus, it'S only 2020 after (albeit there are a few versions in between). But, yes, some great features in 2020.1 or 2019. LTS are something that I was like : ''Ok ok...just This Last Time I am upgrading...after that; no more until the year 2040''. Because new features tempt a lot and some of them are very helpful and can Even transfom/help tremendously to reduce production time (like for example; the 4GB asset limit per scene due to the player made in old 32-bit mem adresses limit intead of 64-bit; in 2020 this is solved and we do not have to worry abou this problem (to refactor scenes...4GB is substantial - per scene, but some people make large games//AAAlike it requires more than 4GB total asset per scene to be loaded; thus hit limit.

The solution before was using asset bundles or 'splitting the scene' into tiny scenes and loading in 'proxy empty one' to 'fool Unity engine' into thinking it is less than 4GB loaded asset per scene (I will have to do this if I don't upgrade). Also, like, keyword limit of 255 keywords for shader ('shader keyword), that is more limit (though I read that apparently it is very demanding and is why it is limited like that; most AAA games have a least 500-1000 shader keyworsd easily but forced to cut down/'choose'). That's the problem sometimes, Unity gives lots fo choice, but sometimes we face 'Forced choice/by inherent limits' of engine; and I can fully imagine that you can't make miracles; there Will be certain limits to an engine. I fully understand and that certain limits are 'hard' and Nothing can do about it (unless Complete refactoring/Remaking engine for scratch)...You have already built confindence in me, I fully belive in engine (would not use otherwise), to increase the confidence is creating a more stable and bug-free experience (really only repeating others feeling); if I can spend much more time on working ont he game Instead of Fuighting the engine/having to find 'workarounds' for problems (problem solving...but in that time..not working on the game...just fixing problems of engine function.

The more you give a near-100% stable tool/engine, the more you will hear 'less' (about saying negatiev things..because will be Super Busy using it and barely complaining/super happy that it works so well). I don't if you can bring these preview feature without instability; there seems to be instability in all releases ( I don't want to say this...but it is a truth) all releases have peculiarities; the only thing hoped is the least (instabiliites) of them. I am aware that it is quasi impossible and the Amount of stuff that can 'bug' in game engine makes admire immensely the fact the engine (even) works (as well) as it does. It's spectacular that despite all the console error happening, the engine can work (I never thought there were so many bugs in game engines before I arrived; I misscalculated and now have utmost appreciation and admiration of coder/fixer/people that engineer the engine (..-WoW)..I read that tehre are 1000 enginners on Unity engine (!). It makes you drop off your chair and try to fathom it (Unity engine is a marvel!...by the same token people may say...but if a 1000 engineers and game tool not working...what is wrong?).

Just a 2 cents.

 

I just want a more stable Unity. I don't care anymore about it being super performant or any new features. At this point I just need it to be stable.
First it has to work, then it can work fast.
It's a bit sad seeing so many people asking for more features, but everyone has different priorities. In my case I would prefer if the latest 2018 LTS didn't crash twice per day

 

It's actually something we've been actively discussing amongst our group. The question that always comes up is how many people are actually contributing to the repos we have now? When we looked at the stats for Shader Graph and Input System there weren't a huge number of user pull requests. Is the reason for having the repos out in the open to track the issues against it, to open PR's against the repos, something else?

Ah, so similar to the automotive model of naming conventions?

 

I'd like to bounce some stuff off the group here as I'm starting to put together the trends and topics I am seeing through the insights we've captured so far. This isn't a 100% snapshot of the forum conversation here yet as I've still got > 200 insights to process from these discussions. This is a mix of the early forum insights and the survey feedback.

• Provide a more user-friendly and functional package experience.
  • Notifications for package updates.
  • Better information on dependencies in Package Manager.
  • More control over “default” Unity packages.
  • More convenient way for users to create and distribute custom packages.
  • Define packages that can be ignored in source control.
  • Support for private packages protected by user/password key.
  • Improve the depth and coverage of package documentation.
  • Package #defines to check if a package is present in a project or not.
• Provide a better user experience in Package Manager.
  • Manageable interface for Asset Store packages in Package Manager.
  • Allow users to perform bulk install/uninstall of packages without modifying their manifest.
  • Locate a package on disk from the Package Manager UI.
  • Easier to find packages without relying on search.
  • Tag support for searching, categorization, and version numbers.
  • Support users behind corporate firewalls.
  • Group packages by category instead of flat list.
  • Opt-in to automatic package updates.
  • All packages must include standardized, accurate, and up to date changelings.
  • Allow users to upgrade packages without having to do major Unity version updates.
  • Ensure packages do not have performance regressions in the Editor.
  • Native UPM (Unity Package) support for the Asset Store.
  • Improve dependency resolution.
  • Make it easier to install and modify packages locally.
  • Prevent users installing packages that are not compatible with the current editor or other package versions.
• Provide a better project creation experience that allows user to have more control over their projects.
  • Create a project from a template with a set of compatible packages.
  • Allow users to create their own custom templates.
• Provide a more stable and production ready Unity product
  • Better support of features and bug fixes in packages for LTS releases.
  • Provide clear communication and guidance on what to expect from a Preview package.
  • Provide infrastructure and best-practices for iterating with customers to validate work-in-progress.
  • Provide information on compatibility between package versions and versions of Unity.
    • Allow Asset Store developers to leverage this to test their offerings against Unity/package versions.
  • Adhere to standard naming and development conventions such as SemVer, Alpha/Beta/RC/Released.

This represents the bucketing of all the insights we've captured so far. It's not a promise of the work we'll be doing but I wanted to bounce this back and see how this currently resonates with everyone. Once I start organizing all the forum insights into this it should build a much larger picture and then we'll do some further validation with this group and the wider Unity customer base.

 

I can't agree more. Also I think all the packages should be inside one github repository. You could use git submodules for packages that already have a github repository. All the packages should be downloadable outside of Unity's package manager, and have documentation and issue tracking all in one place.

Many game engines give you the ability to download the entire engine's source code and all its packages in one repository. I think Unity should start going towards this route as well.

 

I haven't contributed to any of them because my impression was that you still were not taking PR's on any. Whenever I asked about that in the past, the answer from people at Unity was "we can't take PR's, we don't have the legal framework in place to do that right now".

So has that changed?

 

Yes, so previously the issue was we didn't have a Contributor License Agreement (CLA) in place. We have since developed a solution that teams can add to their repo and it will help serve the CLA to people looking to make submissions to public repositories.

 

@smcclelland

As Unity Users, we want to use ChilliConnect but It has to provide a free indie plan to attract more users from other free offerings either currently available (playfab, XtraLife) or will be available (EOS)

- Playfab has Free Plan for Unlimited MAU

- Epic Online Services is making a lot of progress behind the scenes , just read their changelog and they are 100% free once available (hopefully this year)

- XtraLife has Free Plan for 1 Million Users

- BrainCloud is currently superset of All above and have a per api based pricing (1 Million/15$ minimum)

- Even Deprecated GameSparks had Free plan upto 100k Users

 

Cheers for the feedback! I'll make sure the folks over on our ChilliConnect team get this input.

 

Thanks appreciate that, i knew about ChilliConnect before but never bothered about them due to their pricing
But now its Unity, so i really want to use it, and hopefully you guys gives us indies reason to use it

 

What is now implemented in the package manager in 2020 is the ability to filter by label
I want to be able to add / remove the labels from the package manager. ( not go to the website to do this because it breaks the workflow )


I'm using this to sort my packages, for example all the assets that are URP compatible I add a label URP.

Or for example I imported certain packages into my project and add the name of the project as a label.

 

I would like to browse the package source without having to download it, be able to compare changes between versions, and have a sane path to update if I end up having to make local modifications to the package.

 

I still fail to see how having packages instead of baked-in engine features is better for me, the user. You're not doing a good job of selling it, it's more like the new Hub, the 2019.3 flat editor UI, the new Asset Store - even if it's worse users can't choose to not have them, so hooray 100% uptake, users must love this stuff (which was literally an argument made in favor of the new Asset Store to rub some salt in the wound). Any benefit of packages is purely theoretical because in practice it's canceled out by the execution: can't do independent updates because there are very strong dependencies all over the place, can't really pick the features that I want because some packages are incompatible, some require each other, can't patch the C# code to fix bugs locally because it gets overwritten by the original package version anyway, you can't use the huge library of .NET packages (technically you can, just with the old method of copying the dll which has worked way before this package business, again, nothing improved here) because they're NuGet and you reinvented own incompatible wheel, the list goes on.

The theoretical benefits could be provided in more sensible ways. As a thought experiment, if LWRP/URP and HDRP were hard-baked into the engine I would still have the option to only use one of them (or zero, and use the old pipeline), which is the SRP setting under Project->Graphics. The Input system has a setting of old/new/both in Project->Player. Cinemachine just nicely stays out of the way if you never use its components. The Test framework could be built in since it doesn't affect games really. Burst could be built in since again it's controlled by settings anyway. I cannot imagine someone complaining that TextMesh Pro would be available in this theoretical "full" engine, they still have the option to simply not use the component. Unity Physics is simply another set of components that you just use, while PhysX is baked in (it would be so nice though if you didn't have to use a different set of incompatible components and just switch the backend over to, e.g., Havok - one can dream). I could probably write a small book just listing these.

Accepting that things slowly get worse in newer versions of Unity is the new norm and it's not an ideal place to be, to put it mildly.

 

Ensure to add #defines for checking the package version as well. Otherwise, we would be half-way there.

 

I'm not very familiar with the automotive model, but form what I googled, yes it looks like it. The version X is presented (in this case released as alpha/beta/tech) in the year X-1 and is ready (LTS) by the start of the year X.

 

Just my very high level opinion consequently it may not be worth much so I'll keep it short.

I'm not entirely certain that this thread is truly of any value when the problem is clearly within the Unity organization. Simplistically, from what I've seen over the last couple years of mostly sampling as a novice end-user is that development is fragmented, implying a lack of cohesion presumably across multiple development teams. The package developers in this thread are noting concerns that have been ever-present in the forums - often in the form of delayed releases. I guess I am saying there is no surprise at what is being revealed. Why would feedback be required to set clear internal objectives for the core product? All of this should be directed at your developers and/or team leaders followed by a blunt analyses.

This is behavioural problem that should have self-corrected based on the increased frustration from package developers over the years, keeping in mind that not everyone can be satisfied. This seems harsh but why the failure?

A set of checklists or recommendations will simply be ignored as noise because it appears the teams currently do not have a unified objective, whatever that might be, focused on a reliable but evolving tool. Is this too naive an observation/conclusion? I can't imagine anything changing without a strict internal mandate where objectives must converge. The fragmentation, incomplete features, and complexity are obvious even to some one like me. **The risk here is that the feedback will further splinter development and priorities.** This is sort of a feel good exercise pacify the masses.