DeepSeek V4: как удешевить генерацию игр с помощью ИИ

Могут ли доступные модели создавать браузерные игры, в которые действительно хочется играть? Последнюю неделю мы проверяли это в OpenGame Studio. Последнее дополнение — DeepSeek-V4.1-Flash-1017, релиз семейства DeepSeek V4 от 17 октября.

Мы также протестировали Grok 4.6, Xiaomi MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash и Claude Haiku 5.5. Мы хотели улучшить баланс стоимости генерации, времени ожидания, игрового поведения и качества изображения. Игра может успешно открыться, но герой всё равно пойдёт направо при нажатии влево, монеты будут начисляться до столкновения с ними, а во время паузы персонаж продолжит падать.

Последний вариант раннера DeepSeek прошёл основные проверки игрового процесса, которые мы проводили. Графика была скромной. В предыдущих экспериментах возникли другие проблемы, в том числе ошибка в нашей собственной проверке доставки. Такие подробности полезнее для разработчика, чем рейтинг моделей без объяснений.

Исходный раннер DeepSeek-V4.1-Flash-1017. Персонаж, дорожки и монеты различимы; окружение осталось базовым прототипом.

Ищем более доступный способ создавать игры

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

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

У моделей из нашего списка были разные роли:

• Grok 4.6 стал универсальным ориентиром. Для нас это был менее бюджетный вариант, привлекательный отчасти за счёт доступа по подписке. В официальном анонсе среди способов использования для разработки названы Grok Build и другие инструменты.
• Xiaomi MiMo V2.6 Flash и Pro позволили сравнить два варианта одного семейства. Xiaomi позиционирует Flash как эффективную модель для частого использования, а Pro — для более сложных рассуждений и проектной работы. Pro — флагман своей линейки, но в нашем исследовании доступных решений он тоже участвовал.
• GLM 5.3 Flash стала ещё одним эффективным вариантом. В официальном анонсе объясняется такое позиционирование. Мы хотели посмотреть, как модель справится с запросом на целую игру.
• Claude Haiku 5.5 дополнила список зарубежным вариантом с прицелом на стоимость. Anthropic описывает Haiku как модель для быстрой и массовой работы. Мы проверили её в роли создателя игры, но обзор был ограниченным; подробности приведены ниже.
• DeepSeek-V4.1-Flash-1017 стал самым новым экспериментом. В анонсе релиза есть демонстрации проектов. Мы использовали собственный запрос на создание раннера и проверили, насколько он подходит для OpenGame Studio.

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

Один раннер — шесть экспериментов с моделями

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

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

Ниже приведены эксперименты, проведённые с одним оригинальным запросом с 11 по 17 октября 2026 года:

Это отдельные эксперименты, проведённые разработчиками. Они дают практическую основу для сравнения, но у неё есть ограничения: каждая модель создала собственную спецификацию и реализацию, в том числе свои визуальные решения. Проверки проводились в разные дни, а среда сайта не была зафиксирована. Перед запуском MiMo Flash потребовалось дополнительное обсуждение. Время не включает обсуждение, составление спецификации и игровое тестирование; показатель GLM заканчивается на этапе отклонения.

Для раннера DeepSeek мы сохранили ограничения генерации и те же инструкции для 3D-конструктора, что и в экспериментах MiMo. До приёмочных проверок исходный код вручную не исправлялся. Серия экспериментов не устанавливает статистически надёжный рейтинг скорости или качества.

Что добавили к общей картине MiMo, GLM и Haiku

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

Исходный результат MiMo Flash до последующих исправлений при отборе. Ошибку времени сбора выявили проверками игрового процесса и кода; по одному этому кадру её доказать нельзя.

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

Исходная городская сцена MiMo Pro. Чтобы обнаружить ошибку паузы, пришлось проверить игру посреди прыжка — по красивому неподвижному изображению её не заметить.

Результат GLM требует двух отдельных выводов. Запуск Studio завершился с ошибкой доставки, потому что наш валидатор неверно принял встроенный игровой код за запрещённую разметку ресурсов. Это была ошибка платформы. Было бы неверно считать её доказательством того, что GLM не смог создать игру.

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

Восстановленный оригинал GLM при отдельной проверке. Изображение не подтверждает успешную доставку через Studio.

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

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

Почему влево может означать вправо?

В раннере Grok обнаружилась самая очевидная ошибка управления. Из центральной дорожки клавиша ArrowLeft перемещала персонажа в правую часть экрана. Свайпы влево приводили к тому же результату.

До нажатия: раннер по центру.

После ArrowLeft: раннер явно находится справа. На обоих снимках показана неизменённая сгенерированная версия.

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

Игрок ориентируется по видимой трассе. Уменьшение координаты само по себе не означает, что движение на экране пойдёт влево. При следящей камере также нужно проверять положение персонажа относительно дорожек: на экране он может оставаться по центру, пока трасса движется под ним.

Другой эксперимент с гонкой выявил слабое место и в нашей оценке. Автоматический контроллер мог компенсировать перепутанное управление рулём и закончить круг. Теперь мы отдельно проверяем каждое направление, начиная с нового заезда. Финиш не подтверждал правильность подписей управления.

Как DeepSeek V4 показала себя в проверке раннера

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

• Направления: ArrowLeft, ArrowRight, A и D перемещали персонажа в правильную видимую сторону. Повторные нажатия останавливались на крайней дорожке.
• Сенсорное управление: свайпы влево и вправо работали при имитации портретной и альбомной ориентации. Свайп вверх вызывал прыжок, вниз — скольжение.
• Препятствия: при управлении с клавиатуры удалось перепрыгнуть наземный барьер, проскользить под верхней перекладиной и объехать гигантскую преграду по безопасной дорожке.
• Монеты и возрождение: монеты начинали собираться при достижении. Возрождение тратило собранные монеты и безопасно продолжало игру; при недостатке монет ни они, ни попытка возрождения не расходовались.
• Пауза и перезапуск: при паузе в середине прыжка высота и пройденная дистанция не менялись, а ввод управления дорожкой блокировался. Перезапуск возвращал персонажа на среднюю дорожку, обнулял дистанцию и видимое число монет.

Во время одного заезда с препятствиями раннер прошёл дальше 216 метров и собрал 51 монету. Автоматизация браузера отправляла обычные игровые команды. Мы не меняли координаты, очки или состояние столкновений, чтобы получить этот результат.

Свайп влево переводит персонажа на видимую левую дорожку в портретной имитации браузера. Совместимость с физическим телефоном не проверялась.

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

Логику, графику и читаемость нужно оценивать отдельно

В раннере DeepSeek хорошо различались основные объекты: бирюзовый персонаж, яркие края дорожек, золотые монеты и контрастные опасности. Тёмное пустое окружение и простые здания оставляли большой простор для улучшения графики. Единственный результат не подтверждает общий вывод, будто DeepSeek лучше справляется с логикой, чем с графикой.

В отдельном эксперименте с Neon Harbor Sprint получилось яркое неоновое оформление, но силуэт автомобиля и трассу было труднее различать. В ходе оптимизации снизили разрешение рендеринга: управление стало отзывчивее, но детализация уменьшилась.

Отдельный гоночный прототип DeepSeek. Для него использовался другой запрос, поэтому он не входит в сравнение раннеров.

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

Не слишком ли ограничивают работу запросы и навыки?

Мы специально составили подробный запрос для раннера, чтобы использовать его повторно. Обычному автору должна быть доступна возможность начать с гораздо более короткой идеи. Помочь превратить её в полезное описание — одна из задач продукта.

Мы не проводили контролируемое сравнение короткого и подробного запросов. Поэтому длина запроса сама по себе не объясняет перепутанное управление. Ошибка в исходном коде напрямую объясняет, как повлияли камера и ввод; в других результатах по тому же запросу направления были верными.

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

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

Можно начать с такого запроса:

Создай небольшой трёхмерный раннер с тремя дорожками. Нужно уклоняться влево и вправо, перепрыгивать барьеры и проскальзывать под перекладинами. Управление — с клавиатуры или сенсорного экрана. Хочу хорошо различимого персонажа, приятный сбор монет и быстрый перезапуск после столкновения. Выбери сеттинг и стиль оформления.

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

Как эти проверки повлияют на следующий эксперимент

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

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

Посмотрите пример игры — Colossal Runner. В её общедоступных отобранных версиях есть последующие исправления; это отдельные версии, не совпадающие с исходными экспериментами, показанными здесь. Идеи для будущей игры также можно найти, если посмотреть другие браузерные игры.

Появилась идея небольшой игры? Составьте описание в OpenGame Studio, согласуйте основной игровой цикл и проверьте первую версию с обычным управлением.

Источник

Официальные источники подтверждают названия моделей, контекст выпуска и позиционирование разработчиков: релиз DeepSeek от 17 октября, Grok 4.6, MiMo V2.6 Flash, MiMo V2.6 Pro, GLM 5.3 Flash, Claude Haiku 5.5, а также не тестировавшаяся флагманская модель для примера, Claude Opus 5.5.

Наблюдения об игровом процессе и времени генерации получены в наших экспериментах с OpenGame Studio и проверках сохранённых исходных результатов. Восемь изображений — неизменённые снимки этих проверок с оригинальной процедурной графикой или персонажами OpenGame M0 под лицензией CC0-1.0. Ни одно изображение не является демонстрацией провайдера или улучшенной реконструкцией.