Przyczyny powstania silnika Unity3D (obiekt gry / komponent transformacji)

Próbuję zrozumieć uzasadnienie konstrukcji silnika Unity3D i jest to coś, o czym jeszcze nie mogę się zastanowić : dlaczego dane transformacji są przechowywane w osobnym składniku, zamiast być częścią GameObject, jak nazwa, maski warstw i tagi? Zresztą nie można go usunąć tak jak wszystkich innych komponentów, nie ma alternatywy, a zatem nie trzeba go usuwać.

architecture unity component-based

— snake5
źródło

Dla mnie to brzmi jak dziedzictwo architektury. Być może ten komponent transformacji był zwykłym, opcjonalnym komponentem, więc można mieć obiekty „poza” przestrzenią kartezjańską. Następnie pewne ograniczenie implementacji (optymalizacja?) Wymagało, aby ten komponent był zawsze obecny i tak pozostał. Ale to tylko przypuszczenie, że inżynier Unity potrzebowałby prawdziwej odpowiedzi na to pytanie.

— Laurent Couvidou,

Odpowiedzi:

Tylko programiści Unity mogą dać prawdziwą motywację do tego projektu, ale jednym argumentem przemawiającym za zrobieniem tego w ten sposób jest argument, że każda klasa w projekcie oprogramowania powinna ponosić jedną i tylko jedną odpowiedzialność . GameObject to nazwana kolekcja Komponentów, a dodanie pozycji / rotacji / etc do tego oznacza, że miałby on 2 obowiązki. Komponent Transform obsługuje położenie i obrót, dlatego też nie powinien być odpowiedzialny za nazewnictwo ani agregowanie innych (potencjalnie niepowiązanych) komponentów. Dlatego te 2 koncepcje mają sens w 2 osobnych obiektach.

Mówiąc bardziej ogólnie, pytanie to brzmi „jeśli istnieje relacja 1 do 1 między X i Y, dlaczego Y nie jest częścią X lub odwrotnie?” I ogólna odpowiedź jest taka, że oprogramowanie jest łatwiejsze do opracowania i utrzymania, gdy jest podzielone na mniejsze samodzielne części, nawet jeśli 2 części zawsze współpracują razem.

— Kylotan
źródło

Rozważyłem to również, ale mogli przenieść filtr GameObject (warstwy, tagi) do osobnego komponentu z tego samego powodu - a jednak nie zrobili tego. Co więcej, komponent transformacji jest zbyt głęboko związany w systemie poprzez przechowywanie danych hierarchii (rodzic, potomek itp.).

— snake5

Można argumentować, że warstwy i znaczniki są formą nazewnictwa, powinny występować obok nazwy, a więc są nieodłączną częścią tego, co stanowi zbiór składników w systemie. Jeśli chodzi o transformacje utrzymujące rodzicielstwo, masz rację, ale nikt nie twierdził, że system Jedności jest doskonały. Gdyby to był mój system, oddzieliłbym Transforms osobno i przeniósłbym rodzica / dzieci do GameObject.

— Kylotan,

Transformacja jest obowiązkowym elementem Jedności.

Powodem, dla którego transformacja jest obowiązkowym elementem, jest to, że obiekty gry znajdują się w scenie i dlatego potrzebują informacji przestrzennych (pozycji, orientacji i skali) na temat tego obiektu. (Ta informacja nie zawsze jest wykorzystywana, ale utrzymanie obowiązkowego komponentu transformacji sprawia, że rzeczy są nieco prostsze).

— Mortennobel
źródło

Pytanie nie dotyczy tego, czym jest projekt oparty na komponentach. Chodzi o to, dlaczego „transformacja” również nie jest składnikiem

— bummzack

Ale Transformacja jest elementem Jedności! docs.unity3d.com/Documentation/ScriptReference/Transform.html . Jedyną dziwną rzeczą w transformacji jest to, że jest ona obowiązkowym składnikiem GameObject.

— Mortennobel

Myślę, że wtedy pytanie dotyczy tego, dlaczego nie możesz go usunąć? OP nie określiłby swojego pytania jako „oparte na komponentach”, gdyby nie znał tego terminu.

— bummzack

Masz rację - dzięki. Zaktualizowałem odpowiedź, aby lepiej odpowiedzieć na pytanie.

— Mortennobel

Pytanie dotyczy tego, dlaczego dane transformacji są osobnym składnikiem (w przeciwieństwie do zwykłych danych w GameObject, takich jak nazwa, maski warstw, znaczniki). Próbowałem to wyjaśnić w najnowszej wersji mojego postu.

— snake5

Jest TransformComponentto najtrudniejszy Componentdo prawidłowego zaprojektowania w architekturze gier wideo. Prawie każdy inny Componentmusi wiedzieć o danymGameObject pozycji, rotacji lub skali, więc prawidłowe oddzielenie wszystkich tych wzajemnie powiązanych systemów jest z natury trudne.

W architekturze zawsze pojawią się kompromisy. Będąc TransformComponentstatycznym (tj. Nie dynamicznym), programiści w Unity mogą pisać kod przy takim założeniu. Zakładam, że dzięki temu rzeczy stają się znacznie łatwiejsze po ich stronie, nie powodując przy tym znacznych niedogodności. Jest to podobne do paradygmatu obiektowego, gdzie GameObjectbędzie extendpewnym abstract class, Transformable.

— Alex
źródło