2019.3 entered the final stages of beta testing

I am at 50% of a project in 2019.2 and I am getting unity crashes every day at least once, and Unity getting stuck 3 or 4 times daily. When your project grows, the assembly reload is making the crashes and getting it stuck ( at least in my case). As I cannot reproduce with step by step when I report these they close them because "we can't reproduce the bug" so I don't even report them anymore (most of the bugs of my production games are on certain conditions. I will like to close it and say to my clients "I can't reproduce the bug so I close them" but they will freak out so I need to investigate, but Unity can do it )

I need to eliminate all the breakpoints every time that I want to debug the project and assign them again after the debugger has connected, if I don't do so it takes ages to connect the debugger to the editor.

Using the asset store with the new LWRP or URP is a pain in the ass since you need to convert manually all the materials as there is no official way for asset developer to distribute for the differents render pipelines. Some of them implement .rar or .zip with HDRP and LWRP stuff inside, but if you plan to update the package you need to create your own prefabs and unzip it manually which is a pain the ass.

I have lost some references on the nested prefab mysteriously, and lack of some basic functionality like rename them without breaking them and some strange behavior.

Some random error in the editor appear very often but these are not important (not that I am aware of)

Loading times are longer than 2017 in some cases

I delete Progrid from my project since it makes the crashes increment x4 (but this is a preview package, that's expected)

Changing an actual material to LWRP material lose the reference to the albedo map so I need to connect it again manually... these are some of them that I actually remember and the list goes on. I am not even on the release part of the game, at the current state of Unity it will be "funny"

 

Currently waiting for a solution (or at least any kind of response from the staff) about MSAA not working in Quest with URP, which was claimed to be stable but clearly it's not. It's been like this since sometime during LWRP development. To be honest, the whole "developing for Quest" thing is still a game of workarounds, missing documentation, broken features.

I have to agree with the feelings of all the devs here. Since mid 2018 Unity started to feel more inconsistent month after month, adding preview features before the open ones are finalized. Iterating on design is becoming slower and slower, and with my current VR project I actually spent more time trying to get things to work than actually code the base gameplay: first with hands not tracking, then wrong floor height, then singlepass and multipass not working, now this MSAA thing... And I hope it's the last issue so I can work on the actual game code and release a public alpha within reasonable time.

Best of luck to you for the 2019.3 release, but most importantly best of luck to all developers here because in the current state, the future doesn't look very bright for this engine.

 

EDIT: Just removed my previous post. I am done.

I had written a multi page post talking about how we have just started trying to hire some unreal developers to retrain our staff + convert propeitary code to unreal and will be moving engine and once we have done that, ceasing all of our 32-33 license subscriptions in studio, maintaining 1 or 2 licenses for legacy programs.

I had then gone into all the talk in our company leading up to this and how it was a hard decision but unfortunately is out of my hands, and explained things unity could have done to stop this having happened, but you know what. I am done. Why am I actually making all this effort when the company wont even write a single blog post addressing the issue despite 2 years of this?

I am not sure why I am hanging around here putting all this effort in. Majority of time I come here for work not for my personal projects, and my workplace is no longer going to be a user of unity with said retraining occuring in first half of next year.

So I would like to bid everyone goodbye, its been really fun being a part of this community and I have some good memories and chats with people here but I think its time I moved on.

Ill still stop by time to time to check on what people are up to and for resources for my personal project, but beyond that I dont think there is much here for me anymore commercially speaking.

Ive been telling senior management for a week since I posted in this thread that an official response is coming, that unity are aware of the real state of things and wont let it go unchecked before xmas, just like I have been fighting the cause since 2018 here when originally discussions about taking the downtime between projects to retrain into unreal and remove dependency on unity was brought up. But its been a week since my post and 2 years since the initial internal discussions and the decision to switch was made internally this morning, and now this afternoon we are contacting recruiters to find unreal experts to bring in.

So basically, you guys have had multiple chances and now you can cross off the first of many reasonably sized studios to officially dump unity PURELY based on the state of all these changes and the complete lack of communication or even acknowledgement that things are bad. You guys have time to write blog posts about paid tertiary crap like extra services to drain further money via a broken engine, but not to address the actual concerns of your user base.

No, a comment buried in a blog post from official team member (thomas) does not count as a response or official announcement.

 

My former studio did this too, after we had major issues with unity. I wrote some of this down in this post:
https://forum.unity.com/threads/12-...018-and-their-technology.510065/#post-3340219

 

The simplest concept change I can think of is to have only two point releases in a year, not three, and move the LTS release to the final release each year.

New features are great, but truly stable releases are important as well.

With the 2019.3 release pushed into 2020, that makes me think we might not get the 2019 LTS until August - October.

A quick fix for the current situation would be to end 2019's cycle at 2019.2, and rename the 2019.3 release to 2020.1.

Then begin a 2019.2 based LTS.

 

Some time ago, I have suggested this also.

 

Yeah, I don't think it's the first time I've suggested it either. It just seems sensible to make an adjustment, especially since they keep sliding further out of schedule trying to do 3 a year. It also takes a significant amount of time to produce the LTS release.

For me, as a Unity user, I really like the idea of getting a LTS release each year somewhere around November / December. Getting the first LTS release the same year as the first point release would be great. I don't like waiting first 1.25 years (2017), then 1.5 (2018), and now probably 1.75 years (2019) for the LTS release.

EDIT: BTW, I don't mean to mislead people. Unity says in the blog post associated with this release that their intention is for the LTS to be released in the spring, along with the 2020.1 release, and presumably the end of the 2019.3 releases.

What I'm saying is that I'm skeptical they will hit this release date.

 

We feel this buggy mess pain aswell.
I used to really really LOVE Unity, and for the opertunities it brought us as a company but it's time to complain.
I pay plenty of pro licences but there is no way to talk to developers and get things sorted.

We are on 2018.4 LTS, naturally because you want to release an actual game.
However this version is now out for a year almost, and is still riddled with bugs, and some things get fixed and never merged upstream to an actual stable build. and there is no way we will switch to the mess that is 2019.X

Naturally we ignore all the new:
Render pipelines (broken, incompatible with current assets and our own work, I hear you going to deprecate the old renderer soon???)
DOTS/ECS (Broken mess, Unusable, changing API, needing a complete rewrite of our game. no way that is going to happen now. and I hear monobehaviour is deprecated soon???)

What is going on guys?!
The promises of high performance have been lies, nobody can actually use DOTS/ECS in their current developping projects, and people that do it on new projects are hitting massive roadblocks, it's hard to work with, illogical changing API's.. and unstable.

All this development efford could have gone into porting unity to .net core. which probably would give similar if not better performance as all your DOTS/ECS HPC# work. But you guys decided to re-invent the wheel. AGAIN.... WHY????

The new .net core is blazing fast, multi tear compiled. all of this stuff we are missing out on. And that could be used on all of our current projects TODAY. No more GC problems, generally probably 4 times speedup on all code.

If you don't do that. you could at least fix basic performance things, like fix the fact all float operations in unity C# mono are 2 times as slow as they should be..
https://tirania.org/blog/archive/2018/Apr-11.html
Mono resolved that problem almost 2 years ago!
Why not merge it in, and enable the compiler flags? Should take no more than 1 hour of your developer time.

And no don't suggest me to try IL2CPP, that is a giant black box that is generating random crashes, random bugs and is in no way near stable to use.
It translates the C# code to a giant mess of C++ code, just open up anything it generates, if you have any knowledge of C++, you will see that the generated code is not performant by any means, it generates so much bloat that even the best compilers in the world cannot make it fast.
Perhaps the only reason it's faster than mono at this point is the float math problems i mention above. and it's ability to overcome managed to native interop.

A few years ago Unet HLAPI/LLAPI got deprecated (because it was bad I know) and the replacement is still not done, the FPS sample it's alpha DOTS Networking code is full with hacks and "fixme" it's not any example people can use to learn how to use your new stuff. As I expect, you guys screwed it up AGAIN with networking, years later, still nothing significant delivered.

My point in this topic is actually simple.
Unity, fix what you have, stop making new things that you depericate later and never leave fixed.

I've been in this engine professionaly since 2013.
There were moments you went on the right track, around 5.4 you started to fix the basic performance problems plagued the engine for years, and decided to work more on bug fixing and testing. but today, it's worse than before that...
What gives?!

I would actually vote for a feature freeze for a year, that would retain your customers better than all of these new unusable things.

 

Totally agree! It's a shame that Unity now has no any official Networking stuff!
Common Unity, we need Networking!
Last time I think that I need to go for Unreal Engine
Yes, it is more complex than Unity, but it seem like much better and it works - a good article.

 

I don't know about ECS, but I am using Burst, Collections, Jobs and Mathematics (which is almost the entire DOTS) in my project and this is the most stable and solid part of the engine so far. And it helped me to make something, that early was not possible (generating Earth-size planet in real time).

Also I heard many times from Unity staff, that MonoBehaviour and built-in Renderer will not be deprecated any time soon. This release cycle definitely has a lot of problems, bugs and regressions, but please do not spread false information without checking it.

 

You will be surprised, but the same posts "I am tired of bugs of Unreal engine and moving to another engine" is pretty often on Unreal forums too. You can easily google it. Every engine feels good and solid when you start to learn it and make simple projects with it. But in real projects there are always be problems no matter what engine you are using.

I do not deny, that Unreal is more production ready, because Epic Games are using it in real production with real games. And they will very rarely break main engine features and workflows (like broken reflection probes in 2019.3, WTF). But everything has its price. The price of Unreal is C++ and it is a huge price. Don't tell me about blueprints, I can do more work using C# in one hour, than with visual scripting in days.

Anyway, it is not about Unity vs Unreal. The main point of this thread is:

No matter how huge your QA department is and how many automated tests you have, you will never cover all cases. Any developer knows, that even if all your unit-tests are green and you have 98% code coverage it doesn't mean, that you will have no bugs. The most annoying and difficult bugs appear in integration tests. And only good integration tests for game engine are real projects. Until UT has its own games in production — we will suffer and play the QA role for free.

Also the communication point is valid too. Bugs aren't such a big deal. The problem is when you don't know when they will be fixed (or ever). And you can not plan your time because of that. Knowing even approximate ETA in this business is very, very important.

 

I think that this is the main point!
How can we make awesome games with Unity if we do not trust in this game engine anymore?
How many new cool games done with Unity? (Not simple mobile ones but some more serious)

 

I'm well into the current project, about a year and a half and I must finish it within next year. It's a PC online multiplayer game based on well-known IP.
I seriously worry that I won't be able to finish it next year. Right now, I'm spending more time struggling with the clunky Editor and trying to finding workarounds for many Unity problems and it's getting worse every day.

On top of that, Unity still doesn't have a usable network stack. I waited a year but gave up waiting for the new Network Stack after watching Unite 2019. It's pretty much pre-pre-alpha stage and no one knows when it will be in the production stage, if not abandoned before it gets released.

For the network solution, I decided to give Mirror a try, a network stack based on UNET that Unity has long abandoned. It seems the only viable option right now. A few users are trying to triage Unity's leftovers and they are doing superb jobs, the job that Unity should've have done. If Unity cared about the users, Unity wouldn't have just abandoned UNET make everyone wait for the new shiny DOTS network stack.

The whole DOTS stuff is really screwing the many despite the fact that Unity pretty much has focused on DOTS for more than a year; it's constantly changing, breaks things, and slowing things down. I'm guessing many of the performance/regression bugs are due to DOTS. I really think that Unity should've worked on a separate DOTS branch and make the current Editor stable/optimized. I really think .NetCore can fix the slow Editor problem but Unity seems to find only excuses why it's not likely to happen.

From my trusted source, Epic is working very hard on new Scripting Language(UnrealScript 2??) and they will likely make the announcement next year. (around GDC time from what I was told) The only reason that kept me from using Unreal is I really hate Blueprint and C++ is unproductive compared to C#. But in hindsight, Unreal now has a hot-swappable C++ compiler and it will be as fast as C# compilation, or perhaps faster in many situations. I'm pretty sure the new Scripting Language can boost productivity much higher than C#. Once the new Scripting Language is released, I think it will be the final nail in the coffin and many will abandon Unity, like myself. Migrating and adjusting to the new engine will take time but crossing the final line is what's important.

So, Unity has the time until Epic makes the announcement. If Unity is still hopeless as is then, I'll have no choice but to migrate to Unreal and I'll never look back. And I'll do all in my power to help users who want to migrate.
Sorry, but I had enough pains already with Unity. Yeah I know, Unreal isn't going to be painless but at least I won't have to fight with the clunky Editor.

I really wish to finish the current project using Unity, so please help yourself to help us!!!
I beg you one last time. Please do something about it soon, announce for some changes that you are going to fix/optimize the current Editor also instead of focusing on DOTS only. "Performance by Default for the Editor" campaign will change my mind and I'll ride along with you as long as I can. I already suggested what needs to be done above and let us know what you think about it, even if you are not going to do anything about it so that I can plan ahead.

Thanks.

 

There are plenty of them: https://en.wikipedia.org/wiki/List_of_Unity_games#2019, but less than in previous years.

 

FYI, here is a thread I started while ago about "Performance by Default for the Editor"
https://forum.unity.com/threads/how-about-performance-by-default-for-editor.603997/

 

Monobehaviour and gameObject definetly will not be deprecated soon. At least because it is used in entity conversion workflow.

If they officially add the c# support it would be a last nail. But new high level language could be a good idea too.

Unreal lucks high level language as c#, normal official 2d support and generic animator. There is some restrictions in that you can and can't access in blueprints. There is no concept of don't destroy on load objects.

But unreal editor feels much more professional and convenient, stable and trusted almost every editor tool is much better there. Not to mention it has healthy dark theme and it is not paid)) even Godot has much better configurable editor and it is open source project. I am amazed why unity can not make a normal usable modern editor UI with separate tabs.

Bugs and crashes are in every engine but developers who produce games in its engine will definetly not tolerate them for long and try to fix them as soon as possible!!

Abandoned features presents in both engines.

 

Seperate tabs is on the roadmap called workspaces, unless I misunderstood what you mean by that.

 

The list in comparison to "List of Unreal Engine games" is insane. Not just the amount of games but also visual quality (can't comment on performance but I'm assuming it is pretty effective. Funny to see how lazy the list for Unity has been done in comparison to UE). Which is very appealing but the only thing that keeps me from switching to Unreal Engine is the high-level language that is C#. And that IS THE ONLY THING.

In the world of business, it should be apparent to any business that in order to be above its peers the customer satisfaction is above all the MOST IMPORTANT factor when it comes to priority. It is therefore hard for me to understand why the priority for UT is all over the place. I'm not mentioning the product because clearly it is a biased and relative concept but in my opinion Unity's idea of having the C# as high-level language is much better to allow users to become much more productive without having to dive into the enigma that C++ is.

I mean, the forum exists to connect the community but also to take any feedback from its users and learn, analyze and constantly shift priority to improve the existing engine but also satisfy the demand from its users with the likes of angry @chrisk .

 

That does not mean that less game released, its only means less games added to this list.

 

Yeah, I bet a lot of people are still here only for C# (at least myself). By the way, there is a post on reddit by Epic CEO Tim Sweeney, where he basically told that there were some internal debates about C# and other languages for the another programming layer. At least they were considering C# (along with other langs) as the language in UE4.

Honestly I don't see any advantage in Unity except the C# and component system. If UE4 will introduce C#, it will be unreal. Like, the transition will be very smooth, even there will be no component system (that I can understand). But if they will introduce another language, even their own, I will switch immediately too and I won't wait that year with Unity I promised for myself.

 

It saddens me to see anyone call the fine folks at Unity lazy or incompetent, for this is most definitely not the case. They are very competent and work very hard.

There are indeed problems, mostly due to some Faustian bargains made in relation to how many masters Unity wants to take on, and the trade-offs in their approach to moving the tech forward. Trying to be all things to all people causes a dilution of their efforts. Those making games don't give a rat's behind about automotive or film applications, and vice versa. And trying to do radical changes to virtually EVERYTHING in Unity, from rendering pipelines to the fundamental way you implement a game (DOTS) means 2019.2 and .3 feel like a really big incoherent mess.

But these problems are ones they bought into knowingly, with an eye towards a future that will ultimately make sense. The growing pains, however, cannot be denied. And the frustration of the core users of Unity is definitely warranted.

And yes, the fact that Unity refuses to dog-food properly is a serious strategic blunder, and I'm sure there are plenty of folks within the organization that know this. The fact that the freshest parts of their code base is always very well suited to the very limited demos they create and not to doing full-scale game development is quite telling. They de-prioritize extremely critical things (like camera stacking, usable off-screen alpha in HDRP, etc.) for games... because who needs that in a demo of a guy walking through a scifi movie set?

But none of this means the fine engineers are not working their butts off trying to pull it together. These guys are smart and hard working. And they care about doing it right. The institutional problems are coming, in my opinion, from some wrong-headedness at the leadership level, but it is mostly the case that I'd make different trade-offs than them given my own biases. They have other considerations where they sit. And that's just the way it is in anything like this.

 

Claiming they push the tech forward with DOTS and new ways of programming and that is the reason, we are in this state.. that is simply not true. They push nothing forward.
They could implement .net core, or .net 5 coming in 6 months from now that combines Mono, .net core and .net framework in a single runtime.
Which would perform on par with whatever their DOTS will produce. On current code! Nobody would have to rewrite their games!

It would also cost them less development time than trying to make their own DOTS runtime.

I get a strong feeling nobody dares to touch any old engine code, and they rather just kill the whole engine and start over but the new thing is not nessisary better.

Let's take this as an example:

The following code should do:
"Instantiate(prefab, transform.position);"

The "new way!":
https://github.com/Unity-Technologies/EntityComponentSystemSamples/blob/master/ECSSamples/Assets/HelloCube/5. SpawnFromEntity/SpawnerSystem_FromEntity.cs

Please tell me you are joking Unity, anybody will use this?

 

No this is not what that code does. If you give comparisons, please make them correct.
And no, .Net core would never perform on par with DOTS. Please stop talking about things you don't understand.

Will be .Net Core faster than Mono? Absolutely and it would be great to have it in Unity.

 

Does .Net Core have the same Mono scripting logic ?

 

They are both runtime and compiler sets for a C# language. Why should it have different "scripting logic"? And what do you mean by that?

 

You are wrong. The most crucial power battery of the tech stack is Burst which is a C# to IL to IR to machine code transpiler/compiler powered by Clang with LLVM (for those who are not familiar with how it works, I explained it a while ago here). There's no difference in performance between RyuJIT and Burst at raw integer computations. At floating-point computations Burst is ahead, but only because RyuJIT is lack of floating-point optimizations and intrinsics in that field. Comparing them face to face is not right, they work differently: one is designed to serve for the entire .NET ecosystem and supports a full vector of C# features, another is designed for facilities of Unity and supports only a subset of C#. CoreCLR and Burst can work in tandem, and this is what Unity is moving towards now, but only as a part of the new runtime for the tech stack.

The new .NET 5 with LLVM JIT comes to solve performance gaps. With recent changes, they got floating-point optimizations and intrinsics for math, and they already achieved a significant performance boost which brought the new JIT closer to Burst while it's still currently uses only just a few LLVM optimization passes, more will come in the near future.

Another power battery of Unity is the way they are approaching new subsystems of the tech stack: memory management, parallelism, and data processing. Nothing stops from doing the same in .NET environment, but at the cost of safety (I know people and companies who are doing that their own way, including myself). Unity partially mitigates this with built-in safety checks and high-level abstractions.

About two years ago I had a talk with Joachim where we discussed the future of Unity as a product, which going to evolve its own way independently from major projects of .NET Foundation (while Unity is a partner of it). My point was simple: make the single biggest impact by involving CoreCLR to the engine and solve the core problems. Eventually, all your customers will automatically benefit from that as well as your entire data-oriented initiative, you have the time and resources for that. You can't build a new high-performance stack in tandem with the outdated and slow runtime which is way behind the upstream, the editor and standalone builds are tied on it and suffer poor performance of the runtime with conservative GC in complex projects. As you can see, you probably will get it, but again, only for the new runtime which shaped towards the data-oriented stack.

Obviously, Unity is extremely interested in the success of the data-oriented initiative at the cost of customers' pain which is full of this forum.

 

I mean does .Net core require different logic like DOTS ?

 

It's not a framework like ECS. It's runtime and compiler set for C# language. You can use C# whatever way you like.

 

JIT can't be used at all on half the platforms Unity supports. The actual real-world comparison is between IL2CPP and Burst, not a JIT compiler and Burst.

Also one of the reasons DOTS code performs well is because it's structured differently than what you'd typically write with Monobehaviour-style code. Having a more performant JIT compiler than Mono won't fix the performance limitations of OOP.

 

And it's not needed, because a vast majority of the time you spend in the editor and with development builds. IL2CPP is used on the platforms where JIT is not possible and only for the final builds due to slow compilation time. LLVM-based AOT compiler will be shipped with the .NET 5 as well.

OOP limitations is a myth, OO can be approached the right way to achieve the same or even better performance. You hit the limitation of the poor underlayer design of the engine, not the programming paradigm.

 

Thank you for the interesting articles.

 

Aras is done with the Build team so maybe he'll jump in the "fixing all the things©" team.
Cross all the fingers©.

Cool! what type of game? Can share something, I want to see the complexity level, use of exotic stuff and also... what actually works in the engine these days. Reading everyone, it sounds like using this new (agile?) Unity is like dancing in a mine field.

Try out Rider, the debugger connecting is quite fast, on 100 lines of codes at least
Using nested prefab on 2018 is ... what's the nice word for "mad", ah yeah "courageous". Anything unity makes breaks gloriously for at least 2 years. You must be new to this

 

The replies here are very valuable, albeit emotional, but you must be aware of self selection bias.
I have no complex games in production, so I literally don’t know how hard it is to use Unity beyond the basic level, or how unusual it is vs competing engines.
I would love to hear more from people who shipped complex games and hear how they avoided land mines and about their general experience.

 

Unity is usually OK for your basic mobile game (unless it's a big complex one) but the High quality high performance Desktop multiplayer games we produce, it is simply not made for it, and it's a very frustrating ride.
We have around 200 GiB of assets, and it's simply a pain to work with.

I honestly wish we were not so invested into this title and into Unity, and I would choose a difirent engine today in a heartbeat. But once your heavy invested both in money and time, you cannot just switch engines.

I was excited at first when unity announced their Jobs system, and better multithread systems.
Then again the modern .net TPL is doing the same as jobs. And is probably better at it. So they just got overtaken by actual .net progress from the Opensource community. Besides as a multiplayer game server you want to keep your game on a single core, to run many intances in the cloud, but instead unity now creates 1 job thread per cpu thread, and the limiter of it is not even in 2018.4 LTS It's basic stuff like this that shows Unity is just not geared to professionals and what they need.

Lately unity lost all focus, they seem to produce alpha level quality features and code, that never gets stable, maybe declared stable, which it isen't. and seem to only push for fancy unite events with more amazing anouncements. But meanwhile peoples livelyhoods, game projects and companies are at stake. Maybe it is their way of cheap Q&A, just let your users report stuff. the problem is that whatever is reported and submitted to the bugtracker, rarely gets picked up, or fixed.

I would say that unity could move into an Opensource form of the engine, that would solve a lot of issues we are having, I know for a fact many of the companies that work on unity professionally bought the source licence, to fix the problems in unity themselves, most of that stuff rarely gets merged upstream. Companies are tired of waiting on unity. and it's just a pain.

Even if you buy high level support, getting your bug submitted, and handled is a pain, and waiting on unity to fix is, and getting a message "can you check this new version" and you can re-produce the crash again in minutes, it's just unbelievable. I don't even want to know how the guys here are handling issues that just have the Unity Plus subscriptions. There is just no way to get bugs submitted, checked and fixed efficiently.

Also think about submitting an issue, you have to extract pieces of your project into a new project, trying to make a small re-producable bug project, because you are not going to upload 200 GiB of project for a bug report. The whole system is just flawed. and you will spend a day or longer just to make it possible for Unity to pick it up, this costs valuable development time.

I get a general feeling that Unity simply went from being an engine developer company to an engine sales company.
It seems to me they employ more sales people, more advertising people, more managers than actual developers.
And it will kill them in the end. You can only sell this air for so long untill the truth catches up with you.

 

I prefer 2020.1 over 2019.3. It is much smoother to work with. Much of editor performance increase. Besides initial compiling time.

I am not trying being naive, to use every API Unity releases, knowing history of depreciations. Or should stay on same version of Unity otherwise. Trying reducing such dependencies, as much as possible.

However, since I do work with DOTS, I know it has massive capabilities. Is not necessary easy to work with. Neither is animations for your first FPS MMO game. But things are proved to be doable, by number of people.

It requires a bit of tinkering, to utilize tools for right job. Not to follow blindly like cattle and then keep trumping some echoes back, on forum.

Sure, Unity is not best in recent featuring APIs, neither are these critical to make most games. Maybe if you AAA studio? But is far from being unusable.

Clever people can find solutions an do things anyway. Rest will find reason to cry about anything.

Spoiler

On some side joke, some announcement on changing Unity version naming
Unity 20xx.y F changes from FINAL to other F word.

 

So basically you are saying "every one who has complained about the state of Unity is dumb" right?

 

If you upgrade Unity with .Net core, would PhysX API or some other API work from the get go?
Or will it need rewriting ?

 

That are not my words.
To be clear, I occasional also complain about things. But people most of the time are able point into solution, or alternative, if asked nicely. So is not the end of world.

 

That does not mean they have to invest their time to overcome issues that should not exists.
If someone Is not "crying" about situation may be he thinks that is normal or has high pain limit. Or may be he is just a sufferer or blind one.

By any means if he decides to put up with situation and moreover implIes that rest different kind of people are not clever does not make him smart at all.

There is definetly a bad "situation" with engine policy right now and many people are speaking about it. And if you decide to put up with it and even approve It it is just your policy. But you should not Imply that if someone does not tolerate something and says about it is not smart and just crier.

 

@konsic,

Mono, .NetCore, .NetFramework will be unified into .Net5 and you will have a choice of Runtime (Mono or CoreCLR).
We are just talking about migrating Unity Editor to .NetCore. and you can choose Mono for your runtime if you want to ensure your current game is unaffected.

Therefore, PhysX and all runtime components should just work if you choose Mono runtime.
And .Net5 which is due 2020 November should be at feature parity with .Net Framework, and Mono can be erased forever.

Here is more information. https://devblogs.microsoft.com/dotnet/introducing-net-5/

 

These days, I only use the LTS editions. I'm fine with sticking to 2018 LTS for a while, but when 2019 LTS comes out I will migrate.

I really like the LTS concept, but I don't think it gets the star treatment it deserves.

 

Currently working on a project that is sitting on 2019.2.0 and we're not having any major problems with the engine. We're using the new HDRP and I'm working on getting us to the new input system but beyond that we're not using anything else that might be experimental.

How large is your project? We're growing at a steady rate with the project itself being 46GB (Library is 19GB).

 

Yes it's late. And that's the problem. 2019.3 should have been released by now according to their own timeline. Previous years' 201X.3 releases were already released by now. But we're 10 days away from the new year and 2019.3 is still so buggy that it has been delayed until next year and people are expressing their surprise that something so buggy could be considered out of beta, much less a release candidate.

On the one hand, the delay seems very necessary to improve the engine before the official release. On the other hand, it seems some features should have been left out of the 2019.3 release and delayed for the 2020.1 release to allow more time for them to stabilize and mature rather than hold up the timely and stable release of 2019.3.

I'm also concerned by how many Known Issues still exist, even in the LTS releases. In my opinion, emptying the list of known issues should be top priority for each subsequent patch release, especially for the LTS versions.

 

I just did a bench test for a friend who wanted to see how scalable Unity is nowadays. To do that I duplicated this 144+Hz test scene 31 times and the results are pretty darn good. 10s of millions of polygons, 1700 monos at 42Hz.

It's leaps and bounds what we could do on mcdroid in unity 4.6!

Standard PBR renderer is dependable and deferred mode it's fast enough. Maybe it's due to Amplify's impostors, don't know don't care. Given how unoptimized the code is there is margin for improvement.

Nested prefabs haven't corrupted a thing, which seems obvious but back in the days, prefabs were breaking all the time. Also new to me: not a single crash.

Compile is fast - domain reload though...

So far, in proto stage, I'm happy with this release.

I'd like to hear your experiences with entity, my hunch it'll be rock solid soon - to the entire core team is on it.
I'll stir clear from the rest of the new stuff though because I want to release.

 

Something has changed in Unity

We can debate about technical dev stuff like HDRP, ECS, DOTS, .NET all day but I think @Vincenzo was the closest to reality here.

 

Well, yeah:
• Unity:

• Subscription ($35/$125/month, soon to change to $40/$150/month);
• Makes more money the more paying users they have: Make a usable product for beginners — enough to get them to pay for the dark skin — but don't bother a lot with stuff past that;

• In many places you look, you'll see that many people don't seem to realize Plus exists, so they keep whining that the dark skin is $125/month.​

• Market to suck in as many users as possible.​

• Unreal:

• Royalties (5% per quarter over $3k);
• Makes more money the more successful their users are: Make a good product to suck in good users.​

Really, I much prefer Unreal's model. The engine is completely free for every quarter where you make less than $3k, at which point you can afford to pay 5% royalties: 5% of 3000 is 150.

 

Which is almost four team member's plus license cost if you're an indie... So it depends. Sometimes Unreal's royalty is more advantageous, sometimes Unity's fix cost is better.

 

Does anyone remember the transition from Unity 3 -> Unity 5? That transition was painful, I'd say even more painful than the current transition but the result was great. Unity 5 onwards is undeniably better than what they have in Unity 3/4.

I'll be sticking with Unity as they are always improving and as a result always improving the games I can make.

 

There was a period there, somewhere around 4.6 (IIRC), where for like a year or two the bugs were so bad it was practically impossible to publish without going back to a much earlier, stable version. Which is why we now have the LTS system, which I really, really like and approve of.

I'm sticking with 2018 LTS until we have a 2019 LTS. Considering where they are at right now, if I was in charge, I'd strongly think about taking 2019.2 and making that the final release for 2019, and start making a LTS version based on it immediately.

 

The problem there is it would make DOTS and SRP unusable in LTS. I'm all for 2019.3 taking as long as it takes, but the LTS really needs to be 2019.3 or it creates much bigger long term issues.