монолитная архитектура
На ранних этапах развития индустрии игровая логика рассматривалась как единый, неразрывный процесс. В своей работе 1987 года «Логическая структура компьютерной игры» А. Л. Пажитнов [2] описывает функционирование игры через единую структуру трёх «планов» — трёх уровней логической организации, которые определяют поведение игры в конкретный момент времени.
Планы игры по А. Л. Пажитнову
Планы являются вложенными, и непосредственное взаимодействие с пользователем идёт на самом нижнем уровне, в то время как верхние планы реализуют логику уровня и игры в целом. При этом вся структура полностью прописывается в коде, а значит, что изменение игровой логики на любом из планов потребует изменения кода.
Quake — классический пример игры с монолитной архитектурой кода [3].
Архитектура клиентского кода игры Quake
Quake. id Software. — Activison: 1996
проблема
В актуальных исследованиях отмечается, что плотно связанные игровые системы сильно ограничены в масштабировании и уже не удовлетворяют современным требованиям к игровым проектам, так как в их монолитной среде изменение одного параметра может привести к ошибкам в работе даже не связанных с этим параметром систем [1]. Альтернативой монолитного подхода является модульность [4].
модульная архитектура
Согласно этому подходу современные игры должны строиться подобно конструкторам LEGO — из автономных блоков, взаимодействующих через чётко определённые интерфейсы. И это позволит разработчикам отойти от написания уникального кода для каждой ситуации в пользу создания дискретных самодостаточных единиц. Каждый модуль становится микро-экосистемой с заданными входами и выходами, что минимизирует системные риски при обновлении контента.
Связи между системами в модульной и монолитной архитектурах
The Legend of Zelda: Breath of the Wild — пример игры, в которой взаимодействие модульных систем формирует большое разнообразие ситуаций [5].
The Legend of Zelda: Breath of the Wild. Nintendo. — Nintendo: 2017
Фундаментом модульного подхода является принцип декомпозиции — разделения сложного целого на простые, функционально законченные части. В геймдизайне этот принцип наиболее полно отражён в «атомной теории» Рафа Костера [6].
Костер предлагает классифицировать элементы игры по аналогии с физическими структурами:
- Атомы. Это простейшие, неделимые элементы — правила, базовые действия или игровые системы.
- Молекулы. Каждый атом имеет свои входы и выходы, позволяющие ему объединяться с другими атомами. Так возникают молекулы — более комплексные игровые системы и механики.
- Организмы. Как в физическом мире совокупность молекул формирует организм, так и игры могут строиться из отдельных атомов и молекул. При этом формируется фрактальная структура, где весь проект строится из совокупности вложенных атомов.
Модель атома по Костеру
Костер отмечает, что эффективный дизайн строится на понимании того, как эти атомы взаимодействуют между собой. Модульность проявляется в наличии чётко определённых входных и выходных данных. Например, модуль «урона» принимает на вход значение силы и тип атаки, а на выходе выдаёт изменённое состояние здоровья объекта, не заботясь о том, является ли этот объект игроком, бочкой или стеной.
системный дизайн
Модульность неразрывно связана с системным мышлением. Харви Смит в своей работе «Systemic Level Design» [7] говорит о том, что геймплей должен реализовываться через глобально согласованные правила, а не через разовые пазлы и вручную настроенные триггеры. Такой системный подход позволяет дизайнеру уровней фокусироваться на творчестве, а не на технической реализации каждой отдельной двери или врага.
Результатом системного геймдизайна становится эмерджентность — возникновение сложного поведения из простых правил.
Исследователи Джаред Петтит и Нэйтан Алтис, анализируя игры серии Pac-Man, вводят понятие «системной реверберации» [8]. Это эффект, при котором действие игрока вызывает отклик во множестве независимых модулей, создавая уникальный опыт, который не был напрямую прописан программистом, но стал возможен благодаря гибкости связей между системами.
Pac-Man. Namco. — Namco: 1980
модульность в разработке
Геймдизайн и программирование — не единственные сферы, где модульность применяется при разработке игр. Михаил Кадиков описывает использование модулей в разработке уровней, показывая, как всего несколько базовых 3D-моделей позволяют создавать разнообразные локации [9]. Данный подход использовался ещё в таких проектах, как Super Mario Bros., и продолжает использоваться до сих пор, например в Assassin’s Creed Syndicate.
Уровни состоят из небольшого набора многократно повторяющихся модулей — Super Mario Bros. Nintendo. — Nintendo: 1985
Вывески на зданиях собраны из модульного набора букв — Assassin’s Creed Syndicate. Ubisoft Quebec. — Ubisoft: 2015
В целом на сегодняшний день можно говорить о том, что «Модульность ═ Долголетие».
В эпоху «игр как сервисов» (GaaS) только модульная архитектура позволяет проекту жить годами, развиваясь через обновления, которые не требуют полной переработки ядра [1].
Minecraft — отличный пример игры, в которой модульность игрового цикла и модификации позволяют игре существовать и постоянно развиваться.
Minecraft. Mojang Studios. — Mojang Studios: 2011 / Обновление Chase the Skies: 2025
