Как сохранить тестируемость разветвленных игровых сюжетов

Начните с графа, фиксирующего поведение

Представьте каждый игровой фрагмент или сцену как узел, а каждый выбор — как направленное ребро. Снабдите ребра аннотациями с их условиями и эффектами: например, `has_key = true` делает доступным действие «Открыть ворота», которое задает `gate_open = true`. Явно обозначьте концовки, циклы и точки схождения (rejoin points). Точка схождения — это место, где разные маршруты снова пересекаются; здесь удобно проверять, может ли история продолжаться из нескольких предысторий без переноса нежелательного состояния.

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

Такая структура также помогает находить точки принятия решений, которые легко упустить в объемном сценарии. В статье 2024 года Алексей Тихонов исследует обнаружение точек принятия решений персонажами в разветвленных повествованиях и предлагает набор данных на основе графов игр формата Choose Your Own Adventure. Его задача касается именно идентификации нарративных развилок, а не валидации методологии QA; это может подсказать командам, как инвентаризировать выборы, но не доказывает эффективность описанного здесь подхода к тестированию. [Tikhonov, “Branching Narratives: Character Decision Points Detection”](https://aclanthology.org/2024.games-1.8/)

Тестируйте переходы состояний, а не просто посещение сцен

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

Например, тест для выбора «Показать карту» может проверять, что карта показана, значение `trust` не изменилось, а маршрут переходит к общей сцене в обсерватории. Парный тест начинается с `has_map = false` и проверяет, что данный выбор недоступен или приводит к указанной альтернативе. Точное ожидаемое поведение зависит от спецификации сюжета; главное — проверять его явно, а не судить о корректности по названию фрагмента.

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

Используйте вымышленный пример для наглядности покрытия

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

**A:** `trust = high`; попросить архивариуса о помощи. Вариант помощи отображается; `trust` остается высоким; маршрут ведет в коридор. Доступность выбора и переход

**B:** `trust = low`; попросить о помощи. Вариант помощи скрыт или отклоняется согласно спецификации. Негативное условие

**C:** `has_key = true`; открыть боковую дверь. Дверь открывается; маршрут ведет в коридор; ключ расходуется, только если это предусмотрено. Эффект состояния и схождение

**D:** `has_key = false`; попытаться открыть боковую дверь. Дверь не открывается; флаг успеха не устанавливается. Негативная проверка

**E:** Из коридора взять запечатанное письмо. `has_letter = true`; в более поздней сцене с уликами появляется реплика, связанная с письмом. Последующий результат

**F:** Из коридора оставить письмо. `has_letter = false`; реплика о письме отсутствует. Контраст результатов и негативная проверка

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

Приоритизируйте покрытие веток при лавинообразном росте комбинаций

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

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

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

Исследования в области плейтестинга игр предлагают смежную, но ограниченную по применимости идею. В препринте Гордильо и коллег на arXiv за 2021 год описаны агенты с обучением с подкреплением, получающие вознаграждение за новые действия для исследования покрытия состояний в сложном 3D-сценарии. Эта работа посвящена исследованию в трехмерной игровой среде, а не выборам в разветвленном повествовании и не конкретному методу тестирования переходов, описанному здесь. Она подтверждает, что автоматизированное исследование может служить дополнением, однако ни эта работа, ни статья Тихонова не валидируют непосредственно данный метод тестирования нарратива. [Gordillo et al., “Improving Playtesting Coverage via Curiosity Driven Reinforcement Learning Agents”](https://arxiv.org/abs/2103.13798)

Добавьте негативные проверки и плейтесты с участием людей

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

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

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

Практический цикл тестирования изменяющегося сюжета

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

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

Продолжить изучение темы