Jump to content

View more

Image of the Day

「筋肉兄貴のスーパーラン!」
夕焼けにガラス・・・(´・ω・`)
ガラスは割りたいでしょうけど、割ったらクリアできないですよ。
(o・ω・o)
 #indiedev  #indiegame #screenshotsaturday https://t.co/fhKO5NJ5ee
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net's newsletters to receive the latest updates and exclusive content.


Sign up now

Why Unity engine encapsulate everything?

2: Adsense
  • You cannot reply to this topic
3 replies to this topic

#1 Elgauly   Members   

137
Like
0Likes
Like

Posted Yesterday, 03:46 PM

Is there any reason for Unity to encapsulate for example the x, y and z coordinates like this: gameObjectName.transform.position.x

and not just do this: gameObjectName.x or if you need the position in vector form that just do: gameObjectName.position 

and another thing that I don't understand is why do I need to write GetComponent<componentName>() for every component that I need and not just  gameObjectName.component

 

Any reason to make things for complicated?

 

Thank you in advance.


Edited by Elgauly, Yesterday, 03:46 PM.


#2 ApochPiQ   Moderators   

22334
Like
3Likes
Like

Posted Yesterday, 04:43 PM

It's a combination of two things.

Your first example is a case where organization matters. Having a transform with a position is much more organized than keeping dozens of member variables on a single object.

The second example is where genericity has won out; in other words, in order to make things as general-purpose as possible, Unity has opted to take this route instead of other alternatives.

This is not really a situation where one approach is "right" and another is "wrong" - there are tradeoffs involved in both scenarios, and sometimes those are nice and sometimes they are pesky.
Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

#3 kburkhart84   Members   

3038
Like
0Likes
Like

Posted Yesterday, 09:07 PM

Besides what is mentioned above, I see it kind of as keeping "objects" as actual separate objects/classes.  If you only have a .x .y .z for position, then you don't have a nice object.  With an object, you can just use .position where it makes good sense.  For example, if you want to get the distance between two such positions, you need the x, y, and z for both, and as separate variables that makes 6 arguments to a function, or 3 if the function were called comparing "this" object to another.  But with everything all together in one object/class, you only need to send "position" to the function calls.  This is also great because "position" is a Vector3.  And Vector3 type variables are not only x, y, z values, but actual classes, with nice methods you can use.

 

About the second part, it is more for organization I think(not that Apoch is wrong, rather just adding on).  If you have a hierarchy of parent/child classes, with some methods on the parent where it makes sense, then you start getting into a lot of the purpose of OOP.  I'm no expert on the subject of course, but it makes sense.  By having a nice Monobehavior object/class, Unity can suddenly be really powerful.  Monobehavior includes the whole event system Unity is proud to have.  It also internally includes the stuff needed to be used in the editor, for the whole component drag & drop system, etc... that is included in Monobehavior.  Every class you make that is going to execute code(not just storage or similar) will be a child class of Monobehavior so that you can use all that Monobehavior has to offer.

 

*****

And my apologies there ApochPiQ.  I accidently downrated your post there, and it doesn't let me get rid of that.  That's my bad.





#4 Nypyren   Members   

11701
Like
0Likes
Like

Posted Yesterday, 09:21 PM

why do I need to write GetComponent<componentName>() for every component that I need and not just  gameObjectName.component


Because you can create your own classes derived from MonoBehaviour and add those as components. Since fields and properties like gameObject.component have to be defined in the class, and C# does not let you add fields at runtime like some languages do, you would have to edit the GameObject source code to add any of your custom components (which would be a bad idea even if you could).

You can use extension methods, though I would not recommend it.

Edited by Nypyren, Yesterday, 09:25 PM.