Чего ждать от Nau Engine — интервью с Андреем Карсаковым

Александр Семенов, App2Top: Привет. Давай начнем с небольшого рассказа о тебе. Расскажи, пожалуйста, за что именно ты отвечаешь в Nau Engine и над какими движками и играми работал до этого.

Андрей Карсаков

Андрей Карсаков: В проекте Nau Engine я руковожу разработкой, то есть самими командами, создающими движок. У меня в подчинении ряд лидов, которые отвечают за проектирование и техническую реализацию продукта.

Я в IT-разработке с 2012 года, а руковожу командами с 2016 года. Начинал с лаборатории в рамках Университета ИТМО. Мы занимались разработкой систем визуализации научных исследований на нашем собственном движке. Потом, когда мы уже уходили в сторону коммерческой разработки, переключились преимущественно на Unreal Engine, частенько дорабатывая его под свои нужды, но иногда использовали и Unity.

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

Так, из публично «видимых» проектов, моя команда разработала комплексную (смартфоны + телевещание) AR-систему для крупных живых мероприятий, использовавшуюся, например, на финале международного чемпионата WorldSkills в 2019 году в Казани. Также разработали мобильное AR-приложение для шоу «Фантастика» на «Первом канале».

За более чем 11 лет работы в университетской среде и ведения самостоятельного IT-бизнеса я накопил достаточно обширный управленческий и R&D-опыт в области computer science, защитил диссертацию на степень кандидата технических наук, участвовал в крупных международных исследовательских проектах, имею более 30 англоязычных научных публикаций. Если брать вместе с русскоязычными, то, наверное, будет около 50, в большинстве связанных с инструментами разработки, компьютерной графикой, визуализацией, ИИ, дополненной реальностью и образованием.

В ходе недавней презентации было озвучено, что команда Nau Engine насчитывает 25 человек. Можешь немного рассказать о лидах и их опыте? Не поименно, но чтобы понимать, за что ребята отвечали ранее.

Андрей: На текущий момент команда немного подросла, нас уже больше 30.

У нас собралась команда экспертов с большим опытом работы в крупных компаниях: Playrix, Sperasoft, Saber Interactive, Unigine, Nival, Lesta. Все ребята с богатым опытом в разработке как игровых проектов, известных по всему миру, так и движков, на которых эти проекты делаются.

Переходим к повестке, к Dagor Engine. Почему за основу Nau Engine взяли именно его? Какие факторы сыграли решающую роль?

Андрей: Dagor Engine создан высококлассными техническими специалистами из компании Gaijin Entertainment и проверен на множестве проектов, которые зарабатывают хорошие деньги. Данный движок имеет очень хорошую технически реализованную платформенную базу, поддержку современных графических API, позволяет как собирать под большое разнообразие платформ, так и вести кроссплатформенную разработку – это очень важные факторы для нас. Плюс Dagor находится в открытом доступе, по лицензии, позволяющей его использовать, изменять и дорабатывать. В принципе, это основные факторы. Они вполне соответствуют всем критериям, которые мы установили для себя при выборе технологий для Nau Engine.

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

Какие были альтернативные решения? Грубо говоря, между чем и чем выбирали?

Андрей: Ответить на этот вопрос коротко невозможно. В наших списках были десятки различных технических решений, начиная от полноценных крупных игровых движков, которые потенциально могли стать для Nau Engine донорами каких-то частей, заканчивая отдельными фреймворками, библиотеками с открытым исходным кодом, доступным для использования. Анализ всех альтернатив — трудоемкий и длительный процесс. Но по совокупности всех факторов мы решили остановиться на Dagor Engine.

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

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

Части и модули Dagor, пусть даже крупные и фундаментальные – всего лишь одни из многих в технологическом стеке Nau Engine, и они будут изменяться и дописываться, а сам движок обрастать новыми модулями.

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

Какая именно версия Dagor Engine стала основой для Nau Engine? Вопрос важный, поскольку то, что лежит в репозитории, — преимущественно импорт четвертой версии, которая вышла в 2015 году.

Андрей: Насколько нам известно, сейчас в репозитории лежит версия 6.5 – последняя актуальная версия движка, от нее мы и отталкивались.

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

На фоне последних западных релизов мы все чаще слышим такие термины, как mesh shader, тесселяция, ray tracing, DLSS, FSR и так далее. Стоит ли ждать этих решений на этапе публичных бета-тестов?

Андрей: Часть из них есть уже сейчас, например FSR. Что-то будет появляться постепенно, по мере развития продукта и кода. Но пока мы не планируем вступать в технологическую гонку с такими гигантами, как, например, Unreal. Наша задача — сделать хороший качественный рендер, предоставляющий все необходимые на сегодняшний день возможности, а также дать сообществу разработчиков все необходимое для расширения функциональности Nau Engine, чтобы добавлять новые фичи и функции.

В целом, если говорить о технологическом стеке, то о соответствии какой версии DirectX (не поддержке, а именно соответствии возможностям) можно будет говорить на старте публичного доступа?

Андрей: DirectX 12, наравне с Metal и Vulkan.

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

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

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

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

Планируется ли и, если да, то как скоро, реализация в Nau Engine визуального программирования? Возможно ли в раннем доступе или в версии 1.0 будет создавать игры при zero coding?

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

Предыдущий вопрос связан с тем, что, насколько я знаю, Dagor Engine принято считать сложным в освоении движком. При этом и ранее, и в рамках недавней презентации не раз проговаривалась важности создания Nau Engine таким, чтобы у него был низкий порог входа. Хочется понять, как именно к этому планирует идти команда разработки?

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

Хорошо, что ты заговорил про документацию. Многообразие обучающих материалов и инструментов является одним из важных условий популяризаций движка. Например, у Godot есть чудесный интерактивный учебник, обучающий программированию, у Unity внутри движка — набор образовательных демоверсий. И так далее. Что будет на старте у тех, кто захочет разобраться с Nau Engine?

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

Этим сейчас занимается выделенная команда. Мы очень активно работаем с вузами, которые преподают разработку игр уже не первый год (ИТМО, ВШЭ, КФУ, ДВФУ и др.). Собираем всю доступную обратную связь относительно того, какие материалы и в каком виде лучше готовить, чтобы освоение движка шло быстрее, эффективнее и качественнее с точки зрения именно того, кто изучает этот движок, — студента или начинающего разработчика.

Если говорить про инди-команды, то их обычно интересует широкая поддержка двухмерной графики (например, соответствующий эдитор, предполагающий работу с двухмерными тайлами). Что сможет предложить им Nau Engine?

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

Как будет построена работа над улучшениями, внесенными сторонними командами?

Андрей: Работа может быть построена несколькими путями:

1. Первый, самый простой и понятный: команды самостоятельно размещают свои плагины в открытых репозиториях, чтобы сообщество могло свободно их скачивать.
2. Следующий уровень — это размещение сторонних модулей в ассет-сторе или даже официальном плагин-менеджере. Здесь уже предполагается модерация и проверка качества, чтобы пользователи могли получить гарантированно работоспособные модули.
3. Также будет построена система ревью и интеграции разработок и улучшений от сообщества в исходный код. Мы планируем этот трек, чтобы сообщество наравне с нами могло активно участвовать в развитии Nau Engine.
4. Последний момент — это большие, самостоятельные модули, которые разработчики захотят интегрировать в сам движок. В случае подтверждения их качества и востребованности сообществом мы готовы внедрять такие полностью, а не только на уровне плагинов.

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

Альфа-тестирование началось 1 ноября. Что есть в этой альфе? Что с ее помощью могут сделать команды, принимающие участие в тестировании?

Андрей: По большому счету, закрытая альфа — это технологический proof-of-concept, который покрывает весь цикл разработки. То есть установил движок себе на компьютер, запустил, собрал сцену, написал скрипты, подключил, проверил и запустил в редакторе. И, если все хорошо, то собрал билд, который можно дать кому-нибудь пощупать. Те, кто попал в альфа-тестирование, проверяют концептуальные технологические решения и дают нам обратную связь относительно того, что можно улучшить или поменять.

Понятно. Ну что ж, спасибо за интервью. Будем ждать от вас новостей.