Нейросеть вместо геймдизайнера: как собрать играбельный прототип на Unity и Unreal с помощью промтов

Нейросеть вместо геймдизайнера: как собрать играбельный прототип на Unity и Unreal с помощью промтов

Соло-разработчик в 2026 году — это уже не «человек-оркестр», а «человек с оркестром». Пока вы пишете один скрипт на C#, где-то рядом молча ждут своей очереди баланс оружия, диалоги NPC, логика спавна врагов и техдокументация, которую вы всё равно не напишете. По данным отчёта GDC State of the Game Industry, большинство инди-команд работают в составе менее пяти человек, а значительная часть — вообще в одиночку. Именно для них LLM стали тем самым недостающим отделом разработки.

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

Важно понимать ограничение: LLM не заменит художника и не соберёт вам билд. Она заменит геймдизайнера на этапе бумажной работы и техартиста на этапе рутинных скриптов. Это разные роли, и промты под них — разные.

Промт 1. Генерация игровых концептов с проверкой на уникальность

Для какой задачи: когда есть только жанр и настроение, а идеи кончились на третьем питче.

Промт:

Ты — геймдизайнер с опытом в инди-разработке. Сгенерируй 5 концептов игры в жанре [жанр] с настроением [настроение].
Для каждого укажи:
1. Core loop в 2 предложениях (что игрок делает циклично)
2. Уникальный hook (чем это отличается от типовых игр жанра)
3. Референсы (2-3 существующие игры, но не копии)
4. Технический риск (что сложнее всего реализовать соло-разработчику)
5. Минимальный MVP: какие механики обязательны, а какие можно вырезать
Не предлагай игры, требующие более 3 программистов на старте.

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

Промт 2. GDD из концепта за один проход

Для какой задачи: превратить идею в документ, по которому можно кодить, не держа всё в голове.

Промт:

Составь Game Design Document для прототипа по концепту: [описание концепта].
Формат — Markdown. Разделы:
- Elevator pitch (до 40 слов)
- Целевая платформа и управление
- Core loop с диаграммой в виде списка
- Список механик с приоритетом (Must / Should / Could) по MoSCoW
- Прогрессия: как игрок становится сильнее за первые 30 минут
- Технические требования: движок, ключевые системы, внешние ассеты
- Что НЕ входит в прототип (явные границы скоупа)
Пиши конкретно, без маркетинговых прилагательных.

Пример использования: раздел «Что НЕ входит в прототип» — самый ценный. Именно он спасает от скоуп-крипа, когда на второй неделе хочется добавить крафт, мультиплеер и открытый мир.

Промт 3. Генерация игрового баланса в виде таблицы

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

Промт:

Сгенерируй таблицу баланса для [тип контента: оружие / юниты / ресурсы].
Параметры: [список параметров, например: урон, скорострельность, дальность, стоимость].
Условия баланса: [например, «время убийства обычного врага — 2-4 секунды», «стоимость растёт быстрее урона на 20%»].
Выведи в формате Markdown-таблицы. Добавь столбец «комментарий дизайнера» с объяснением, зачем предмету такое значение.
Затем предложи, какие 2 предмета — «якорные» (задают мету) и почему.

Пример использования: для шутера с 8 пушками модель выдаёт таблицу, где дробовик имеет высокий урон, но низкую дальность. Дальше вы прогоняете эти числа в скрипт-калькуляторе Time-To-Kill и проверяете, что ни одно оружие не доминирует. Это не финальный баланс, но стартовая точка, которую не стыдно тестировать.

Промт 4. Диалоги NPC с характером, а не с энциклопедией

Для какой задачи: написать диалоги, которые звучат как люди, а не как выгрузка из вики.

Промт:

Ты — сценарист игр. Напиши диалог между NPC [имя, роль, характер] и игроком.
Контекст: [что происходит в сцене, что знает игрок, что скрывает NPC].
Требования:
- 6-10 реплик
- NPC не говорит напрямую то, что хочет скрыть — только намёки
- У NPC есть речевая привычка: [например, задаёт встречные вопросы]
- В конце диалог даёт игроку выбор из 2-3 вариантов ответа
- Никаких «как ты знаешь, я старый кузнец» — экспозицию подавай через действие
Выведи как JSON: [{speaker, text, emotion, next_options}]

Пример использования: формат JSON сразу импортируется в диалоговую систему. В Unity это может быть ScriptableObject, в Unreal — Data Table. Вы получаете не текст для чтения, а структуру для кода.

Промт 5. Процедурная генерация уровней: правила, а не ассеты

Для какой задачи: спроектировать логику генерации уровня до того, как вы откроете редактор.

Промт:

Спроектируй систему процедурной генерации уровня для [тип игры: roguelike / платформер / шутер].
Входные данные: [размер карты, тайлсет, ограничения, например «обязательно 2 выхода, не более 3 тупиков на комнату»].
Опиши алгоритм пошагово: как строится граф комнат, как проверяется связность, как расставляются точки интереса.
Затем напиши псевдокод на C#-подобном синтаксисе для Unity или Blueprint-логику для Unreal.
Укажи, где алгоритм может зациклиться, и предложи защиту — лимит итераций и fallback.

Пример использования: для roguelike модель предлагает генерацию на основе BSP-дерева с последующей проверкой связности через обход в ширину. Это классический подход, который легко реализовать на C# с использованием структур данных из System.Collections.Generic.

Промт 6. Ревью кода на C# для Unity

Для какой задачи: найти узкие места до того, как игра начнёт тормозить на сцене с 200 врагами.

Промт:

Проведи код-ревью следующего скрипта Unity на C#: [вставить код].
Ищи:
1. Аллокации в Update/FixedUpdate (GC pressure)
2. Вызовы GetComponent в цикле
3. Проблемы с порядком выполнения (разные скрипты пишут в одну переменную)
4. Утечки: подписки на события без отписки
5. Что можно заменить на Job System / Burst
Для каждой проблемы дай исправленный фрагмент и объясни, почему так быстрее.
Не переписывай то, что уже оптимально — отметь это отдельно.

Пример использования: типичный результат — замена GetComponent<Rigidbody>() в Update на кэширование в Awake. Это базовый, но реальный прирост производительности, который многие упускают в прототипах.

Промт 7. Blueprints для Unreal: описание логики словами

Для какой задачи: спроектировать Blueprint-логику, когда вы ещё не уверены, как её собрать в визуальном редакторе.

Промт:

Опиши пошаговую логику Blueprint для Unreal Engine 5.
Задача: [например, «дверь открывается, если у игрока есть ключ, и проигрывается анимация»].
Формат:
- Список нод в порядке выполнения
- Типы переменных и где они живут (Actor, GameMode, PlayerState)
- Где ставить Branch, а где — Sequence
- Какие события использовать: BeginPlay, Overlap, Custom Event
- Что может пойти не так (порядок выполнения, репликация) и как проверить
Не пиши псевдокод — описывай именно ноды и связи между ними.

Пример использования: новичок в Blueprints получает карту сборки, а не 40 минут перебора нод. Для сетевой игры модель отдельно предупредит о необходимости репликации переменной bIsOpen.

Промт 8. Техническое задание для 3D-модели или текстуры

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

Промт:

Составь техзадание для ассета [тип: персонаж / проп / текстура].
Контекст игры: [сеттинг, стиль, референсы].
Укажи:
- Стиль и уровень детализации (low-poly / stylized / semi-real)
- Технические ограничения: полигонаж, размер текстур, формат (FBX, PNG), количество материалов
- Обязательные элементы (читаемость силуэта, цветовая кодировка фракций)
- Что запрещено (например, тонкие элементы, которые ломаются при LOD)
- Чек-лист приёмки

Пример использования: чек-лист приёмки превращает субъективное «мне не нравится» в объективные критерии: силуэт читается на 20 метрах, текстура не превышает 2048×2048, нет более 3 материалов.

Промт 9. Локализация и адаптация текстов

Для какой задачи: перевести и адаптировать игровые тексты без потери характера.

Промт:

Адаптируй игровой текст для локализации на [язык].
Исходный текст: [текст].
Контекст: [кто говорит, кому, в какой ситуации].
Требования:
- Сохрани характер персонажа, а не буквальный перевод
- Учти длину строки для UI: не более [N] символов
- Предложи 2 варианта: нейтральный и с местной идиомой
- Отметь места, где шутка или каламбур не переносится, и предложи замену

Пример использования: для UI-кнопки «Продолжить» в немецкой локализации модель предупредит, что «Fortsetzen» длиннее и может сломать вёрстку — это реальная проблема, с которой сталкиваются при локализации.

Промт 10. Плейтест-опросник и анализ фидбэка

Для какой задачи: собрать структурированную обратную связь и не утонуть в ней.

Промт:

Составь опросник для плейтеста прототипа [жанр].
Цель теста: [например, «понятна ли механика без объяснений»].
Вопросы должны быть:
- конкретными (не «понравилось ли вам»)
- смешанными: закрытые + открытые
- разделены на блоки: понимание механики, сложность, желание играть дальше
Затем напиши промт для анализа ответов: как из 20 ответов вытащить 3 главные проблемы, а не 20 мнений.

Пример использования: вместо «игра прикольная» вы получаете, что 14 из 20 тестеров не поняли, зачем нужен второй ресурс. Это конкретный баг дизайна, который можно чинить.

Промт 11. Оптимизация: профилирование и гипотезы

Для какой задачи: когда FPS падает, а вы не знаете, с чего начать.

Промт:

Игра работает на [N] FPS, падает до [M] при [условие: например, 50 врагов].
Движок: [Unity / Unreal].
Платформа: [PC / mobile / консоль].
Составь план диагностики:
1. Что проверить в первую очередь (Profiler, Frame Debugger, статистика рендера)
2. 5 самых вероятных причин для этих симптомов
3. Как проверить каждую гипотезу конкретным действием
4. Что оптимизировать в первую очередь, если подтвердится
Не предлагай «оптимизировать всё» — дай приоритет по соотношению «усилие / прирост».

Пример использования: для падения FPS при большом числе врагов модель чаще всего указывает на физику и поиск пути. Решение — замена Update-поиска на таймер, кэширование, использование NavMesh в Unreal или NavMesh-агентов в Unity с ограничением количества активных.

Промт 12. Генерация названий и описаний для стора

Для какой задачи: когда игра готова, а описание для Steam писать нечем.

Промт:

Придумай 10 названий для игры в жанре [жанр], сеттинг [описание].
Требования: короткие, легко произносятся, не заняты крупными проектами (проверь логически, без выдумывания фактов).
Затем напиши описание для страницы Steam:
- короткое описание (до 300 символов)
- полное описание с абзацами: hook, механики, мир, особенности
- список тегов (до 15)
- 3 варианта короткого трейлерного скрипта (30 секунд)

Пример использования: модель не проверит занятость названия в базе Steam — это делаете вы. Но она даст 10 вариантов, из которых 2-3 будут рабочими, и черновик описания, который останется только отредактировать.

Сравнение: какие промты дают больше всего экономии времени

Как не превратить LLM в генератор мусора

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

Второе правило: просите объяснения. Если модель предлагает решение, попросите обосновать его и указать, когда оно не сработает. Это ловит галлюцинации до того, как они попадут в проект.

Третье правило: проверяйте факты. LLM может уверенно назвать несуществующий метод API. Официальная документация Unity (docs.unity3d.com) и Unreal Engine (dev.epicgames.com/documentation) — единственный источник истины по синтаксису. Промт — это черновик, а не финальный код.

Что в итоге

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

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

Если хотите системно разобраться, как встраивать LLM в пайплайн разработки — от прототипа до билда — смотрите материалы по AI-ассистированной разработке на asibiont.com/blog. Там разбираем не отдельные промты, а процессы.