Please Unity, slow down.

I never thought that one day I could ask such a thing to a software vendor, but please, Unity, slowdown!
Here is what it feels like when using Unity 5 :

Each 5.X update is like the Doc's colored logs exploding in the locomotive. It goes faster but the locomotive falls apart.

I'm using Unity since version 1.6 and it has always felt stable and under control. But, since Unity 5, I have the feeling that the software is going crazy. I'm always walking on eggs, going around bugs and inconsistencies, dealing with features going on and off or with complete changing behavior, being disappointed by major features with poor implementation (like GI) and for the first time I'm really scared as my current project can't follow Unity's development because of a broken feature!

So please Unity, slow down your development process and take some time for stabilization because it's much much needed, or your locomotive will fall in the ravine!

 

Actually, we have. The releases may be moving quicker, but development is taking more time and care. The difference is we're releasing the current progress all the time. It has also taken us some time to get on top of some areas and issues, but I suggest that you should be able to see a constant improvement (granted with minor trips) since 5.0.

 

5.2 was such a mess, hopefully it'll go better from now on. Have you though about something like nightly builds for the betas? New builds once a week is kinda slow, especially since they usually have some dealbreaker issues that are spotted instantly and fixed 1-2 weeks later.

 

What if we disagree? 5.2's UI is far buggier than 5.0's. Also, what may seem a "minor trip" to the devs can make a build completely unusable to a user.

 

Since 5.0 was released way too early, 5.1 was a huge improvement, there is nothing to say about that. It still has many flaws but I was definitely able to work with it. But these 5.X minor versions updates act like major upgrades as they delete and add too many big features, something old that has finally been fixed gets replaced by something new but broken. The 5.2 update can't be used for my game as the reflection probe controls has been broken, there are also many problems with the trees. The 5.3 also begins nicely as it still carries the old open bugs and add new ones like huge display bugs, and I've only used it for some minutes. Switching to different 5.X updates feels like switching from v2->v3 or v3->v4. It introduces too many problems and changes in projects and too many old bugs don't get fixed. I really think that those 5.X updates are too frequent and introduces too many inconsistencies. Slowing this down a bit could certainly be beneficial. More time should be allowed to release the much needed 5.X.X updates.

 

A mess how specifically? You have to give me a lot more to work with. Can you give me specific bugs? We were more transparent with a number of issues and need to know specific things to work on specific areas. We can't lift everything simultaneously. A number of folk were quite happy with the release, but I've also heard folk with complaints, however I don't have a specific measurement swaying it either way.

We've also post-mortem'ed 5.2 and discovered some communication chains and areas to address. Some bugs got lost in processing and weren't elevated appropriately. We're already in a better position for things with 5.3, so let's see how things go.

Regarding nightly builds... you're complaint of timing between seeing a bug and when it gets fixed is a separate issue - we're also working on improving that. However, there's a number of things to be considered in that. Often a fix is wrapped up with other work and comes together in a bundle at a later time. Plus, there's the usual catch that a fix has to be tested across many platforms and tweaked to get it working across everything. This just simply takes time.

 

So, UI is one area we are working actively to shore up on our automated testing. The problem is that it sits on top of so many other systems (graphics, events, inputs) that are also fixing, tweaking, perf improving at the same time. I'll just leave it at that we're actively working on it.

Edit: I feel like I should make sure and credit the UI team though. They've been slogging through bugs since _before_ the 4.6 release. For 5.2 they addressed some deficiencies and performance issues - but otherwise they've been just on bugs for more than a year. In addition, fighting all the changes between 4.6 and 5.x and navigating getting the changes across.

 

Alex please see this issue, I know its not related to 5.3 specifically but the fix will be included within 5.3 as the developer has mentioned:
http://forum.unity3d.com/threads/unity-5-2-ios-performance-issues.353646/
This is very long time to wait for a urgent fix like this, anything that impacts performance should be marked as top priority. I think what the original posters and others are saying is Unity moving fast with new features and releases but the stability has suffered as a result. Many performance related bug especially with mobile and its just taking to long to fix some these crucial ones, we all waiting each week for a specific fix (especially mobile related ones) and UI.

 

I can understand and sympathise with all those who have suffered pain during the 5.x cycle so far.

But I don't think they should slow down or become far more conservative with their release cycles and features. I don't think that being much less ambitious with 5 was really an option, because a lot is changing in the wider world in terms of graphics API's, VR, browser plugins etc. And there is more competition in the game engines/tools/services world, and changing ideas about monetisation. I really don't think Unity could afford to go slower on these fronts at this point, without ending up too far behind, or unable to implement their latest vision for services offered by Unity.

But I'm aware that any sense I might manage to make when describing those fronts will not necessarily be of any comfort at all to those who have suffered from bugs that have been showstoppers for them, and sometimes explanations are seen as excuses which antagonise further.

Nor do I expect the following suggestion to be greeted with universal applause, but I'll make it anyway. I hope Unity manage to improve some of these things over time, but I don't expect them to suddenly become orders of magnitude better at squashing all the killer bugs in a timely manner. So users of Unity have their part to play in minimising pain too. For some this may mean becoming more conservative with what version of Unity they are using to develop specific projects, sticking with older versions longer until they know a particular issue in newer versions has been solved. At times it may mean becoming more adventurous and inquisitive - for example some people are probably averse to trying patch releases, and I don't know what proportion of Unity users read the patch release notes every week.

 

Answered in thread, but short answer is - please don't jump to conclusions.

 

Yes but the problem is that you can't sustain the race if everything is falling apart. You can't build something if you are not on solid ground and right now Unity 5.X feels a bit like quick-sands. I've never had this feeling with 2.X, 3.X and 4.X that's why I wanted to ring a bell.

Solution like being conservative and sticking to an older version are fine but can only be temporary. The game I'm finishing will have to be released using the 5.1 version as it's completely broken in newer versions. But what will happen when I will have to make it compatible with VR headsets which will be supported in future unity versions if the showstoppers bug are still there? Trying other versions of Unity can also be a very long process, the project conversion process can take a while. A version might have the bug fixes that you were waiting for but can also introduce new ones that can be worse.
It's also stated that the bugs of current Unity versions are treated with higher priority. So what's the chance for the bugs reported from unity 4.6 and still present in 5.X to be treated?

Maybe alternating a feature-oriented update for even version number and a stability update for odd version number could satisfy at the same time users waiting for new features and users waiting for more stability? But finding the right balance is always easier said than done.

 

Actually, we are already - by team/developer. Though to be fair, we haven't all converted over yet. Some teams have just been fixing bugs since 5.0, while others are having to deal with platform changes (Win10, etc.)

We've been aiming that if a feature comes out in say 5.1, that 5.2 they're only addressing found issues and other bugs. They can submit for 5.3 again. We have got some systems to pretty clear bug queues, and just lists of "needs updating", "deficiencies", perf or otherwise.

So, I'm sorry the features you're focused on are still in flux. We're working on stabilizing those, but often peripheral areas halo into them. As I mentioned before, stabilization is in-route, however keep in mind it takes a little time and such to re-build the foundation. As elbows mentioned, waiting between versions is a solution. In fact, it's what most people did since Unity versions were far between and you didn't have much choice. We've switched to a constant-progress-type release and you're seeing our growing pains. So, you're free to wait out aspects of this, or join in to help us address it.

 

Ok, this is a relief to see that behind the scenes the situation is really being cared of. So if the stabilization operations can catch the speed of the new-features operations, Unity is promised to a brilliant future.
I was really worried because the more the new versions were released the more my bug list was growing. Also, after one month now, I still don't have any feedback from Unity about the two showstopper bugs that I have encountered so that's not reassuring (726588 and 727234). Another 1 year old bug is still there (643713)

 

Glanced at the bugs - all graphics affiliated. 727234 though is valid though not exactly a bug per se (really just a valid critique...). Bluntly, graphics is an area we need to catch up on the bugs, but part of the reason is the team has been doing heavy refactors in areas to make things better for the future for stability _and_ improvements: for example the unified OpenGL, or multi-threaded rendering. So, all I can offer for 726588 and 643713 is that they're in the queue, but not yet addressed.

 

please unity, don't slow down. considering all that unity is, which i can't, but the small amount i can see is INCREDIBLE. wish i had it in school so much.

 

I feel much the same way as F-R and am glad he posted this. You can read my latest horror story with patches here (post 13 is where I got a little steamed):

http://forum.unity3d.com/threads/performance-drop-in-vr-on-unity-5-2-0-and-later.358784/

This kind of thing has happened before, this was just the first time I actually ranted a little in the forum about it.

I skipped the 5.2 beta just because I didn't want to deal with that type of headache again after 5.1 beta. That first 5.2 version release is good on my project (a little slower on the VR side, but still good enough), but about every patch since has show stopper problems for me. This includes several of the 5.1 patches and virtually all of the 5.2 ones.

I spent a good day and a half just trying to figure out which version to settle on. Eventually I chose 5.1.2p3 which is excellent in my project. I really wanted 5.1.3p2 because Rift performance is the best on that one, but it completely breaks my game. I also tried the 5.3 beta, but stopped almost immediately even though there is some really cool new stuff in it I'd love to use. I look forward to a very stable, sufficiently bug free 5.3.

From now on I'm probably going to do the conservative thing Alex described and just stick to the major releases and skip all the patches. It just feels too much like I'm using a beta even when they aren't beta versions. When I'm using a public version I don't want to be a product tester, I want to be a paying customer with a solid, well tested and reasonably bug free product. When I want to be a tester I'll run the beta. I tried at least six different public versions the other day and only two of them worked well (or at all with a couple of them) with my project.

Updating to a non-beta patch has become a downright scary endeavor. Beta should be fast and scary, public releases shouldn't. As F-R said, please slow it down some if that'll help.

 

I don't want Unity to slow down. They need to keep the pace up. Yes, there will be pain, but the pain doesn't last. It seems like it will to you, but these bugs are getting killed and the number of new features are reducing. Keeping the pace up is pretty much the way Unity will stay in business.

It's just 5.0 required an abnormal amount of refactoring (changes) - this isn't going to be the norm so logically increasing stability is going to happen.

 

So, I'm confident in Unity's QA team, and let's hope that 5.3 will be the version where Unity can finally be considered stable and that everyone stuck in the previous versions can migrate safely their project.

Now I have some questions and suggestions about the bug reporting process.

Would it be possible to unify what's happening behind the unity bug reporter and the issue tracking page on Unity's website? The issue tracking page doesn't have all the reported bugs so that doesn't make it as useful as it should be.

The fogbugz interface could be improved. I think it's lacking some features like, editing the report, downloading attached files and most of all it lacks the ability to directly add a message or communicate with unity QA. You can answer by mail but I don't find it very convenient. I just made a mistake yesterday answering an email about another problem without even noticing. It also happens frequently that while intensely working on something I find a bug and make a quick crappy and incomplete bug report with all my anger, and the next day, I want to take the appropriate time to improve this report. So an editing feature would be useful.

Also, sometimes bugs are treated and solved in a 48h timeframe and others are never treated. Would it be possible to have a quick feedback each time a bug is reported? The people receiving the bug reports could just select in a drop down menu if the bug is receivable and an estimated timeframe of when the bug will be addressed (something like Not reproductible/need more infos/Planned to be fixed in version X.X, etc). And if a bug isn't fixed in the estimated time frame it would then automatically gain a higher priority.
Some sort of "bump" or "up" buttons on bug reports to raise attention on a forgotten bug can be useful too.

Some bugs are simply annoying or can be worked around but some others can ruin a project. When reporting a bug it could be useful to have a "showstopper bug" checkbox to tell that a bug is more important and should be treated with more care.

I've heard that owners of pro-licenses have a better access to bug fixes. What does that mean in practice?

 

First of all, all of the 5.2 beta versions had problematic known issues / immediately discovered issues that caused me to skip all of them. Stuff like editor crashes and corrupted prefabs on common actions, which I immediately know would make it not worth it to upgrade and test our project. I'm willing to do beta testing and report bugs, but if I know beforehand there's a serious problem, I won't bother.

I finally did the upgrade with 5.2.1p3, until that it was mostly UI bugs (Iike the default white sprites in image components missing, performance problems and memory allocations, API changes that forced us to wait for TextMesh Pro updates) that kept me away.

I'm under the impression that the transition from "when it's ready" to release dates caused problems with 5.2, as it seemed to be the messiest release I can remember since I started using Unity. Obviously you could've used some more beta releases, which is why I was wondering if something like untested nighly builds or alpha versions would be feasible.
There might be a single bug that keeps me away from new versions until it's fixed, and that usually means at least 2 release versions that I will be skipping and thus not testing and sending bug reports from. Also, sending bug reports from older versions seems pretty much worthless, even if the bugs aren't fixed in latest versions.

As a related note, I think the bug report process in general needs a lot of improvements. Here's my thoughts about that: http://forum.unity3d.com/threads/improved-bug-tracker.339570/

 

Lots of great ideas here.

 

I'm stuck with 5.1.1 since it just works for me. What concerns me is the backward compatibility with existing assets.

As an asset developer I would like to have some automated tests published on your cloud builder infrastructure and let them run automatically with each new beta. You can get a great preview of what you can be breaking out there...
And we can provide a great QA powerup with this collective and massive number of test suites. Just give us a QA tool for uploading assets and tests...

 

Hmmm... no mention of the "Insert bacon, receive bugfix" method of getting bug fixes? So strange

 

i've personally found unity to be more stable since 5.0, while things like GI are a bit shaky. people are acting like unity was perfectly stable before. i remember tons of bugs that have gone away with 5. if you know what you're doing with 5(and no its not as simple as it should be) i've found more stability. it handles way more complex scripting, renderer is more stable than ever, less API holes/black spots and almost all the new features are well implemented with the exception of reflection probes and GI being still really limited(GI is shaky and reflection probes are still don't give you enough control). and frankly, have you tried other tools? ue4 can't go 15 minutes without crashing, that's not counting the API holes, bugs and awful performance. if your hitting tons of bugs its probably you should prolly look at how your using unity more so than just blaming unity. while i would love a bug free software that just isn't realistic. some patterns to keep in mind Component Based Design, Pooling, Minimal Allocation, Modular coding in general. etc...

 

Transparency has definitely improved, and I applaud the weekly patching because if nothing else it provides hope that our issues might get fixed within a reasonable timeframe. Forum communication has also improved significantly. Compared to where we were with the early 4.x cycle, I don't want to return to the days of infrequent updates and zero communication. In those areas, Unity has most certainly delivered.

However 5.x has been a painful experience with widespread negative impact. The adage of "99 bugs on the wall [in Unity], 99 bugs to go, take one off and push the fix, 127 bugs on the wall" sums it up well. The same was true for 4.x. The need to innovate and remain competitive as a business doesn't usually sit comfortably with the goal of stability, yet a balance must be struck.

We've not been able to update the public build of Folk Tale in Steam Early Access now for several months, firstly because of the fatal DirectX 9 bug (SetResolution) that raises questions over automated test coverage, and now potentially a memory leak in the 5.2.1p3 C++ code (bug reported). Instead, we've been updating an opt-in experimental build and caveating the known issues. Also, the Unity Editor crashes almost every time after exiting play mode on Windows licenses, and has started crashing during compilation on OSX. Far from ideal, but if we continue to report bugs and communicate the issues to UT, they should get fixed.

I do question how effective impact analysis and product backlog grooming currently is, given such a massive bug as DX9 could go unfixed for so long. I fear Unity3D is getting too complex, with too many platforms and too many features, presumably making maintenance a mare. Coupled with the amount of noise 0.5 million active customers must generate in bug reports, it must be a challenging environment to work in. So fair play to Unity as they transition into a new way of working.

From a customer perspective, three down (patch frequency, communication, innovation), one to go (stability). Keep up the good work.

 

This is basically how I feel.

 

On a separate note, why is Unity developing a json serializer when jsondotnet by Dustin works fine on all platforms and is superior? I though the team is overloaded?

 

Well, I think every or most of projects today needs to persist some kind of data. Bringing native support to JSON is IMHO something very basic and obvious.
There's no problem to have improved/extended JSON serialisers on the Asset Store. Existing projects will still work and you will have the choice to go ahead with the standard JSON support from Unity or use another library.

There're some other assets that are on the verge of what should be included in Unity framework or not. SSRR or TextMeshPro comes to my mind for example, or even some patching solutions.

 

Comparative to everything in Unity that needs fixing, I think JSON is a pretty lowest priority, considering that there are third party solutions which work, and work better. I like to hear why Unity thinks JSON is pretty important, compared to JSON.Net.

 

btw, I've used the package of Dustin, and it's pretty awesome.

 

I would suspect that Unity needed JSON built into Unity for some of their other recently added services, so with that done it made sense to make the API more widely available inside unity.

 

Not sure how the JSON topic fits into this discussion. However, Unity is using JSON as well and it was part of Unity since at least a few releases, but was not a public API if I remember correctly.
It simply makes sense that Unity provides a data serialization format that can be used at runtime. It is not too unlikely that they have further plans with it and want to use it themselves in different areas. Even if that is not the case, I don't think it is worth a discussion, because it doesn't have a noticeable impact on the overall development progress.

 

The JSON strand of conversation does provide the opportunity to point out the obvious problem with a lot of the complaints. Like the weather, its a personal and local thing where human brains can get the perspective a bit wrong, muddling their own experience with the wider picture.

eg a bug that affects someones project badly may be a showstopper to them, but won't bother some other people at all. And a feature that some can't see the point in being developed now may be considered crucial or at least very useful to others.

Not always of course, and plenty of people get the perspective right too, but we are less likely to hear from them.

 

What Unity needs is getting more useful features while getting rid of useless ones, like the Animator Parameters window and legacy particle system and the old GUI and deprecating some classes and simplifying the API.
I haven't had a bug in the 2D tools since their introduction in 4.3 except the OnCollisionXXX2D bug, same for Navigation, same for Frame Debugger, same of LODGroups, same for Substances.
I would still want a buggy 2D character animation system without FFD over none at all (ie, if it won't break the Sprite Renderer for 6 months of course).

 

We haven't. Not by any means. 5.2.x is an outright disaster in that respect.

 

We shouldn't be seeing your growing pains. We, as paying Pro customers, are not your QA department. You're simply doing a bad job - sorry for the plain speaking, but you are. There's something fundamentally flawed with your development process. Get it right, or see people leave.

 

Well, we are not their QA department, but I for one am really glad that I was able to influence (in tiny ways) the development of Unity with my bug reports (Which were things that were corner cases and/or specific to my workflows, which I wouldn't expect the QA to catch) and/or reasonable requests.

 

feeling like QA, that's the nature of participating in beta
also glad i get the opportunity

 

I'm sure they do. What's wrong with using a proven, almost industrial standard solution than to develop a half complete version?

I'm sure the engineer working is an experienced developer, and it took at least 50 man hours, so I'm sure there are many low lang easy to fix bugs that are long ignored that could be fixed in that time.

 

Almost industrial standard doesn't mean it is an actual standard. That's exactly what makes it difficult in some situations. It is not uncommon that I use it, but whenever I work with others, I have to be careful, because they may not yet have a license. So I can't just share my project with them and I am also not allowed to put it in a public repository, even if it is so standard.

The time is well spent in my opinion. I will never understand why customers have the impression that they can think about any kind of micro management, because it is usually not possible to understand the reasons behind such decisions. It is especially not possible for us to know whether the people who worked on such a feature know the code base well enough in another area to be able to resolve easy bugs there.

 

I don't see the problem with keeping the older systems around, especially if they have advantages over the new ones. For example, the legacy animation system is easier to set up, more performant, and less bloated. This allows programmers to easily set up their own animation systems without the repercussions of the new Mecanim animation system.

Another example: the legacy GUI system is notably easy to prototype with. GUILayout.Label is much easier than going into the scene, creating a canvas, creating UI text, getting a reference to that UI text during runtime, then adjusting the text's value.

A complicated API is not Unity's problem - the recent lack of stability is.

 

I completelly agree

 

Glad to know you are not reinventing the wheel. I see it's a C++ solution, so I guess there's no reflection, that's why enum and Dictionary are unsupported. It's good for your internal use at C++, but I will continue to use json.net.

I never saw an issue with garbage collection using json, there are much bigger areas to fix.

 

Ah, that makes sense. Deprecated Unity systems don't seem too tightly coupled though. Except for legacy GUI, which is used by the inspector. Do you guys often have to maintain legacy features?

 

Unity's serialization API can be used for enums and dictionaries, just like in the editor. It is good in my opinion to make it consistent like that. This kind of functionality is very welcome in my opinion. It is important from my point of view to regularly have a look at such basic features and to improve existing ones.

Let's face it, there is always a more important area, no matter what Unity or any other company does.

 

That's exactly what I meant in my first post, I was thinking from a developer perspective. But we users can also benifit.
For example:

• AndroidInput
• AndroidJavaClass
• AndroidJavaObject
• AndroidJavaProxy
• AndroidJNI
• AndroidJNIHelper

-These classes are stuffed full with static methods and functions that better be left for 3rd party plugins, and we still have API specific of the 2011 Sony Xperia Play.

• HumanBone
• HumanDescription
• HumanLimit
• HumanTrait

-What's this? who wants to build a the Avatars muscles in code.
-Not to mention the 20 new namespaces in the last cycle alone many of which have fewer than 3 classes or structs.
I used to remember all the exposed API back in the day, now I'm overwelmed.

Jp I didn't remotely suggest removing the old animation, between the two Mecanim is the one that should be removed (all the humanoid crap except the state machine and animator window, that's done outside).
Plus can I ask you where you get that Stabil-o-meter of yours, I didn't have any crash at all but on the other hand performance is perhaps an issue

 

There has been 0 new features since 4.3 that are more important to me than having a stable code base. ZERO

Stop introducing new systems and depreciating old ones and prioritize actually fixing the existing systems before building new (buggy) ones. None of us want to keep learning Unity's complex systems only to have that system depreciated (UI, animation are two relevant examples) and then needing hundreds of hours to get up to speed in the new system. How many thousands of dollars should I invest into Unity if it never stabilizes? Why should I spend hundreds of hours learning and mastering your systems to just have those system become depreciated? It's like when one of your subsystems starts to get relatively bug free, you guys introduce a crap ton of new unstable features into the "stable" branch, so we never actually get a stable branch or anything even close to one. You guys should bring this thread up in your next meeting, because whenever I talk to other gamedevs about Unity I recommend against it because of these exact stability/feature creep issues.

I'm looking back at Unity 4.3 and thinking I might as well start any new projects on that and keep it on that forever, because I haven't had a relatively stable Unity build since that time period. Also the performance costs of Enlighten compared to it's visual fidelity doesn't appear to be worth it.

I would like to see Unity adjust it's release model. There should never be testing or incomplete subsystems live inside of a supposed "stable" release. Unity should get rid of this hard deadlines for "stable" releases and switch to a STABLE and BLEEDING EDGE style release cycle, so that all this new unstable crap can go in the releases where it belongs, and all the stable, relatively bug free code can sit around for a year and provide developers a stable, mostly unchanging branch so that we don't always have a moving goal post.

As a PRO customer, I'd like to see Unity's development achieve stability, but I don't think the current release philosophy is capable of producing a stable build, and therefore when my PRO subscription expires I will be moving future projects to a platform that does actually provide stable builds instead of constant experimental builds.

 

Do you expect that anyone will read that or that anything useful will come out of such a post?