Stumbled across this one here today: http://darkgenesis.zenithmoon.com/get-prepared-for-unity-5-the-dreaded/
A little concerned about: “Unity3D V5 is still a way off (might be this year but more likely to be early next year – MY OWN VIEW!) so you have time.”
I’m loving it! Thanks for sharing.
Thanks for the optimisation tips.
For Unity 5 i think they have it working already, they shown global illumination working on mobile already, i think it won’t take too long to make it enought complete and stable for a public release.
That article has a strong linkbait-y vibe to it. The only real bit of information in there is the author’s claim that convenient access properties like rigidbody and collider will be removed. Not deprecated as has been the case in the past, but outright removed, with some sort of VB6 to VB.NET conversion wizard poly-filling over it.
I suppose it’s possible, but seems improbable to me. Even if it’s true, then it’s more “insider information” than “insight.”
I actually like that idea. And I did notice that there’s no convenience “animator” field on MonoBehaviour.
To be honest I’ve never liked those convenience fields (aside from gameObject and transform, given their relationship with the script), in so far as I’ve never understood the need for a bunch of variables pointing to things that usually don’t exist. If you’re going to use them you need to check that they’re there anyway, so that may as well be a GetComponent<…> into a field you define yourself.
According to Aras, this is not a big deal, just a syntax change.
It’s more or less random whether the “shortcut” properties exist for any of the built-in components. Removing them (except for Transform, which always exists) makes things more consistent and less confusing, as I can attest to after answering many questions about this over the years. The article isn’t particularly accurate anyway, as noted by Aras in his comment.
–Eric
Yep, it also clears up name collisions quite a bit, so you can just name some renderer component “renderer” without worrying about that name already being used by Unity.
? Why do they keep the transform shortcut?
To be honest, the information is pretty hidden in the manual. If I remember correctly you even have to click on some “show” button to see it. It should be on top of the manual but instead this bad style is propagated everywhere in the examples of the manual.
Because you can’t have a GameObject without a transform. It’s always there and is guaranteed not to be null.
I can confirm this change it is going to happen. The reason is not only consistency of API (but that is a big one, currently it is very random whether a component type has an custom getter or not), but also enabling better modularization of code. Ie, by having these accessors, we have hard coded dependencies from MonoBehaviour (which defines these accessors) to other subsystems like Physics (.collider), which is ugly and makes code less stripable (think build sizes).
Hmm, I understand why UT would do this. The change is more explicit and simplifies things considerably. However it does have two negative side effects.
Firstly you get much more verbose code to do the same thing. Counter to the above arguments this makes it more prone to error and harder to maintain. It also doesn’t force anyone into better coding habits just because it’s convenient to hope so.
Clearly there’s strain showing between the existing object system of Unity and a flat non OOP front end now. Both should have changed rather than just one, at least GetComponent should be extended to replace the use of fluent interfaces in C# so you could just go
component = object.GetComponent<FirstComponent, SubComponent, SubSubComponent>();
Secondly it’s far less beginner/user friendly, it’s less “discoverable”. Niceties like autocomplete cease to be workable. That’s a real shame as for most human beings (i.e. people who don’t prefer VI or EMACS, so the kinds of folk that would use Unity in the first place) visual autocomplete operates both to speed up typing and as a contextual help/search to see what’s related or available for an object without resorting to the full documentation.
Of course the Unity API is already fundamentally broken in that regards however I tend to err on the side of fixing things is probably preferable to ditching them, especially when it comes to useful things like core concepts of OOP (not everyone wants to go back to pure C nor views it as the ideal).
As a developer I see the worth of the change. But as a user I worry that small changes like this do mount up and over time make it harder to justify the proposition that Unity is the user friendly option. Once that’s gone I’m not sure exactly what the unity “value add.” is.
C# as a language is much more friendly to beginners as a whole, especially considering C style shader languages. There comes a time when you have to cut the fat or the engine will remain excessively bloated, hard to support and inferior. Even OpenGL had to start deprecating to move forwards, if it improves the overall engine then a slight increase in verbosity can be forgiven.
A welcome change in my opinion. I like when things are consistent.
Not really a big deal but i guess you would to update all the code from the asset store to make it work with unity5. Could be a pain in the ass.
There’s absolutely nothing to stop creation (or even inclusion as a standard asset) of something that addresses the issues you’ve raised, and it could quite possibly do so in a superior manner. If I had been tasked with solving the issues as a designer I very much doubt that my recommendation would have been “add references to MonoBehaviour”. In fact, I’d have avoided that for precisely the reasons the Unity guys here have cited.
As for core concepts of OOP, doesn’t this change improve that? Encapsulation immediately springs to mind.
I’m not really understanding his problem, you can just do it this way can’t you?
GetComponent<Renderer>().GetComponent<Collider>().GetComponent<Rigidbody>().angularDrag = 0.2f;
I mean this is a little longer, but it’s not 4 lines of code long. That’s what’s going on behind the scenes anyways right?
I suspect that the 4 lines is coming from also assigning the thing to a locally cached variable (which many users recommend doing anyway) and/or checking that it actually exists (which I think is a good idea to do anyway).
Not that you’d ever chain GetComponent in the first place, or rather you shouldn’t because there’s no reason to. You can’t have components of components, so it’s just wasted work–all components are in a flat structure attached to a GameObject. Instead of doing gameObject.renderer.collider.rigidbody, you’d just do gameObject.rigidbody.
–Eric
Doddler: You do not want to call GetComponent in the Update routine, since that would cause a performance hit in every frame. Use GetComponent in the Awake routine to get a reference to an object and store it in a variable, and then use that variable in the Update routine.