Dont you think that [GameObjects] in [Component system] are redundant?

Unity Engine
1

Dont you think that Component should be also a GameObject?

Component - “Transform” is already in most cases plays role of GameObject in Unity scripting, thus “Transform” could be replacement for “GameObject”. So we could add entire functionality of a GameObject (Tag, Layer etc…) into “Transform Component”.

Plus make Components (or only Transform Component) be able to have Children Components, along with Raw Components. So Components could grow Horizontally and also Vertically (like a GameObject)

And we will get even more simple and universal component system. Where components could also play role of a GameObject AND/OR Component simultanously.

The main problem with GameObjects - they can’t have Type for using inside Scripting. Thus if i want to make singleton GameObject i have to make redundant singleton Component and place it inside GameObject. When i want to access Typed Component, i have to take GameObject, Find(Component), and only then i can use that component.

OR in short: GameObject class could be just derived from Component class, and also inheritable (not sealed) => public class Transform : GameObject : Component : Object. (or smth like that).

2

Now i am using Unity 4.1.2 and i do the following to imitate this behaviour as closely as possible:

I test special ObjectMonoBehaviour class, for implementing Component + GameObject behaviour when i need.

public class ObjectMonoBehaviour : MonoBehaviour
{
	public GameObject ComponentObject;
}

Then, if i want my Component be able to contain other Components (like GameObject), i use ObjectMonoBehaviour for such components, instead of MonoBehaviour. The only “minus” for such method is that i have to manually set ComponentObject for Component inside Inspector, and also i have to manually create Child GameObject inside current Component.gameObject via HierarchyView. Thus it is very error-prone approach, because of too much manual actions.

PS: donno yet how much this is useful 10% or useless 90%. This could help for creating dynamically extendable components (i.e. components with children components). This is all about moving traditional code scripting further to graphical editor scripting.

3

I tested ObjectMonoBehaviour, and it dont fits Unity’s architecture. Separate object for Component’s body, looks very robust, because Unity doesnt support this by default anyway.

Now i consider to do the following:
We know that, every Component has gameObject field, so, we can use that Object, not only as Owner of Component, but also as Component’s Body. But with 1 condition: we should manually provide that Object will have only 1 Extendable Component representing entire Object, and other components should be usual Fixed Components. Or even, we can assume that gameObject’s Children is single container for all different Component’s children.

Something like as Transform representing each Object, i.e. Transform - is Extendable Component, but it’s Common Component for all objects. And we will have Extendable Component representing current particular Object, for example we have Object - “Player 1”, and this Object will have Component - “Player”. Some kind of Representative Component for Object, which adds some Static functuionality to an entire Object, i.e. Object becoming Component and vise-versa.

4

Digging component system further…

Now lets discuss GameObject.components and GameObject.children.

Components are quite simple to understand. It’s just partitioned functionality of a GameObject.
But what about Children?

Unity uses Children objects as Transform increment, i.e. Physical parts of a GameObjects. But what else it could be?
Could Children be Components? Why not, but why?

Components could be GameObjects and vise-versa. Because of new assumption: “GameObject can have Representative Component”, or another words “GameObject can have custom code realization, like inheritance”.

=> GameObject.components = GameObject.children.

The only difference that by default Unity assume, that Components are part of an Object, and Children are separate objects, connected only by Transform’s logic.

What i want is to expand Children’s role:

  1. Childrens are also Objects created by Object (by it’s Components).
  2. Childrens are also Objects contained by Object (by it’s Components).
  3. Childrens are also Objects temporally created by Object (by it’s Components).

=> Children of a GameObject = Children of Components (AND/OR) Contained by Components.

Technically ofcource we always use GameObject parenting like this, but what is missing in Unity, is: built-in “Per Component parenting”, instead we have “Mixed” Children for All Components at once and have to arrange all those children manually.

So what i did in short:
I assumed that each GameObject can have “Representative Component” (or GameObject’s code body), for ability to Script entire GameObject.

Now i have the following architecture of a GameObject:
(GO have RC) have Components have Children.

GO+RC = ScriptableGameObject.
Components = Components of ScriptableGameObject.
Children = ScriptableGameObjects of All Components.

This is my approximation to solve problem. What i did is only added additional “Representative Component” semantics.
What is still missing: individual Components can’t automatically have Children objects, instead all objects placed in a single bin object’s “Children”. But i can manually create Child GameObject with similar name as Component, so this could have meaning of Children Folder for particular Component. Perhaps in some situations this could be “plus” rather than “minus”, because common Children for all dont have so much Hierarchy, as for Children per each Component.

Anyway, even if my problem is approximately solved now. Perhaps Unity should change architecture of GameObject, to allow it to be Extended by Code via Inheritance, like Component(MonoBehaviour) + also have like Component Body inside of Inspector.

Conclusion:

  1. GameObject should inherit MonoBehaviour (or Component), and also GameObject should be not sealed. To allow GameObject to have code Body.
  2. Transform should not be a Component, but part of GameObject’s Body (or Interface) instead.

i.e. GameObject’s Body - is like-component body meaning.
In short: GameObjects should be able to have different code Types, like different Components. (may be i am wrong, needs investigation)

5

No.

The design here is pretty clear. Components are objects which provide functionality or a resource to be used within a Scene. GameObjects are containers which are used to group Components which are used together. A Transform is a type of Components who’s function is to give the scene structure.

Yes, there are different ways that these could be implemented, but the approach taken here is to have a distinct class for each of those roles. The roles are pretty clear, and if you understand them it’s pretty easy to overcome the issues you’ve identified.

6

No.

Partially.

7

Yes.

http://docs.unity3d.com/Documentation/Components/class-GameObject.html

Completely.

All of the issues you’ve identified are based on going against the grain, and attempting to implement design patterns or solutions that don’t take Unity’s architecture into account. There are equivalent approaches to nearly everything, and reasonable workarounds for the rest.

8

Too predictable. Guys like you should use only Assembler. Everything is possible, completely. But truth is, you bother to High-Level development. You assume GameObject as only Container, you think everything is possible with Unity. Nothing to discuss with you.

9

Haha, ok.

10

Good that you understand :).
Btw, i didnt even hope that someone will read this topic and try to answer, it was just my mind flow notes without order. Absolutely impossible for someone to understand all this (+my bad English). The only “Conclusion” is more or less important.

PS: i care only pure logic, not people’s opinions.

11

All I really understood was that you’re not actually open to discussion, or even to reading documentation.

12

True ^). I above this.

13

Going further. I think i was completely wrong.

I was interpretting Components with wrong point of view.
Now i interpret Components not as part of an Object functionality, but role of an Object instead.

With this point of view: Components = Object’s Roles. Means Object can be Application, Server and Log System at the same time (i.e. Component can be a noun)

This conclusion (components = roles) puts everything in its places.

PS: the triumph of pure logic, correct definitions are very important.

14

Do you even read what you send? “Youre above that” referring to having to read the documentation in order to understand key elements of the engine?

I’m sorry, but I can’t make much sense from your pieces.
Other then that, GameObject.Children will point to other GameObject’s, and GameObject.components only lists components for that specific object.
as far as i know, a GameObject ALWAYS contains GameObject.components and ALWAYS contains GameObject.Transform (i believe Transform is even a component) like every script added to a prefab is also a GameComponent.
(Though on a side note, i’ve never checked actual documentation on this)

I just really don’t understand exactly what you’re trying to suggest, or i can only see an incrementing amount of possible confusion.

15

Unity’s documentation has only 50% of useful information, other information:

  1. Poor
  2. Wrong
  3. Misleading

You right, dont try to understand, its just my thinking aloud for my own purposes. I thinking deeper when i writing + if i will find solution i give chanse to humanity to find this topic after 100 years and learn the truth :smile: + very little but chanse that someone on forum may write smth really logical, not just opinion.

16

Haha, gold! :smile: Not only is your interpretation of these things precisely what I was trying to discuss with you, but the documentation also makes it pretty clear.

I agree with you that the documentation often leaves much to be desired, but you do yourself a disservice by writing it off as worthless.

He was “rubber ducking”, a process where you initiate a discussion purely to make your mind get its thoughts about a problem in order. The re-organisation alone often helps you make the connection that leads to a solution.

17

Haha nice, man ^)