Las razones detrás del diseño del motor Unity3D (objeto del juego / componente de transformación)

Estoy tratando de entender el razonamiento detrás del diseño del motor Unity3D y esto es algo que aún no puedo entender: por qué la transformación de datos se almacena en un componente separado, en lugar de ser parte de GameObject, como el nombre, las máscaras de capa y etiquetas? De todos modos, no puede eliminarse como todos los demás componentes, no hay alternativas y, por lo tanto, no es necesario eliminarlo.

architecture unity component-based

— serpiente5
fuente

Para mí esto suena como esto suena como legado de arquitectura. Quizás este componente de transformación solía ser un componente regular, opcional, por lo que podría tener objetos "fuera" del espacio cartesiano. Luego, alguna restricción de implementación (¿una optimización?) Requirió que este componente siempre estuviera presente, y se mantuvo así. Pero eso es solo una suposición, se necesitaría un ingeniero de Unity para responder esa pregunta de verdad.

— Laurent Couvidou

Respuestas:

Solo los desarrolladores de Unity pueden dar su verdadera motivación para este diseño, pero un argumento en apoyo de hacerlo de esta manera es que hay un argumento de que cada clase en un proyecto de software debe manejar una y solo una responsabilidad . GameObject es una colección con nombre de componentes, y agregar posición / rotación / etc. a eso significa que tendría 2 responsabilidades. El componente Transformar maneja la posición y la rotación y, por lo tanto, no debería ser responsable de nombrar o agregar otros componentes (potencialmente no relacionados). Por lo tanto, tiene sentido que estos 2 conceptos existan en 2 objetos separados.

En términos más generales, esta pregunta pregunta "si hay una relación 1 a 1 entre X e Y, ¿por qué Y no es parte de X o viceversa?" Y la respuesta general es que el software es más fácil de desarrollar y mantener cuando se divide en partes independientes más pequeñas, incluso si 2 partes siempre trabajan juntas en conjunto.

— Kylotan
fuente

También lo consideré, pero podrían haber movido el filtrado de GameObject (capas, etiquetas) a un componente separado por la misma razón, y sin embargo no lo hicieron. Además, el componente de transformación está vinculado demasiado profundo en el sistema al contener datos de jerarquía (padre, hijos, etc.).

— serpiente5

Se podría argumentar que las capas y etiquetas son una forma de denominación, deben convivir con el nombre y, por lo tanto, son una parte intrínseca de lo que constituye una colección de componentes en el sistema. En cuanto a las transformaciones que sostienen la crianza de los hijos, tiene un punto, pero nadie afirmó que el sistema Unity es perfecto. Si fuera mi sistema, mantendría las Transformaciones separadas y reubicaría a los padres / hijos en el GameObject.

— Kylotan

La transformación es un componente obligatorio en Unity.

La razón por la cual una transformación es un componente obligatorio es que los objetos del juego se encuentran en una escena y, por lo tanto, necesitan información espacial (posición, orientación y escala) sobre ese objeto. (Esta información no siempre se usa, pero mantener el componente de transformación obligatorio hace las cosas un poco más simples).

— Mortennobel
fuente

La pregunta no es sobre qué diseño basado en componentes es. Se trata de por qué "transformar" no es un componente también

— bummzack

¡Pero Transform es un componente en Unity! docs.unity3d.com/Documentation/ScriptReference/Transform.html . Lo único extraño de transform es que es un componente obligatorio para GameObject.

— Mortennobel

Bueno, supongo que la pregunta es por qué no puedes eliminarlo. El OP no habría etiquetado su pregunta como "basada en componentes" si no estuviera familiarizado con el término.

— bummzack

Tienes razón, gracias. He actualizado la respuesta para responder mejor la pregunta.

— Mortennobel

La pregunta es por qué transformar los datos es un componente separado (a diferencia de los datos simples dentro de GameObject como nombre, máscaras de capa, etiquetas). Traté de aclararlo en la última revisión de mi publicación.

— serpiente5

El TransformComponentes el más difícil Componentde diseñar adecuadamente en la arquitectura de videojuegos. Casi todos los demás Componentnecesitan saber acerca de GameObjectla posición, rotación o escala de una determinada, por lo que desacoplar adecuadamente todos estos sistemas interrelacionados es inherentemente difícil.

Siempre habrá compensaciones en arquitectura. Al TransformComponentser estáticos (es decir, no dinámicos), los desarrolladores de Unity pueden escribir código bajo este supuesto. Asumiría que esto hace las cosas mucho más fáciles de su lado sin agregar muchos inconvenientes de nuestro lado. Esto es similar a un paradigma orientado a objetos, donde GameObjectharía extendalguna abstract class, Transformable.

— Alex
fuente