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

Обзор

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

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

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

Вопрос — если что-то уникально, возникает ли привязанность?

Игры позволяют выбирать, развивать и называть персонажей, пока те не начинают ощущаться по-настоящему своими. Но отправной точкой всё равно остаётся набор вариантов, подготовленных разработчиком. Если бы генеративный ИИ позволял игроку участвовать в создании персонажа с самого начала, стала бы привязанность сильнее?

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

Прототип не позволяет сделать вывод о привязанности. Его цель — встроить сгенерированный контент в обычную игру и определить условия для будущих сравнений.

Ход игры

Ниже показан вариант с участием игрока. В лесу Петалбург (Petalburg Woods) игрок говорит со старушкой и выбирает шесть слов из существующего словаря Easy Chat. Генерация продолжается в фоне, пока игрок играет дальше. Крик сообщает о готовности нового вида; вход в высокую траву вызывает встречу, и покемона можно поймать обычными действиями. При каждой генерации создаются имя, тип, базовые характеристики, приёмы, боевые спрайты спереди и сзади и значок для команды. Полная последовательность показана в демонстрационном видео.

Задача проектирования: сделать сгенерированных персонажей пригодными для игры

Создать нового персонажа и обеспечить его работу в игре — разные задачи. Слишком высокие характеристики нарушают баланс сложности, а несогласованные типы и приёмы могут затруднить развитие персонажа. Чрезмерно сложный дизайн может стать неузнаваемым при уменьшении до спрайта 64 × 64 пикселя.

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

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

Подход: определить условия генерации

Система просит большую языковую модель (LLM) заполнить заранее заданные поля — имя, тип, базовые характеристики, приёмы, форму тела и цвет, — а не написать произвольный текст. Валидатор проверяет каждый ответ перед его принятием. Если ответ нарушает правило, система возвращает конкретное нарушение и просит модель повторять генерацию, пока требования не будут выполнены.

1. Человек задаёт границы. Требования к игровому балансу, читаемости спрайтов и допустимому содержанию становятся явными проверяемыми правилами.
2. ИИ разрабатывает варианты. Модель использует слова игрока, предлагая значения разрешённых полей.
3. Система проверяет результат по правилам: автоматически проверяются числовые диапазоны, сочетания приёмов и запрещённое содержание.
4. Обратная связь касается только нарушений. Вариант, нарушивший правило, возвращается с указанием причины и генерируется заново.

Ограничения для сохранения игрового баланса. Я задал сумму базовых характеристик в диапазоне 280–360 и верхние и нижние пределы для каждой характеристики. Приёмы извлекались из исходного кода игры и ограничивались приёмами типа самого вида или нормального типа. Приёмы, приводящие к нокауту с одного удара, самоуничтожению, фиксированному урону, а также чрезмерно мощные приёмы были исключены. Валидатор также проверял число атакующих приёмов и наличие приёмов типа самого вида. Шанс поимки, скорость роста и другие факторы были фиксированы, чтобы различия между результатами генерации оставались пригодными для сравнения.

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

В одном зафиксированном запуске модель сначала предложила сумму базовых характеристик 380. Валидатор обнаружил нарушение и запросил повторную генерацию; в итоге получилась спецификация с суммой 320. Результатом разработки стал процесс, который отклоняет варианты за пределами заданных ограничений, а не полагается на случайный успех.

Сохранить весь процесс внутри игры

Игрок использует только внутриигровые разговоры, выбор слов и встречи в траве; отдельного экрана генерации нет. Вычислительно сложная работа выполняется процессом Python на ПК, который обменивается данными с игрой через файлы. Lua-скрипты в эмуляторе mGBA связывают две части, сохраняя привычное управление и вынося обработку ИИ за пределы игры.

1. Генерация спецификации. Локальная языковая модель превращает шесть слов в данные вида, которые проверяются перед использованием.
2. Генерация изображений. Модель создаёт опорную иллюстрацию, а затем визуально согласованные спрайты спереди и сзади и значок для команды.
3. Преобразование в игровые данные. Изображения сокращаются до 15 цветов, затем преобразуются и сжимаются в спрайты и палитры, совместимые с Game Boy Advance (GBA).
4. Интеграция в работающую игру. Данные записываются в зарезервированную область, добавляя новый вид без перезапуска игры.

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

То, что было подтверждено с помощью прототипа

Я самостоятельно создал прототип для проверки технической осуществимости. Это не законченная игра и не исследование с участием пользователей. Ниже разделены проверенные возможности, реализованные функции и то, что ещё не проверено.

• Проверено от начала до конца. В mGBA я подтвердил полную последовательность: внутриигровой разговор, выбор шести слов, фоновая генерация, интеграция в работающую игру, встреча в дикой природе, поимка и ввод прозвища.
• Реализовано для будущего сравнения. Я добавил два способа запуска: пассивную генерацию без ввода и генерацию с участием игрока через выбор слов. Разговоры, встречи и поимки можно записывать в журнал для сравнения.
• Связано с существующими системами, но не проверено в длительной игре. Повышение уровня после поимки, изучение приёмов, бои, хранение покемонов в ящиках и использование после сохранения интегрированы с существующими игровыми системами. Я не проверял их в продолжительных игровых сессиях.
• Дальнейшая работа. Генерация эволюционировавших форм во время игры не реализована; сравнительные исследования привязанности с несколькими участниками не проводились.

Результат собственного опыта — только уникальности оказалось недостаточно для возникновения привязанности

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

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

• Качество результата. Если внешний вид и концепция персонажа недостаточно привлекательны, одного статуса «единственного в данном прохождении» может не хватить для поддержания привязанности.
• Глубина участия. После выбора шести слов результат ощущался скорее как полученный, чем как созданный мной. Я предполагаю, что вовлечённость зависит от качества творческого процесса — пересмотра выбора, сравнения альтернатив, исправления деталей и ответственности за результат, — а не просто от увеличения объёма ввода.

При этом я чувствую привязанность к Ханагицунэ (Hanagitsune) — персонажу, которого создал вне автоматизированного игрового процесса через повторные диалоги с несколькими инструментами генеративного ИИ и ручную доработку. Я сравнивал варианты, исправлял детали и продолжал, пока результат меня не устроил. Думаю, этой привязанности способствовали и качество результата, и моё участие в процессе последовательных доработок.

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

Реализация

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