Генерация единственного в мире покемона

Обзор

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

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

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

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

В играх есть удовольствие в том, чтобы выбрать персонажа, развивать его и дать ему имя, превращая его в «собственное уникальное существо». Однако отправная точка находится среди вариантов, подготовленных разработчиками. Когда с помощью генеративного ИИ можно создать уникальное для игрока существо прямо с самой отправной точки, будет ли привязанность к нему еще сильнее?

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

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

Ход игры

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

Проблемы проектирования — если генерировать свободно, игра ломается

То, что ИИ способен придумать нового персонажа, и то, что этот персонаж будет состоять внутри игры, — это разные вещи. Если способности слишком высоки, то нарушается сложность, а если тип и навыки не сочетаются, его трудно развивать. Если внешний вид слишком сложный, то при преобразовании в спрайт размером 64×64 пикселя форму будет невозможно распознать.

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

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

Подход — проектировать не продукт, а условия его создания

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

1. Человек устанавливает границы. Сбалансированность игры, форма, читаемая на экране, выражения, которых следует избегать, сделать проверяемыми правилами.
2. ИИ конкретизирует кандидатов. На основе слов игрока предлагаются значения разрешённых элементов.
3. Машина проверяет правила. Автоматически определяет числовые значения, комбинации техник и запрещенные выражения.
4. Сообщать только о нарушениях. Кандидаты, не соответствующие требованиям, возвращаются с указанием причины и создаются заново.

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

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

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

Завершить опыт внутри игры

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

1. Создавать спецификации. Локальная языковая модель преобразует шесть слов в проверенные данные о расах.
2. Создавать форму. Модель изображений рисует эталонную иллюстрацию, а затем генерирует передний, задний и иконки для рук в едином стиле.
3. Преобразовать в игровые данные. Сократить число цветов изображения до 15 и преобразовать и сжать его в спрайт и палитру, которые могут обрабатывать GBA.
4. Отразить в запущенной игре. Записать данные в заранее зарезервированную область и вызвать появление нового вида, не перезапуская игру.

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

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

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

• В пределах проверенного действия. Я проверил на mGBA весь процесс от диалогов в игре, ввода шести символов, генерации фона, отражения в работающей игре, встреч в дикой природе, поимки до ввода прозвища.
• Это было реализовано для сравнения. Были подготовлены два входа: «пассивное поколение» без ввода и «активное поколение» с выбором слов, чтобы можно было записывать разговоры, встречи и захваты.
• Есть основа, но область не проверена полностью. Повышение уровня после поимки, изучение приемов, бои, сохранение в коробке, дальнейшее использование после сохранения подключены к существующей системе, но проверка при длительной игре не проводилась.
• Не реализованный диапазон. Функция генерации последующей эволюции на месте и эксперимент по сравнению привязанности нескольких участников остались в качестве будущих задач.

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

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

Есть два условия, которые, похоже, могут влиять на привязанность.

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

Противоположностью этому стала «Ханагицунэ», созданная отдельно от автоматической генерации для игр, через взаимодействие с несколькими генеративными ИИ и ручную работу. У этого персонажа есть особая привязанность, так как мы сравнивали варианты, исправляли их и дорабатывали до формы, которая нас устраивала. Я считаю, что это произошло благодаря как достаточному качеству, так и вовлеченности, включающей проб и ошибок.

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

реализация

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