Третий материал из серии «Дневников разработчиков» уже перед вами: за нашими плечами два интервью с основателем и генеральным продюсером российской геймдев-студии WATT. Про историю команды, про то, как она работает и чем вообще занимаются директор и продюсер, мы узнали. А что насчет СТО?

Часто ли вы задумываетесь, как вообще игра «живет», за счет чего вы можете управлять персонажем, взаимодействовать с окружающим виртуальным миром и вообще запускать тайтл на своем компьютере? Если нет, то самое время погрузиться в техническую внутрянку геймдева в компании Артема Головина — СТО студии WATT.

WATT — что за студия и какие игры разрабатывает?

Но прежде чем углубиться в самое захватывающее, давайте сначала поближе узнаем студию WATT: сейчас команда работает сразу над двумя проектами: «Царевна» и GRIMPS. Давайте немного о них поговорим и разберемся, что же команда готовит для нас, игроков.

«Царевна»

«Царевна» — это первый в мире слэшер с элементами балета. Для его создания разработчики использовали захват движений настоящей балерины Большого театра.

Разработкой игры занимается, нетрудно было догадаться, студия WATT. Основная идея проекта — это переосмысление жанра экшен-игр, вдохновленное культурным наследием и хореографией.

Геймплейный трейлер

Увидеть, как выглядит «Царевна» в бою, можно в новом геймплейном трейлере. Там показаны ключевые элементы: комбо, уклонения, магия и система, основанная на управлении движением.

«GRIMPS»

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

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

Артем Головин: кто делает «базу» для игр или кто такой технический директор

Мы с вами, как обычные игроки, желающие насладиться готовым продуктом, мало задумываемся о том, на что эту картинку «натягивают» — а зря. Ниже вас ждет небольшой, но информативный разговор с Артемом Головиным, СТО студии WATT, о разработке игр.

Не удивляйтесь, если видите в скобках небольшие пояснения ответов. Термины не всегда бывают понятны новичкам даже с контекстом, потому мы постарались подробнее объяснить, что же имел в виду Артем.

— Технический директор в геймдеве — тот самый человек, на котором буквально держится игра. Как по-простому объяснить, кто такой технический директор или СТО? Чем ваша работа отличается от работы обычного программиста?

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

Моя задача — обеспечить масштабируемость архитектуры, выбрать стек (например, переход на UE 5.5/5.7) и настроить пайплайны так, чтобы 30 человек не затерли код друг друга в Git. адача Артема — сделать так, чтобы проект нормально рос и не разваливался: выбрать технологии и настроить процессы, чтобы команда из 30 человек спокойно работала и не ломала код друг другу.]

Я отвечаю за бюджет производительности: распределяю миллисекунды кадра между рендером, физикой и логикой. Если у нас на отрисовку кадра есть 16.6 мс (для 60 FPS), я решаю, сколько из них заберет Lumen (система освещения в Unreal Engine), а сколько анимационный блюпринт (визуальный способ программирования в UE).

— Что происходит с технической стороны, когда команда решает делать новую игру?

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

Параллельно тестируем все интеграции, которые планируем использовать. Например, пайплайн захвата движения.

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

— Какие решения приходится принимать в самом начале разработки? Насколько сильно технологии могут ограничивать идеи игры?

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

— Какие проблемы возникают чаще всего при разработке игр с технической стороны?

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

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

— Бывали ли ситуации, когда технические ограничения заставляли менять задумку игры?

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

Например, в «Царевне» балетная боевая система строится на идеальных таймингах. Мы хотели сделать сложную симуляцию ткани, чтобы это выглядело эффектно. Но на прототипе выяснилось, что из-за нагрузки на процессор ввод становится неотзывчивым, удары перестают ощущаться. Пришлось идти на компромисс: упростили симуляцию ткани, пожертвовали частью визуальной детализации, но сохранили тот самый темп, ради которого затевался балетный слэшер.

— Сколько времени в разработке уходит на исправление от мелких багов до критических ошибок?

— В среднем около 40% времени. В геймдеве есть понятие «технического долга». На старте мы часто собираем прототип быстро, чтобы проверить, увлекает ли сама механика, есть ли в ней тот самый «фан». Если идея сработала, дальше начинается самая трудоемкая часть: мы переписываем все в стабильный продакшн-код, который будет выдерживать нагрузку, обновления и не подведет в непредсказуемых местах.

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

— Какие баги бывают самыми неожиданными? Можете назвать один из самых забавных случаев?

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

Забавный случай у нас был с котом. Настраивали систему слежения за взглядом для анимации персонажа, и в редакторе кот смотрел куда надо. В собранной игре у него вдруг появилось косоглазие — зрачки смотрели в разные стороны. Исправили за пару строчек кода, но косоглазый Баюн остался в памяти команды как напоминание о том, что сборку всегда надо тщательно тестировать.

— Насколько сложно технически реализовать идеи геймдизайнеров и художников?

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

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

— Что приносит больше всего удовлетворения в технической работе над игрой?

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

— Что бы вы посоветовали тем, кто хочет стать программистом в геймдеве?

— Изучайте низкоуровневые вещи: управление памятью, работу GPU-конвейера, векторную алгебру. На старте кажется, что можно обойтись готовыми движками и скриптами, но настоящие проблемы начинаются там, где нужно выжать максимум из железа. Геймдев-программист это прежде всего инженер, который понимает, как данные текут по шине из RAM (оперативная память) в VRAM (видеопамять) [Проще говоря, как данные проходят путь внутри системы от оперативной памяти в видеопамять и дальше на экран].

Заглавное фото: CQ.ru / WATT