Разработчики, использующие игровой движок Unity, теперь могут интегрировать свои проекты с экосистемой Steam на официальном уровне. Компания Unity Technologies в ходе конференции Game Developers Conference 2026 (GDC) объявила о расширении поддержки платформы Valve, включив в неё нативную сборку для операционной системы Linux и устройств под управлением SteamOS. Это означает появление штатных инструментов для публикации игр в сервисе Steam, а также для их запуска на портативной консоли Steam Deck и готовящихся к выпуску Steam Machine.
До настоящего момента разработчикам приходилось самостоятельно реализовывать подключение к функциям Steamworks, поскольку движок официально не поддерживал эту платформу. Интеграция игр на Unity с магазином Valve и его аппаратным обеспечением осуществлялась силами студий через сторонние решения. Для работы на устройствах с Linux, включая Steam Deck, создатели игр часто полагались на слой трансляции Proton, который позволяет запускать сборки, предназначенные для Windows, без портирования кода.
Новый подход предполагает отказ от эмуляции в пользу нативных исполняемых сред. Как пояснил представитель Unity Джеймс Стоун, компания намерена предоставлять цели сборки не только для самой операционной системы Linux, но и непосредственно для Steam Deck с учётом особенностей его аппаратной части. Планируются целевые улучшения среды выполнения Linux, которые должны повысить производительность приложений по сравнению с версиями, запускаемыми через Proton. По заявлению разработчиков движка, определённые улучшения для Linux, ориентированные на оборудование Steam Deck, доступны уже сейчас.
Необходимость такого шага в компании объясняют отсутствием контроля над слоем трансляции Proton и невозможностью полноценно его поддерживать. Нативный подход, по мнению Unity, позволяет гарантировать стабильность работы и использовать преимущества прямой компиляции кода под конкретную платформу.
Техническая реализация новой функции базируется на существующем Platform Toolkit для Steamworks. В документации к версии 1.0.1 этого набора инструментов указаны выделенные пакеты Steamworks и поддержка, протестированная с использованием Steamworks SDK версии 1.62. Это означает, что анонс на GDC представляет собой не создание поддержки Steam с нуля, а официальное закрепление и расширение ранее доступных сообществу возможностей до уровня стандартизированного решения.
В контексте более широкой картины развития инструментов для создателей игр под Linux стоит отметить, что Unity не единственный движок, обеспечивающий такую возможность. Например, Unreal Engine предлагает порт под Ubuntu и предкомпилированные бинарники для Linux, а Godot изначально проектировался как кроссплатформенный и доступен в большинстве распространённых дистрибутивов. Однако для Unity, который переживал сложный период после скандального изменения бизнес-модели и отставки генерального директора Джона Риччителло, этот шаг может стать важным сигналом для сообщества.
Для конечных пользователей Steam Deck и будущих владельцев Steam Machine ключевой остаётся готовность студий выпускать нативные сборки, а не полагаться на Proton, который продолжает оставаться стандартным путём для множества Windows-игр на SteamOS. Сама Unity не публиковала сравнительных данных о производительности нативных билдов и версий, работающих через трансляцию. Реакция разработчиков на нововведение пока неоднозначна: некоторые скептически отмечают, что нативный компилятор под Linux существует в движке более десяти лет, и речь идёт скорее об интеграции готовой обёртки, а не о технологическом прорыве. Другие сомневаются в экономической целесообразности создания нативных портов для относительно небольшой аудитории пользователей Steam Deck, когда имеющийся транслятор Proton не требует дополнительных затрат на тестирование.
В то же время существуют и противоположные мнения: некоторые игроки указывают на то, что нативные версии игр для Linux нередко страдают от проблем с управлением, визуальными эффектами и стабильностью, тогда как версии, запускаемые через Proton, работают надёжнее благодаря стабильности Windows API. Дискуссия показывает, что просто наличие инструментов для нативной сборки не гарантирует их массового применения, если разработчики не увидят в этом чётких преимуществ перед существующими методами.
