Feedback Maybe Unity should start fixing their engine instead of adding 30 new features a day

I feel like this is getting worse and worse.
They just released 2020.2 and they somehow managed to completely break VR support with URP...
Right now their backlog is probably bigger than the all the Harry Potter books combined

 

Is this where I make the statement that people shouldn't update just because the latest release is available?

 

If you want stability, stick to a year old LTS version of Unity.

 

If it's not stable, then it shouldn't leave beta/alpha.
People are updating to the latest STABLE version and according to Unity, 2020.2 is now officially one. (which is wrong)

 

No. Unity's stable release is the LTS release. An LTS release includes extensive bug fixing beyond the short cycle a TECH release is active and only receives new features backported from newer releases if the feature is required to continuing development (eg Android 64-bit support).

Unity's TECH releases are intended for people who want or need the new features they include but come with the expectation that it will not be a completely stable experience (though it is more stable than the alpha and beta releases). Furthermore patches are only provided until the next TECH release.

If you want a stable development environment you should be choosing an LTS release. If you instead choose a TECH release that's your mistake and not at all the fault of Unity. I'm providing sources below but they're by no means the only ones. Unite conferences spent time discussing the idea back when it was still new.

https://blogs.unity3d.com/2018/04/0...g-the-tech-and-long-term-support-lts-streams/
https://blogs.unity3d.com/2020/01/29/switching-to-two-releases-in-the-2020-tech-stream/

 

OK, this makes sense, but here is my problem– who wants to release something that is years behind current device technology?

One way a new app, game or project creates buzz is by utilizing the latest device features, like Lidar scanning, face recognition, etc. It bugs me that I have to trade stability for lack of current features or taking advantage of the latest tech from the hardware.

This is mainly about mobile, but it also holds true for VR, hololens, etc. People want to develop for X feature that was just released, not be told that to safely develop for X feature wait 2 or 3 years until Unity properly supports it. Who cares at that point?

I suppose an argument could be made that to develop for that latest feature, I should just use the native development platfore, But, as a Unity user, it should be assumed I'm trying to save time and use an engine that just 'makes it work'.

Sorry for the rant, but just spent another day trying to 'connect the dots' to get an AR app to run with some of the various latest tech - URP, VFX and UIElements. I guess to be safe, I could just avoid all the new tech in Unity and use 2019 LTS. But, how to transition to the new Unity systems if I don't use it in a project? That used to be a workflow that worked and kept me up to date.

 

New technology is going to less reliable than older, more established tech. That's just how it is.

If you use the native development platform, you are still going to find this tech to be buggier than the older tech.

You may have to hack your way around (potentially numerous) problems, that's just how you do it with bleeding edge tech.

 

It is.

It is also where I make the statement that I have often encountered bugs that are "fixed" in the next version of the feature, and the next version of the feature is only available in new versions of Unity <- leaving us no choice.

It is also where I make the statement of "If you're a mobile dev, you don't really have a choice of staying behind too much, because platform requirements often require stuff that are in new versions of Unity".

Also, INTRODUCING: a new statement: I'm really tired of the yearly Tech / LTS cycle. It takes quite a while for LTS to be kinda stable (less random issues in builds, less random issues in editor) and even just going from late LTS (say, late 2018LTS) to early LTS (say 2019LTS when it was first released) is a painful experience and has a lot of "let's see how many months it will take us to hunt down all the random things they broke".

Frankly I'm very tired of Tech releases completely resetting any sense of stability and the cycle ending before the editor gets any good at all, and their mania of abandoning features as soon as they are released and then instead of fixing/improving them, introducing a completely new feature is beyond tiring.

I don't see steady improvement in Unity. IMO they are stuck in a cycle of *breaking everything* kinda fixing them, then breaking them again, but with no real benefit in the meantime.

 

The problem is that Unity always has been behind in technology, and even their bleeding edge stuff are kinda old news by the time Unity makes them usable.

Their "reliable" tech, is also likely abandoned and decades old by now.

 

New technology relatively speaking

 

We often had people that wanted to hire us to do projects that were directly inspired from Unity's own marketing.

"A city like the Megacity demo"
"Yeah, uhhh, that tech never actually matured"
"But they showed that years ago"
"Yeah, don't know what to tell you"

Unity keeps pushing stuff that isn't ready, or will never be ready, people ask for those stuff, and when you can't deliver those things exactly, or have to explain "to do that we will have to make our own solution, which will take time and money" it's obviously your fault, or you're trying to scam them.

 

If you cared about the latest and greatest technology you wouldn't be using Unity.

 

Exactly.

Whilst there are a lot of reasons Unity is a great engine (imo) it's kind of like a gifted child with behaviour issues. When you can get them to sit still for 10 minutes they produce some amazing work. Unfortunately, the rest of their time is spent running around setting things on fire or kicking and biting other children.

ECS is not suitable for anything outside of small games & demos and appears to be stuck in limbo.

SRP has less documentation than a toaster.

Device Simulator (arguably critical for anyone making mobile games) has been a preview package for almost 2 years.

However, my main issue has always been Unity's insistence that anyone and everyone should be able to dive into Unity and makes games even when this has a negative impact on the engine. Not everyone should be a developer. Not everyone should "learn to code" - especially when it impacts those who need more complex features that get shelved for improvements that make it easier for my grandad to make a flappy bird clone.

Don't know how to write shader code? Introducing shader graph!

(cool but we can still write custom shaders for SRP right?)

Well... yes and no. You can make them but you're going to have to dig through the Unity github graphics repo to find out how we handle light (and we might change these at any point so.... good luck with broken shaders).




This is a perfect example. Provide support via shader graph because 99% of devs don't write shader code, and anyone that wants to write custom HLSL basically gets a "sucks to be you I guess." from Unity.

2020.2

iOS: Removed support for Launch Images, to adhere to new Apple guidelines.

Android: Improved Screen.resolutions to include supported display resolutions for 4K detection

Android: Added target display support for Android

Android: Added anti-piracy measures which print your Company Name and Product Name in the log during
application start. This can be used to prove that the game is yours if someone pirates it.

Android: Improved Application.genuine implementation, so it checks that the package name set in Player Settings matches with the one acquired at runtime.

Android: Added update so that frame rate is decided automatically when optimized frame pacing is enabled

Android: Added support for Vulkan backbuffer pre-rotation.

Mobile: Added Adaptive Performance settings.

Android: Improved Screen.currentResolution.refreshRate to correct itself if the display refresh rate changes.

Android: Optimized async texture readback and CopyTexture when using Vulkan on Mali GPUs.

 

If you don't jump on pretty early (we just jumped on with 2020.2) there will be a bunch of bugs not found because it seems my team are the only one using the engine

Also we have found bugs in LTS so no guarantee.

Edit: you do this in a migration branch, goes without saying

Edit: unity really need to have better code coverage and regression testing.

 

They don't even test the stuff they put in the announcement trailer.. :

 

I never said it was guaranteed that the LTS release would be bug free. A statement like that would be absurd.

While the Unity developers like to make the statement that being able to make your game solely with ECS is one of their long term goals, I'm firmly of the belief it's best used in small doses with the remainder of your game made with traditional methods.

By the way there are alternatives available to Unity's ECS framework. Entitas has been popular with members of this community that have needed an ECS approach for several years and it's an excellent choice if you need a stable release now.

https://github.com/sschmid/Entitas-CSharp