Игрок D&D отрезает себе палец ради загадки - и почему для этого не нужны отдельные правила
В настольных ролевых играх ведущий регулярно сталкивается с действиями, которых нет ни в одном своде правил. В бою персонаж должен атаковать противника, использовать заклинание или отступить, но игрок внезапно предлагает нечто совсем иное: "Я откусываю себе мизинец и кладу его в чашу, чтобы открыть проход". На первый взгляд кажется, что для такого поступка необходимо заранее прописать отдельную механику. Однако создать правила на каждый возможный случай невозможно - да и не нужно.
Именно с такой ситуацией столкнулся разработчик игрового ИИ-бота для D&D. Во время первого альфа-тестирования Telegram-бота один из игроков четыре раза пытался отрезать себе палец. Каждый раз ИИ-мастер отвечал по-разному: иногда разрешал действие, иногда запрещал, а иногда просто описывал происходящее текстом. При этом состояние персонажа не менялось: здоровье не уменьшалось, загадка не обновлялась, а последствия никак не отражались на дальнейшем сюжете.
Проблема заключалась не в отсутствии конкретного пункта "правила Dungeons & Dragons отрубить палец". Гораздо важнее было научить движок обрабатывать непредусмотренные действия последовательно: определить, возможно ли оно, нужен ли бросок, какие будут последствия и как эти последствия повлияют на мир игры.
Через три месяца разработки появился MVP, способный обрабатывать подобные нестандартные запросы без жёсткого сценария. Правил именно про пальцы в системе по-прежнему нет. Вместо этого ИИ формирует суждения, а программный код принимает окончательные решения, меняет параметры персонажа и записывает результат в базу данных. Такой подход позволяет сохранить свободу импровизации и одновременно избежать противоречий.
Как устроена система судей
Любое действие игрока сначала анализирует роутер. Он разбивает запрос на отдельные атомарные действия, определяет зависимости между ними и выбирает, какие экспертные модули должны вынести суждение.
В системе используется несколько параллельных LLM-судей. Каждый отвечает за ограниченную область:
- "Дуэлянт" оценивает боевые действия;
- "Резолвер" разбирает загадки и головоломки;
- "Часовой" отслеживает реакцию врагов;
- "Импровизатор" рассматривает нестандартные решения;
- другие модули анализируют проверки, окружение и игровые ресурсы.
Разделение ответственности делает ответы более стабильными. Узкому судье не приходится удерживать в контексте всю игру и самостоятельно управлять всеми последствиями. В результате такая архитектура остаётся сравнительно недорогой: каждый модуль работает с небольшим объёмом данных, а для большинства задач достаточно компактной модели вроде GPT-4o-mini. Более подробно концепцию подобного механизма судей в игровом ИИ можно рассматривать как практический пример применения LLM в ролевом движке.
Разбор конкретного запроса
Фраза игрока "я откусываю палец и кладу его в чашу" превращается роутером в два действия:
1. персонаж откусывает себе мизинец;
2. персонаж помещает палец в чашу.
Второе действие зависит от первого: если палец не удалось откусить, положить его в чашу невозможно. Для каждого шага судьи отвечают на набор вопросов:
- возможно ли действие физически;
- существуют ли в сцене нужные предметы;
- требуется ли проверка d20;
- какая характеристика используется;
- какова сложность;
- что произойдёт при успехе и провале;
- активирует ли действие загадку или ловушку;
- заметят ли его противники;
- расходуется ли действие, бонусное действие или другое игровое ограничение.
Например, для попытки откусить палец система может определить проверку Атлетики со сложностью 15. При успехе персонаж получает урон, а загадка, связанная с чашей, считается решённой. При провале палец остаётся на месте, а загадка не активируется. Если действие происходит во время боя, оно дополнительно расходует основное действие персонажа.
Здесь особенно хорошо видно, чем отличается качественный мастеринг D&D: правила для ведущего не должны превращаться в перечень исключений на все случаи жизни. Ведущий или игровой движок должен уметь вывести решение из общих принципов - физической возможности, риска, цены ошибки и логики конкретной сцены.
Почему последствия обрабатывает код
Одного текстового ответа ИИ недостаточно. Если модель написала, что герой потерял палец, это ещё не означает, что персонаж действительно получил урон. Поэтому ИИ не изменяет состояние игры напрямую, а передаёт движку структурированное суждение.
Пока результат броска неизвестен, оба действия помещаются в отложенную очередь. Игрок нажимает кнопку броска, система берёт модификатор из карточки персонажа, генерирует случайное значение d20, складывает его с модификатором и сравнивает итог со сложностью.
При успехе движок:
- применяет урон;
- уменьшает количество хитов;
- проверяет, не погиб ли персонаж;
- фиксирует потерю пальца;
- переводит загадку в состояние "решена";
- открывает связанный проход или локацию;
- списывает использованное действие;
- сохраняет изменения в базе данных.
При провале первое действие считается неудачным, а второе автоматически отменяется. Если герой пытался сделать это в бою, дополнительно фиксируется расход хода. Когда доступных действий уже нет, система может применить предусмотренное правилами ограничение - например, перенести попытку на следующий раунд.
Такой механизм решает проблему зависимых действий. ИИ не обязан заранее знать все возможные комбинации. Ему достаточно описать условия и вероятные исходы, а код уже гарантирует, что изменения будут применены один раз и в правильном порядке. Это важный принцип, если разбирать, как вести нестандартные ситуации в Dungeons & Dragons: повествовательная интерпретация остаётся за моделью, а критические игровые последствия контролирует детерминированная логика.
Что это даёт ведущему
Подобный подход полезен не только для бота. Он показывает, как можно организовать Dungeons & Dragons создание правил для игровых ситуаций без постоянного расширения книги исключений. Вместо того чтобы заранее описывать сотни странных действий, достаточно определить универсальные категории: возможность, проверка, цена, последствия, реакция мира и связь с другими действиями.
Система также помогает сохранять честность. Если ИИ каждый раз по-разному решает, можно ли пожертвовать частью тела ради загадки, игроки быстро перестают понимать границы мира. Когда же решение проходит через одинаковый набор вопросов и фиксируется в состоянии игры, даже необычный поступок воспринимается как полноценная игровая механика.
Ещё один плюс - прозрачность для разработчика. Можно отдельно тестировать работу роутера, судей, генератора бросков и обработчика последствий. Если загадка открылась без успешной проверки, проблема будет найдена в конкретном модуле, а не потеряется в длинном текстовом ответе модели.
В итоге правила D&D решение загадок в игре не обязаны быть заранее прописаны для каждого предмета или жертвы. Достаточно, чтобы система понимала контекст, умела разделять действия и проверяла зависимости между ними. Тогда игрок может предложить почти любую безумную идею, а мир отреагирует логично, последовательно и с учётом реальной цены поступка.