Feedback The State of Unity & Packages in 2020

https://github.com/Unity-Technologies/InputSystem/issues/868#issuecomment-605009688

> we're going to close all the github issues

Well that just happened

 

What they don't show you is the full list of Known Issues. Those are simply the ones they deem "most critical"; most likely to affect a large proportion of users.

My point is simply that using that list to gauge "how buggy" any given release is will probably yield poor information - the list is subjective. For a more comprehensive set of data, filter the active bugs in the Issue Tracker.

 

Only 145 pages of known active issues, hardly any at all /s

 

The problem is that their metric has been quantity as engagement not quality.

 

Don't miss to check out my issue tracker statistics, to let this feeling kick-in even harder
https://docs.google.com/spreadsheets/d/1jOju0jhGrWa21ZtOKgZPy0DZo7vVTfiACvIvE1AUEfQ/edit#gid=0

 

Early access does not mean that the few features that you offer are unusable and buggy. This is not what early access is about. The fact that people point it out in this thread again and again, shows a fundamental problem with the approach Unity takes.

A "verified" package in a point release should NOT be unusable and buggy because it is not the LTS release. Yes, you get away with it, BUT every time this happens it reduces the brand value. It's one drop of muck in your bucket of clear water. One step towards unprofessionalism you allowed your self/team to take. And for more than a year a lot of drops have formed a thick layer of muck in your bucket. One would expect that Product Managers would be pointing this out and avoiding it like hell.

 

That is absolutely what early access means in common vernacular.

 

Early access was supposed to be a way for dev to monetize the development of a game, showing how the sauce get made when it's not ready. But right now it has shift to a mvp model, and people feel robbed if it's less than that. People joking about earliest access or early early access, are actually describing what early access was supposed to be.

 

Which is, honestly, a pretty S***ty model if I'm being real. Like, cool, good job, you found a way to make your testers pay you.

 

Yeah we call that patreon now

 

Or, at the company level you could set a policy about the conditions under which teams should open up their repos, and the level of support and/or attention those repos should get under different circumstances.

Having individual teams make all of those decisions on their own probably wastes a bunch of energy re-hashing the same stuff, potentially results in inconsistent decision making, and is probably a part of the underlying cause of issues people here have mentioned such as two-liner contribution instructions.

 

What this doesn't cover is the terrible backporting support, bugs that are in 2018.4 LTS or 2019.3 (which soon will turn into 2019.4 LTS) are fixed in 2020.2 alpha. but not backported.. It's sad..
Just make a search for 2018.4 fixed bugs. and then check, most are fixed in 2020.1 or 2020.2 but never backported. it's hilarious.

Long Term Support??? or more like... Light Terminal Support.

 

I finally watched the 2020 roadmap video and this is a good start but only if the ideas put forth here are actually stuck to, which is a faith I don't particularly have right now, I admit.

 

Standard assets 2017 is deprecated and there are no updated standard assets to download? It's impossible to use 2017 standard assets without making code changes.

 

Also, I wonder what their current timeline for these pre-release and development cycles are. Are we talking about 2 years? 5 years?

 

What is the reasson LTS exist? Instead having 2 builds: 19.4 and 2020.1, why not having just one build 2020.1 to reduce version complexity.

Creating new C#script process and compiling is very lengthy. Could this creation and compilation be reduced to very fast.

 

From: https://unity3d.com/unity/qa/lts-releases

They exist for people who want bug fixes but don't want features being added or changed, along with the bugs and instabilities that typically come from that. It also gets longer support than a normal Tech branch, which is useful if you're contractually obliged to support something.

 

Unfortunately, LTS doesn't mean that the bugs get fixed... currently it means that the bugs exist longer...

 

I forgot to ask in roadmap q&a. Can MonoDevelop return to Unity? MonoDevelop uses less resources and was faster than Visual Studio Community.

 

If you want less resource use, use Visual Studio Code.

 

They cut it because it was taking up a ton of developer time, and very few people actually liked it. The cost of upgrading it to support new C# versions was considered too high for the gain.

@valarus, try this. Note that it's a completely different program than Visual Studio, with no overlap whatsoever. They're named almost exactly the same thing because Microsoft can't name things for S***.

Case in point, MonoDevelop was a version of a program named "Xamarin Studio". Microsoft bought Xamarin and rebranded it as "Visual Studio For Mac".

 

Is it possible to put 3D Model on the terrain for AR ? I mean when i shoot using my android phone to the Image Target ..then it will appear the 3D Model standing on The Terrain ? Thx in advanced

 

I think you''ll have more luck if you make a new post in the correct forum.

 

Thank you Brother . Gbu.

 

Some bad news about contributing to unity projects: Contributing to packages

 

As @okcompute_unity mentioned in the thread mentioned by @JoNax97:

(Where "this requirement" refers to allowing community contributions to Unity projects on GitHub.)

@smcclelland Given that it appears Unity currently has zero plans to open up the GitHub projects to community contributions and has already turned off Issues in many (most/all?) repositories, what is the point in providing access to the repos on GitHub?

The only thing that comes to my mind at the moment is to continue to allow people to create their own custom forks of the projects...

Is there a plan for the package ecosystem here or are we all just flying by the seat of our pants at the moment?

 

I'm wondering why when my unity updates, I have 2 versions of unity on my desktop taking up multiple gigabytes worth of data, instead of just rewriting the old one into the new one?

 

You can then choose which unity version you want to use for your project.. i know other devs they got around 30 versions of unity just to see what SRPs are most compatible with each other.. but if you dont need that, its pointless of having an update not override the older version i guess..

 

Because engine updates can break your project.

Once you've verified your project is fine, you can easily uninstall the older version of Unity in the Unity Hub. Just click on "Installs", click on the triple-dot menu in the top-right corner of the old version, and click "Uninstall".

Easy-peasy; safe and squeezy.

 

I'm wondering about the new DOTS associated preview packages and when will they be more ready for a production game? I've been using Unity on and off since I started my bachelor towards game design in 2009, but never really took the time to focus on it outside of schoolwork.

In the last 2 years I took a change and decided to start learning how to create the games I've been developing for 20+ years in notebooks and ideas in my head. I took new courses from some of the best on Udemy to catch myself up, but it wasn't everything I needed to process my ideas. I was so close to just developing my own engine so I knew how it worked and had features I didn't see in any available engine. Then in my process of searching these things recently to start on that and even looking at Unity Learn while it's available I saw a lot of awesome features that are still in preview.

I'm mostly looking into Animation Rigging, ECS, Unity Physics, the Jobs system, and the new multiplayer setup. I have 4 or 5 games that I want to release that will tell the story and evolution of this world I've created but I was looking into procedural animation for a greater control of character movements during runtime and to have reactions to certain stimulus in the game but workable in any possible pose.

I also liked the performance of a pure ECS design for a battle royal type game and a separate MMO game all with a RPG stat based setup. If this looks as good as it's been shown I could see some great improvements over designing this in the basic method and would love to develop my skills in these new systems but also don't want to waste time I could be putting into making games if these systems are far from functional.

In general what are the best ways to test out these systems and possibly even get a start on something? What about a procedural terrain generator with several layers of noise, biomes, material and vegetation placement, water levels, and holes that could lead to dungeons that would work with DOTS and what would this entail compared to a doing this the normal ways such as shown by Sebastian Lague (

) and Penny De Byl?

 

Respectfully and factually, this reminds me of when they had too many issues with UNET (due to understaffing - 2 devs running the entire project, specifically) and just swept it under the carpet instead of fixing the many bugs + inability to keep up with documentation.

By the time I port to DOTS, I'm sure it'll be completely scrapped the next day instead of receiving tweaks. Why is this the only product I'm not excited for when it comes to new features? Enterprise level products should not be this way. Expectations are much higher that are reached in other projects as giant as Unity, but not Unity. Perhaps the team should look at Canonical (Ubuntu) to see what they're doing right. Seems to be around the same budget - why do their releases feel so, incredibly stable while Unitys is the opposite? I truly wish I didn't feel this way, but to ignore this would be like deleting a massive list of bugs pretending it will fix things - it's better to be realistic.

It's the unity pattern mentioned several pages back. Instead of following standard QA along the way, bugs build up then entire modules get swept under the carpet and asks end users to port or stop using something (which sucks for long term projects since Unity modules go obsolete sooo fast - once they do, bye bye LTS patches for the topper).

Why does lacking QA happen where so many core bugs slip to full releases? It's not the devs fault, it's managers. This can further be confirmed by alleged Unity members posting their rage on Reddit regarding unrealistic due dates combined with understaffing. Higher budget (you guys surely have it) is likely the answer that turns the other cheek if you want quality instead of a list of features the same size as the list of bugs [...that you deleted, so "existing" bugs rather than listed bugs].

Deleting bug reports isn't going to make them go away. QA budget, reasonable dev chair counts, and realistic deadlines will prevent them altogether.

If these alleged ex Unity devs speak the truth, then our feedback isn't going to do anything if managers say to cram a 6 month project that should take 20 devs into a 3 month project of 2 devs (again, which defined UNET -- and if UNET, what else?). The devs are awesome if they can superman some code to meet unrealistic expectations, but that leaves 0 time for QA and documentation (+likely some dirty workarounds to speed up development at the cost of scalability/QA, which would explain modules being ditched instead of fixed).

Quality Assurance. PREVENT spilled milk instead of wait until it's spilled (cleanup costs more than prevention). Just the same way, would you not treat a security vulnerability until after you're hacked if that vulnerability is known? Treat it the same way -- this is just what Unity needs. Leak some of that monthly sub budget (come, now, don't be like Comcast hoarding all the bandwidth) to QA/devs and allow devs realistic deadlines and this feedback won't even be needed since the issue may just simply be lack of resources/overpressured staff. Then @Shareholders

TL;DR: Upper mgmt / shareholders are the most-likely deduction for Unity being so unstable, making unrealistic pressures for time/budget to create things beyond the resources required for them. It's not as if the devs are making these decision to release prematurely, lacking time to properly test/document, and having no QA / not enough teammates to aid in these massive, enterprise modules. Passionate devs want a solid product -- managers just want it done -- and their managers just want a new feature listed. Without adjustments from the decision makers, this feedback thread won't make much difference (although this thread may make solid cases to present to these decision makers).

 

I find it's actually useful to have the source code indexed by Google.

In 20 years, Unity has not been able to write a working "Search" feature for their own website (last time I tried it: a few weeks ago. Still broken. Still often returns 0 hits for terms that are copy/pasted from their own API). That's fine - Google will do it better, for free, so let them! IT's what all the other corporates do .

Simultaneously ... although I have full decompiled versions of everything, sometimes it's easier to browse the source through GH's web interface.

You can see the problem where Unity does not publish their source: Shaders. There we have a bunch of people randomly posting the full shader source to old versions of Unity on GH *because Unity refuses to*, and many of us using those (sometimes very outdated) source trees because trying to navigate Unity's huge complex shader code from an IDE is torture.

 

This is probably the most important thing to solve now. It doesn't matter if bugs are fixed if they're not delivered to the active LTS version.

 

Why does process of backporting exist? It is like double work.
2020.1 is near to release in end of april or may. Set that version the best it can be. Why not make 2020.1 as if LTS?

 

"Just make software without bugs!"

Backporting exists because forcing people into a perpetual upgrade cycle to new versions of the editor with potential API conflicts is a terrible idea.

 

Normally the idea would be to add the large, heavy features at the start of a TECH cycle, finish with the lighter ones and bugfixes, then call it a day and label it LTS. The heavy features then land in the next TECH cycle and so on.

2019.x is messed up, they added, e.g., the UI overhaul right at the end of the cycle in the last release, which is (among other things) why you don't perceive any stabilization and quality improvement this time around, so really 2019.3 vs 2020.1 is not that big of a deal, they're both roughly as reasonable candidates for an LTS. That's not how it should be though.

 

I don't personally know the issues in Unity as I haven't used the engine since 2013 for anything but tutorials, but I try to use either the LTS version or newest (If the tutorial is based off newer versions than LTS) and have minimal issues trying to make things work in different versions. The usual suspect may be shaders but that is an issue with many samples I've downloaded from Unity. For example, the animation rigging samples opened in 2019.3 has an issue with LWRP shader v. 7.1.0 but opens perfectly fine in 2020.1.

I believe that as the version is still alpha and not fully tested they may be waiting to see if the fixes introduce further issues in the engine. You have to remember that they are constantly changing up the engine over the years so they might fix things by using a different method not compatible with that version of Unity. Not to mention they haven't released a 2019 LTS so maybe they want to make sure all is stable before committing to anything.

This is why I'm so interested in learning the new DOTS packages as that is how the engine is moving especially with the "Performance by Default" statement that shows where they are focused. I can see some amazing potential in all of the future work, but as someone that hasn't touched Unity in over 6 years except for tutorials I can't see how this affects in process works but a huge change in the way they want the engine to operate will change how they address the issues in the engine.The talks of this being swept under the rug are rather bothersome though.

I can see that if the engine doesn't progress it will grow stagnant and lose popularity and usability to competition, but I also see that if they stop addressing issues they are no longer giving proper long term support. Although technically I'm not sure how long is left in the 2018LTS lifespan as you only have 2 years of support. This makes most large game small team builds harder to complete with support.

 

When Unity switched to the subscription model they were very open about wanting to break the exact cycle you just described. They wanted to ship new features when they were ready, rather than arbitrarily holding them back for a version number to change (and the associated income from upgrades).

The LTS stream is one way to deal with some of the issues arising from this. The Package Manager is another.

Backporting is a part of the support being offered in "long term support".

Importantly, however, "long term support" does not mean "bug free" or "flawless" or "more stable" or anything of the kind. That's a common positive side effect of big fixes in the absence of feature development, but it's not the primary purpose.

To me, using "long term support" versions of Unity is about risk mitigation.
- The 2 year support period for those releases reduces the likelihood that I'll be forced into upgrading during that period.
- I know that the API isn't going to change as long as I stick to that version, which makes project management a bit smoother.
- I know it's going to get some bug fixes during that time, which might save me from needing to find workarounds or needing to upgrade. To clarify, my focus and Unity's published focus here are the same - it's not about a smooth and stable dev environment, it's about "major changes that would prevent... users from shipping their game".

Back when I regularly did contract work for clients I'd have loved something like the LTS that's available now, particularly in the light of working in a fast paced environment where things tend to get deprecated. It gives a really clear indication of how long I can support my work for, which is super useful when doing things like negotiating and entering contracts.

Before LTS there was an increased risk that things could change on Unity's end, create extra work for us, and we'd just have to deal with it. In a worst case scenario that could mean something like paying developers to replace a deprecated / removed system, with something which may not be equivalent, then repeat whatever QA work is associated with the project, then deal with potential fallout from the client. That risk isn't gone, but it's much lower now, and there are clear time periods associated with the LTS builds which makes it far easier to manage.

So that's why LTS backporting is important to some of us.

If Unity manages to also give me a more stable development environment with less bugs while they're at it then bonus! But that's not actually what I'm there for.

 

That's great and all, but if you're not making real, actual games, at significant scale (one-person team is unlikely to be significant - it's possible, but very unlikely), then ... you have no idea what Unity's actually like to develop with. You just won't see many of the bugs that the rest of us are seeing sometimes on a daily basis and that soak up vast amounts of our time (and in some cases: money) to workaround let alone solve.

This has always been Unity's curse, but it's been a long journey of reducing it - where Unity doesn't reduce it, they lose market share and money. Where they do reduce it, developers become more productive and ship more games - at a higher output quality with more impact on the market. This is (should be!) fundamental to Unity's business model today: the company they were in the early 2000's, where I once saw half the company sitting at a single dinner table at a conference ... had real resource constraints that meant "scrappy" was the only option. The multi-billion-dollar company there are today ... is a completely different universe.

(I've been using Unity since the Unity v3.x days. I actually used Unity v2.x a bit too - but it was so ruined by these kinds of issues that it was too much a waste of my time for anything except tutorials. Any real game you immediately ran into major bugs that you had to rewrite big parts of Unity to solve. You needed a lot of time / budget to workaround that, and Unity games were often a lot more expensive than writing it in native code!)

 

LTS is not an excuse for release stability. The moment that happens is the moment someone is being silly. LTS is for bugs they didn't know existed, you know, Long Term which obviously covers bugs that pop up after.

When Unity and their customers start seeing LTS as a band aid, you know it devalues the meaning of "release".

 

I don't understand how subscription and a rigid release schedule allows them to do that though. I remember them saying that too, but it makes zero sense.

- Subscriptions incentivize releasing stuff often (otherwise someone might wonder why they keep paying if there are no releases)
- I totally do not understand how a rigid 3 Tech releases per year (2 now, but still), "we will ship new features when we're ready".

From my point of view, ever since Unity went subscription, what they've actually been doing is : "OMG WE NEED TO RELEASE 3 TIMES PER YEAR AND WE GOT NOTHING, LET'S JUST SHOVE A BUNCH OF STUFF THAT ARE NOT READY IN THERE SO PEOPLE KEEP PAYING"

 

I think this thread is slowly but surely drifting into offtopic and general venting. I wonder if anyone from unity is still listening to all this.

 

Thank you for that insight as I'm currently trying to create a game I've been designing and learning these tutorials so I can understand the components I'll need to solo develop some large scale games. I was worried that Unity didn't provide enough for what I was trying to accomplish and was even starting to develop my own engine just to have the control to do things as I needed. In the process of seeing how I might implement different things I saw that Unity has big plans for the future of the software, but it concerns me that waiting on these systems and learning them may just waste time that I could spend on creating what I need.

 

Unity definitely provides enough. Take away the AssetStore and it still provides enough, but competitor engines are probably better at that point (personal opinion; IMHO Unity Corp is enormously reliant upon the assetstore, to an extent that even they don't realise / are in denial about / have been in denial about for 5+ years. They sniggered when I put this to them back in 2016 or so, but I believe they still don't understand - none of them make actal games!). All engines require extra manual work, to some degree - the trick is to look at what you're prepared to pay (in time + money) and what genre/features you need, and find the engine that fits closest (bearing in mind that the biggest cost will probably not be the license fee! It's usually the cost of your time spent working around / fixing problems).

 

Unity 4.0 to Unity 5.0 was nearly 3 years, during which time the pressure internally was to hold off any major new functionality as a carrot to purchase an upgrade. Now, because everyone is paying anyway, it just goes in the next release.

If you're over the income cap and you're using the engine then you need to pay. You're paying for the right to use the engine, not the new stuff that gets added. They add stuff because they need to be competitive, not because we'd stop paying for the updates.

As for adding stuff when it's not ready... I don't have a problem with it. I'd rather they let their customers use it and get real-world feedback than keeping it to themselves. It's (mostly) clearly marked as "preview", and we're (usually) not forced to use any of it. I agree it has resulted in patches of awkwardness, but fingers crossed they'll grow out of it.

 

Back on topic. I had been complaining for a long time about not being able to detect in code when a package is present in the project or not.

If you're involved in this surely you already knew it, but it turns out that using Assembly Definition Files (scroll down to "Version Defines") one can not only detect the packages but also add defines based on the specific version available. I was totally ignorant here. So @smcclelland please ignore my (repeated) requests on this.

 

I've been looking into this too, but the prolem is - yet again - it seems to fail completely when it comes to AssetStore .

(EDIT: to be clear, my problem for the asmdefs approach is that it only works for Unity packages, which is some - but not all! - the packages where we have dependencies. I prefer a general-purpose solution that works everywhere, rather than a niche solution that works in some places, and having to use the general solution anyway because you need it for everything else.)

However ... I recently discovered the CCU miniproject (one of the internal UnityLabs things) that seems to neatly solve this while remaining compatible with the assetStore. Here's the latest link (from the Unity folks): https://github.com/Unity-Technologies/ConditionalCompilationUtility

...haven't put it into production yet, but it seems to tick my needs. (and, eventually, I hope to switch over to using the custom-defines-in-asmdefs once that's been upgraded to work with assetstore, or assetstore has majorly changed to be compatible with it)

 

Is there some way they could have made it easier for you to find out? For instance, would it be useful if they added information about common use cases to the manual, or something like that? Functionality existing is only part of the story.

 

Version defines only works for certain Unity stuff right? Like I can't say if x asmdef exists? If the latter is true then I'm also surprised