95% систем без кода: секреты разработки Clair Obscur: Expedition 33

Clair Obscur: Expedition 33 выглядит как RPG, на которую должна уйти целая армия разработчиков. Но у Sandfall Interactive оказалось всего четыре программиста, а 95% игровых систем команда создала с помощью визуального программирования. Получается, теперь для масштабной RPG достаточно освоить пару инструментов и запастись кофе? Не совсем. Разбираемся, как устроен этот подход и чему он может научить всю игровую индустрию.

Как маленькая студия замахнулась на RPG масштаба AAA

Clair Obscur: Expedition 33 легко принять за проект крупной студии. Здесь есть зрелищные сражения, необычный фэнтезийный мир, длинная сюжетная кампания и постановочные сцены, которым позавидуют некоторые блокбастеры. При этом игру создавала французская Sandfall Interactive. Студия решила не соревноваться с гигантами индустрии количеством сотрудников, а найти более эффективный способ разработки.

Студию основали выходцы из Ubisoft, в том числе Гийом Брош, ставший режиссёром Expedition 33, и технический директор Том Гийермен. Вместо очередного проекта с открытым миром на сотни часов они взялись за необычную RPG с пошаговыми боями, реакциями в реальном времени и эстетикой французской Прекрасной эпохи (начало XX века до Первой мировой). Получился мир, в котором причудливая архитектура соседствует с сюрреалистичными пейзажами, а сказочная красота постоянно напоминает о надвигающейся катастрофе.

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

Sandfall решила максимально оптимизировать процесс, используя новые технологии. По словам разработчиков, в технической команде было всего четыре программиста, которым предстояло обеспечить работу множества игровых систем. При этом речь не о том, что остальные сотрудники просто обходились без технических знаний. Команда использовала инструменты Unreal Engine 5, чтобы передать часть повседневной работы дизайнерам и другим специалистам.

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

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

Четыре программиста на целую RPG: секрет продуктивности без нейрослопа

Когда говорят о маленькой команде, которая выпустила большую игру, легко представить универсальных солдат, работающих по 16 часов в сутки. Ну или студентов, которые просто копируют ответы нейронок. Но секрет Sandfall Interactive оказался куда интереснее. Студия не пыталась заставить четырёх программистов вручную написать каждую механику или отдать её на откуп ИИ, а перестроила сам процесс разработки. Задача заключалась в том, чтобы технические специалисты создавали инструменты, которыми смогут пользоваться остальные члены команды.

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

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

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

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

Заявление о четырёх программистах не означает, что техническая часть Expedition 33 была простой. Скорее, от небольшой команды требовалось создать достаточно гибкую основу, чтобы остальные разработчики могли работать с ней без постоянного вмешательства инженеров. Важен и обратный эффект: программисты не тратили всё время на бесконечные мелкие просьбы, а могли сосредоточиться на сложных задачах, которые действительно требовали их квалификации. Например, делать и оптимизировать инструменты разработки для остальной команды.

Красивый мир — не только благодаря таланту художников

Первое, что бросается в глаза в Clair Obscur: Expedition 33, — её визуальный стиль. Разрушенные дворцы, фантастические скалы, причудливые существа и пейзажи, будто сошедшие с полотен сюрреалистов. При этом красота игры не сводится к количеству полигонов или разрешению текстур. Важную роль сыграли художественное направление и инструменты, которые позволили небольшой команде воплотить свои идеи без лишней технической рутины.

В основе проекта лежит Unreal Engine 5 — движок, который предоставляет разработчикам множество готовых решений для создания современных игр. Например, Nanite позволяет работать с очень детализированной геометрией и уменьшает необходимость вручную подготавливать несколько уровней детализации для множества моделей. Проще говоря, художники могут создавать сложные объекты, не тратя столько времени на оптимизацию каждого из них традиционными методами.

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

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

Для работы с материалами и текстурами Sandfall использовала инструменты Adobe Substance 3D. Они помогают художникам управлять поверхностями материалов: задавать свойства металла, камня, ткани и других элементов, добавлять потёртости, загрязнения и мелкие детали. Это важно не только для реалистичности. Единый рабочий процесс помогает поддерживать общий художественный стиль, даже когда над разными объектами трудятся разные специалисты.

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

Повторное использование контента: почему игроки не замечают производственные хитрости

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

Clair Obscur: Expedition 33 — хороший пример такого подхода. В рассказах о разработке Том Гийермен отмечал, что команда повторно использовала компоненты существующих уровней при создании карты мира. Похожие принципы применялись и к другим элементам игры: вместо того чтобы каждый раз изобретать новую систему, разработчики могли опираться на уже созданные механики и инструменты.

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

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

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

Почему нельзя просто скачать Unreal Engine и повторить успех

История Clair Obscur: Expedition 33 звучит как мечта начинающего разработчика. Берёшь Unreal Engine 5, осваиваешь Blueprints, собираешь небольшую команду или сам вкалываешь несколько суток подряд — и вот уже на горизонте маячит собственная RPG, способная конкурировать с крупными проектами. Жаль, что в реальности между скачиванием движка и выпуском успешной игры лежит несколько лет работы, десятки сложных решений и немало возможностей всё испортить. Нейросети тут кардинально ситуацию не меняют, а лишь немного ускоряют работу.

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

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

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

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

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

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