Опубликовано: 12.09.2026 | Источник: The Verge – Tech Section

# Семантический анализ (перед генерацией) **Primary keyword:** нарративный движок для ВКР / ветвящийся сюжет в дипломной работе **LSI-запросы:** конечный автомат состояний, графовая модель данных, Neo4j / Cypher, Dialogue System, Unreal Engine 5, Unity, JSON-схема диалогового узла, OpenTelemetry, CI/CD-пайплайн, Git LFS **Вопросы студентов:** «Нужно ли делать игру целиком или хватит подсистемы?», «Где брать метрики, если нет реальных игроков?», «Как оформить граф диалогов по ГОСТ?», «Обязательно ли писать код на защите?», «Чем оправдать выбор графовой БД, а не реляционной?» **Ключевые сущности:** ГОСТ 34.602-89 (ТЗ на АС), ГОСТ 19.701-90 (схемы алгоритмов), ISO/IEC 25010 (модель качества ПО), OpenTelemetry, CI/CD-пайплайн, Neo4j. ---

Ветвящийся нарратив в дипломе: движок графовых диалогов и телеметрия выборов игрока

24 марта 2026 года выходит Life is Strange: Reunion — продолжение, которое возвращает Макс и Хлою спустя годы после первой части и «Double Exposure». По сообщению The Verge, для актёров озвучки возвращение стало такой же неожиданностью, как и для фанатов: сюжет пришлось перепривязать к решениям, принятым игроками больше десяти лет назад. С точки зрения инженерии это не «ещё одна игра», а классическая задача сериального продукта: как хранить, версионировать и мигрировать состояние ветвящегося мира между релизами. Для выпускника ИТ-направления здесь лежит готовый каркас ВКР — от модели данных до наблюдаемости и метрик.

Три темы ВКР, которые вырастают из этого кейса

Тема 1. Подсистема хранения и воспроизведения состояния ветвящегося нарратива на графовой модели

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

Цель: спроектировать и реализовать подсистему, которая хранит решения игрока, воспроизводит их при загрузке и корректно переживает обновление контента.

• сравнить модели представления нарратива (дерево, граф, иерархический автомат) и обосновать выбор;
• разработать схему данных: узлы-сцены, рёбра-переходы, флаги состояния, версия схемы;
• реализовать API доступа к состоянию и слой миграций между версиями;
• провести нагрузочное тестирование и оценить трудоёмкость внедрения.

Структура. Глава 1 — анализ предметной области и существующих движков диалогов. Глава 2 — проектирование модели данных, схемы БД, UML-диаграмм. Глава 3 — реализация, тестирование, расчёт экономического эффекта.

Тема 2. Сервис телеметрии выборов игрока и аналитика «воронки» сцен

Актуальность. Сериальные проекты живут за счёт данных: какие ветки игроки проходят, где бросают, какие решения статистически доминируют. Без телеметрии решение о ретконе принимается вслепую.

Цель: построить сервис сбора и агрегации событий прохождения с метриками качества по ISO/IEC 25010.

• спроектировать событийную схему (идентификатор игрока, узел, выбор, время, версия сборки);
• развернуть приёмник событий и хранилище с партиционированием;
• настроить сбор метрик через OpenTelemetry и дашборды воронки;
• оценить пропускную способность и стоимость хранения.

Структура. Глава 1 — обзор подходов к продуктовой аналитике. Глава 2 — архитектура сервиса, потоки данных. Глава 3 — нагрузочные испытания, расчёт затрат на инфраструктуру.

Тема 3. Конвейер локализации и озвучки для многоязычного нарративного проекта

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

Цель: автоматизировать подготовку, валидацию и доставку локализационных ресурсов средствами CI/CD.

• формализовать формат обмена строками и привязку реплик к узлам графа;
• настроить хранение крупных бинарных ресурсов (Git LFS) и пайплайн сборки;
• реализовать автоматические проверки: пустые строки, расхождение ключей, превышение длины;
• измерить время сборки до и после автоматизации.

Структура. Глава 1 — стандарты локализации и обзор инструментов. Глава 2 — проектирование пайплайна. Глава 3 — внедрение, метрики, экономика.

Аналитическая глава: чем обосновать выбор модели нарратива

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

В тексте главы обязательно свяжите выбор со статьёй: первоисточник описывает, что продолжение «дописывает» историю задним числом. Это и есть аргумент в пользу графа — вставка узла не ломает уже сохранённые прохождения. Не забудьте про ГОСТ 34.602-89: требования к системе оформляются как ТЗ, а ГОСТ 19.701-90 пригодится для схем алгоритмов обхода графа.

Проектная часть: схема данных и API

Проектирование начинается с формата узла. Держите контракт явным: версия схемы, идентификаторы, условия перехода. Пример фрагмента:

{
  "schema_version": "2.1",
  "node_id": "ch3_reunion_meeting",
  "text_key": "LIS_REUNION_CH3_014",
  "conditions": [
    { "flag": "chloe_saved", "op": "eq", "value": true },
    { "flag": "farewell_ending", "op": "in", "value": ["stay", "leave"] }
  ],
  "choices": [
    { "id": "c1", "target": "ch3_reconciliation", "sets": { "trust": "+2" } },
    { "id": "c2", "target": "ch3_silence", "sets": { "trust": "-1" } }
  ]
}

Для хранения графа удобна документно-графовая связка. Запрос на поиск всех сцен, достижимых при текущем сохранении, читается почти как естественный язык:

MATCH path = (start:Scene {id: $current})-[r:TRANSITION*1..20]->(reachable:Scene)
WHERE all(rel IN relationships(path) WHERE rel.condition IS NULL OR rel.condition IN $activeFlags)
RETURN DISTINCT reachable.id, length(path) AS depth
ORDER BY depth;

В пояснительной записке отразите три вещи: ER- или UML-диаграмму классов, спецификацию API (лучше в виде таблицы методов с кодами ответов) и описание слоя миграций. Миграции — это то, что отличает серьёзную работу от учебного прототипа.

Тестирование, метрики и наблюдаемость

Раздел «Тестирование» проваливается чаще всего, потому что студент пишет «программа работает корректно». Замените это на измеримые величины — и защита станет разговором по делу.

Наблюдаемость стройте на OpenTelemetry: трассировка запроса «загрузка сохранения → обход графа → выдача сцены» покажет узкое место без догадок. Нагрузочное тестирование можно проводить синтетическим потоком событий — реальные игроки для ВКР не требуются, достаточно обоснованной модели нагрузки.

Чему вы научитесь на такой работе

• формализовывать предметную область в виде модели данных, а не «табличек в блокноте»;
• обосновывать выбор стека через критерии, а не через популярность технологии;
• проектировать миграции и версионирование — навык, который спрашивают на собеседованиях;
• собирать метрики и строить отчёты о нагрузочном тестировании;
• оформлять ТЗ, схемы и спецификации по ГОСТ 34.602-89 и ГОСТ 19.701-90.

Частые вопросы

Нужно ли делать игру целиком, или хватит одной подсистемы?

Хватит подсистемы. ВКР по направлению «Информационные системы» оценивает инженерное решение, а не коммерческую полноту продукта. Достаточно прототипа интерфейса и набора синтетических данных, на которых подсистема проверяется. Полноценная игра увеличит объём в разы без прироста оценки.

Где брать метрики, если реальных пользователей нет?

Три источника: генератор синтетической нагрузки с обоснованным профилем (например, 500 прохождений в минуту), эталонные сохранения из разных версий схемы и замеры на заранее подготовленном наборе из 10 000 узлов графа. Главное — описать методику измерения, тогда цифры будут защищаемыми.

Как оформить граф диалогов и схему БД?

Диаграмму состояний или деятельности — по ГОСТ 19.701-90, модель данных — в нотации «вороньих лапок» или UML-диаграммой классов. Дублируйте крупные схемы в приложения, а в тексте оставляйте ссылку на приложение с кратким пояснением.

Обязательно ли демонстрировать код на защите?

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

Чек-лист перед сдачей

Источник: Life is Strange: Reunion is a full-circle moment for its stars (опубликовано 2026-03-24)