# Attribute Stats Visibility MVP ## Purpose Этот документ фиксирует, какие derived stats должны быть видимы игроку в MVP, какие можно показывать только в расширенном виде, а какие должны оставаться внутренними runtime-параметрами. Отдельная цель документа - зафиксировать легковесный подход к обновлению статов: система не должна постоянно пересчитывать весь набор характеристик, если можно применять только минимальные изменения к уже подготовленным значениям. ## Related Docs - `docs/gameplay/attribute-system-gdd.md` - `docs/gameplay/attribute-reference.md` - `docs/gameplay/stat-catalog-mvp.md` - `docs/gameplay/combat-resolution-gdd.md` ## UI Philosophy Для MVP игрок должен видеть минимум информации, но этот минимум должен быть полезным. - игрок должен понимать, что прокачка реально меняет боевую эффективность - экран характеристик не должен превращаться в таблицу внутренних коэффициентов - основные сложные расчеты должны оставаться под капотом - вторичные и технические derived stats лучше не показывать, если они не помогают принимать решения в билде Главный принцип: отображать только те числа, которые игрок может быстро связать со своим ощущением в бою. ## Performance Philosophy Система статов должна быть легковесной и быстрой. - не пересчитывать весь stat sheet каждый кадр - не пересчитывать все derived stats при любом мелком изменении - хранить базовые атрибуты и заранее выделенные группы derived stats отдельно - применять только минимальные модификаторы к затронутым группам статов - обновлять итоговые значения по событию, а не по постоянному polling Рекомендуемый runtime-подход для MVP: - есть `base attributes` - есть `derived stat buckets` - есть `modifiers` от экипировки, класса, бафов и навыков - есть `dirty flags` или аналогичная пометка затронутых групп - при изменении источника обновляется только нужный bucket, а не весь персонаж целиком Пример групп пересчета: - offensive bucket: damage, attack speed, crit, penetration - resource bucket: mana, mana regen, stamina, stamina regen - caster bucket: spell power, cast speed, status power - defense bucket: HP, HP regen, armor, control resist, stagger resist - utility bucket: move speed, projectile speed, reload modifiers, class-specific mastery bonuses Если меняется только `Стойкость`, нет причины пересчитывать весь ranged или caster stack. Если меняется только бонус на projectile speed, не нужно заново собирать защитные статы. ## MVP Main Stats Это основные числа, которые стоит показывать в базовом MVP UI. - `HP` - `Stamina` - `Mana` - `Damage` - `Attack Speed` - `Armor` - `Move Speed` Правила показа: - `Damage` должен быть приведен к понятной игроку форме, без раскрытия всех внутренних коэффициентов - `Stamina` должна отображаться как ресурс сильных физических действий, dodge/sprint и weapon-heavy commitments, а не как постоянный налог на базовый бой - `Mana` должна отображаться как магический ресурс каста и spell-oriented умений - `Armor` лучше показывать как единое защитное число для MVP, если отдельный breakdown еще не нужен - `Move Speed` полезен, потому что напрямую ощущается руками в top-down action RPG Почему именно этот набор: - он достаточно мал, чтобы не перегружать интерфейс - он покрывает offensive, defensive и utility-изменения - игрок видит, что числа меняются от атрибутов, оружия и экипировки - сложные производные параметры при этом остаются скрытыми ## Advanced Stats Эти статы не обязаны быть видны в основном экране, но могут отображаться в detail view, tooltip, расширенной панели или отладочном UI. - `HP Regen` - `Stamina Regen` - `Mana Regen` - `Cast Speed` - `Crit Chance` - `Magic Resist` - `Armor Penetration` - `Control Resist` - `Status Power` - `Block Power` - `Projectile Speed` - `Mastery Bonus` Правила показа: - `Mastery Bonus` лучше показывать не как абстрактное число, а как контекстный бонус класса, оружия или archetype - `Crit Chance` и `Cast Speed` полезны только если соответствующий archetype реально на них опирается - `Magic Resist` не нужно тащить в основной экран, если магические угрозы еще не занимают большую долю MVP-боя - `Projectile Speed` и `Block Power` стоит показывать только когда игрок использует подходящее оружие или билд - `Magic Resist` в advanced view должна читаться как итог из `Фокуса`, `Мастерства` и экипировки, а не как прямой показатель одного атрибута Почему это не main UI: - эти статы уже полезны для билдостроения, но не нужны каждую секунду - без контекста они быстро создают лишний визуальный шум - часть из них зависит от класса или weapon archetype и не обязана быть всегда релевантной ## Hidden Runtime Stats Эти значения должны оставаться внутренними runtime-параметрами и не обязаны отображаться игроку в MVP. - `crit quality` - `weak spot multiplier` - `headshot precision bonus` - `debuff duration reduction` как отдельное техническое число - `stagger threshold modifiers` - `interrupt resistance coefficients` - `anti-slow coefficients` - `friendly fire reduction` - `projectile control coefficients` - `reload window modifiers` - внутренние `mastery conversion rules` - soft cap thresholds и post-cap diminishing returns - служебные class-specific multipliers - промежуточные коэффициенты скейлинга оружия и навыков Почему эти статы нужно скрывать: - они в основном полезны движку, а не игроку - многие из них не читаются без длинного системного контекста - их отображение повышает шум, но не улучшает качество решений в MVP - часть этих параметров еще может меняться при балансировке и не должна закрепляться в UI слишком рано ## Attribute To UI Mapping Чтобы игрок видел связь атрибутов с результатом, но без перегруза, для MVP рекомендуется такой уровень читаемости: - `Мощь` в основном проявляется через `Damage` - `Ловкость` в основном проявляется через `Attack Speed` и частично `Move Speed` - `Фокус` в основном проявляется через `Mana` - `Стойкость` в основном проявляется через `HP` и частично `Armor` - `Stamina` в основном читается как отдельный физический ресурс, который поддерживается `Стойкостью`, `Ловкостью`, классом и экипировкой - `Мастерство` в основном проявляется через контекстный `Mastery Bonus` в advanced view, а не как центральный main stat Это дает игроку понятную обратную связь, но не заставляет UI раскрывать весь внутренний combat math. ## Runtime Update Model Для MVP рекомендуется событийная модель обновления статов. Источники изменений: - изменение атрибутов персонажа - смена класса или class state - экипировка или снятие предмета - применение бафа или дебафа - смена оружия - активация временного skill modifier Правила обновления: - каждое изменение должно помечать только затронутые stat buckets - derived stats пересчитываются только по dirty-группам - UI обновляется только если изменились отображаемые main или advanced stats - hidden runtime stats могут обновляться вместе со своим bucket, но не должны триггерить лишние UI refresh - ресурсные пулы и их автопополнение должны обновляться отдельно от offense/defense bucket, если изменение не затрагивает другие группы - `Stamina` изменения должны отдельно обновлять pool и regen, чтобы heavy-weapon pressure или dodge-расход не вызывали лишний пересчет unrelated боевых bucket Для MVP нежелательно: - полный пересчет всех статов на каждом тике - хранение одной гигантской формулы для всех классов и всех источников сразу - постоянная сборка UI-строк из runtime-модели без кэша итоговых значений ## Recommended MVP Contract Минимальный контракт для практической реализации: - `MVP Main Stats` - `HP` - `Stamina` - `Mana` - `Damage` - `Attack Speed` - `Armor` - `Move Speed` - `Advanced Stats` - `HP Regen` - `Stamina Regen` - `Mana Regen` - `Cast Speed` - `Crit Chance` - `Magic Resist` - `Armor Penetration` - `Control Resist` - `Status Power` - `Block Power` - `Projectile Speed` - `Mastery Bonus` - `Hidden Runtime Stats` - все внутренние коэффициенты, soft caps, class hooks и промежуточные combat modifiers ## Final Position Для MVP UI нужно показывать мало, но полезно. Игрок должен видеть, что его персонаж стал сильнее, быстрее или живучее, не погружаясь в технические детали формул. Основной массив derived stats должен оставаться под капотом. Runtime-система должна обновлять только затронутые группы характеристик и не выполнять полный пересчет без необходимости. Это даст одновременно чистый UI и легковесную реализацию.