Документация: Quest Architect

1. Назначение

Quest Architect нужен для визуального проектирования квестового потока: что говорит игрок, что проверяется, где обновляются цели и где сценарий завершается.

• Редактор помогает держать структуру, а не только отдельные реплики.
• Главная цель UX: быстро видеть, где ветвление, где риски и где финал.
• Используй граф как «дизайн-карту» квеста, а не только как хранилище данных.

2. Быстрый старт

1. Построй «скелет» от Start до основных развилок.
2. Добавь Dialog/Condition/Switch для основных решений.
3. Отметь прогресс через Objective Set и закрытие через Objective Complete/Fail.
4. Явно поставь Quest End для финального состояния ветки.
5. Проверь warnings, пройдись по иерархии и только потом полируй тексты.

3. UX-принципы графа

Слева направо

Держи основное направление чтения слева направо. Это упрощает ревью и снижает ошибки в сложных ветках.

Один экран - одна мысль

Если в зоне слишком много пересечений, разбей ее на блоки и свяжи через Link Entry/Link State.

Минимум «скрытой логики»

Критичные переходы не должны быть неявными. Финалы и ключевые проверки лучше делать отдельными нодами.

4. Роли нод

• Dialog: коммуникация с игроком, выборы.
• Action: изменение значений.
• Condition/Switch: маршрутизация.
• Wait Event/Wait Condition: длинные сценарии с ожиданием.
• Objective*: UX-прогресс задачи.
• Quest End: явный финал.
• Comment/Group: документация и структурирование.

5. Ветвление

Condition

Считай корректной только ветку, где подключены оба выхода: true и false.

Switch

Всегда оставляй default как fallback. Это снижает риск «тихого» тупика при новых значениях.

Dialog

У каждой значимой реплики должен быть исходящий путь. Пустые ответы и тупики усложняют UX игрока.

6. Ожидания и длинные квесты

• Используй Wait Event для внешних триггеров (событие мира, завершение активности).
• Используй Wait Condition для ожидания конкретного состояния переменной.
• Ставь рядом Comment с условием и ожиданиями дизайна, чтобы при ревью не терялся контекст.

7. Работа с objective

Идентификаторы

Для одной цели придерживайся одного objectiveId во всех нодах (Set, Complete, Fail).

Жизненный цикл

Хорошая практика: Objective Set -> игровая работа -> Objective Complete/Fail -> Quest End.

8. Нода Quest End

Quest End фиксирует явный итог ветки. Это лучше, чем «случайный» конец в тупике.

• Выбери результат: complete, fail или abort.
• Не веди из нее исходящие связи.
• Стремись, чтобы финальные ветки доходили до нее осознанно.

9. Link State / Link Entry

Используй link-ноды для переиспользуемых точек входа, когда прямые длинные провода ухудшают читаемость.

• Link Entry: именованная точка продолжения.
• Link State: переход к выбранной Link Entry.
• Имена entry должны быть уникальными и смысловыми.

10. Group и Comment

Group

Разделяй крупные квесты на смысловые области: «Вход», «Проверка», «Развязка», «Фейл-ветки».

Comment

Фиксируй правила ветки, критерии успеха и временные допущения. Это ускоряет согласование в команде.

11. Hierarchy и Warnings

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

12. Горячие клавиши

• D + click: Dialog
• A + click: Action
• C + click: Condition
• S + click: Switch
• E + click: Wait Event
• W + click: Wait Condition
• O + click: Objective Set
• K + click: Objective Complete
• F + click: Objective Fail
• Q + click: Quest End
• G + click: Group

13. Чеклист ревью

1. От Start есть валидный путь.
2. У условий и свитчей нет потерянных веток.
3. Ключевые ветки заканчиваются Quest End.
4. Нет «немых» dead-end без смысла.
5. Цели имеют консистентные objectiveId.
6. Комментарии и группы помогают читать граф, а не мешают.

14. Антипаттерны

• Граф без явного финала (опора только на случайный тупик).
• Слишком длинные «провода» вместо link-механики.
• Смешивание нескольких логических сценариев в одной зоне без группировки.
• Пустые/дублирующиеся имена ключевых нод.
• Откладывание структурной проверки до конца работы.