Le ragioni alla base della progettazione del motore Unity3D (oggetto di gioco / componente di trasformazione)

Sto cercando di capire il ragionamento alla base del design del motore Unity3D e questo è qualcosa su cui non riesco ancora a capire: perché trasformare i dati memorizzati in un componente separato, invece di far parte di GameObject, come nome, maschere di livello e tag? Non può essere rimosso come tutti gli altri componenti comunque, non ci sono alternative e quindi non è necessario rimuoverlo.

architecture unity component-based

— snake5
fonte

Per me questo suona così come un retaggio di architettura. Forse questo componente di trasformazione era un componente normale, facoltativo, in modo da poter avere oggetti "fuori" dallo spazio cartesiano. Quindi alcuni vincoli di implementazione (un'ottimizzazione?) Richiedevano che questo componente fosse sempre presente e rimase così. Ma questa è solo una supposizione, ci vorrebbe un ingegnere di Unity per rispondere davvero a questa domanda.

— Laurent Couvidou,

Risposte:

Solo gli sviluppatori Unity possono dare la loro vera motivazione per questo progetto, ma un argomento a sostegno del farlo in questo modo è che c'è una discussione secondo cui ogni classe in un progetto software dovrebbe gestire una e una sola responsabilità . GameObject è una raccolta denominata di componenti e l'aggiunta di posizione / rotazione / ecc. Significa che avrebbe 2 responsabilità. Il componente Trasforma gestisce la posizione e la rotazione e pertanto non dovrebbe essere responsabile della denominazione o dell'aggregazione di altri componenti (potenzialmente non correlati). Quindi ha senso che questi 2 concetti esistano in 2 oggetti separati.

Più in generale, questa domanda chiede "se esiste una relazione 1 a 1 tra X e Y, perché Y non fa parte di X o viceversa?" E la risposta generale è che il software è più facile da sviluppare e mantenere quando suddiviso in parti autonome più piccole, anche se 2 parti lavorano sempre insieme.

— Kylotan
fonte

Ho pensato anche a quello, ma avrebbero potuto spostare il filtro GameObject (livelli, tag) in un componente separato per lo stesso motivo - eppure non lo hanno fatto. Inoltre, il componente di trasformazione è collegato troppo in profondità nel sistema trattenendo i dati della gerarchia (padre, figlio, ecc.).

— snake5

Si potrebbe argomentare che i livelli e i tag sono una forma di denominazione, devono convivere con il nome e quindi sono parte intrinseca di ciò che costituisce una raccolta di componenti nel sistema. Per quanto riguarda le trasformazioni che detengono la genitorialità, hai ragione, ma nessuno ha affermato che il sistema Unity sia perfetto. Se fosse il mio sistema, terrei Transforms separato e trasferirò il genitore / i figli su GameObject.

— Kylotan,

Transform è un componente obbligatorio in Unity.

Il motivo per cui una trasformazione è un componente obbligatorio è che gli oggetti di gioco si trovano in una scena e quindi necessitano di informazioni spaziali (posizione, orientamento e scala) su quell'oggetto. (Queste informazioni non vengono sempre utilizzate, ma mantenere obbligatorio il componente di trasformazione rende le cose un po 'più semplici).

— Mortennobel
fonte

La domanda non riguarda quale sia la progettazione basata su componenti. Riguarda il motivo

— bummzack,

Ma Transform è un componente di Unity! docs.unity3d.com/Documentation/ScriptReference/Transform.html . L'unica cosa strana riguardo a Transform è che è un componente obbligatorio per GameObject.

— Mortennobel,

Bene, allora la domanda è: perché non puoi rimuoverlo? L'OP non avrebbe etichettato la sua domanda "basata sui componenti" se non avesse familiarità con il termine.

— Bummzack,

Hai ragione, grazie. Ho aggiornato la risposta per rispondere meglio alla domanda.

— Mortennobel,

La domanda è perché trasformare i dati è un componente separato (al contrario dei semplici dati all'interno di GameObject come nome, maschere di livello, tag). Ho provato a renderlo più chiaro nell'ultima revisione del mio post.

— snake5,

Il TransformComponentè il più difficile Componentper progettare correttamente in architettura videogiochi. Quasi tutti gli altri Componentdevono conoscere GameObjectla posizione, la rotazione o la scala di un dato , quindi disaccoppiare correttamente tutti questi sistemi correlati è intrinsecamente difficile.

Ci saranno sempre compromessi nell'architettura. Essendo TransformComponentstatici (cioè non dinamici), gli sviluppatori di Unity possono scrivere codice sotto questo presupposto. Immagino che questo renda le cose molto più facili dalla loro parte senza aggiungere molti disagi dalla nostra parte. Questo è simile a un paradigma orientato agli oggetti, dove GameObjectsarebbe extendcerto abstract class, Transformable.

— alex
fonte