GameObject как контейнер, компоненты как кубики

Главная идея Unity, без которой ничего не понять: объект сам по себе пустой. Всё, что он умеет, дают ему компоненты.

Суть: GameObject — это пустой контейнер с именем. Компоненты (Component) — это «кубики», которые навешивают на него поведение: рендер спрайта, физику, твой скрипт. Игровой объект = сумма его компонентов. Это называется композиция.

В обычном программировании ты бы создал класс Enemy, унаследовал от него FlyingEnemy и так далее — дерево наследования. Unity идёт другим путём: композиция вместо наследования. Есть пустой GameObject, и ты навешиваешь на него нужные компоненты, как кубики Lego.

Хочешь, чтобы объект был виден? Добавь SpriteRenderer. Хочешь, чтобы падал? Добавь Rigidbody2D. Хочешь, чтобы сталкивался? Добавь Collider2D. Хочешь своё поведение? Добавь скрипт. Объект — это просто набор компонентов.

Как работает под капотом

Внутри Unity GameObject хранит список ссылок на свои компоненты. Когда движок обновляет сцену, он проходит по объектам и дёргает их компоненты.

GameObject "Игрок"
   |
   +-- Transform        -> позиция, поворот, масштаб (есть ВСЕГДА)
   |
   +-- SpriteRenderer   -> рисует картинку героя
   |
   +-- Rigidbody2D      -> физика: гравитация, скорость
   |
   +-- BoxCollider2D    -> форма для столкновений
   |
   +-- PlayerController  -> твой скрипт (поведение)

Обрати внимание: у любого GameObject всегда есть компонент Transform — его нельзя удалить, ведь объект обязан где-то находиться. Все остальные компоненты добавляются по желанию через кнопку Add Component в Inspector.

Смоделируем идею «объект — это набор компонентов» на Python через словарь:

# GameObject = имя + словарь компонентов
player = {
    "name": "Игрок",
    "components": {
        "Transform": {"x": 0, "y": 0},
        "SpriteRenderer": {"sprite": "hero.png"},
        "Rigidbody2D": {"mass": 1.0},
    }
}

def has_component(go, name):
    return name in go["components"]

def add_component(go, name, data):
    go["components"][name] = data

print("Есть физика?", has_component(player, "Rigidbody2D"))
add_component(player, "BoxCollider2D", {"size": [1, 1]})
print("Компоненты:", list(player["components"].keys()))

Та же логика на Python ▶ — именно так Unity и устроен внутри: объект хранит набор компонентов, и ты можешь спросить «есть ли у тебя такой-то компонент?» (в C# это GetComponent<T>()).

Частые ошибки

Искать «класс игрока». Новички ищут единый объект-герой. В Unity герой — это пустышка плюс компоненты. Поведение размазано по компонентам, и это нормально.
Складывать всё в один гигантский скрипт. Лучше несколько маленьких компонентов (движение, здоровье, стрельба), чем один на 1000 строк.
Удалять Transform. Его нельзя удалить — это базовый компонент каждого объекта.

Best practices

Дроби поведение на маленькие компоненты — это и есть «дух Unity». Один компонент — одна ответственность.
Называй объекты и скрипты понятно: Player, EnemyPatrol, HealthBar.
Если двум разным объектам нужно одинаковое поведение — вынеси его в отдельный компонент и навесь на оба.

Итоги: GameObject — пустой контейнер, компоненты дают ему поведение. Это композиция вместо наследования. У объекта всегда есть Transform; остальное добавляешь через Add Component. Думай об объекте как о наборе кубиков — это ключ ко всей архитектуре Unity.

Почему композиция победила наследование

Представь дерево классов: Entity, от него Character, от него Enemy, от него FlyingEnemy. А теперь нужен летающий, но ещё и плавающий враг — и иерархия ломается, потому что один класс не может наследоваться от двух веток сразу. Это знаменитая «проблема ромба» наследования. Композиция её обходит элегантно: летающий враг — это объект с компонентами Fly и Health, плавающий — с Swim и Health, а летающий-плавающий просто получает оба: Fly, Swim, Health. Никаких ромбов, никакого переписывания иерархии. Поведение собирается из кубиков под конкретную задачу. Именно поэтому Unity, Unreal и почти все современные движки построены вокруг компонентов, а не глубоких деревьев классов.