2019.3 entered the final stages of beta testing

You shouldn't be on 2019.3 thread if you want that. TECH releases are about new and exciting, LTS are for stability and dependability.

Netcode has always been problematic with Unity, it's not a new development at all. Many things you referred to are in preview packages and these packages are not meant for people wanting stability out of the box at all. Out of curiosity, have you used Unity's new terrain tools? There's been more development on that side than in the past decade now and more is coming.

DOTS ecosystem is years away from being production ready and Unity has communicated this on their DOTS roadmap talks too, you shouldn't try to adopt it now if you hate new things as it's simply not ready yet.

In overall, I struggle to understand people who complain about both:
- change/new development
- lack of functionality on current tools

These two things contradict: change and new development is mandatory if you need to go forward. Of course new things will break but things always stabilize with time. If you want old, you can keep using 2017/2018 LTS and forget any new shiny thing exist.

 

I'm talking about Unity in general, not specifically this version. Using an LTS release is a no-brainer if you know what you're doing, but sadly even the LTS releases are unstable, buggy and incomplete.

Also, I'm not for a second trying to use DOTS or any system in Preview in a product nearing completion, that's not my point (and yes, I've tried the new terrain system, which still is a decade behind everything else).

The point is that Unity is in a total state of flux and has been for quite some time. This affects every aspect of the product, even the ones that haven't changed. It's the mad scramble for AAA relevance which is killing Unity as a product, plus the sheer arrogance from the management in setting unrealistic goals whilst at the same time leaving fundamental flaws which have been around for ever without any fixes.

Well, I'm not one of those people and you have clearly misunderstood what I tried to convey. Unity needs to slow down, do things more thoroughly and stop treating their customers as their private CI integration pipeline. If you have followed these forums for some time, as I have since 2010, you know this is not a new suggestion.

Unfortunately, Unity always says they will improve, but they never really do; brief periods of consolidation are always followed by yet another bout of immature releases, as if the lessons learned again were completely ignored. Also, Unity as a company is full of first-rate technical talent. It's not their fault. It's the people who set the company's priorities.

 

I've been around for a "while" and I still remember people complaining about the black box design, nontransparent development, things getting outdated, things not developing fast enough etc. Now that Unity has opened the development more, speeded up their development, given us more code access on c# packages and now people complain about seeing unfinished things even when they are still clearly labeled as previews/betas or about things changing in general, wanting to stick to the old things (in which case, they should just stick to older engine version IMO).

I'm personally just happy to get earlier access to new items as it's the only way we can truly affect their development direction (give constructive feedback throughout the development). We all can rant as much as we want here but it's not going to get things done the way we want unless there's actually something to take away from it. Complaining about things being broken doesn't tell much. Complaining about their management doesn't help anything.

Different engine users also have very different agendas and want the engine to go in different direction. But in the end there is no perfect game engine that can make everyone happy. I know none of the available engines will ever do things the way I'd want them to but that's something that I as a dev just have to adapt into.

 

Well, now we're firmly in the realm of what Basil Fawlty might have called "the bleeding obvious".

Sorry, this simply isn't true. Unity are asking for our impressions about the workflow and about 2019.3. The reasons 2019.3 isn't ready for prime time are exactly the same as those that plague Unity as a company and have affected previous releases. We need to talk about this on a higher level than just this particular release, or things will never improve in any real and substantial way. CEOs and CTOs do have influence over the direction of the company and of the technical considerations made on a day-to-day basis. Believe me, they are aware of all the vitriol being spilled about Unity in this and other forums on the net. Were they not, they would be remiss. However, they are clearly ignoring it and will continue to do so until those voices no longer can be ignored. So it very much matters that we speak up.

 

He's right, you're wrong.

 

The irony is that all "chasing AAA" efforts have done nothing to change how AAA studios view Unity, since the most fundamental issues that make them not even bother with Unity outside of the occasional mobile spin off are still there, untouched.

 

Exactly.

 

It takes time and that time will turn into a solid product (That's what all the changes are about and it's exciting if you can visualize what all the changes will be like in the end when everything's together). Just as most people were raving about Intel until AMD pushed through everyone thinking their products are inferior and won't ever catch up to Intel's. Now they are on top and that narrative has definitely changed.

 

People have been saying this since Unity 5.x half a decade ago.

 

True, back then the engine wasn't getting a rewrite and updated systems/features as now since the foundation it was previously built on was kinda at its limits. People wanted the old stuff to be improved and now it is on a fundamental level all the way up to the tools and at some point how the editor looks. So we just wait for the new stuff to be solid, and those who want to test/use them early can, and those who want to stick with the old can as well (Until the new is finalized and replace them).

 

Okay, but here's the thing: this should be the 2020.1 release, not 2019.3. By making it the 2019.3 release, we're pushing this entire thing into the LTS branch effectively halfway through a rewrite when there are still loads of systems that are outright missing or incomplete, which drags the LTS branch down with it as well. This is, quite possibly, the worst way to handle a major rewrite because it's not going to affect just the Tech branch.

 

I'm curious, which systems in particular do you think were partially rewritten for 2019.3 when they should have been left until 2020.1?
adbv2 and UIElements-related changes were the cause of a large portion of the 2019.3 beta's more noticeable problems. I'm not too familiar with the UIElements stuff, but I do know adbv2 has been publicly usable in previous 2019 releases and was in development for a long time before that. What it really needed was very thorough QA with a lot of projects, which is what the 2019.3 beta got it.

 

We've seen things actively removed (the resolution dialogue) rather than being replaced; the UI rewrite has broken a not insignificant amount of assets; there are numerous performance regressions across the board; configurable enter play mode is in an absolute mess of a state; script compilation has seen a bunch of changes, which has lead to decreased workflow speed; I'm not sure what's causing it, but a lot of prefabs still break if you upgrade a project and that's not expected to get fixed before LTS; and if you check the issue tracker there's loads of stuff that's just outright nonfunctional.

If this is going to be the last update of the cycle before a major update, it should focus on making sure the LTS branch is going to be as rock solid as it can be, honestly. The whole Tech/LTS system is showing a severe weakness right now.

 

I think that Unity pushed way too many ambitious engine changes too late into the 2019.3 branch, probably with the intent to squeeze them into the LTS version to provide functionality needed for experimental tech e.g. DOTS and other engine overhaul stuff. It feels to me some of those changes were simply not ready and were pushed regardless under the motto that they can be fixed later without time pressure in 2019.4.

Not the first time this happens nor will it be the last. But nevertheless, it still bites them in the behind.

 

The most important thing for me is a truly stable LTS, and I have to wonder if Unity is biting off more than they can chew here with 2019.3. It looks like it.

Aren't we in a situation where use of the 2020 cycle is going to be hampered, waiting on fixes for the 2019 cycle anyway? I might be misunderstanding the situation here, but it seems like problems could snowball for people trying to use the point releases. It could go on for a while, maybe half a year or so.

I know we don't vote on it, but I say since 2019.3 is running late ... break 2019 off at 2019.2, if you can. Make that the basis of the 2019 LTS and move 2019.3 to be the effective 2020.1. Start developing the 2019 LTS today.

I suppose to an extent it doesn't really matter for me, as I will be sticking with LTS releases only, and I am prepared to stay with 2018. But for people who have been working with 2019 and expecting to use those features ... they could have a long wait for a stable version.

 

2019.3 release can't be far away. So nothing can be really gained to make 2019.2 the LTS version.
Important would be that Unity reflects on the release cycle to not make the same mistakes over and over again.

I'd suggest to limit the releases to only 2 tech and 1 LTS releases per year to allow more time for stabilization and also be strict with feature freeze late in the development of each release.

 

They should also really make the LTS branch the default selected version in the Hub if you're installing Unity, honestly.

 

Is that true? My understanding is that we'll need point increments of 2019.3 for a few months, till it is considered complete, and then once they start the LTS, it will be another few months before the first version of the LTS is ready.

I'm pretty sure that's what happened last year. Am I not remembering it right?

 

You would think they'd want their developers using the most stable releases.

 

I don't know when exactly Unity starts to call a release LTS. However, patching 2019.3 should be basically the process of developing the LTS version.

 

None of the ongoing rewrites actually target the issues that make Unity a terrible choice for AAA or larger scale AA projects. DOTS is not going to bring in the AAA. Multiple SRPs which aren't compatible with each other is not going to bring in the AAA. Addressables, which is built on top of the flawed AssetBundle system, is not going to bring in the AAA. This bizarre release schedule where we have three releases per year with different different feature sets and breaking changes but only the latest one will ever get bug fixes going on isn't going to bring in the AAA.

If Unity wants to sell their engine to AAA projects, they will have to prove its usability for such projects by making an AAA game themselves or paying a studio to do it. No company will risk tens of millions of dollars without solid prior work showing the engine can both run and work on a project of such scope. And right now it can't, and it will still won't even with DOTS and SRPs.

 

I did make a feedback request for similar before, as at one point hub didnt differentiate between alpha, beta, released and lts.. and people would say see 2020.x and say that must be the one I need.. not knowing it could be a bag of worms.. I asked for the option (which we originally had in hub) which was to "default" to a specific unity version.. While there is a drop down, its not hidden but it doesnt show you your current selection so you click new and... Oh, wait its the last installation not the best installation.. Hmm cancel.. As you say, it really does seem it should kinda go in preference order of LTS, released, beta, alpha.. so sure if you only have alpha installed thats fine, but the default should be the most stable, or at least prefer a stable unless you go change it.. the new unity people seem to find themselves so confused... I spoke to one today whos hub hasnt updated since the 2019.3.0f3 accidentally went out as released so they thought it was a released version.. no idea it was only release candidate, and there'd been 2 more.. and...

 

Why have 20 tech streams per release? Unreal has only a couple of them. They call it hotfixes per release.

Build-in RP should be removed and make optional in package manager as SRP.
If you use SRP you don't need built-in. That will speed up development of SRP and next year it could become real established and robust engine which everyone will use it.

 

There are three. What are you talking about? Incremental updates aren't streams. Also the built-in pipeline is integrated into the engine itself. You can't separate it out like that.

 

According to their blog:

https://blogs.unity3d.com/2018/04/0...g-the-tech-and-long-term-support-lts-streams/

 

Example.
UE4 4.21. You can make and build the game complete. It has only 2 hotfixes, patches.
Unity tech streams had around 15 patches per tech release. That takes a lot of development time.

Development strategy should be reorganized for robust and prod. ready tech streams so that more time is spent on SRP, new editor tools ...

 

Dont know how you count it but it seems there are dozens of changes
https://docs.unrealengine.com/en-US/Support/Builds/ReleaseNotes/4_21/index.html

 

He means that each version gets updated only a couple times, while each Unity version gets several. 2019.2 is on patch 18 right now, for example, and as soon as 2019.3 becomes "final" it won't get any bug fixes anymore.

Past UE4 versions don't get bug fixes either, but since you have the source code it's at least possible to backport fixes and even platform SDKs instead of being forced to upgrade.

 

Getting less isn't better. Unity wants to deliver fixes for tech streams once per week, hence getting many releases:

They do this to give users constant stream of getting the bug fixes flowing in ASAP. In other engines you often can get few hotfixes (with no guarantee when you'll get them) and then they forget about that branch of development, leave remaining bugs unfixed on that version and fix only issues on newer versions. Whole TECH / LTS stream setup is there to prevent issues like this as we get weekly fixes while in development (tech) and biweekly fixes while in 2 year maintenance (lts). If you've ever used UE4, CryEngine etc, you'd know immediately what this is about and why it sucks to get left behind.

Of course this partly still happens with TECH releases when new TECH release comes along but you really should treat these as betas toward the next LTS anyway.

 

With UE4 that is only the case if you are using the Launcher version. If you're using the github version you get fixes as they come.

But you have a point about the LTS: there's no such thing with UE4. There each version is like the Unity TECH releases, only being supported until the next one drops.

Of course, not having the source code makes a difference: the Unity tech releases are pretty much dead ends. You're shooting yourself in the foot if you ship a game using them.

 

2019.2 -> LTS.
2019.3 -> x
2019.4 -> x
2020.1 -> fix and release.

I think this is the best way.

 

No. We are seeing right now, in this thread, why this idea does not work. We need a focus right now on stability because we're entering into what will be the basis for the LTS version.

Stop comparing superficial details while ignoring the underlying issues. You do this all the time.

 

I'm not software engineer so don't take my words as facts.

I think that tech streams and patches contribute to regressions. Therefore Unity 2019.2 has about 17 patches.
My argument is to reorganize development strategy in order to have robust and stable tech stream. It would require less patches because it will be stable.

If developers would want to use Unreal right now they'll use 4.24 because it is latest version and reliable. If developers want to use Unity, well why is choice not so simple to use 2019.3? Well there is a lot of going. Some use 5.6, 2017LTS, 2018 for production development, less 2019.2/3.

 

The blog entry introducing 2018.3 appeared on December 13, 2018, and it features a download link, so that's probably when 2018.3 was first released. (?)

2018.3 went all the way to 2018.3.14. The LTS for 2018 was released May 10, 2019.

So it took from December 13 to May 10 for 2018.3 to turn into 2018 LTS.

2019.3 has already taken a month longer, today being January 19. If 2019.3.0 was released today, looking at the experience with 2018.3, we could logically assume the LTS version of 2019 won't appear till mid-June.

 

2019.4 is tied to the release date of 2020.1, which is being developed in parallel with 2019.3.

 

If I'm not mistaken that was the release Unity was trying to cram in the new prefab system which at the time was far from stable.

 

You're say you're not a software engineer and you then follow it up with things that you would know are inaccurate if you looked into software engineering.

 

If. It's not a 100% chance, but we can hope cause of their own debates about new UE4 language. Fingers crossed.

 

There's already MonoUE, but it's slightly outdated (cue this comment getting removed just like the last ones talking about this competitor in 5... 4... 3...)

 

Hey, Rizu. I can't see the preview or beta label on LWRP or URP, can you help me to find it there? Uhh, I am so silly, sorry, just picked that technology for my new mobile project in September and since that I am dealing with constant bugs and performance problems/regressions. Really ashamed of myself, maybe I missed it in the Package Manager... Will be more attentive the next time.

 

Unity only releases once a year and the version number always ends with a ".4". Everything else is preview/beta/experimental so expect a lot of bugs.

 

LWRP left preview on 2019.1 so it's a fully released thing. URP is techinically relabeled LWRP but it's a new package on 2019.3 still. Current URP doesn't have preview status because it's only fully released along with 2019.3, same goes with HDRP which is only officially released once 2019.3 goes live. I'd expect Unity to put out new packages with "verified" status to make this more clear when that happens.

I agree that it can be confusing but only people who see the packages without "preview" suffix prior to these packages officially release are people who run pre-release Unity editor versions (alphas/betas/RCs).

 

My point is that not so many people are such hypocrites as you showed, yes, sometimes some people demand new features right now and simultaneously moan about bugs. But I see more people being not very cool with lots of bugs around the both editor and "production ready packages". Also the performance became worse. And about the DOTS -- it's in the development for more than 3 years now (the fish boid demo is almost 4 years old now, no?) and there is no hope for a stable release soon.

I mean, look at all the threads. The people who want new features are not exactly the same people who are feeling bad about bugs and stuff. Also, there are difference between "Add that new fancy teach feature" and "Add that thing all the other engines had 10 years ago". Let's not forget.

 

This is correct, Unity has told they plan to get DOTS "ready" by 2022 but anyone who's been around for a while here know these targets shift eventually. IMHO DOTS isn't something majority of the engine users should even touch at this point. Even if you are used to living on the edge with new features, DOTS API changes make you rewrite your code on almost every preview version and there can be major changes in the direction it's heading at, even today.

As for packages leaving preview status too early, this is not ideal situation and it's clearly happened quite many times in past and will happen in the future too. I guess the bottom line there is that they have to get these out at some point when Unity thinks these are stable enough. Common user side complain at that point is that there's tons of features missing that existed on the older systems, but those are not really a bugs (I can totally understand it will annoy the users still).

 

this. sure, play with it, dabble with it, but its like trying to shoot fish in a barrel from the other side of the fence when you cant see, you have no idea what changes are there, and so much can change in the blink of an eye. Sure, understand the technology, but I imagine by the time its released todays version will be only a distant memory

 

DOTS is just under 2 years old.

The core of it is quite stable, far more so then URP. DOTS is also a far higher value overall, if you are pushing the envelope performance wise or doing stuff at scale it's really a no brainer even though it's in preview.

Also, professional funded studios evaluate all of this very differently then hobbyists. Neither is right or wrong it just is. A funded team has a game, it has things it needs. The question is more do we use what Unity has preview or otherwise, or do we roll our own. Depends a lot on the genre but in some you are just always living on the edge, it's a natural state if you want to stay competitive.

 

A lot of that is really dependent on developer experience and design choices made. We used DOTS since day one actually since the first week that the first job api's appeared. And the changes we had to make due to api changes were never significant.

We correctly evaluated that while the core was unlikely to see significant changes, higher level flows likely would. So we stuck with lower level api's mostly giving higher level api's time to settle. Unfortunately this is an areas where hobbyists get hit the hardest, because they naturally gravitate towards high level flows and lack the experience to see those are where the most churn is likely to happen. Combined with Unity not keeping tutorials up to date it's not a great place for hobbyists to be right now.

 

@PeterB was spot on. I've been complaining about the situation for years just to learn to give up and move on. The amount of unfulfilled promises just keeps growing. And when they finally do it it's been too little too late. (new terrain system? took them 9 years of requests to finally add holes).

And don't get me started on performance... 2019.3 is the slowest Unity Engine release by far in all of Unity history.

It's a trainwreck but if you check the demos and marketing, it's all unicorns and happy faces. Seriously, the new people at management for the past 2 years lost complete track of what's going on and the sentiment keeps getting worse.

 

@PeterB I am curious, which features of C# would make UE4 a better choice and why not just use it now with C++? C# is a garbage collected language but Epic strapped on a garbage collector onto Unreal's C++ classes anyway so I don't know what the major difference would be. Unity example code seems to shy away from the more hip features such as lambdas, null-coalescing operator,... and they've even done crazy stuff like actually allowing MonoBehaviours to be null-checked as booleans (a very C++ thing to do) so other than perhaps speeding up build times during development the big advantage of Unity, in my opinion, is a cleaner API and better naming conventions that don't reek of Hungarian notation.

The other big advantage from at least my point of view is the ease of extending the editor, it tends to help a lot with the workflow when you can just write a Run in edit mode script that generates stuff by simply adding an attribute.

 

Much faster iteration times, almost instant with the last .net core. Much less abilities to shoot yourself in the foot. A lot cleaner workflow without .h and .cpp boilerplate. And I think that the syntax will improve too, I personally hate macros and especially Unreal's macros.