open-wc/docs/GAME_DESIGN.md

Геймдизайн пользовательского контента

Цель

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

Карточка игровой функции

Перед реализацией функции фиксируются:

• целевой игрок и player goal;
• core loop и ожидаемая длительность;
• правила, ресурсы и серверная авторитетность;
• affordance, feedback и failure/recovery states;
• reward, progression и economy impact;
• solo/group/PvP context;
• accessibility и localization;
• telemetry/test questions;
• abuse/exploit risks.

Настройка должна быть data-driven там, где это не нарушает безопасность и целостность сервера.

Квесты

Квест описывается через intent и progression graph, а не только набор DB-полей. Проверяются:

• понятная причина и цель;
• доступность giver/ender;
• достижимость каждого objective;
• prerequisites, chains и mutually exclusive branches;
• плотность целей, travel time и конкуренция игроков;
• drop chance и ожидаемое число действий;
• failure/retry для escort, timed и scripted objectives;
• reward относительно уровня, сложности и экономики;
• локализация и отсутствие противоречий текста фактическим правилам.

Graph validator обнаруживает циклы без намеренного repeat policy, недостижимые узлы, отсутствующие targets и dead ends.

Spatial validator на основе navigation backend (первоначально optional recast-rs) отдельно проверяет физическую достижимость giver, objectives и turn-in для заявленного movement profile. Результат является authoring diagnostic: он не заменяет server pathfinding и требует server-integrated playtest для окончательного подтверждения.

Локации

Локация проектируется слоями:

• macro navigation и landmarks;
• безопасные маршруты и опасные зоны;
• quest hubs и distribution целей;
• spawn ecology и respawn pressure;
• точки отдыха, vendors, graveyard и transport;
• визуальная читаемость, lighting, audio и weather;
• streaming/performance budgets;
• boundary behavior и переходы между зонами.

Редактор должен показывать heatmaps плотности spawn, quest travel paths, level/difficulty bands, line-of-sight blockers и приблизительную стоимость рендера.

Для подземелий navigation graph должен проверять связность входа, encounter rooms, дверей, recovery route и graveyard. Dynamic obstacles и off-mesh connections описываются явно, чтобы закрытая дверь или специальный переход не давали ложный положительный результат.

Подземелья и encounters

DungeonPackage объединяет входы, difficulty, encounters, doors, triggers, trash groups, bosses, loot, quests, graveyards, scripts и localization.

Для encounter фиксируются:

• learning objective и fantasy;
• phases и transition conditions;
• ability cadence и telegraphs;
• positioning/movement requirements;
• tank/healer/damage responsibilities без исключения альтернативных составов, если это цель;
• fail states, wipe recovery и reset;
• tuning parameters отдельно от script logic;
• deterministic simulation cases и live playtest checklist.

Сложность должна появляться из читаемых взаимодействий, а не из скрытой информации или случайной несовместимости механик.

Баланс

• Формулы и tuning values версионируются отдельно от UI и scripts.
• У каждого параметра есть unit, диапазон и rationale.
• Нельзя балансировать только по одному идеальному сценарию; проверяются level, gear, party size и latency bands.
• Изменение reward/economy сопровождается impact report.
• Randomness документирует distribution, pity/guarantee policy при наличии и worst-case experience.

Feedback и UX

Игрок должен понимать: что произошло, почему, что изменилось и что можно сделать дальше. Network delay не маскируется ложным успехом: pending, confirmed и rejected состояния различаются визуально.

Критическая информация не должна зависеть только от цвета, звука или addon. Ошибки range, target, resource, cooldown, inventory space и prerequisites имеют специфичное сообщение.

Совместимость и модификации

Автор может переопределять tuning, тексты, layouts, content graphs и presentation assets через overlay-пакеты. Изменение protocol/security/authoritative rules требует отдельного совместимого profile. Пакет объявляет зависимости, конфликты и ожидаемые core capabilities.

Playtesting

Каждая feature проходит:

1. content validation;
2. designer smoke в offline preview;
3. server-integrated functional test;
4. exploratory playtest с заранее заданными вопросами;
5. regression после правок;
6. performance и multiplayer soak, если применимо.

Отчёт отделяет наблюдения от интерпретаций и решений. Исправление симптома не заменяет проверку исходной design hypothesis.