I see a trend where users/customers are increasingly accepting responsibility for bugs in the newer Unity versions.
How much time is wasted when an unfinished/broken piece of software is released to the masses? Countless hours of tracking problems and voting up for which bug should be dealt with first by the users - all of who have their own tasks to complete.
Unity is a pretty good at what it does, as an all-in-one development software, but the 3.x series was definitely a superior product IMHO.
Hmm, can’t compare to Unity 3 because I never used it, but I don’t think I’ve run into a Unity4 bug yet. Nothing substantive anyway. What do I have to look forward to? =)
On one hand I agree, things should be perfect before they’re passed on to customers.
On the other hand, I accept that the above isn’t actually practical, and also that there’s huge advantages in making things available before they’re “finished”.
Lets take Mecanim for example. It’s an awesome tool, does great stuff, is very useful as it is. But also, there’s a lot of stuff that it can’t do that’s actually common use cases in standard game development. As a result, I’m doing a lot of work “around” Mecanim to get what I want done. Does that mean I wish they hadn’t released it? Hell no!
First, if they hand’t released it then the people who it is currently good enough for would have… nothing. And it’s current out of the box functionality does indeed save plenty of time in quite a few real world use cases. So why deny those people its use just because it doesn’t suit other people with different needs?
Secondly, putting it out there and seeing what people are trying to do with it shows the developers what the real world shortcomings are, instead of relying on guesswork and imagination about what the shortcomings might be.
Thirdly, it still allows me to do stuff that would have taken much longer were it not available. I’d rather have to employ some workarounds (which Unity support are actively helping me with) to reach my goals than have to start from the ground up. Total time to completion is a far more important statistic than whether or not there are bumps along the way.
There’s always a risk when you’re using “bleeding edge” technology. If you can’t take that risk then it’s best not to jump on new things immediately upon release.
Well, software is never really in a finished state, and I understand the need of getting user feedback for current features and future directions for those features for sure. However it is also quite a bit of a rub to have a feature marketed to you in order to get you to spend real money on an upgrade only to find it isn’t quite fully baked… and sometimes these features never get fully baked.
And we’re not really JUST talking about Unity here… this happens pretty much everywhere. All you can do is read marketing materials with a skeptical eye and take your chances, and not get too upset about these things.
a) We ship an alpha to a very small group of customers who we know are actively going to use the new version. We seek their input typically on usability. When the alpha group are positive then:
b) we ship a beta to around 1000 customers. These customers (are meant to) provide bug reports to allow us to fix bugs. Once these bugs are replicated and fixed:
c) we declare a release candidate. This is just a wake up call for the beta testers that if they have issues, then they need to let Unity know yesterday. Assuming we get no further bug reports
d) we make a release and push it to the website.
So, in a sense @Zenchuck is 100% right that customers help us find bugs.
Now, to answer the obvious question:
“How do I get on the alpha and/or beta list?”
Once you have a track record of submitting good, reproducible bugs, and you are a familiar face to our QA team, get in touch.
Need to get some Windows Phone 8 / Windows Store Apps users on that beta list. I’m getting a lot of support requests for the WinRTLegacy.dll changes in 4.3.3 and 4.3.4 that are impossible for me to code around and the answer from the Unity devs is to copy the WinRTLegacy.dll from 4.2.2 into your new installation and use it instead. And since there’s a “workaround” it won’t be fixed in the 4.3.x iteration (also according to the Unity devs).
The alpha and beta programs are great… I was in the original WP8 Beta and it was a very communicative group. One suggestion I would have though is to make sure for version upgrades both the Alpha and Beta groups have good cross-platform coverage. My JSON .NET asset would also be a great one to use for testing because of all of the low-level reflection work it does.
I just tried an alternative to Unity today. After 4 hrs and almost no progress - I’ll stick with Unity. While not perfect - it is still by far the most accessible for the programming illiterate like myself.
I’m getting a lot of support requests for the WinRTLegacy.dll changes in 4.3.3 and 4.3.4 that are impossible for me to code around and the answer from the Unity devs is to copy the WinRTLegacy.dll from 4.2.2 into your new installation and use it instead.