Причини дизайну двигуна Unity3D (ігровий об’єкт / компонент перетворення)

Я намагаюся зрозуміти міркування, що стоять за дизайном двигуна Unity3D, і це те, про що я поки не можу оглянути: чому дані перетворення зберігаються в окремому компоненті, а не входять до GameObject, як-от ім'я, маски шару та теги? Її не можна видалити, як і всі інші компоненти, так чи інакше, немає альтернатив, і тому немає необхідності в її видаленні.

architecture unity component-based

— змія5
джерело

Для мене це звучить так, як це звучить як архітектурна спадщина. Можливо, цей компонент перетворення був звичайним, необов'язковим компонентом, тому ви могли мати об'єкти «поза» декартового простору. Тоді деяке обмеження в реалізації (оптимізація?) Вимагало, щоб цей компонент був завжди присутній, і він залишався таким. Але це лише припущення, інженеру з Unity знадобиться реально відповісти на це питання.

— Лоран Кувіду

Відповіді:

Тільки розробники Unity можуть дати справжню мотивацію цього дизайну, але один аргумент на підтримку цього зробити так, що існує аргумент, що кожен клас у проектному проекті повинен нести одну і лише одну відповідальність . GameObject - це іменований набір компонентів, і додавання позиції / обертання / тощо до цього означає, що вона матиме 2 обов'язки. Компонент Transform обробляє положення та обертання, а тому не повинен також нести відповідальність за іменування або агрегацію інших (потенційно не пов'язаних) компонентів. Тому має сенс існування цих 2 понять у двох окремих об'єктах.

Загалом, це питання задає "якщо між X і Y існує взаємозв'язок від 1 до 1, чому Y не є частиною X або навпаки?" І загальна відповідь полягає в тому, що програмне забезпечення легше розробляти та підтримувати, коли їх розбивають на менші автономні частини, навіть якщо 2 частини завжди працюють разом.

— Kylotan
джерело

Я також вважав це, але вони могли перенести фільтрування GameObject (шари, теги) в окремий компонент через ту ж причину - і все ж вони цього не зробили. Крім того, компонент трансформації пов'язаний занадто глибоко в системі, зберігаючи дані ієрархії (батьків, дітей тощо).

— змія5

Можна стверджувати, що шари та теги є формою іменування, повинні жити поряд з назвою, і тому є невід'ємною частиною того, що становить сукупність компонентів у системі. Щодо перетворень, які проводять батьківство, у вас є точка, але ніхто не стверджував, що система Unity є досконалою. Якби це була моя система, я б тримав Transforms окремо і переміщав батьків / дітей до GameObject.

— Kylotan

Трансформація є обов'язковим компонентом в Єдності.

Причина, чому трансформація є обов'язковим компонентом, полягає в тому, що ігрові об’єкти розташовані на сцені і для цього потрібна просторова інформація (положення, орієнтація та масштаб) про цей об’єкт. (Ця інформація використовується не завжди, але обов'язкове використання компонента перетворення робить речі дещо простішими).

— Mortennobel
джерело

Питання не в тому, що таке компонентний дизайн. Йдеться про те, чому "трансформація" також не є складовою

— bummzack

Але Трансформація - складова в Єдності! docs.unity3d.com/Documentation/ScriptReference/Transform.html . Єдине дивне в трансформації - це обов'язковий компонент для GameObject.

— Mortennobel

Я гадаю, тоді питання полягає в тому, чому ви не можете його видалити? ОП не позначила б його питання "на основі компонентів", якби він не був ознайомлений із цим терміном.

— bummzack

Ви маєте рацію - дякую. Я оновив відповідь, щоб краще відповісти на питання.

— Mortennobel

Питання полягає в тому, чому дані перетворення є окремим компонентом (на відміну від простих даних всередині GameObject, таких як ім'я, маски шарів, теги). Я намагався зробити це більш зрозумілим в останній редакції моєї посади.

— змія5

TransformComponentЄ найбільш важкою Componentдля правильного проектування в ігровій архітектурі. Практично кожен інший Componentповинен знати про дану GameObjectпозицію, обертання чи масштаб, тому належним чином роз'єднати всі ці взаємопов'язані системи по суті складно.

В архітектурі завжди будуть компроміси. Маючи TransformComponentстатичну (тобто не динамічну), розробники Unity можуть писати код під цим припущенням. Я б припустив, що це значно полегшує справи на їхньому боці, не додаючи багато незручностей на нашому боці. Це схоже на об'єктно-орієнтовану парадигму, де GameObjectб extendякийсь - то abstract class, Transformable.

— Олексій
джерело