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

Генеральный директор Rocketwerkz Дин Холл и основатель Floating Point Origin Interactive Фелипе Фаланге с неподдельным восторгом рассказывают о новом фреймворке на языке C# под названием "Brutal". В ходе недавнего разговора с разработчиками игр, создатели DayZ и Kerbal Space Program не переставали обмениваться случайными ремарками о том, что им удалось реализовать с помощью этого инструмента, и как они вдохновляли друг друга в работе.

Их радость заразительна, поскольку, когда вы понимаете, как функционирует Brutal, становится ясно, что каждая новая функция является подлинным достижением даже для этой пары опытных разработчиков. "Он называется Brutal не просто так", — сказал Холл, после того как Фелипе сравнил работу с ним с ощущениями от сидения на барном стуле, в то время как все друзья, использующие такие движки, как Godot, сидят на мягком диване.

Как отмечает представитель Rocketwerkz, Brutal — это инструмент, который "использует новейшие функции .NET, предоставляя при этом доступ к низкоуровневым API высокопроизводительных библиотек C++, включая графический API Vulkan". Всё на этом.

Rocketwerkz создала фреймворк для разработки Kitten Space Agency, духовного наследника Kerbal Space Program. Компания пригласила Фаланге в руководящий комитет по консалтингу Kitten Space Agency, что привело к его консультациям по движку. Brutal будет сделан открытым исходным кодом через коммерческую организацию под названием "Ahwoo".

Разработчики, помнящие времена XNA и самодельных движков, могут содрогнуться при этой мысли. Визуальные инструменты сценариев, такие как Unity и Unreal Engine, должны были ускорить разработку и позволить дизайнерам больше думать о своей игре, нежели о коде. Зачем возвращаться в мир, где все строят свои собственные игровые движки?

Холл понимает это беспокойство. Но в нашем разговоре он сделал довольно смелое предсказание: фреймворки, такие как Brutal, а не игровые движки, будут будущим разработки игр.

Brutal заставляет разработчиков строить рабочие процессы с нуля

Чтобы следовать логике Холла, нужно рассматривать Brutal с точки зрения рабочих процессов разработчиков, а не с точки зрения того, что он может или не может сделать по сравнению с движками сторонних разработчиков.

Rocketwerkz создала Brutal для управления разработкой Kitten Space Agency, потому что они решили, что рендеринг на основе сцен недостаточен для задачи. "Если вы возьмете Unity или Unreal, у вас есть эта редакторская сцена, и когда вы нажимаете "играть", она становится игровой сценой, и всё в ней относительно 0-0-0 этой сцены", — сказал Холл. "Так вы рисуете вещи, и это настолько укоренилось, что людям трудно представить что-то другое."

"В Kitten Space Agency всё контекстуально. Так что объект рисуется относительно чего-то другого. Камера на самом деле всегда находится в своём 0-0, она никогда не движется, и всё рисуется в неё."

Симуляторы космических полётов изображают большие расстояния, концепцию рендеринга, иногда называемую "плавающим происхождением". Фаланге сказал, что он переосмысливал свой подход к этому в своём новом проекте и пришёл к аналогичному решению с Rocketwerkz, назвав это "первичным плавающим происхождением", где система решает позиции объектов относительно камеры как можно позже перед рендерингом. "Вы всё ещё получаете в основном ту же функциональность, но можете использовать числа высокой точности на протяжении всей игровой сессии", — объяснил он.

"В нашем случае мы решаем их на GPU. Мы отправляем пару чисел, которые действуют как значение двойной точности, в шейдеры, и шейдеры затем определяют координаты относительно камеры." Чтобы сделать что-то подобное в Unity (инструмент, который Фаланге использовал для создания Kerbal Space Program), нужно "грубой силой" заставить существующую систему сместить каждый объект в игровом мире на одинаковое количество.

Для разработчиков, интересующихся оптимизацией производительности в Brutal, Rocketwerkz объяснила, что код C# Kitten Space Agency выполняется на Common Language Runtime (CLR) и компилируется JIT во время игры, а не компилируется на этапе предварительной компиляции. Это было сделано отчасти для того, чтобы сделать игру "более легко модифицируемой", так как управляемый код "более доступен" для игроков.

Обратите внимание на процесс. Мысль не была "Unity не может это сделать, мне нужен инструмент, который это может". Это было "нашей игре нужно, чтобы плавающее происхождение работало так, как нужно, как это сделать?"

Это мышление, которое естественно для Фаланге, сказал Холл. "Одной из суперспособностей [Фаланге], о которых он, по-моему, не до конца осознаёт, является то, что он всегда думает о том, как он хочет что-то сделать, особенно если это не то, с чем он хорошо знаком."

Во время второго звонка Холл показал нам другие системы Kitten Space Agency, созданные с помощью Brutal. Некоторые, включая одну, которая использовала объёмное освещение для создания свечения двигателя, были для меня сложны, но система Холла для математических пользовательских интерфейсов была легко понятной.

Kitten Space Agency позволяет игрокам моделировать космический полёт с рядом полуреалистичных элементов интерфейса, которые можно расширять или уменьшать и даже перемещать на другие мониторы. Видеоигровые интерфейсы обычно основаны на текстурах, но Холл хотел, чтобы они основывались на математических расчётах, чтобы позволить масштабирование и перемещение. Он также считает, что они выглядят более чёткими и менее "выцветшими".

Это лишь часть систем Kitten Space Agency, которые технически возможны в других игровых движках, но, создавая их с нуля, разработчики могут ответить на вопрос "что я пытаюсь сделать?" прежде чем спросить "как я пытаюсь это сделать?"

Холл и Фаланге сказали, что это стало возможным благодаря очень случайной череде событий, которые произошли вместе с созданием Brutal: прогресс и популяризация больших языковых моделей в генеративном ИИ.

Рабочие процессы Brutal противоположны кодированию по настроению

"Мне трудно говорить об этом, не звуча как член культа", — сказал Холл, описывая, как он использует ChatGPT при работе с Brutal. Но он и Фаланге согласны — использование LLM сделало языковое кодирование более простой задачей.

Не то чтобы намного проще, чтобы было ясно. Они оба сказали, что при запросе к LLM они редко копируют и вставляют сгенерированный код. Вместо этого они задают вопросы о библиотеках C# или документации Vulkan, и программное обеспечение способно возвращать качественные ответы. Ответы, которые обычно требуют от программистов часов, чтобы изучить документацию или просмотреть старые форумы в поисках того самого поста с решением (который, вероятно, был написан в 2014 году).

"LLM по сути токенизирует язык, затем размещает массу векторов вокруг этих токенов, чтобы создать связи между ними", — сказал Холл. "Что может быть лучше, чем высоко структурированный, фактически brutally структурированный язык?" Vulkan и последняя версия C# очень "высоко структурированы, с очень чётким синтаксисом".

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

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

Это также противоположно кодированию по настроению, методу, при котором программисты говорят LLM, что они хотят, чтобы система делала, и LLM генерирует код — и это не автозаполнение кода, когда инструменты ИИ "предсказывают", что кто-то пишет, и завершают строку, чтобы ускорить рабочий процесс. Единственное, что LLM делает для разработчиков Brutal, — это ускоряет доступ к информации, позволяя им исследовать без просмотра 40-минутного видео на YouTube.

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

"Вам не нужно платить кому-то за этот опыт, вы можете просто сделать это с ИИ и быть разочарованным," — пошутил он.

Как фреймворки могут изменить разработку игр?

Вы можете свести теорию Холла о том, что он называет "смертью больших движков", к следующему: если LLM делают языковое кодирование более доступным, то визуальное скриптование теряет своё преимущество. Разработчики, которые принимают метод Brutal, становятся ответственными за понимание каждого элемента технологии, на которой работает их игра.

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

И несмотря на сложность использования фреймворка, Холл сказал, что Rocketwerkz было легче нанимать программистов, использующих этот инструмент, чем тех, кто работает с Unreal. Программирование на высоком уровне в Unreal требует специализированных знаний, настроенных не только для движка, но и для типов игр, которые создаются. Программист, уже знакомый с C#, может освоить рабочий процесс Brutal, если он готов принять его... ну, брутальность.

Холл отмахнулся от идеи, что Brutal станет единственным фреймворком, ведущим к концу игровых движков. Он даже стал немного раздражённым при мысли о том, что некоторые компании могут утвердиться как эксперты по Brutal, которые могут создавать инструменты для других разработчиков поверх фреймворка, подобно разработчикам, создающим плагины для Unity и Unreal. "Brutal был создан для того, чтобы доставить очень специфическую, труднодоступную игру, где вам нужно сесть и задать кучу вопросов [о том, как она работает]."

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

Видение Холла о будущем игровой индустрии почти полностью противоположно тому, что представлено платформами UGC и сторонниками ИИ. Вместо мира, где разработка игр становится проще благодаря упрощённым инструментам, она становится более доступной благодаря лучшему пониманию языкового программирования через LLM.

Скептики могут отмахнуться, сказав, что языковое кодирование никогда не сможет двигаться так быстро, как разработка игр на движках. Если бы это было правдой, альфа-версия Kitten Space Program заняла бы годы на создание, верно?

Холл ответил на этот момент, пролетая через смоделированную солнечную систему своей команды, стремительно маневрируя по каньонам Марса вскоре после направления аппарата на посадку на детализированную поверхность Луны. "Мы сделали всё это примерно за год," — сказал он.