2019.3 entered the final stages of beta testing

I would rather have regular updates of LTS, so there are new stable versions of the engine to use.

Sure, it would be great to be able to use big new features like DOTS and SRP, but they aren't finished yet. Why hold off making a new LTS till they are stable? HDRP was supposed to be stable a year ago, IIRC, but they are still struggling with it, and who knows when they will be done?

IMO, the most sensible thing to do is to have an annual STABLE release, and it should come at year end. It should NEVER be the policy to hold off on a LTS release until some feature or another is finished.

 

???

The LTS version was not the .3 ever. It was based on it, but with additional bug fixes and stabilization. The .3 was released the last in the version year (2017, 2018, and now 2019 maybe) and the LTS came around in the spring as .4.
https://forum.unity.com/threads/unity-2018-4-lts-is-now-available.675865/
https://forum.unity.com/threads/unity-2017-4-lts-is-now-available.526260/

The only rule for LTS is to not to contain any new features, only bug fixes and stabilization fixes comparing to the .3.

 

What I meant is LTS needs to be post 2019.3. 2019.3 is almost like a major version upgrade compared to 2019.2.

 

I don't really disagree with this. But the reality here is also that core DOTS is pretty stable, it's not like SRP. DOTS users need a stable release. If LTS was based on 2019.2, what happens to 2019.3?

I think they sort of cornered themselves here. I don't see any direction that ends up in a 'good' place for everyone.

 

I hear you. But Unity users would get all of what's stable now in the LTS, and packages are somewhat separate from releases.

My opinion is that the current 2019.3 should become 2020.1. Which would mean the LTS version of whatever's in 2019.3 wouldn't become available for a year.

Which maybe sounds undesirable. Especially when right now they say the LTS for 2019, including 2019.3, is going to be ready in the spring. I just don't believe them. I think they have a history of promising things long before they can actually be delivered.

From what I see, I think it's much more reasonable that 2019.3 - which hasn't even been released yet - matures late in the spring, say April, and then the LTS comes like four months later, so not until August.

 

TLDR; for anyone joining this thread:

1. It’s entirely unclear to users if Unity is on the right track.
2. Consequently, it’s very clear that the bulk of the Unity Communications team should probably be moved on. As friendly as some of these people might be on a personal level, the Comms team is overseeing a strategy (or lack thereof) that is antagonising the existing user-base.

On a personal but related note: when I’ve complained about things on this forum, I’ve very rarely gotten a reply from Unity. We’re treated like difficult people rather than talented professional people with valuable ideas who desperately want Unity to succeed. Like everyone, at first my suggestions are very friendly. But after asking 20 times for a bug to be fixed (one I could fix in less than 10 minutes if I had access to the code), the tone of my suggestions can appear grumpier. I see this happen over and over again on this forum.

 

I kinda disagree. I think we never left that transitional period. Ever since early 5.x we've been in "eh we're rewriting stuff, so things are kinda broken now, but they'll pay off eventually" and we're still in that mode.

 

Lots of assumptions there that are not safe to make. For a start there is more than one sort of communications, there is marketing, there is technical and support communication etc. Also, even if teams are structured in the manner you assume, dont assume they set their own strategy, perhaps the teams are fine and decent and its higher management that have setup the strategy you dont like.

Also communication is only part of the issue (and believe me, I am mad that they still havent put in a new roadmap system). If the actual source of the problems is the state of the technology, there are severe limits as to how much communication can improve the situation.

 

No, not deprecated soon. They dont put any new feature engineering efforts into the old pipelines though, so in that sense the old renderers are already on their way out. But they wont actually go away for ages.

Immature systems that need a lot more work and nobody pretends otherwise. The traditional ways of doing things are not going away though, so your concerns in this area are not based on the actual picture.

 

Well, here https://blogs.unity3d.com/2019/12/1...-final-stages-of-beta-testing/#comment-419729 Thomas from Unity said that the built-in pipeline will be around for a few years, which I guess means it will be deprecated in a few years. What actually "a few" means is anyone's guess, but given that game development can take more than 3 years normally and that developers usually support their games for many years after launch with DLC and updates, "a few years" doesn't sound reassuring enough.

There's also this info from Unite at at 37:19

Still not clear enough.

 

Yes it could mean 2020 lts is the last version to support it.

I hope its longer than that

 

Me too, that would kill our project. 2020 LTS means support until 2022 ends, which is not enough for the planned lifespan of our game. The only way I can see that to be fair is if they prolong the support for 2020 LTS in the sense that they keep it working with new versions of console manufacturer's SDKs, which is required to publish anything.

 

The problem with Built-in RP is that it wont be updated within new releases. Maybe they will squash a few bugs, but they won't add new platforms (PS5/Xbox) and features.

 

I think there is a misunderstanding of what I meant with deprecated status of the current forward/deferred renderer and monobehaviour.

The fact is already for two years no progress is made on improving, stability and development of them. That is in some way depreciation. Even bug fixes are sporadic.

The new thing like dots and URP is still not stable or production ready. Although unity might claim it is. It's far from it.

So customers are left behind.

Argumentation like clever people work around the problems in the engine is silly. What do you think my day job is?

By now it seems like making workarounds instead of developing games.

 

This is crucial to our project. Did you get that specific info about not adding new platforms from someone at Unity?

Man, you know that communication is extremely bad when there's so much speculation and no real information.

 

I agree.... It has felt like a large transition state since 5.0. Has graphics ever been stable since then? Since then we've seen: Enlighten, PBR, PLM, HDRP, LWRP, URP, 2D... So many graphics subsystems, I can't keep up.

The new tech is cool, but UT really needs to set a team aside the sole challenge of creating a large game. Not a tech demo.

 

From what I read on forums built-in won't get any major updates, only some fixes. It's better to clarify that by speaking directly to unity staff.

 

Still not sure what's the problem here other than that 2019.3 be released and not unstable. This is about 2019.3 not about the new packages for DOTS or SRP. Those mainly live on their own and in preview except for URP/Shader Graph (Those are production ready. URP is just doesn't have feature parity with the Built-in pipeline)

No one is being forced on the new tech. It's just for those who want to get their hands on it now so if you use them sometimes you encounter the things you would with something in preview. Everything that was there for the old renderer and scripting is still there, and depreciation of the builtin renderer will only happen after URP reaches feature parity with it. We aren't sure when that is but even then I'd assume the Builtin renderer would stay around for a few more years for everyone to transition.

For those worried about supporting projects throughout their lifetime, I'm also not sure of this concern. The version of Unity you settled on (Hopefully an LTS) would be the version you use to support your game moving forward and not updating to new versions. The only reason to update would be for game-breaking bug fixes that didn't land in your current LTS and a bug like that would stop a release.

 

That is a long wait November.
Will performance with Mono be on par with DOTS after upgrading to NetCore 5?
I'm interested in future of Mono with Unity.

After when Unity does visual scripting with DOTS, they could make visual scripting with Monobehavoir.
NetCore 5 could change all things for the better.

 

Unless you are publishing on platforms that require changes that are generally only added to the latest Unity versions.

Or if that fix you really wanted lands on a Tech release.

 

Yes, for PC it doesn't matter that much, but on consoles, even if they support new SDK versions throughout the LTS life, you'll be forced to update after two years.

 

Yes. I was being a bit mischievous. I did mean management - not the whole team. I meant anyone with a say on a communications strategy that essentially involves ignoring users and hoping they will lose patience and stop complaining. It’s very hard for organisations to be open about their shortcomings because they are afraid it will be thrown back at them. Being honest takes guts. But it’s appreciated by users and generally works out better than the alternative head in the sand approach.

The issue here is not whether DOTS is great or not. It probably is the future. The issue is that no one knows what’s happening, including the asset developers that help sustain Unity. The Comms team have been over-eager to say things are ready when they’re not. None of this would be happening if we had been told that these technologies were far from being production ready. So many things could be done to improve the situation. Changing the dev cycle from one that no one understands to something simpler would certainly help. 2019.1, 2019.2 and 2019.3 should all be 2019.preview and 2019.4 should be 2019.LTS That way more people would be aware of the risks they are taking.

And here’s a tip... I can find a bunch of threads where someone from Unity asks for feedback and users give feedback and then never receive any follow-through. It’s Xmas and Unity are allowed a break as well so we’re not being fair right now to expect a response. But the reality is that this happens at all times of the year. The longer threads go without an official response, the more antagonistic they become. If I were in the Comms team I would be setting up a crisis response to the current insurrection. I would have alerts that would pop up on my desktop for any thread that has received 15 comments without a response from staff. I would close feedback threads after receiving the necessary feedback, thanking everyone first.

 

This is especially an issue for early adopters. Being told that features are production-ready when in reality there is still an incredible amount of unresolved bugs. You jump onto your next venture with incredible tech proposed by unity. You spend a couple of days learning with excitement when you hit a wall and end up downgrading your projects.

I feel pessimistic in regard to the improvement of communication and prioritization by the unity team. Great ideas, poor execution. Nevertheless, it is still a great engine for small games.

 

Definitely. I started with Unity a couple of years ago. I’m a hobbyist. Made great progress for the first year. And then stupidly switched to 2019 and URP. Now my project is actually behind where it was a year ago. And I’ve been working on it almost daily, after I get home from my regular job.

The past 365 days with Unity 2019 have been spent trying to fix things, never knowing if it’s a bug I’ve introduced or if it’s on the Unity side. I also had expected basic parity between URP and the standard pipeline. I don’t remember reading any warnings about losing custom post processing effects, ambient occlusion, decent shadowing, etc. And without a proper timeline or communication from Unity I wait. And I wait. Not a day without a crash. Even on empty projects. And then the bug reporting tool crashes. Or my project is too big to send. So despite maybe a 1000 crashes not one has been reported. I’m sure it’s the same with a lot of users. If only we could at least be given the option to send a snippet of the crash log to alert Unity of our pain.

I’ve basically wasted a year trying to quash bugs while I could have been learning how to use the app. And now I’m looking at the release notes of the 2019.3 release candidate and under known issues I’m seeing that the bug reporter crashes on OSX when you’re connected to the internet. Sigh.

I love you Unity, but gosh you can be a real pain sometimes!!!

On a more joyful note... Merry Christmas to my fellow Unity users/masochists as well as to all the Unity team (including Comms!)

 

Regarding crashes, I submit crash reports often, even without an attached project. When Unity crashes, most of the time this triggers the crash reporter to run, which has a button to submit a crash report. You then have the option to remove the attached project, which I always do in this case, because my project is too big to submit. But it at least sends along the crash dump.

That being said, nearly all of the responses I get to these crash reports is QA telling me they can't reproduce the issue. Even when I say in the bug report, "This was a random crash that I can't reproduce, but I thought you might want the crash dump", the response will be "We can't reproduce this. Do you have details steps?". But I figure if enough people submit crash dumps, maybe eventually a trend will emerge and Unity will be able to fix another bug.

 

I'm exactly in the same case..... Spending more time to fix things, making bug report for something called ready for production ....

 

Had it crash 6-7 times today. 2019.3.0f3. half the time the bug reporter crashed too (didn’t know about the OS X bug, how ironic).
I got so mad at it I opened the editor log in vscode too see if there is a trigger I can understand, after that it didn’t crash a single time. On one hand, WTF?!
On the other - you are staying open vscode
Happy holidays everybody.

 

.0f4 crashes less.

 

2019.3 and DOTS/SRP is decidedly not hobbyist friendly at this point. DOTS is more stable and I think a good place to be learning game development. SRP as a hobbyist I would not use. If SRP doesn't have something you really need, there is just no reason to use it. It's not like DOTS where you stand to learn a lot about development generally.

Also you have to reconcile yourself to OSX being a second class citizen. It just has such a tiny developer and player base in comparison to windows so expecting it to be otherwise just isn't reasonable. Just like I don't expect Unity features to always work well if I'm using them in a context most games don't. Just how it works.

 

Thankfully, you are not obligated to upgrade SDKs when releasing updates to your game on consoles. If you used a valid SDK at time of release, you can stick with it forever.

Android and iOS, though...

 

Assuming an upgrade from LTS to LTS versions of unity, and even assuming the same pipeline, is it really such a daunting task to upgrade the project? A week / two weeks of labor perhaps?
The one main thing that perhaps can’t be resolved is performance degradation between versions.
I’m asking, have no clue.

 

so many complains reminds me of jonathan blow's talk about "tech regression", i'm sure unity are somewhat facing the same situation.

actually, he literally use unity as example to prove his point.

 

I was skeptical at the beginning of the video where this is going, but that talk turned out to be really good and I would agree with that. Thank you for posting this!

 

Good talk. Not done with it yet

Not fully understand what @filod want to say but
My Understanding is that Unity facing this around Unity 5. Over complicated engine, hard to maintain, move on and develop with it (totally black box for us)

Already 3 years trying to solve situation and now with DOTS they mostly solve it.
With DOTS we have mostly zero abstraction over low level CPU workflow but with good safety systems.
Most simple and straightforward solutions every thing is open in packages modularized and most important most data (except some caches inside systems) is visible on components and can be modified and debugged from our side.

Yes all this come with ton of Bugs and lowered support for old tech (most of us complain about this) but near future is glorious and I Personally very like current direction of Unity.

P.S. Strange but the same situation that lead some people to go to Unreal from Unity allows me to forgot Unreal and stick to Unity even stronger

 

But no one is talking only about DOTS. DOTS won't solve SRP mess, it won't solve domain reloads and editor performance (in most cases). It won't solve bugs, clunky workflow and "production ready" not being actually ready for anything. It won't solve "abandoning features after few years" situation. It won't solve miscommunication. Plus, some people won't switch to ECS, because it's only useful inside Unity ecosystem and it's not necessary for high-performance.

I saw a lot of complaints in this thread, but all people are saying against it "DOTS will solve everything". DOTS won't solve even a half of those problems. It's not a silver bullet.

 

agreed, Johnathan's programing language JAI almost did the same thing as DOTS did.
see this for a glimpse

 

yes DOTS will not solve old issues, i'd rather see DOTS as a new engine. and also DOTS is not only about ECS, for example, "domain reloads issue" may "partially solve" in DOTS by hot swap brust-compiled code rather than move to .net core (just my guess, don't know if it's possible), it's not about abandoning features, it's about abandoning unity itself.

my biggest unsatisfy thing is that they propagandize too much about DOTS, but it's far far away from "production ready", and also hybrid-dots may cause more problem than it solved.

 

It varies greatly from project to project, and is very hard to predict how much effort it will take in advance. It is well known in the game dev industry that you should avoid updating engines unless you absolutely have to. This is actually recommended by Epic in the Unreal camp.

I'm going exactly through this right now, going from 2017.4 to 2019.2 (where we'll wait for 2019.4 before making the last jump). We didn't want to, but it's stated Stadia, PS5 and Xbox One Series X support will not come to versions bellow 2019. Here's a rough list of the stuff we had to go through:

- Game used Ampifly Bloom, Color and Ambient Occlusion assets. Those were all discontinued and don`t work in 2019, so we had to set up PostProcessing stack v2 as a replacement, then migrate all custom post process shaders we had into it.
- Hack our scenes and prefab files in a text editor to fix the TextMeshPro transition from asset to package, since the upgrader script left a lot of orphaned script references.
- Re-factor our code to use far less SphereCast queries because they got drastically slower in 2019.2 compared to 2017.4 on PS4 and Xbox One.
- Optimize a particle system that had collision enabled because that too became much slower in 2019.2.
- Test the entire game extensively, to hunt down broken things and other performance regressions.

The last bit is the expensive part: when you upgrade engine version, you have to do extensive QA to make sure everything in your game is working. The bigger your game is, the worse that is. If it's a mobile game, it means you need to do compatibility testing with a wide range of devices to make sure it still works on them.

In our case we had it easy: our game isn't multiplayer (UNET is "gone"), we don't use pre-computed GI (Enlighteen *is* gone), we used very few closed source assets, and we weren't using any of the new stuff that has seen major breaking API and functionality changes since 2018 LTS (SRPs, ECS).

However, our ability to ship for PS5 and XBSX is still up in the air since it's unknown if UT will actually support the built-in render pipeline on those platforms or if they will require migrating to SRPs, which would cost us a good deal since our game is packed full of surface shaders with no upgrade path (the current "solution" is to manually re-create them using shader graph) and unknown performance implications: we use built-in deferred with many real-time point lights, which means our only choice would be to migrate to HDRP (which is far from production ready unless you're in UT's marketing team).

This is where the lack of (affordable) source access hurts the most for me. In cases like UE4 and Godot, it is at least possible to stick with the same version and backport compatibility features from newer versions, even if it's not trivial. I actually did that twice myself with different UE4 projects: back porting 64-bit iOS support and a newer PS4 SDK to two games using older engine versions.

 

2019.3 and 2020.1 both look to be very major releases. I for one look forward to both.

 

I’m also excited to see what future Unity will be like when all the new stuff is ready, but the current situation is unbearable if you’re in production.

I’d bet that among people who wrote in this thread, those who wrote positive posts aren’t actually producing a game right now.

As KokkuHub said, even if you update smoothly, you have to re-test everything, every nook and cranny. And it costs time and money.

In our game, all the projectiles stopped working when updated to 2019 because of a physics collision bug. I reported it and was told not to wait for a fix, to find a workaround instead, which I did in the end.

@KokkuHub I have the same concerns regarding PS5 support for built-in. I’m thinking about contacting someone from Unity about it but I’m not sure whom. We should start a new thread about it and post any info we can get, for all the others interested.

@interpol_kun said it well, DOTS won’t solve communication issues

 

Can not say for others but we will release in January and new Unity features like DOTS, URP and another small improvements helps a lot. Yes there is tons of bugs but bugs were always there

 

Okay, I take it back

 

In fact, I love DOTS, and I welcome all the new features. It's just that while the Editor is so buggy and transitioning DOTS makes things worse. And not many will benefit from DOTS until a few years later. Unity should've worked on a separate DOTS branch and merge them once it's stabilized. And fix and optimize the current Editor so that we can all benefit.

Unity is ok when you are working with a small to a medium-sized project (say, less than 50gb Assets). You will only have to deal with bugs but when your project grows, the Editor crawls like a snail and the number of bugs will be compounded.

Basically, you will spend more time fighting with the Editor, rather than working on your game. You won't know it until you have worked on a large project. Unity should've put some big warnings about it. But Unity is Unity, they will just ignore you like they always have been.

 

@chrisk, Unity works on DOTS, as we know today, since At least Unity 5, converting engine slowly since. First fruits are obviously visible in form of Jobs. Then burst. And eventually ECS. But there are multitude inner Unity components changed since. Information are however scattered and not always obvious for 'naked' eye, but we all are affected since long time.

My question is, since you know Unity long enough that has issues and is slow for larger project and all that. Why still using Unity then, over other engine alternatives?

Despite all that, somehow people are able to manage release tons of games, of different qualities and sizes, every single year.

By all means Unity is not perfect, but is workable.

 

Workable is not a particular high bar to clear and we should be able to ask for more from Unity without silly “if you don’t like it use something else” type comebacks.

Also that Unity falls apart as projects get bigger is something that Unity themselves are aware too, it’s not a point of contention, it’s pretty much fact.

 

@Antypodish, I used Unity while back(~10 years ago). Unity staff back then was very stubborn and didn't listen to users. For example (there are countless other examples and the current Editor still works like ~10 years ago with missing many fundamental features), when asked about UI improvements, (Unity only had IMGUI back then), the response I got was, "IMGUI is very powerful, you can do everything and anything with IMGUI and why you need another GUI?" It took a couple of years Unity to realize they need a new GUI and it took another 3+ years to come up with UGUI. And there is other famous quote, "We don't want to compete with our customers" not to work on any games or improving the Editor. What a shameless excuse. It's not the first I heard recently, but it sounds so familiar.

Anyway, as a result, Unity Editor today still uses IMGUI, basically rendering everything at every frame. It's one of the biggest sources of the Editor slowness. Yeah, they realized they need new Editor UI but it's ~10 years too late. (better late than never, though)

So, I gave up on Unity and switched to Unreal3. But I love C# and I watched last year's Unite and I was very excited about DOTS, SRP, Kinematica and decided to give a try, thinking that Unity must be different.(~10 years has passed and they must be, right? Wrong!) However, I never thought the slow Editor will drag me down beside all runaway bugs.

I'm already deep into the project and trying to find ways to workaround. All I can do is try to do my best to find the workaround unfortunately and suggested some help for the workaround, but no response. Deja Vu?
https://forum.unity.com/threads/using-addressable-to-save-our-lives.793422/
If it can be doable, I think it will help many others. What I like to know is a reason if it's not doable so that I can try to find another workaround, but nothing.

Lastly, we are not a large game studio that can afford custom tools and such. I hope that explains my situation.

 

Yep, that explains your concerns and I see them valid from one, or other angle. Thx.

 

I really think that UT should adopt the workflow of UE4 and their Fortnite project. UT should develop and release large enough game to validate the engine's ability to scale. That project could turn out to be the blessing in disguise in terms of development experience. And I imagine that from a business perspective, this is a heavy decision, but at this point, how else can UT TRULY understand the usability of their engine? And how else would they know what should be at the top priority in the backlog column on their kanban boards?

Thinking about it, instead of receiving feedback from its users, they would DIRECTLY get the issues in front of their monitors (granted the development machines aren't off the charts to mimic their users' experience). The speed of bug fixing could drastically improve and I'd even accept the lack of communication as long they're trying to understand the work required to work around the engine's sometimes, poor performance.

A simple collection process by unity's forum guys could be activated to gather all the engine's features that cause the most problems to its users. Come up or clone an existing game (BATTLE ROYALE genre for example) then try and implement this game by heavily utilizing the collected features. You might bump into rock-solid walls, or you might not but if you do, you'll understand the frustration and the struggles that some of us have to endure because we have come to love this engine due to its friendly UI and C#

Am I delusional and naive to bring this up? Perhaps, but I truly believe in showing rather than talking.

 

Unity does not need to make a game or a tech demo, they need to make the ux better and no more waiting hours to import assets or to switch platforms. Many processes should be done in a background process so we can continue working in the editor.

Because making a game would only result in many custom solutions that are tied to one editor version like book of the dead.

 

I stated that is 'workable', because I know how Unity is form the past. I don't try expect much from new features, neither they existence for long life span. These comes and goes like a tide. Simply I can not trust them to stay. I can only hope they stay. Assets also get depreciated every now and then. We all know how things go. Of course, we can lock project on Unity version, to stay 'safe'.

In my view, DOTS related features seems one of the most constant developed utilities for years, in comparison to anything else so far. Sure, I may be biased however. But I am happy to be challenged. And even there, things changes like seasons.

I don't expect much change in what we discuss here, in comparison what was 3-6 years ago. There is still same management on top. But I hope I am wrong. And I am happy to be proved wrong. But from industrial experience, drastic changes only happens (sometimes for good and bad), when new management/takeover take place.

And yes, looking on asset store since back years and blogs and Unite, there is tons of marketing going on. I expect only more to be honest.

Some bugs will be resolved, but as many stated, there will be 10 more for each.
I treat Unity more like Engineering tool, rather drag and drop toy, which UNFORTUNATELY, challenges us every day.

I think significant thing would need to happen in Unity market share, like a huge drop, to make some form of revolt in Unity. Until then ... meh, most likely all will be as it was.