Unity 5 Beta Insights

According to the benchmarks forum user Nevermind did on the built-in properties and GetComponent (http://chaoscultgames.com/2014/03/unity3d-mythbusting-performance/), the properties are actually faster to access than GetComponent, so removing them is actually going to make performance worse?

 

I think you definitely should. And while you're at it, you might review your API and change it to follow usual C# / .NET naming conventions.

GameObject.transform indicates clearly that this is a member variable - not a property (as it really is). Having something that looks like a variable be a property that actually does native stuff that takes a lot of time is really one of the worst things I'm aware of in all of Unity ;-)

So, when GameObject.transform is cached (on the mono side of things), even though it may still be a "property", this would be much closer to what it looks like.

Any properties should be using PascalCase, so this should actually have been GameObject.Transform in first place (admittedly, that would make it even more confusing and I'm not even sure having a property that has the same name as a class is possible in all cases).

Either way, I like the change. Cleanup up the Unity API is very much appreciated. Now if you could only move everything to its appropriate namespaces (like you did with Social), I'd be totally in awe.

 

Agreed.

 

Right, in a hope to bring more clarify since the original article, I've updated it with an additional section which I'll also share here.
Based on all the discussion here in the forums and several other avenues I've put together this three part list to highlight what IS affected, what is not and what is unconfirmed.

What properties / components are known to be affected:

The following types / properties are known to do GetComponent<> under the hood and implement the shortcut:

- Scripts (any script you attach to a GameObject)
- Animation
- Audio
- Collider
- Collider2D
- GuiText
- GuiTexture
- NetworkView
- ParticleEmitter
- ParticleSystem
- Renderer
- Rigidbody
- Rigidbody2D

The following properties may be affected (not confirmed)

- Camera
- ConstantForce
- HingeJoint
- Light

Finally these are confirmed as NOT affected

- ActiveInHierarchy
- ActiveSelf
- Layer
- HideFlags
- IsStatic
- Tag
- Name
- GameObject
- Transform (even though transform is a component, Unity devs confirm this is not affected due to its special implementation)
If you get any more detail, comment below and this list can be updated

If the Unity Devs could chime in and point out any inconsistencies in this list, we can have a definitive list

 

Why do you need an official list for that? They get rid of all the direct component access properties in MonoBehaviour except for transform. That's it.

 

I must say that this is good news, I never liked these "magic" properties.

I would also like to see similar seemingly innocent properties removed since all they do is provide duplicate functionality and mislead people into believing they are quite efficient.

For instance, Camera.main = FindByTag. Performance implications of the property become immediately obvious when using "FindByTag", yet use of a property called "Camera.main" implies that some sort of caching might be going on.

 

BTW there is time for remove "magic" method/event? and replace for override version or delegate/event? I have in mind OnGUI, Update, Awake, Start and so on....

 

Completely agree. Not being able to define Update on a base class is very annoying and limiting.

Also, I want a way to subscribe to Update events from a non-GameObject

 

Whilst I would agree entirely, I fear that this change would break many existing Unity projects.

You could declare your Update function as virtual inside your base class:

Code (csharp):

1.  
2. public class BaseClass : MonoBehaviour {
3.     public virtual void Update() {
4.         Debug.Log("Base Thingy");
5.     }
6. }
7.  
8. public class SuperClass : BaseClass {
9.     public override void Update() {
10.         base.Update();
11.         Debug.Log("Super Thingy");
12.     }
13. }
14.  

 

Yeah, being able to hook into events arbitrarily would be awesome. I like the current MonoBehaviour model in general, I wouldn't get rid of those, but if there were also delegates we could hook into manually for stuff like update, scene changes / loads, and so on, that'd be handy. These things are all possible at the moment, but we have to use an adapter GameObject + component, and then we have to maintain that over multiple scenes and such. It's doable, but it'd be nice if it was just there for us to use.

I do this pretty commonly, using the model numberkruncher gave.

 

Yes, but you have to define Update on your subclass as well or it won't work (sorry, first post wasn't very clear).. Or at least it didn't when I last tried it.

Sometimes I want to hide the Update plumbing and expose my own set of virtual methods.

 

You should be able to introduce a new event in a subclass without it being implemented in the base class.

 

Wow, ok just tried it out and it appears I'm wrong.. But I'm sure I tried it a few months ago and it wouldn't work! Feeling very confused now

 

Yeah, I thought it worked, but couldn't quite remember if I'd done anything special. But I was pretty sure that I've had cases where the only difference between subclasses was how they responded to my own event calls, and I couldn't remember re-plumbing Unity's stuff to make it work.

 

That would make things consistent from an OOP point-of-view. But if there's no performance benefit to the change (or if for some reason, it is slower), then I'm also fine with how it is currently.

However, it could be confusing for those with a programming background and trying Unity for the first time. I can't remember, but the first time I tried it, I'm pretty sure I was confused as to how my supposedly private Update() function was getting called.

+1

Also being able to use coroutines from a non-MonoBehaviour-inehirted class.

I use the open-source library StrangeIoC, and the way we do it is have one dummy gameobject with a script whose job is to be able to provide corountines to any class. It's an extra setup, and if this is the chance to redesign the Unity API, might as well address this.

 

I'm surprised this is an issue: "Which is a step in our never ending quest to find the right balance between “fix and cleanup old things” and “do not break old projects”"

Is that common? I would assume that if you have an old Unity project and you are nearing release you would definitely not be upgrading to the newest version of Unity. That's just asking for trouble.

If you are far enough from release to consider it worthwhile to upgrade you have to expect to budget in a bit of refactoring time. Even better if Unity put out a "refactor guide" on each release with some tips on what's changed, what's the new intended usage, etc. Something beyond just the change list to highlight particular changes would be nice.

 

I also think that the properties should be changed to upper case. Yes, it breaks compatibility, but it would clarify so many things and communicate directly, that we are not just accessing variables, but that actual code is being executed. If we had to call CachedTransform.Position (or Transform.Position) instead of transform.position, it would directly be understandable for programmers that a computation may take place.

As this discussion is very much about improving Unity's API, I would like to ask whether there are plans to create a better solution for the MonoBehaviour calls like Update? We probably don't have to discuss that the current implementation is against about any programming rule and convention. If you have a look at the forum, there are hundreds of posts where people have issues because of typos regarding that. Be it because they used "update ()" or something like "OnColisionEnter ()" or because of a wrong argument list. Some of those posts are really long, because those errors are not always that easy to spot. But if there was an object oriented programming integration in Unity, those issues would be caught at compile time without the need for long debug sessions.
When I started with Unity, I spent at least 2-3 days with that kind of unnecessary issues. I am almost certain that about everyone who is writing scripts in Unity went through that as well. If we sum all the time up that is wasted because of that, we easily end up getting several years. This is a very strong point in my opinion.
I understand that non programmers are on the other side of this. But especially they should be taught to good practices and Invoke/SendMessage were never good practices and will never be. I don't think they should be removed, but at least Unity itself shouldn't use them. Neither for MonoBehaviour, not for editor scripts.

 

I'm for both renaming properties to look like properties and Dantus's suggestions above.

Honestly, if you're going to break something then a major version revision is the time to do it. If not now I have my fingers crossed for Unity 6.

Trivialising it as "just to comply to some convention" seems a little odd to me as a programmer, since so much of what makes our jobs easier comes from both ourselves and others sticking to conventions - especially smart, easy ones that make our lives easier. After all, if conventions are worthless then why bother with consistent use of white space, naming styles, positioning of braces/parentheses/semi-colons, directory structures, design patterns, user interface principles... etc. etc. etc?

 

I, for one, would personally not mind at all if I update my project to Unity 5 and am forced to edit my code if the Unity API were using more namespaces, change in Update/Start events, properties, etc.

As for capitalizing property calls, I vote yes on that, since that would actually make my calls to Unity code be consistent with the rest of my game logic, as I capitalize my property names as well.

 

I would love proper virtual and overridden methods, At some point you guys should absolutely do this, and to support older projects, you could always support both ways, new and old...Then deprecate the old way after a couple years.

 

Or add an option to disable the legacy way to avoid any additional performance burden.

 

Gotta love those people.
On the one hand complaining "duh! (i think) Unity's performance is so bad" - "but i want to continue using unity anyway"
then "well, we could improve the performance and stuff, but you'd have to do some manual updates to your project, if you update the unity version your project is using. But you could also continue using the current version and continue doing as you're now. But as always we also do not advise to switch unity versions in mid-projects".
but then "No i don't want to put work and effort into my game project to make it better, it's on UT to make my games epic!"
and at the end "damn, my game is bad, unity sucks".

Don't want extra work? Don't upgrade. Want all those shiny new features? Have some extra work. You'd already have extra work to make use of the new features anyway. Like all those new audio and rendering stuff does not get automatically implemented in your already written code, does it? Like reflection probes won't place themselves effectively throughout your scenes.

It's sad to see people not letting things advance, when even they themselves notice it could be better.
As it would even just be for the project upgrade part, one time, when it would be best to not even do it at all.
If they started a new project there would be no issue at all.

The only problem i can really see with such upgrades are asset store products. But well, the asset store is always a quite delicate thing when it comes to completely good working assets.

 

I have proposal for "magic" method - keep it in Editor but only Editor API (like OnGUI will be used only for Editor after 4.6) but remove these behaviour in game logic or place in preferencies disable option - i think these change make smaller troubleshoot for third party assets and people will have to fix only problems with game logic and will not worry about inspector problems. Any thoughts?

 

I think this is a good example of why you should communicate with people outside the beta list about significant upcoming changes. I am not on the beta list, nor are most of the authors of popular Asset Store assets that I use, and it was a huge pain in the ass to fix both my own code and to both show various asset store authors how to fix their code and convince them that they should do it when the "active" change came out. Similarly, the change that stopped people from changing the hierarchy within Awake broke a lot of assets, and had no explanation anywhere in the patch notes nor any warning that it was coming. If you were more public about these upcoming changes, more people who have time to get ready for them. Dropping sudden breaking changes, especially without mentioning them in the change logs, is a bad idea. You can't depend on the beta list to tell the rest of us about these things... In fact, I'm pretty sure most of them are afraid to tell us about upcoming changes because they are under NDA's that they don't entirely grasp.

 

One solution to gradually getting rid of the reflection-based magic methods would be to introduce a new "MonoBehaviour2" (or whatever name you want) class that inherits from MonoBehaviour but has virtual methods for all the magic methods. That's the way DirectX and similar API's tend to do things. Deprecate the original MonoBehaviour class and document that it will go away in a year or two. That makes it a non-breaking change and gives people time to adapt to the new structure.

 

I also want to mention that the "pain" of renaming / refactoring things these days is much less than it used to be. I feel like most of the people who freak out about the idea of renaming a variable are having nightmares about editing C code in vim. Using a modern IDE, it takes like five seconds to do a solution-wide rename of a C# property. Less than that if you're using Resharper.

 

I understand that the cost of change is genuine and significant, but the cost of change will only ever increase. You'll get more customers, customers will each have more legacy and/or current projects, so on and so forth.

It wasn't really something I expected for 5.0, but it is something I absolutely think should happen at some point. Preferably 6.0, being the next major version.

 

I fear we would end up with pretty bad performance if it was made like that in a straight forward way. I believe that someone from the community even tested it, but I am not entirly sure about it. The reflection mechanism to perform all the calls would suddenly call all the virtual ones, without exception.
The way it is solved should be made by the Unity engineers, because they know the internals. But as Jonas mentioned, it will not be in Unity 5.0.

 

But it's indeed one way, I think, to introduce the new system without breaking a user's project when upgraded, if UT will want to do this.

The only thing I think, is that the "MonoBehaviour2" should not inherit from MonoBehaviour, but mimic its functionality.

Give warnings about deprecations, and let new scripts inherit from the so-called "MonoBehaviour2" instead.

Would be a good chance to rename it also. Why was it named Behaviour anyway? It makes me think of AI. Make it MonoScript or something.

 

That is a very good point, I would love to see this renamed. "MonoScript" or "MonoComponent" make good sense given that we use AddComponent and GetComponent.

 

I get it. Well then, in the future (certainly not now), how about UT look into those too? From us users' point of view, we don't really care about dealing directly with the Behaviour class anyway.


So from what I can gather:

UnityEngine.Object -> Component (anything attached to game objects) -> Behaviour (adds enabling/disabling) -> MonoBehaviour (adds coroutines "magic" events)

I'm sure there was a reason for all these separations.

What I had in mind was, for the least intrusive way I can think of, for the moment, and if it makes sense for UT to do it:

UnityEngine.Object -> Component (anything attached to game objects) -> Behaviour (adds enabling/disabling) -> MonoScript (Will have no "magic" events, and have overrideable virtual methods instead. Coroutine handling would be a static class instead of being methods in here. Also no more Invoke methods.)

MonoBehaviour would still be there for backwards compatibility.

 

It would be handy if MonoBehaviours included "AddComponent" for simplicity.

Also, I think that it would be useful if there was a function (on both MonoBehaviour and GameObject) which gets the component if present, otherwise automatically adds it. For instance, "AutoAddComponent".

 

http://wiki.unity3d.com/index.php/GetOrAddComponent

 

Why? It's only a gameObject reference away, and it's misleading to call "AddBlah(...)" on a thing that doesn't get the Blah actually added to it.

 

What about if you'd introduce an actual new base class that's called ScriptingBehavior that'll eventually replace the MonoBehaviour? You'd mark it as experimental and discourage using it in actual production but slowly rebuild it using all the lessons learned from the quirks of MonoBehaviour (e.g. the messages, naming, etc). That way you could fix it without breaking existing code and when the ScriptingBehavior is mature enough you start marking the MonoBehaviour as deprecated. I guess that would give everybody more than enough time to update their projects/assets and gives Unity more than enough time and space to properly fix the base scripting behavior

 

I prefer the current Pascal and camel that Unity uses now and would hate it to be changed. It's the way I've coded for a decade anyway.

The method name is Pascal cased, so having parameters inside that are camel cased makes it easier to separate the two categories of code.

Code (csharp):

1.  
2. class Poop
3. {
4.        public bool wee;
5. }
6.  

 

Since the .NET library itself follows the conventions documented in the MSDN library it makes sense for the Unity API to be consistent: http://msdn.microsoft.com/en-us/library/ms229043(v=vs.110).aspx

 

Yeah but we were talking about C# properties. Fields, yeah, I go with camel case too. But I treat properties like methods, so I use pascal case on them.

 

I would like it renamed to something more indicative of it's use like UnityEngine or UnityCore

 

This is property casing debate getting really off-topic, but honestly, it should be obvious why Unity uses camel-casing for properties. They use it because they expect users to treat their properties like plain old variables - so they want them to look like plain old variables. And this makes perfect sense, especially considering the user-friendliness that Unity likes to enforce.

In my own code, I follow Unity's convention for the exact same reason. I don't want people auto-completing my properties, having them in Pascal case, and wondering why something they treat like a variable is cased like a function/namespace/class.

I honestly don't understand why Microsoft would even use Pascal for properties to begin with, unless the person who came up with the convention had no sense of user-experience... or just made a mistake that continues to this day.

 

According to the MSDN guidelines, pascal case should be used for fields as well since this makes it possible to silently convert a field into a property. Admittedly this is hard with Unity serialization, but it is certainly possible with vanilla C# classes.

Unity seem to be mixing JavaScript style notation with C# style notation which is confusing and messy.

 

I don't think it's off-topic to re-examine the code conventions in the Unity API.

I'm not arguing with you, but if you're curious why, for me it's because most of the time, my property code ends up with some heavy computations inside it, it really isn't just a simple variable. Using a variable in a tight loop isn't exactly the same as calling a get property in a tight loop, it's an easy mistake to make. But that's just me.

I was actually thinking of something as simple as BaseScript.

 

It seems like some simple extension methods could seamlessly add them back without the end user even noticing, and you would still have a clean API.

 

For me, I don't really care if I have to do some extra work, if the Unity API improves by that. I'm in for all previously named improvements

 

Yes, you're correct. Still, you could do it, and the user could add "()". That would blow the whole not noticing thing though.