105 lines
6.7 KiB
Markdown
105 lines
6.7 KiB
Markdown
# Геймдизайн пользовательского контента
|
||
|
||
## Цель
|
||
|
||
Инструменты должны помогать создавать понятный, проверяемый и поддерживаемый контент, не навязывая автору один стиль игры. 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.
|