19 сентября 2026 года на сабреддите r/LocalLLaMA пользователь /u/EcstaticDentist опубликовал пост: три промпта в формате one shot к модели Qwen3.8 27B, цель - собрать клон Super Mario Bros. Автор оценил результат фразой «Not bad». Исходный пост в доступном описании ограничивается этой оценкой.
Прямой ответ на главный вопрос: подтверждённых данных о качестве игрового кода здесь нет. Есть заявление о трёх one shot промптах и субъективная оценка. Ни версии модели, ни квантизации, ни параметров сэмплирования, ни самого кода, ни скриншотов, ни метрик в источнике не приводится.
Дальше разбираем, что вообще можно ожидать от one shot генерации игр, почему такой кейс не заменяет бенчмарк и какие проверки понадобятся, если вы решите повторить подход на своей машине.
Что произошло: кейс с Reddit и Qwen3.8 27B
Суть простая: пользователь Reddit прогнал через Qwen3.8 27B три промпта, каждый за один проход, чтобы получить клон Super Mario Bros. Результат он назвал неплохим. Какие механики заработали и как выглядела игра, в посте не показано.
Формулировка «Not bad» ничего не сообщает о деталях. За ней может стоять запускаемый платформер с движением и платформами, а может - статичный экран с наброском логики. Различить эти случаи без кода и запуска невозможно.
Почему один пост на Reddit - это не бенчмарк
Демонстрация и тест различаются набором данных. Для воспроизводимой оценки нужны: точное имя и версия модели, формат весов и квантизация, железо, параметры запуска (длина контекста, температура, top_p), полный текст промпта, сгенерированный код, критерии приёмки и хотя бы один внешний проверяющий. В посте нет ни одного из этих пунктов.
Оценка «неплохо» зависит от ожиданий автора. Для одного человека платформер с прямоугольным персонажем и одной монетой уже успех, для другого это нерабочая заготовка. Пока нет кода и записи запуска, понять, к какому случаю относится результат, нельзя.
Практический вывод: относиться к таким сообщениям стоит как к сигналу, что тему имеет смысл проверить, а не как к доказательству уровня модели. Один удачный запуск не отменяет прогонов на своих задачах. Методику честной проверки LLM на генерации игрового кода с контрольными сценариями и внешней валидацией мы разбирали в материале про Minecraft-подобную игру.
One shot против итеративной разработки: в чём разница
One shot - это один промпт и один ответ, без правок и уточнений. Итеративный подход - цикл: промпт, запуск кода, ошибка или наблюдение, уточнение, повтор. Разница не в объёме текста, а в обратной связи. В режиме one shot модель не видит результат: у неё нет доступа ни к выводу программы, ни к логам, ни к вашему экрану.
Отсюда главное ограничение. LLM порождает код как текст по вероятностным паттернам, а не как инженер, который прогнал сборку. Неверная гравитация прыжка или инвертированное управление выясняются только при запуске, а исправлять их в one shot некому.
Пример. Промпт «сделай платформер на Python» даст каркас: окно, персонаж, платформы, обработка клавиш. При этом гравитация может оказаться слишком слабой, персонаж будет проваливаться сквозь платформы на высокой скорости или застревать в углах. Каркас есть, играть нельзя. Без второй итерации это не исправляется.
При этом one shot не бесполезен. У него своя ниша: быстрый черновик, проверка идеи, демонстрация, генерация шаблонного кода, который всё равно придётся переписывать. Кейс с Reddit относится именно к этой категории: три отдельных запроса и оценка результата.
Разбор мифа о том, что one shot заменяет обычный процесс разработки, с практическими тестами и чек-листом собран в статье про DeepSeek V4 и one-shot программирование.
Когда one shot оправдан, а когда нет
Рабочий критерий: если результат можно оценить за пять минут и переписать без потерь, берите one shot. Если нужна механика, которая должна вести себя предсказуемо, сразу закладывайте итерации.
- One shot оправдан: черновик структуры, прототип интерфейса, шаблонный код, тестовая заглушка, быстрая демонстрация идеи.
- One shot не оправдан: продакшн-код, сложная физика, интеграция со сторонним движком, задачи с длинным контекстом и несколькими модулями.
Три промпта из кейса, кстати, не превращают ситуацию в итеративную разработку. Это три отдельных запроса, а не серия правок по одному проекту: автор не пишет, что что-то исправлял после запуска. Такой набор годится для сравнения вариантов, но отладку не заменяет.
Что Qwen3.8 27B реально может сгенерировать с первого промпта
Модель класса 27B, запускаемая локально, уверенно воспроизводит типовые паттерны кода, которых много в обучающих данных. Для игр это значит: каркас на HTML5 Canvas или Pygame, обработка ввода, простые состояния (меню, игра, проигрыш), счёт очков, генерация уровня по шаблону.
Точных бенчмарков в источнике нет, поэтому оценку стоит строить на своих прогонах. Что можно утверждать без домыслов: 27B достаточно крупная, чтобы удерживать структуру проекта в контексте и следовать формату ответа, и достаточно компактная, чтобы запускаться локально в квантизованном виде.
Полезное сравнение даёт публичный разбор генерации HTML-клона Galaga на Qwen 3.8 27B: там показано, как бюджет рассуждений меняет детализацию спрайтов, анимации и механик. Читать разбор теста.
Простые механики: платформер, аркада, пошаговая логика
Что модель воспроизводит стабильно:
- Платформер: движение по горизонтали, прыжок, статические платформы, сбор предметов. Базовые паттерны повторяются в тысячах учебных примеров.
- Аркада: счёт, жизни, уровни, простые коллизии, ускорение со временем.
- Пошаговая логика: ходы, условия победы, простой ИИ соперника. Реального времени здесь нет, поэтому рассинхрон кадров и физика не мешают.
- Текстовые квесты и конечные автоматы: переходы между состояниями, инвентарь, ветвление диалогов.
Пример формулировки: «платформер на Python с Pygame, один файл, персонаж прыгает по платформам и собирает монеты». Такой запрос даёт рабочий каркас, но с огрехами в физике и коллизиях, которые придётся править.
Где начинаются проблемы: физика, коллизии, анимации
- Физика: значения гравитации, ускорения и трения модель подставляет произвольно. Персонаж прыгает слишком высоко или «прилипает» к стенам.
- Коллизии: обработка столкновений на углах и при высокой скорости - типичное место багов. Классический случай - туннелирование, когда быстрый объект проходит сквозь препятствие между кадрами.
- Анимации: согласование кадров и состояний (бег, прыжок, падение) требует дисциплины. Модель может перепутать порядок кадров или забыть про переходы.
- Звук: генерация аудио вне задач текстовой модели. Она напишет вызов воспроизведения файла, но сам файл не создаст.
- Баланс уровня: расстановка врагов, кривая сложности, ощущение управления. Это проверяется только игрой.
Отдельное направление - когда игру порождает не код, а модель мира. Прототип, где кадр Fallout 2 превратили в интерактивную 3D-сцену с управлением от языковой модели, разобран в материале про H3 World Model.
Как ставить задачу модели, чтобы получить рабочий прототип
Конкретика важнее общих фраз. Запрос «сделай игру» даст случайный набор кода. Список требований сужает пространство решений и снижает число галлюцинаций, когда модель вызывает несуществующие методы.
Структура промпта:
- Язык и библиотека: Python и Pygame, JavaScript и Canvas, без вариантов на выбор.
- Структура: один файл или конкретный набор файлов с именами.
- Управление: какие клавиши и что они делают.
- Механики: гравитация, прыжок, коллизии, условия победы и проигрыша.
- Уровень: сколько платформ, врагов и предметов, как они расставлены.
- Ограничения: без внешних ассетов, всё рисуется примитивами, без сетевых вызовов.
- Формат вывода: только код, без пояснений.
Шаблон промпта для генерации игры
Напиши на Python с Pygame один файл - платформер. Разрешение 800x600, 60 FPS. Персонаж: прямоугольник 32x32, управление стрелками, прыжок по пробелу. Физика: гравитация, ограничение вертикальной скорости, приземление на платформы. Уровень: три платформы, одна монета, победа - собрать монету. Все объекты рисуются примитивами, внешние файлы и звук не использовать. Выведи только код в одном блоке, без пояснений.
Каждый пункт работает на результат. Указание библиотеки убирает выбор между движками. Разрешение и FPS задают согласованные числа. Точный размер персонажа избавляет от случайных значений. Запрет на внешние зависимости исключает битые пути к файлам, которых у вас нет. Требование вывести только код экономит контекст и упрощает копирование.
Даже выверенный промпт не даёт готовую игру. Он даёт предсказуемый черновик, который быстрее довести до играбельного состояния.
Проверки перед запуском сгенерированного кода
Код от LLM запускается на вашей машине с вашими правами. Сгенерированный файл может содержать обращение к сети, запись в файловую систему, установку пакетов или бесконечный цикл, который подвесит систему. Проверки занимают пару минут.
Чек-лист:
- Изолированная среда: отдельное виртуальное окружение (venv, conda) или контейнер. Для кода с сетевыми функциями - только контейнер.
- Импорты и зависимости: посмотреть, что подключается, установить только явно перечисленные пакеты из официальных источников.
- Аудит логики: пройтись по вызовам функций и убедиться, что все методы существуют в вашей версии библиотеки.
- Тестовый запуск без сети и без доступа к личным файлам: отключить интернет или ограничить контейнер, чтобы сетевые запросы сразу падали.
- Лицензии: если фрагмент похож на код из открытого проекта, проверить условия использования.
- Логические ошибки: рабочий на вид код может содержать неверные условия выхода, утечку ресурсов и состояния, которые ломаются при быстром вводе.
Изоляция и аудит: минимальный набор действий
Для игрового прототипа на Pygame обычно хватает venv и визуального просмотра кода: библиотека рисует картинку и читает клавиатуру. Если в коде встречаются requests, socket, subprocess, работа с файлами или запуск внешних команд, без изоляции не обойтись.
Практический чек-лист для повторения такого кейса на своём ПК описан в разборе про локальную LLM и мод Minecraft.
Стоит ли использовать локальные модели для прототипирования игр
Плюсы локального запуска: код не уходит на сторонний сервер, нет лимитов на число запросов, можно работать офлайн и зафиксировать конкретную версию модели вместе с квантизацией, чтобы результаты повторялись.
Минусы: требования к GPU и VRAM, скорость генерации ниже облачной, качество кода обычно уступает топовым облачным моделям, обновления и настройку сервера инференса вы ведёте сами.
Облачные API дают обратное: быстрее, качественнее, но платно и с передачей кода с промптами на сторону провайдера.
Критерий выбора. Если прототип под NDA или нужны десятки и сотни итераций в день, локальная модель выгоднее. Если требуется максимально рабочий код с первых попыток и нет требований к приватности, облако сэкономит время. Локальные модели не обязаны проигрывать облаку: на узких задачах с чётким шаблоном разница стирается.
Требования к железу и реалистичные ожидания
Модель на 27B параметров требует заметного объёма видеопамяти, особенно без квантизации. Квантизация снижает запросы к VRAM и часто поднимает скорость, но влияет на качество кода и работает неодинаково на разных задачах. Точных цифр по конфигурациям в источнике нет, поэтому ориентируйтесь на свои прогоны.
Для генерации игрового кода важнее не скорость, а способность держать контекст и следовать структуре. Если модель уже запускается локально для других задач, она подойдёт и для игровых прототипов, но закладывайте время на отладку.
Ориентир простой: если одна итерация занимает больше времени, чем вы готовы ждать, локальный вариант начнёт проигрывать облаку по темпу работы.
Итог: что делать с этим кейсом на практике
Пост с Reddit - повод попробовать, а не доказательство уровня Qwen3.8 27B. Один запрос даёт черновик, рабочая игра собирается итерациями. Модель такого класса подходит для простых прототипов, но требует проверки кода и реалистичных ожиданий.
План действий:
- Сформулируйте промпт по шаблону: язык, библиотека, структура, управление, механики, ограничения, формат вывода.
- Сгенерируйте каркас и сохраните код в отдельную папку.
- Запустите в изолированной среде, без сети и без доступа к личным файлам.
- Оцените по списку: запускается, управление работает, физика предсказуема, победа и проигрыш срабатывают.
- Перейдите к итерациям: правьте по одной проблеме за раз и каждую правку проверяйте запуском.
- Зафиксируйте версию модели и параметры запуска, чтобы результат можно было повторить.
Если после третьей итерации механика всё ещё ведёт себя непредсказуемо, дешевле переписать проблемный модуль руками, чем уговаривать модель.