LLM управляет героем онлайн-RPG: Gemini тянет только каждый 10-й игровой шаг

Большинство игровых проектов с LLM заканчиваются разговорами: нейросеть играет NPC и отвечает на реплики. Автор этого эксперимента пошёл дальше и отдал модели управление персонажем в сетевой RPG. Разница принципиальная: сказать можно что угодно, а сделать можно только то, что разрешают правила мира.

Как это устроено

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

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

Формат ответа задаётся схемой response_format. Автор сравнил два подхода: числовые поля с вероятностью для каждого действия и одно поле action с enum. Заметной разницы в качестве не нашёл и выбрал enum, потому что его проще парсить. Дополнительно модель возвращает цель, планы, мысли и необязательную реплику.

Где всё упирается в лимиты

На бесплатном тарифе lite-моделям разрешён один запрос раз в 4 секунды. Шаг сервера сделан 0,45 с, так что LLM в лучшем случае видит каждый десятый шаг. Дневной лимит составляет 500 запросов, после чего приходится переключать модель. Есть и неочевидный лимит: цепочка ответов ломается ошибкой про максимальную глубину примерно после 100 итераций. Возможно, он зависит от заполнения контекста.

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

Что получилось

Агент ходит, собирает предметы, строит здания и иногда выплавляет металл. Однажды он отлил наконечник кирки, один из самых сложных рецептов, правда, часть ингредиентов нашёл на трупе дварфа. Реплики у него вполне осмысленные, он комментирует свои действия и пытается говорить с NPC.

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

Практический вывод

Во-первых, скорость решает. Если бы ответ приходил за полсекунды, игру можно было бы вести синхронно и не терять шаги. Автор думает о небольшой локальной модели. Во-вторых, перечень координат в тексте плохо работает как пространственное описание. В-третьих, самый разумный вывод такой: LLM стоит поручать высокоуровневые решения и речь, например «подойди к кузнице», а путь и исполнение отдавать классическим алгоритмам.

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