Search Unity

Unity 5 Beta Insights

Discussion in 'Unity 5 Pre-order Beta' started by rwetzold, May 11, 2014.

  1. Neeko

    Neeko

    Joined:
    Mar 9, 2012
    Posts:
    24
  2. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,088
    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.
     
    Ryiah likes this.
  3. spraycanmansam

    spraycanmansam

    Joined:
    Nov 22, 2012
    Posts:
    247
    Agreed.
     
  4. SimonDarksideJ

    SimonDarksideJ

    Joined:
    Jul 3, 2012
    Posts:
    1,625
    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
     
  5. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    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.
     
  6. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    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.
     
  7. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    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....
     
  8. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    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
     
  9. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    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.  
     
  10. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    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.
     
  11. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    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.
     
    Last edited: May 19, 2014
  12. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    You should be able to introduce a new event in a subclass without it being implemented in the base class.
     
  13. minionnz

    minionnz

    Joined:
    Jan 29, 2013
    Posts:
    391
    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
     
  14. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    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.
     
  15. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,491
    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.
     
    Last edited: May 19, 2014
  16. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    If you look at Lucas' latest blog post (http://blogs.unity3d.com/2014/05/16/custom-operator-should-we-keep-it/), you will see that both him and I did try the caching (with some interesting observations). We are looking at it.

    As for properly following .NET naming conventions for our lower-case properties - this has been a controversial topic inside Unity for years. Yes, our property naming is utterly stupid for being lower-case, and we should have never done this in the first place. Nobody disagrees on that. But whether this case justifies introducing pain for all Unity developers by changing it, just to comply to some convention? Well, there are different opinions on it, but so far there has never been any consensus to do it (personally, I don't think it's worth it). As for moving stuff to namespaces, I do think that is more worth it, and I expect that to be something we will fix eventually (but only if we can do it with some relatively painless automated update process, similar to what we do for the component accessors now).
     
  17. Silly_Rollo

    Silly_Rollo

    Joined:
    Dec 21, 2012
    Posts:
    477
    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.
     
  18. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    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.
     
  19. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    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? ;)
     
  20. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,491
    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.
     
    Last edited: May 19, 2014
  21. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    Yes, the "magic" way how Unity finds MonoBehaviour functions (instead of using virtual and override) is another example of something we should have done right from the start, but where changing it now would introduce a lot of update pain. For those of you asking to "just do it now" for 5.0, i can assure you that this in *not* going to happen for 5.0. 5.0 will be going into beta soon, and is too far along the way for changes of this size. Wether we'd do it at some other point, not sure.

    For people wondering if project backwards compatibility is indeed such a big deal: Yes, i can assure you that many people do get very upset about having to update their projects. A good example is changing the behavior of the "active" flag on GameObjects in 4.0. Nobody was really arguing that the change was not for the better, or that we should not have done it that way from the start. But the fact that people would have to update projects, and asset store packages, resulted in weeks of discussions and upset people when we announced that plan on our beta list. And in that case, easily 90% of previous use would keep working, i think the changes suggested here are much more significant.
     
  22. charmandermon

    charmandermon

    Joined:
    Dec 4, 2011
    Posts:
    351

    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.
     
  23. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    Or add an option to disable the legacy way to avoid any additional performance burden.
     
  24. Fuzzy

    Fuzzy

    Joined:
    Feb 11, 2011
    Posts:
    264
    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.
     
  25. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    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?
     
  26. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,298
    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.
     
  27. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,298
    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.
     
  28. makeshiftwings

    makeshiftwings

    Joined:
    May 28, 2011
    Posts:
    3,298
    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.
     
  29. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    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.
     
  30. Dantus

    Dantus

    Joined:
    Oct 21, 2009
    Posts:
    5,667
    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.
     
  31. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,491
    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.
     
    Last edited: May 20, 2014
  32. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    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.
     
  33. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,186
    Because it derives from Behaviour. The Behaviour components are all the ones that can be enabled/disabled.
     
  34. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,491
    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.
     
  35. jonas-echterhoff

    jonas-echterhoff

    Unity Technologies

    Joined:
    Aug 18, 2005
    Posts:
    1,606
    I agree, you are right in pointing this out. Personally, I'd like to see our betas become public altogether, but, if as long as that will not happen (it might some day, who knows), we should get better in sharing upcoming changes like this in blog posts or other formats.

    Regarding the naming topic in this thread: "MonoBehaviour" by itself is a very bad name in today's perspective.

    1. We don't exclusively use Mono for scripting any more. Windows phone uses MS's .NET, and we have WebGL using IL2CPP.
    2. We are using US-english in all our communication, so the 'u' should go.

    Today, we would probably call it "ScriptingBehavior".
     
  36. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    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".
     
  37. Carpe-Denius

    Carpe-Denius

    Joined:
    May 17, 2013
    Posts:
    804
  38. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,028
    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.
     
  39. besttof

    besttof

    Joined:
    Jul 17, 2012
    Posts:
    15
    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 :)
     
    Last edited: May 30, 2014
    Ryiah likes this.
  40. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,476
    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.  
     
  41. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    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
     
  42. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,491
    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.
     
  43. goat

    goat

    Joined:
    Aug 24, 2009
    Posts:
    5,177
    I would like it renamed to something more indicative of it's use like UnityEngine or UnityCore
     
  44. deram_scholzara

    deram_scholzara

    Joined:
    Aug 26, 2005
    Posts:
    1,025
    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.
     
  45. numberkruncher

    numberkruncher

    Joined:
    Feb 18, 2012
    Posts:
    949
    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.
     
  46. AnomalusUndrdog

    AnomalusUndrdog

    Joined:
    Jul 3, 2009
    Posts:
    1,491
    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.
     
  47. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    4,779
    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.
     
  48. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,186
    Extension methods can't be used to add properties; only methods. The clue is in the name...
     
  49. Vanamerax

    Vanamerax

    Joined:
    Jan 12, 2012
    Posts:
    818
    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
     
    landon912 likes this.
  50. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    4,779
    Yes, you're correct. Still, you could do it, and the user could add "()". That would blow the whole not noticing thing though. :)