# Геймдизайн пользовательского контента ## Цель Инструменты должны помогать создавать понятный, проверяемый и поддерживаемый контент, не навязывая автору один стиль игры. 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. ## Локации Локация проектируется слоями: - 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 и приблизительную стоимость рендера. ## Подземелья и 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.