Использование языковых моделей в настольных ролевых играх, таких как Dungeons & Dragons, долгое время наталкивалось на фундаментальные ограничения. Модели забывают контекст, подыгрывают пользователю, путают очерёдность ходов и теряют сюжет. Один из разработчиков решил проблему эволюционным путём: от простого чат-бота на Gemini до многокомпонентной системы с тремя специализированными агентами.
Первая попытка — интеграция Gemini через чат-бота — быстро выявила четыре ключевые проблемы. Модель не могла корректно выполнять математические операции (броски кубов), поддавалась манипуляциям игрока («подыгрывание»), путала очерёдность в бою и теряла нить сюжета по мере развития игры. Попытки исправить это через костыли типа саммари и перезапуска контекста давали лишь временный эффект.
| Агент | Отвечает за |
|---|---|
| Боец | Боевые действия (атаки игрока и NPC) |
| Арбитр | Мирную логику, загадки, триггеры врагов |
| Рассказчик | Нарратив и описание событий |
Второй прототип (PoC) строился на хранении состояния в базе данных и использовании llama-70b-versatile с инструментом для броска кубов. Автор интегрировал N8N, Telegram-бота и Google Таблицы, а модель выдавала ответ в JSON. Это решение позволило канонично пройти сценарий, но системный промпт разросся до нерабочего состояния: модель не справлялась с одновременным анализом локаций, интерпретацией намерений, бросками кубов, генерацией истории и сериализацией.
Для решения автором был создан PoC с хранением состояния в базе и единым агентом на llama-70b-versatile, но он упёрся в ограничения системного промпта.
Финальная архитектура разделила ответственность на три специализированных компонента: «Боец» — отвечает только за боевые действия, «Арбитр» — за мирную логику, загадки и триггеры, «Рассказчик» — за нарратив. Вычисления (броски кубов, попадания, HP, флаги) были вынесены в код. Это решение стало ядром движка, на котором провели закрытый альфа-тест с живыми игроками — «вертикальный срез» с одной локацией, загадкой и парой врагов.
Хотя разработка находится на ранней стадии, подход демонстрирует, что разделение задач между специализированными LLM может преодолеть ограничения монолитных моделей. Вопросы масштабирования, стоимости вызовов и адаптации к другим системам правил пока остаются открытыми.
