Решили: величина, которая читается как категория и сравнивается с соседями, объявляется
ступенью из закрытого именованного списка; число за ступенью живёт в одном конфиге, а персональное
отклонение задаётся долей от ступени. Правило общепроектное, а не про свечение: его повод — bloom,
но дом ему code-standards §9.
Почему: паттерн уже жил в проекте на одной величине (AttackRangeBand) и там же был обоснован,
но не был назван, поэтому не переносился. Пока он не назван, каждая новая величина заводится
свободным числом и повторяет оба известных отказа: незаданное поле молча уезжает на дефолт
конфига (Кровомант — дальник со снарядом, дравшийся вплотную), а заданные расползаются в россыпь
несопоставимых чисел без базы. Яркость свечения дошла до семи множителей (1.8 / 2.0 / 2.2 / 2.5 /
2.6 / 2.75 / 3.2) в двух конфигах, и весь их разброс уложился меньше чем в полтора стопа — язык
света оказался плоским, а вспышка смерти светила тусклее ядра обычного удара.
Отвергнута форма «база плюс отклонение в процентах», которую разбирали первой: при пороге bloom
1.0 в свечение уходит превышение над порогом, поэтому «+20% к множителю» (×2.0 → ×2.4) даёт +40%
свечения. Процент от числа в поле не равен проценту от того, что видит глаз. Отсюда общее следствие
в правиле: шаг лестницы берётся в единицах восприятия величины (для света — стоп, и считается он от
яркость − порог), а не в единицах хранения.
Граница положена сразу, до первого применения: ступень нужна там, где на вопрос «почему тут именно столько» честный ответ «потому что это важнее обычного удара», и не нужна там, где ответ «так посчиталось» — каскад статов, урон после множителей, тайминг, замеренный из клипа.
Сказано: «одна лестница - супер гуд идея. У нас такое много очень где юзается (например, дальности атаки и не только). Запиши это как наша постоянная фича - делить все на такие “уровни”, а балансить или что-то менять уже относительно конкретных уровней, уменьшая или убавляя значение конкретного уровня. Будто очень удобная фигня.» (2026-08-06, сессия d760c178). Формулировка правила и его граница — мои, решение обобщать паттерн — его.
Грабли: soft knee у URP bloom захардкожен на половину порога (thresholdKnee = threshold * 0.5f в BloomPostProcessPass.cs, в профиле не настраивается). При пороге 1.0 это значит, что
светится всё ярче 0.5, а чистый белый LDR-пиксель отдаёт в bloom 12.5% своей яркости — то есть
светлый арт подсвечивается сам, хотя светящимся его никто не назначал. Прежняя формулировка «цвет,
выведенный ровно в 1.0, порог не пробивает» этого не учитывала.
Владелец правды: docs/wiki/tech/10-reference/code-standards.md §9,
Assets/_Project/Scripts/Data/Definitions/AttackRangeBand.cs.