Перейти к основному содержимому

1.18. Архитектура компьютерной игры

ДЛЯ НОВИЧКОВНЕ ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ
Всем

Архитектура компьютерной игры​

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

Архитектура как свойство системы, а не как документ​

Согласно стандарту IEEE 1471–2000 (ныне заменённому ISO/IEC/IEEE 42010:2011), архитектура — это базовая организация системы, воплощённая в её компонентах, их взаимосвязях, а также в принципах, управляющих проектированием и эволюцией системы. Это определение подчёркивает: архитектура существует объективно — будучи свойством самой системы — независимо от того, зафиксирована ли она в документах или диаграммах. Любая игра, даже если она создавалась без предварительного проектирования, обладает архитектурой. Эта архитектура может быть неосознанной, неявной, хаотичной или избыточно связанной, но она присутствует как результат совокупности решений, принятых в процессе разработки.

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

Модель архитектуры в терминах UML и системного мышления​

В методологии UML (Unified Modeling Language) архитектура определяется как структура организации и связанное с ней поведение системы. Эта структура поддаётся рекурсивной декомпозиции: система раскладывается на части (подсистемы, компоненты, классы), причём каждая из этих частей взаимодействует с другими через чётко определённые интерфейсы. Связи между частями описываются статически (кто с кем соединён) и динамически: какие условия требуются для сборки подсистем, в каких контекстах допустимы вызовы, какие гарантии предоставляет каждая сторона интерфейса.

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

Архитектура как инструмент управления сложностью​

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

Такое разделение позволяет:

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

Ключевой момент здесь — значимость выбранного уровня абстракции. Архитектурное описание не обязано включать все классы, методы или переменные. Оно фокусируется на тех элементах, которые определяют стратегические свойства системы: её масштабируемость, производительность, расширяемость, стабильность, соответствие техническим ограничениям платформы. Детали реализации — например, выбор конкретного алгоритма сортировки в списке объектов рендеринга — относятся к уровню проектирования (design), а не архитектуры (architecture), если только этот выбор не оказывает системного влияния (скажем, требует изменения парадигмы обработки кадров).

Где проходит граница между архитектурой и деталями реализации?​

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

  • выбор парадигмы обработки кадров: фиксированный или переменный game loop;
  • организация сцен: единое дерево сцены с компонентами versus раздельные менеджеры для разных типов объектов;
  • стратегия управления памятью: пулы объектов, регионы, сборка мусора или ручное управление;
  • модель сетевого взаимодействия: peer-to-peer, авторитетный сервер, клиент-предсказание с компенсацией;
  • подход к ресурсам: загрузка по требованию, потоковая загрузка, предварительная инициализация.

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

Архитектурное описание как логическая конструкция​

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

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

Без этого логического сопровождения диаграмма остаётся декоративной иллюстрацией, не помогающей в принятии решений или разрешении конфликтов. Именно аргументация делает архитектуру действенным инженерным инструментом.

Архитектура и жизненный цикл игры​

Процесс формирования архитектуры не обязательно линеен и не всегда предшествует кодированию. В практике игровой индустрии распространены следующие подходы:

  • архитектура «сверху вниз» — подробное планирование структуры перед написанием кода; характерно для крупных студий, AAA-проектов, проектов с жёсткими требованиями к совместимости и поддержке;
  • архитектура «снизу вверх» — постепенная эмерджентность структуры по мере роста кодовой базы; типично для инди-разработки, прототипирования, экспериментальных проектов;
  • эволюционная архитектура — сознательное принятие временной неоптимальной структуры на ранних этапах при условии, что предусмотрены механизмы её последующей рефакторинговой трансформации.

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

Кроме того, наличие архитектурного описания существенно облегчает передачу знаний в расширяющейся команде, внедрение стандартов (например, код-ревью по архитектурным критериям), а также управление ожиданиями со стороны нетехнических стейкхолдеров: продюсеров, художников, дизайнеров уровней — за счёт перевода технических ограничений в понятные им термины («мы не можем добавить динамическое освещение в эту сцену, потому что текущая архитектура рендеринга не поддерживает deferred shading без полной переписки шейдерного конвейера»).

Общая схема компонентов игровой программы​

Любая компьютерная игра, от простейшего аркадного прототипа до многопользовательского AAA-проекта, реализуется в виде программы, структурированной на несколько логических уровней. Эти уровни не всегда физически разделяются в коде (особенно в небольших проектах), но всегда присутствуют концептуально и определяют, какие задачи решаются на каком уровне ответственности.

На самом высоком уровне выделяют движок и игровую логику. Движок — это многократно используемая основа, предоставляющая инфраструктурные сервисы: управление памятью, загрузку ресурсов, рендеринг, физику, звук, обработку ввода, сетевое взаимодействие. Игровая логика — это уникальный для конкретной игры код: правила, поведение персонажей, сценарии событий, дизайн уровней. Разделение между движком и логикой не всегда строгое (в некоторых инди-движках граница размыта), но стремление к такому разделению является одним из ключевых архитектурных принципов — оно позволяет повторно использовать техническую базу и снижает риски при изменении геймплея.

Внутри движка принято выделять следующие крупные подсистемы:

  • Система рендеринга — отвечает за преобразование виртуального трёхмерного (или двумерного) мира в изображение на экране. Включает управление материалами, шейдерами, камерами, освещением, тенями, постобработкой. Может быть построена поверх низкоуровневых графических API (Vulkan, DirectX, Metal) или использовать промежуточный слой абстракции.

  • Система физики и коллизий — обеспечивает симуляцию механики: гравитацию, импульсы, трение, столкновения. Может быть основана на библиотеках (PhysX, Box2D, Bullet) или реализована вручную. Часто работает с собственным внутренним временным шагом, независимо от частоты кадров рендеринга.

  • Система анимации — управляет скелетной и морфинговой анимацией, блендингом анимаций, синхронизацией с физикой и игровыми событиями.

  • Система звука — загрузка, микширование, пространственное позиционирование, эффекты (реверберация, доплер), синхронизация с визуальными событиями.

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

  • Система управления сценой — хранение иерархии объектов (часто в виде дерева сцены), управление их жизненным циклом, обновление трансформаций, распространение событий.

  • Система скриптов и поведения — среда выполнения пользовательских (обычно высокоуровневых) сценариев: Lua, C#, Python, или собственный DSL. Обеспечивает интеграцию с нативным кодом через API.

  • Система сохранения и загрузки — сериализация состояния мира, управления версиями, совместимостью между патчами.

  • Система ресурсов — управление жизненным циклом ассетов (модели, текстуры, аудио), кэширование, потоковая загрузка, разгрузка по требованию.

  • Сетевая подсистема — при наличии многопользовательского режима: синхронизация, репликация, прогнозирование, компенсация задержек, обработка читерства.

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

Не все игры содержат все перечисленные подсистемы. Для 2D-платформера может отсутствовать полноценная физика, для текстовой адвенчуры — система рендеринга в общепринятом смысле, для оффлайн-головоломки — сетевая подсистема. Архитектура всегда отражает конкретные требования проекта.

Цикл обработки событий (game loop)​

Центральным элементом архитектуры почти любой игры является цикл обработки событий, или game loop. Это бесконечный (до выхода из игры) цикл, в котором последовательно выполняются этапы, обеспечивающие непрерывное обновление состояния мира и его визуализацию. В отличие от классических событийно-ориентированных приложений (например, веб-серверов или десктопных GUI), где цикл ожидает внешних триггеров, игровой цикл активен: он постоянно работает, даже в отсутствие ввода пользователя, чтобы поддерживать иллюзию непрерывного движения и реакции.

Стандартный game loop состоит из трёх основных фаз:

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

  2. Обновление состояния (update) — ядро логики игры. Здесь обрабатываются команды от ввода, рассчитываются физические взаимодействия, обновляются анимации, происходит принятие решений ИИ, проверяются условия победы/поражения, запускаются триггеры и скрипты. Эта фаза может быть разбита на несколько подэтапов с разной частотой вызова: например, физика может обновляться с фиксированным шагом 60 Гц, а логика ИИ — с переменным шагом, привязанным к частоте кадров.

  3. Отрисовка (render) — преобразование текущего состояния мира в изображение. Сбор видимых объектов, построение команд рендеринга, отправка их в графический API, вывод на экран. Эта фаза может выполняться реже, чем обновление (например, при вертикальной синхронизации), или ускоряться за счёт интерполяции между состояниями.

Критически важным для стабильности и предсказуемости является управление временем внутри цикла. Существуют два основных подхода:

  • Переменный временной шаг (variable timestep) — длительность обновления равна реальному времени, прошедшему с предыдущего кадра. Преимущество: максимальное использование доступной производительности. Недостаток: поведение системы становится зависимым от частоты кадров: при падении FPS объекты движутся медленнее, физика теряет стабильность, синхронизация в сетевой игре нарушается.

  • Фиксированный временной шаг (fixed timestep) — обновление выполняется с постоянной частотой (например, 50 раз в секунду), независимо от времени рендеринга. Если рендеринг отстаёт, обновления накапливаются и выполняются пачками; если рендеринг опережает — вставляются паузы или выполняется интерполяция. Преимущество: детерминированность, стабильность физики, простота сетевой синхронизации. Недостаток: потенциальная потеря производительности (ожидание следующего шага), сложность реализации.

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

Game loop также отвечает за обработку системных событий, не связанных с геймплеем: изменение разрешения окна, потеря фокуса, переход в фоновый режим, сигналы ОС. Эти события могут требовать приостановки обновления (но не обязательно рендеринга — например, для показа затемнённого меню паузы), пересоздания графических ресурсов или освобождения памяти.

Модульность архитектуры​

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

На уровне движка модульность означает, что подсистемы могут быть:

  • включены или выключены без перекомпиляции всей программы (например, через конфигурационные флаги);
  • заменены на альтернативные реализации (например, PhysX → Bullet, FMOD → Wwise);
  • расширены без изменения ядра (через плагины, скрипты, пользовательские компоненты).

Это достигается за счёт чёткого определения интерфейсов и соблюдения принципа инверсии зависимостей: высокоуровневые модули не зависят от низкоуровневых, а оба зависят от абстракций. Например, игровая логика не вызывает функции PhysX::Rigidbody::ApplyForce, а работает с интерфейсом IRigidbody, реализация которого может быть подменена.

На уровне игровых объектов модульность чаще всего реализуется через компонентную модель. В отличие от иерархии наследования («персонаж — наследник от движущегося объекта, который — наследник от физического тела»), компонентная модель предполагает, что объект представляет собой контейнер (обычно сущность), к которому прикрепляются независимые компоненты: Transform, Renderer, Rigidbody, Health, AIController. Каждый компонент отвечает за одну функцию, не знает о других компонентах напрямую, а взаимодействует через сущность или через системные менеджеры.

Более продвинутой формой является ECS (Entity-Component-System) — архитектурный паттерн, в котором:

  • Сущности (Entity) — просто уникальные идентификаторы;
  • Компоненты (Component) — чистые данные (структуры без методов);
  • Системы (System) — процедуры, которые выбирают сущности по наличию определённого набора компонентов и обрабатывают их данные (например, система MovementSystem находит все сущности с Position, Velocity, Rigidbody и обновляет Position в соответствии с Velocity).

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

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

Принципы реального времени и детерминированности в играх​

Игры относятся к классу систем реального времени (real-time systems), однако с важным уточнением: они почти всегда являются мягкими (soft real-time), а не жёсткими (hard real-time). В жёстких системах (авионика, промышленные контроллеры) пропуск временной дедлайна считается катастрофой. В играх пропуск дедлайна (например, не уложился в 16.6 мс для 60 FPS) приводит к просадке частоты кадров, но не к аварийной остановке. Тем не менее, требования к предсказуемым временным характеристикам остаются высокими, так как пользовательский опыт напрямую зависит от плавности и отзывчивости.

Основные временные требования в играх:

  • Время отклика (latency) — задержка между действием пользователя (нажатие клавиши) и визуальной/слуховой реакцией. Должна быть минимальной (в идеале < 50 мс), иначе возникает ощущение «заторможенности».
  • Стабильность частоты кадров (frame pacing) — средний FPS, отсутствие джиттера (неравномерности интервалов между кадрами). Рывки раздражают сильнее, чем постоянные 30 FPS.
  • Синхронизация подсистем — физика, анимация и рендеринг должны быть согласованы во времени, иначе возникают визуальные артефакты (например, «дрожание» объектов при интерполяции).

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

  • Сетевой синхронизации по принципу lockstep — когда все клиенты выполняют одну и ту же симуляцию, обмениваясь только командами;
  • Воспроизведения демозаписей (replays) — для анализа, обучения или создания контента;
  • Автоматизированного тестирования — особенно для баланса, баланс-патчей, ИИ;
  • Поиска ошибок — детерминированное воспроизведение бага упрощает отладку.

Достижение детерминированности — нетривиальная задача. Она нарушается множеством факторов:

  • использование float с неодинаковыми режимами округления на разных CPU/GPU;
  • неопределённый порядок итерации по хеш-таблицам;
  • системные вызовы с непредсказуемым временем выполнения;
  • мультитрединг без строгой синхронизации;
  • неинициализированные переменные.

Поэтому в сетевых и соревновательных играх часто применяются меры: использование fixed-point арифметики вместо float, отказ от стандартных контейнеров с неопределённым порядком, строгий контроль инициализации, отключение всех несущественных источников недетерминизма.

В однопользовательских играх, где нет необходимости в синхронизации, допустимы недетерминированные элементы (например, случайная генерация локаций), если они не влияют на баланс. Важно понимать: архитектура должна явно определять, где допустима недетерминированность, а где она запрещена, и обеспечивать соответствующие гарантии.

Типовые архитектурные стили в игровой разработке​

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

Монолитная архитектура​

Это классическая, наиболее часто встречающаяся структура: вся игра представляет собой единый исполняемый модуль с внутренней декомпозицией на подсистемы. Подсистемы могут быть логически разделены (например, по пространствам имён или директориям), но компилируются в один двоичный файл и запускаются в одном процессе. Преимущества — минимальные накладные расходы на межмодульное взаимодействие, упрощённая отладка, предсказуемая производительность. Недостатки — сложность повторного использования частей, высокий риск неявных зависимостей, затруднённое тестирование подсистем изолированно. Большинство инди-игр и движков среднего масштаба (включая ранние версии Unity) строятся по монолитному принципу. Архитектурная дисциплина в таком случае обеспечивается за счёт внутренних соглашений и инструментов статического анализа.

Сценарная (data-driven) архитектура​

Здесь поведение игры определяется кодом, но в значительной степени — внешними данными: конфигурационными файлами, таблицами баланса, скриптами, графами поведения (behaviour trees, state machines), визуальными сценариями (blueprints). Код реализует только интерпретатор этих данных, а не логику напрямую. Это позволяет отделять дизайн от программирования, ускорять итерации и вовлекать нетехнических специалистов (гейм-дизайнеров, сценаристов) в процесс тонкой настройки. Важно, что data-driven не означает «всё настраивается в редакторе» — речь о чётком разделении: код отвечает за возможности, данные — за конкретику. Unreal Engine — яркий пример: C++ предоставляет базовые примитивы, а логика уровня и поведение актёров реализуются в Blueprints, сериализуемых как JSON-подобные структуры.

Компонентно-ориентированная архитектура (COA)​

Развитие идеи компонентной модели до уровня всей системы. Здесь акцент делается на компонентах как независимых единицах функциональности, а не на классах-наследниках. Компоненты объединяются в сущности, но могут существовать и вне их (например, глобальные системы). Отличие от классической компонентной модели — в строгом запрете на прямые ссылки между компонентами: все взаимодействия идут через централизованные менеджеры (event bus, message queue, ecs-системы). Это обеспечивает высокую степень изоляции и поддерживаемости. COA особенно эффективна при работе с большим количеством однотипных объектов (массовые сражения, симуляции), где важна предсказуемость поведения и производительность.

Гибридные стили​

На практике чистые стили встречаются редко. Более типично сочетание: например, движок реализован как монолит с чёткими внутренними границами, а игровые подсистемы — по data-driven принципу; или сетевая часть построена как набор слабосвязанных микросервисов (matchmaker, lobby, game server), тогда как клиент остаётся монолитным. Решение о стиле принимается по доменам: для рендеринга важна производительность — монолит; для баланса — гибкость — data-driven; для инфраструктуры — масштабируемость — микросервисы.

Выбор стиля определяется совокупностью факторов: размер команды, сроки, целевые платформы, требования к переиспользованию, опыт разработчиков. Архитектура не должна быть «как у AAA-студии», если проект не требует соответствующих масштабов гибкости и поддержки.

Управление зависимостями и жизненным циклом объектов​

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

Основные механизмы управления жизненным циклом:

Фабрики и пулы объектов​

Фабрика инкапсулирует логику создания сущностей: загрузку ресурсов, инициализацию компонентов, регистрацию в подсистемах. Это позволяет централизовать правила порождения и избежать разбросанного кода вида new Enemy(...). Пул объектов — развитие идеи фабрики: вместо создания и уничтожения объекты переиспользуются. После «смерти» сущность возвращается в пул, сбрасывает состояние и ожидает повторного запроса. Это критично для производительности в играх с высокой динамикой (шутерах, аркадах), где аллокации в куче во время кадра вызывают фризы из-за сборки мусора или фрагментации памяти.

Инверсия управления и внедрение зависимостей (IoC / DI)​

В отличие от классического подхода, когда модуль сам создаёт или запрашивает зависимости («я сам найду систему физики»), в IoC зависимость внедряется извне — через конструктор, свойство или метод. Это достигается либо вручную (передача интерфейсов при создании), либо с использованием DI-контейнеров (Zenject в Unity, собственные решения в C++). Преимущество — тестирование: можно подменить реальную физику на мок-объект. Важно, что в играх DI часто применяется выборочно: для высокоуровневых сервисов (сохранение, звук), но не для тысяч игровых сущностей — там предпочтительны фабрики и пулы.

Событийно-ориентированное взаимодействие​

Напрямую вызывать методы других подсистем — плохая практика: это создаёт жёсткую связь. Вместо этого объекты публикуют события (PlayerDied, LevelLoaded), а заинтересованные системы подписываются на них. События могут быть синхронными (обработка сразу в том же кадре) или асинхронными (очередь, отложенная обработка). Такой подход снижает связанность, но требует контроля за порядком обработки и избегания циклических событийных цепочек.

Фазы инициализации​

Крупные системы требуют многоступенчатой инициализации: сначала ресурсы, затем графические контексты, потом физика, только после этого — игровые объекты. Нарушение порядка приводит к ошибкам. Архитектура должна явно определять последовательность этапов и обеспечивать проверку готовности (например, через Ready-флаги или promise-подобные конструкции).

Архитектурные анти-паттерны в играх​

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

«Божественный объект» (God Object)​

Один класс (часто GameManager, GameController, World) накапливает всё: управление состояниями, доступ к подсистемам, логику ИИ, сохранение, обработку ввода. Признаки: тысячи строк кода, десятки приватных полей, методы с разнородной ответственностью. Причина — отсутствие границ ответственности на ранних этапах. Лечение — декомпозиция по доменам и введение промежуточных абстракций.

«Спагетти из событий»​

Чрезмерное использование событий без контроля: A посылает событие → B реагирует и посылает другое → C посылает третье → A снова реагирует, замыкая петлю. Результат — непредсказуемый порядок выполнения, ошибки, зависящие от регистрационного порядка подписчиков. Лечение — документирование потоков событий, ограничение глубины цепочек, использование агрегирующих систем (например, GameStateSystem вместо прямых OnPlayerKilled в десяти местах).

«Скрытые зависимости через глобальные переменные»​

Обращение к Physics::Instance(), AudioManager::Global() напрямую из игровых объектов. Это нарушает тестируемость и создаёт неявные связи: чтобы протестировать ИИ, нужно инициализировать всю физику. Лечение — внедрение зависимостей через интерфейсы, даже если реализация пока одна.

«Жёсткая привязка к движку»​

Код игровой логики напрямую использует API движка (UnityEngine.Object.Instantiate, Unreal::SpawnActor), что делает его непереносимым и затрудняет модульное тестирование. Лечение — слой абстракции («движок как сервис»), где игровая логика работает с IInstantiator, а не с конкретным движком.

Выявление анти-паттернов — задача архитектурного аудита: регулярного анализа цикломатической сложности, количества зависимостей, покрытия тестами, статических анализаторов (например, SonarQube, PVS-Studio). Архитектура должна предусматривать механизмы такого контроля.

Документирование и верификация архитектуры​

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

Архитектурные решения (ADR — Architecture Decision Records)​

Это лёгковесный формат документирования: каждый принципиальный выбор фиксируется в отдельном файле (обычно Markdown), содержащем:

  • дату и автора,
  • контекст (требование или проблема),
  • рассмотренные варианты,
  • принятое решение,
  • последствия (плюсы, минусы, риски).

Пример: «Решение использовать фиксированный timestep 60 Гц для физики, несмотря на переменный рендеринг. Причина — необходимость детерминированной синхронизации в P2P-матче. Риск — дополнительная сложность интерполяции». ADR живут в репозитории рядом с кодом, версионируются, позволяют отследить эволюцию мышления.

Метод ATAM (Architecture Tradeoff Analysis Method)​

Структурированный процесс оценки архитектуры по ключевым качествам: производительность, безопасность, сопровождаемость, масштабируемость. Состоит из:

  • выявления сценариев качества («игра должна запускаться за ≤ 3 сек на устройстве X»),
  • построения архитектурных моделей,
  • анализа точек риска и компромиссов,
  • проверки чувствительности — как изменение одного решения влияет на другие сценарии.

ATAM особенно полезен перед масштабированием проекта или переходом на новую платформу.

Архитектурные спайки (spikes)​

Это целенаправленные эксперименты: создание минимального прототипа для проверки гипотезы («можем ли мы достичь 120 FPS на мобильном GPU с текущей моделью рендеринга?»). Спайк имеет чёткие критерии успеха/провала и срок, после которого код удаляется — он не становится частью основной системы. Спайки снижают риски, связанные с преждевременными архитектурными решениями.

Статический и динамический анализ​

Архитектура должна быть проверена. Инструменты вроде NDepend (для .NET), Understand (мультиязыковой), или SonarQube позволяют:

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

Динамический анализ (профилирование, трассировка вызовов) помогает выявить узкие места, неочевидные в статике — например, кэш-промахи при итерации по ECS-компонентам.

Сравнительный структурный анализ архитектур движков​

Ниже — нейтральное описание архитектурных особенностей трёх широко используемых движков. Оценки и сравнения по «лучше/хуже» исключены; приводятся только структурные факты, подтверждённые документацией и открытым кодом.

Unreal Engine​

Архитектура построена на слоистой модели с чётким разделением:

  • Core — основные сервисы: память, потоки, сериализация, рефлексия (UHT — Unreal Header Tool генерирует метаданные);
  • Engine — подсистемы: рендеринг (RHI — Rendering Hardware Interface как абстракция над API), физика (Chaos), анимация (Control Rig), звук (Audio Mixer);
  • Gameplay — слой для разработчика: актёры, компоненты, blueprints, game mode.

Ключевые архитектурные решения:

  • Blueprints как first-class citizen — визуальное скриптование тесно интегрировано в рантайм, не является внешним DSL;
  • World Partition — система управления открытым миром через пространственное секционирование;
  • Hot Reload — замена кода без перезапуска, поддерживаемая за счёт двойной компиляции и ABI-совместимости.

Зависимости направлены строго вниз: gameplay не может вызывать engine напрямую без интерфейсов; engine — через RHI и другие абстракции.

Unity​

Архитектура изначально задумывалась как компонентно-ориентированная, с доминированием GameObject–Component модели. В последние годы идёт переход к DOTS (Data-Oriented Technology Stack) — ECS + Jobs System + Burst Compiler, что меняет фундаментальный подход:

  • Burst — AOT-компилятор для C#-кода в нативный машинный код с векторизацией;
  • Entities Package — реализация ECS с фокусом на data locality;
  • Package Manager — модульность на уровне дистрибуции: движок разбит на пакеты (com.unity.render-pipelines, com.unity.physics), которые можно обновлять независимо.

Важная особенность — скриптовый цикл: MonoBehaviour.Update() вызывается движком, но сам движок написан на C++, а взаимодействие идёт через привязки (bindings). Это создаёт границу между managed и native кодом, что влияет на производительность и отладку.

Godot​

Отличается единым архитектурным стилем на всех уровнях: всё — объекты, наследующие от Object, всё — через рефлексию и сигналы.

  • Scene System — композиция через дерево сцены, где каждый узел — объект с компонентами (script, collision, mesh);
  • GDScript — встроенный язык со статической типизацией опционально, компилируемый в байт-код;
  • Single Inheritance + Composition — вместо множественного наследования — компоненты и группы;
  • Modules — движок собирается из модулей (modules/), которые можно отключить на этапе компиляции (например, module_mobile_vr_enabled=no).

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