Les raisons de la conception du moteur Unity3D (objet de jeu / composant de transformation)

14

J'essaie de comprendre le raisonnement derrière la conception du moteur Unity3D et c'est quelque chose que je ne peux pas encore comprendre : pourquoi transformer les données stockées dans un composant séparé, au lieu de faire partie de GameObject, comme le nom, les masques de calque et Mots clés? Il ne peut pas être retiré comme tous les autres composants de toute façon, il n'y a pas d'alternative et donc pas besoin de le retirer.

architecture unity component-based snake5
la source
Pour moi, cela ressemble à cela ressemble à l'héritage de l'architecture. Peut-être que ce composant de transformation était un composant régulier et facultatif, de sorte que vous pourriez avoir des objets "hors" de l'espace cartésien. Ensuite, une contrainte d'implémentation (une optimisation?) Exigeait que ce composant soit toujours présent, et il en est resté ainsi. Mais c'est juste une supposition, il faudrait un ingénieur d'Unity pour répondre à cette question pour de vrai.
Laurent Couvidou

Réponses:

11

Seuls les développeurs Unity peuvent donner leur véritable motivation pour cette conception, mais un argument en faveur de le faire de cette façon est qu'il existe un argument selon lequel chaque classe d'un projet logiciel devrait gérer une et une seule responsabilité . Le GameObject est une collection nommée de composants, et l'ajout de position / rotation / etc à cela signifie qu'il aurait 2 responsabilités. Le composant Transform gère la position et la rotation et ne devrait donc pas également être responsable de la dénomination ou de l'agrégation d'autres composants (potentiellement indépendants). Il est donc logique que ces 2 concepts existent dans 2 objets distincts.

Plus généralement, cette question demande "s'il existe une relation 1 à 1 entre X et Y, pourquoi Y ne fait-il pas partie de X ou vice versa?" Et la réponse générale est que le logiciel est plus facile à développer et à entretenir lorsqu'il est divisé en parties autonomes plus petites, même si 2 parties fonctionnent toujours ensemble.

Kylotan
la source
J'ai également considéré cela, mais ils auraient pu déplacer le filtrage GameObject (couches, balises) vers un composant distinct pour la même raison - et pourtant ils ne l'ont pas fait. De plus, le composant de transformation est lié trop profondément dans le système en contenant des données de hiérarchie (parent, enfants, etc.).
snake5
1
On pourrait faire valoir que les couches et les balises sont une forme de dénomination, devraient cohabiter avec le nom, et font donc partie intégrante de ce qui constitue une collection de composants dans le système. En ce qui concerne les transformations détenant la parentalité, vous avez raison, mais personne ne prétend que le système Unity est parfait. Si c'était mon système, je garderais les Transforms séparés et déplacerais les parents / enfants sur GameObject.
Kylotan
1

La transformation est un composant obligatoire dans Unity.

La raison pour laquelle une transformation est un composant obligatoire est que les objets de jeu sont situés dans une scène et ont donc besoin d'informations spatiales (position, orientation et échelle) sur cet objet. (Ces informations ne sont pas toujours utilisées, mais garder le composant de transformation obligatoire rend les choses un peu plus simples).

Mortennobel
la source
1
La question n'est pas de savoir ce qu'est la conception basée sur les composants. C'est pourquoi "transformer" n'est pas un composant aussi
bummzack
1
Mais Transform est un composant dans Unity! docs.unity3d.com/Documentation/ScriptReference/Transform.html . La seule chose étrange à propos de la transformation est qu'il s'agit d'un composant obligatoire pour GameObject.
Mortennobel
Eh bien, je suppose que la question est de savoir pourquoi vous ne pouvez pas le supprimer? L'OP n'aurait pas étiqueté sa question "basée sur les composants" s'il n'était pas familier avec le terme.
bummzack
Vous avez raison - merci. J'ai mis à jour la réponse pour mieux répondre à la question.
Mortennobel
3
La question est de savoir pourquoi transformer les données est un composant distinct (par opposition aux données simples dans GameObject comme le nom, les masques de calque, les balises). J'ai essayé de le rendre plus clair dans la dernière révision de mon message.
snake5
0

C'est TransformComponentle plus difficile Componentà concevoir correctement dans l'architecture de jeux vidéo. Presque tous les autres ont Componentbesoin de connaître GameObjectla position, la rotation ou l'échelle d' une donnée , il est donc intrinsèquement difficile de découpler correctement tous ces systèmes interdépendants.

Il y aura toujours des compromis en architecture. En étant TransformComponentstatiques (c'est-à-dire non dynamiques), les développeurs d'Unity peuvent écrire du code sous cette hypothèse. Je suppose que cela rend les choses beaucoup plus faciles de leur côté sans ajouter beaucoup d'inconvénients de notre côté. Cela ressemble à un paradigme orienté objet, où GameObjectserait un extendpeu abstract class, Transformable.

Alex
la source