Архитектура игрового проекта: сцены, системы и компоненты

Когда я только начинал разбираться в устройстве игр, меня поражало, насколько хрупкими бывают даже небольшие проекты. Добавляешь одну фичу — и половина механик перестаёт работать. Меняешь баланс у оружия — враги вдруг перестают атаковать. Это не магия и не кривые руки, это отсутствие архитектуры. И речь здесь не о красивой структуре папок в проекте, а о том, как игра вообще живёт: где хранятся данные, кто ими управляет, как переключаются экраны и почему проект остаётся понятным через полгода, а не разваливается после первой же большой фичи.

Хорошая архитектура — это когда вы можете быстро добавить новый контент, меньше ломаете старое и тратите минимум времени на поиск ошибок. Звучит скучно, но на практике это разница между проектом, который вы доделаете, и тем, который бросите от отчаяния на третьем месяце разработки.

Что такое архитектура игрового проекта

Когда говорят «архитектура», часто представляют сложные диаграммы и многобуквенные паттерны. На деле всё проще. Это высокоуровневая организация игры: сцены, игровые объекты, компоненты, системы, менеджеры, сервисы и правила их взаимодействия. В современных подходах сцена выступает как контейнер для конкретного состояния или части игры, а логика распределяется между системами и компонентами, чтобы не смешивать всё в одном монолитном скрипте.

Я сам через это прошёл: первый прототип на Unity выглядел как один огромный скрипт на 800 строк, который управлял и движением, и здоровьем, и UI, и переходами между экранами. Работало. До первого серьёзного изменения. Потом я потратил три дня, чтобы понять, где именно в этом монолите ломается логика спавна врагов.

На практике архитектура сводится к трём вещам:

• сцена отвечает за конкретный экран, уровень или состояние;
• компонент хранит данные или маленькую поведенческую часть объекта;
• система выполняет одну крупную задачу для группы объектов или сущностей.

Такое разделение делает проект масштабируемым: одна часть отвечает за визуал, другая — за правила, третья — за переходы и загрузку. Когда вы через месяц захотите добавить новую механику, вы будете точно знать, куда идти и что менять.

Сцены: зачем они нужны и как ими правильно пользоваться

Сцена — это рабочая единица игры. В ней может быть меню, уровень, кат-сцена, экран паузы или отдельный игровой режим. В Unity и похожих движках сцены обычно используются как способ собрать набор объектов, связанных общей задачей. Это не просто «место, где лежат объекты», а логически завершённый контейнер состояния игры.

Помню свой первый проект: всё лежало в одной сцене. Главное меню, три уровня, экран результатов, настройки — всё вперемешку. Работало через активацию-деактивацию объектов. Выглядело как коммунальная квартира: вроде все живут, но хаос невероятный. Добавить четвёртый уровень было подвигом, потому что приходилось вручную настраивать видимость десятков объектов.

Когда сцена — хороший выбор

Используйте отдельную сцену, если нужно:

• разделить меню, игру и результаты;
• загрузить крупный уровень;
• сбросить временное состояние;
• изолировать тестовую область;
• упростить переход между экранами.

Отдельная сцена — это как чистая комната: зашёл, сделал дело, вышел. Никакого мусора из предыдущего состояния, никаких случайных зависимостей. Особенно это важно при работе с большими уровнями, где счёт объектов идёт на тысячи.

Когда сцену не стоит дробить

Слишком много сцен — тоже проблема. Если вы делите игру на десятки крошечных сцен без понятной причины, усложняется навигация, логика переходов и повторное использование объектов. Часто лучше оставить одну сцену и управлять состояниями внутри неё, если это не требует полноценной загрузки уровня.

Я видел проекты, где каждый экран инвентаря был отдельной сценой. Звучит аккуратно, но на деле порождало монструозную логику переходов и проблемы с сохранением контекста. Не надо дробить ради дробления — каждая сцена должна решать конкретную задачу.

Практический подход к сценам

Надёжная схема обычно выглядит так:

• Bootstrap/Initialization — стартовая сцена для инициализации;
• Persistent/Global — постоянные сервисы, которые живут между экранами;
• Main Menu — меню и настройки;
• Gameplay — игровой процесс;
• UI/Overlay — интерфейс, который нужен во время игры;
• Additive scenes — дополнительные части уровня, загружаемые по необходимости.

Такой подход удобен тем, что не заставляет всё держать в одной огромной сцене и позволяет контролировать, что именно находится в памяти в каждый момент. Additive-загрузка вообще открывает массу возможностей: можно подгружать части уровня по мере продвижения игрока, динамически менять окружение или включать дополнительные режимы без перезагрузки всей сцены. Я активно использую это для процедурно генерируемых подземелий — основная сцена содержит только структуру, а наполнение загружается аддитивно.

Системы: кто делает работу внутри игры

Система — это модуль, который отвечает за одну область логики: ввод, боёвку, физику, инвентарь, сохранения, анимации, звук, UI. В хорошо организованном проекте система не пытается делать всё сразу. Она решает одну задачу и общается с другими частями через события, данные или сервисы.

Когда я только начинал, у меня была «GameManager» — система, которая делала вообще всё. Спавнила врагов, считала очки, управляла UI, сохраняла прогресс, проигрывала музыку и даже обрабатывала ввод. Это работало ровно до того момента, пока я не решил добавить мультиплеер. Тогда весь этот монолит пришлось выкинуть и писать заново.

Примеры систем

Хорошая система — это не «бог-объект», а понятный модуль с узкой ответственностью. Если одна система начинает включать в себя и инвентарь, и квесты, и диалоги, и автосохранение, и спавн врагов, архитектура уже пошла не туда. Я проверяю это простым тестом: могу ли я объяснить, что делает система, в одном предложении? Если нужно три абзаца — пора делить.

Компоненты: строительные блоки поведения

Компоненты — это маленькие части поведения или данных, которые прикрепляются к объекту. В компонентном подходе объект не обязан «знать» всё о себе. Он собирается из отдельных частей: визуал, физика, здоровье, управление, анимация, звук. Это как конструктор LEGO: каждый кубик делает что-то одно, но вместе они создают сложное поведение.

Помню, как меня поразила эта идея, когда я впервые открыл Unity. Вместо того чтобы писать класс «Враг», наследующий от «Персонажа», который наследует от «Игрового объекта», я просто накидывал компоненты на пустой GameObject. Нужно здоровье — добавляем HealthComponent. Нужно движение — добавляем MovementComponent. Нужна анимация — AnimatorComponent. Никакой сложной иерархии наследования, только композиция.

Простое объяснение

Представьте персонажа как конструктор:

• один компонент отвечает за перемещение;
• другой — за здоровье;
• третий — за анимацию;
• четвёртый — за получение урона.

Если нужно изменить только здоровье, не придётся переписывать весь персонаж целиком. Это особенно ценно, когда у вас в игре 20 типов врагов, и каждый отличается только парой параметров. Вместо 20 классов вы создаёте 20 префабов с разными комбинациями компонентов.

Два типа компонентов

• Данные — хранят параметры: скорость, урон, запас HP, радиус атаки.
• Поведенческие — выполняют действие: движение, стрельбу, проигрывание анимации, реакцию на столкновение.

Чем лучше разделены данные и поведение, тем проще поддерживать проект. Это особенно заметно, когда появляются разные типы врагов, оружия или предметов. Я стараюсь выносить данные в ScriptableObject — это позволяет менять баланс без правки кода и даёт возможность не-программистам (дизайнерам, например) настраивать игру.

Сцены, системы и компоненты: как они связаны между собой

Упрощённо схема выглядит так:

• сцена содержит окружение и набор активных объектов;
• объекты состоят из компонентов;
• системы проходят по нужным объектам и выполняют логику;
• сервисы обслуживают проект целиком и живут дольше отдельной сцены.

Это не жёсткая иерархия, а скорее слои ответственности. Сцена не управляет системами, системы не владеют сценой — они существуют параллельно и взаимодействуют через чётко определённые интерфейсы.

Пример на практике

Допустим, в игре есть враг:

• сцена хранит сам уровень;
• враг как объект содержит компонент здоровья, агрессии и модели;
• система боя наносит урон;
• система AI решает, когда атаковать;
• система анимации проигрывает нужное действие;
• система UI показывает полоску HP, если она нужна на экране.

Такой подход позволяет менять одну часть без переписывания остальных. Хотите улучшить AI? Меняете только систему AI. Решили переработать визуал здоровья? Правите UI систему и компонент здоровья. Всё остальное продолжает работать как ни в чём не бывало. Это не теория — это то, что спасает проекты на поздних стадиях разработки.

Типовая архитектура для инди-проекта

Для небольшого проекта не нужно сразу строить сложный фреймворк. Часто достаточно здравой базовой схемы. Я видел слишком много новичков, которые начинали с внедрения ECS и DI-контейнеров в игру размером с Pong. Это как использовать промышленный экскаватор, чтобы посадить цветок в горшке — можно, но зачем?

Рекомендуемая структура

• Core — инициализация, настройки, глобальные сервисы;
• Gameplay — механики, враги, предметы, уровни;
• UI — меню, HUD, окна;
• Audio — музыка и звуки;
• Save — прогресс и конфиги;
• Tools — вспомогательные редакторские утилиты.

Это не догма, а отправная точка. В моём текущем проекте, например, Tools разрослись в целую подсистему с кастомными инспекторами и генераторами контента. Но начинал я именно с такой простой структуры.

Что важно сразу продумать

• где лежат общие данные;
• как происходит переход между сценами;
• кто создаёт и уничтожает объекты;
• как работают события;
• как сохраняется прогресс;
• где находится «точка входа» игры.

Если эти вопросы отложить, проект быстро превращается в набор скриптов, связанных между собой случайными ссылками. Я через это прошёл: в какой-то момент мой проект напоминал спагетти, где каждый скрипт через FindObjectOfType находил нужный менеджер. Работало медленно, ломалось часто, отлаживать было невозможно.

Три принципа, которые спасают архитектуру

1. Один модуль — одна ответственность

Если скрипт управляет всем подряд, его будет трудно тестировать, менять и переиспользовать. Это не просто красивые слова — это практика. Когда у вас скрипт одновременно двигает персонажа, проверяет коллизии, воспроизводит звуки шагов и обновляет UI, любое изменение в одной области рискует сломать всё остальное.

2. Данные отдельно от логики

Параметры лучше хранить отдельно от кода, особенно если их нужно часто менять: баланс, характеристики оружия, числа для врагов, настройки уровня. Я использую ScriptableObject для этого — создал однажды, настроил, и никакой магии с числами в коде. Дизайнер может сам крутить баланс, не заходя в скрипты и не рискуя что-то сломать.

3. Слабая связность между частями

Чем меньше прямых зависимостей, тем легче менять проект. Вместо того чтобы один объект напрямую знал о десяти других, лучше использовать события, посредников или сервисы. На практике это означает: когда враг умирает, он не ищет UI-менеджер, чтобы обновить счёт, а просто вызывает событие «EnemyDied». UI-менеджер подписан на это событие и реагирует сам. Враг не знает о существовании UI, UI не знает о конкретном враге — красота.

Ошибки, которые ломают проект

Частые проблемы

• Одна огромная сцена на всю игру
  Удобно в начале, мучительно дальше. Я так делал — потом сцена грузилась 40 секунд, а редактор тормозил нещадно.
• Один скрипт на всё
  Вроде быстро, но потом невозможно понять, что именно он делает. Классический God Object, который со временем становится неуправляемым.
• Прямые связи между объектами везде
  Любое изменение тянет за собой цепочку поломок. Поменяли префаб игрока — сломались все враги, которые на него ссылались.
• Данные захардкожены в коде
  Баланс становится неуправляемым. Чтобы поменять урон у меча, нужно лезть в код, перекомпилировать проект и молиться, что ничего не сломалось.
• Менеджер на каждый чих
  Когда всё называют manager, проект теряет смысловую структуру. PlayerManager, EnemyManager, BulletManager, ParticleManager — за этими названиями часто скрывается просто набор методов без внятной архитектуры.

Как понять, что архитектура уже плохая

Есть несколько простых сигналов, которые я выработал на собственном горьком опыте:

• чтобы добавить новую механику, приходится менять 5–7 старых файлов;
• один и тот же код копируется в разные места;
• сцену страшно открывать в редакторе;
• невозможно объяснить, что делает конкретный скрипт, не читая его 200 строк;
• баги появляются после правок в, казалось бы, не связанных системах.

Если такое началось, пора не «допиливать», а пересобирать структуру. Да, это больно. Да, это займёт время. Но альтернатива — проект, который вы никогда не закончите, потому что каждая новая фича будет ломать три старых. Я проходил через рефакторинг дважды в своём основном проекте, и оба раза это было правильное решение, хотя и очень неприятное в моменте.

Пошаговый план: как спроектировать архитектуру нового проекта

Шаг 1. Определите границы игры

Сначала ответьте на вопросы:

• что является отдельной сценой;
• какие состояния есть у игры;
• какие системы обязательны;
• что должно переживать смену сцен.

Не пытайтесь предусмотреть всё — это невозможно. Но базовые границы должны быть понятны до того, как вы напишете первую строку кода.

Шаг 2. Выделите ядро

Сразу обозначьте:

• загрузку;
• сохранения;
• аудио;
• ввод;
• глобальные настройки.

Это то, что будет жить дольше одной сцены и обслуживать весь проект. В Unity это обычно делается через DontDestroyOnLoad и синглтоны (или DI-контейнеры, если вы готовы к более сложному подходу).

Шаг 3. Разбейте геймплей на модули

Например:

• движение;
• бой;
• инвентарь;
• квесты;
• враги;
• интерфейс.

Каждый модуль — кандидат на отдельную систему. Не надо сразу проектировать все до мелочей, но понимание границ модулей спасёт от хаоса в будущем.

Шаг 4. Опишите связи

Решите заранее:

• кто кого уведомляет;
• где использовать события;
• где допустимы прямые ссылки;
• что хранится в данных, а что считается логикой.

Я обычно рисую простую схему на бумаге: прямоугольники — системы, стрелки — события. Это занимает 15 минут, но экономит дни разработки потом.

Шаг 5. Проверьте на изменяемость

Хороший вопрос для проверки:
«Если завтра добавится новый тип врага, мне придётся переписывать архитектуру или просто добавить новый компонент и конфиг?»

Если ответ второй — структура близка к здоровой. Если первый — возвращайтесь к шагу 3 и пересматривайте границы модулей. Это не паранойя, а здоровая практика: хорошая архитектура должна быть устойчива к расширению.

Чек-лист перед стартом разработки

• Понятно, какие сцены есть в проекте
• Есть точка входа и инициализация
• Выделены постоянные сервисы
• Логика разделена по ответственностям
• Данные вынесены отдельно от кода
• Переходы между сценами описаны
• Есть способ обмена событиями
• Проект можно расширять без переписывания половины системы

Я держу этот чек-лист перед глазами, когда начинаю новый проект. Не всё получается идеально с первого раза, но он помогает не уйти в совсем уж дикие дебри на старте.

Таблица: что выбирать в разных случаях

Это не жёсткие правила, а рекомендации, проверенные практикой. В небольших проектах можно отходить от них, но чем больше становится игра, тем важнее придерживаться такого разделения.

FAQ

Чем сцена отличается от системы?

Сцена — это контейнер для части игры или её состояния. Система — это логика, которая обрабатывает данные и объекты внутри этой сцены или проекта в целом. Сцена отвечает на вопрос «где?», система — на вопрос «как?». Сцена может существовать без систем (пустой уровень), система может работать跨-сценно (например, аудиосистема).

Можно ли делать игру только на компонентах?

Да, но без систем и понятной структуры проект быстро станет хаотичным. Компоненты хороши как строительные блоки, а не как единственная архитектурная идея. Я пробовал — получается мешанина из компонентов, которые ищут друг друга через GetComponent, и логика размазывается тонким слоем по десяткам объектов. Работает для очень маленьких игр, но расти не может.

Нужны ли менеджеры в проекте?

Нужны, если они действительно управляют отдельной областью: аудио, загрузкой, сохранением, сценами. Проблема начинается тогда, когда один менеджер начинает делать всё. Хороший менеджер — это система с понятным названием и узкой ответственностью. Плохой менеджер — это свалка методов, которую назвали менеджером для солидности.

Что лучше для новичка: простая или сложная архитектура?

Простая, но не хаотичная. На старте важнее понять границы ответственности, чем внедрять сложные паттерны ради вида. Я начинал с монолита, потом перешёл к разделению на сцены и системы, потом уже к DI и событийной шине. Не пытайтесь перепрыгнуть этапы — каждый следующий уровень сложности должен решать реальные проблемы, а не гипотетические.

Когда стоит переходить на более строгую архитектуру?

Когда проект начинает расти: появляются новые режимы, сцены, типы объектов, сохранения, сложный UI и несколько систем, которые завязаны друг на друга. Если вы чувствуете, что каждое изменение даётся всё тяжелее — это сигнал. Не ждите, пока проект превратится в неразгребаемый хаос, но и не стройте космический корабль для игры в крестики-нолики.

Вывод

Архитектура игрового проекта — это способ сделать игру управляемой. Сцены отвечают за крупные состояния и части мира, системы — за отдельные области логики, компоненты — за сборку поведения из маленьких блоков. Если с самого начала разделить эти уровни, проект будет проще развивать, тестировать и передавать другим людям.

Главная мысль простая: не пытайтесь запихнуть всю игру в один скрипт, одну сцену и одну идею. Чем раньше появятся понятные границы между сценами, системами и компонентами, тем меньше времени уйдёт на борьбу с хаосом и тем быстрее появится реально работающий проект. Я прошёл этот путь от первого трейнера до собственных прототипов на Unity, и могу сказать точно: хорошая архитектура — это не про «правильно», это про «возможно». Возможно закончить проект, возможно добавить новую фичу, возможно не сойти с ума при отладке. И это стоит того, чтобы потратить время на проектирование в самом начале.