Сначала роль предмета, потом красивое имя
Игроки видят атмосферное название. Команде нужен стабильный технический идентификатор. Внутренний ID должен отвечать на скучный, но жизненно важный вопрос: что это за объект внутри проекта, независимо от его лоровой формулировки. Поэтому артефакт может называться relic_sun_seal, даже если игрок видит Печать четвёртых врат.
Самое полезное правило — сознательно разделять видимое имя и системное имя. Заголовок может быть художественным. Hidden ID лучше держать спокойным, точным и пригодным для людей, которых не было в исходном обсуждении дизайна.
Схема именования, которая переживает рост
Рабочая формула — категория + семейство + вариант. Например: currency_bone_token, quest_marshal_writ, relic_storm_core, prop_court_seal. Смысл не в красоте, а в том, чтобы взгляд сразу понимал, на какую полку положить объект.
Когда такая схема уже есть, предупреждения о дублях становятся полезнее. Вы видите не просто две случайные строки, а то, что два предмета лезут в один и тот же слот внутри одного семейства.
Где визуальный хук должен совпадать
Визуальный хук не обязан повторять весь внутренний ID, но он должен быть узнаваемым. Если предмет называется relic_storm_core, то item_model или CMD-заметка не должны прятаться за чужим шорткатом. Достаточно частичного эха: storm_core, relic/storm_core, ritual/storm_core.
Особенно это важно на стадии паков. Когда каталог говорит одно, а путь к модели другое, команда тратит время только на то, чтобы доказать, что это вообще один и тот же объект.
Минимальные поля для именования
| Поле | На какой вопрос отвечает | Хороший признак |
|---|---|---|
| Internal ID | Что это за объект на языке системы? | Стабилен и легко ищется. |
| Visible name | Что видит игрок? | Читаемый и атмосферный. |
| Visual hook | Какая модель или иконка к нему привязана? | Связь можно быстро проследить. |
| Notes | Что делает его особенным? | Хватает, чтобы не гадать потом. |
Вам не нужна огромная бюрократия. Нужно ровно столько полей, чтобы предмет переживал передачу между людьми.
Частые ошибки
- Называть предмет только по внешнему виду, так что после редизайна ID теряет смысл.
- Использовать сокращения, понятные одному человеку.
- Оставлять один hidden ID на несколько прототипов, потому что различие кажется временным.
- Менять стиль именования посреди контентной линии и не помечать старое семейство.
Все эти ошибки кажутся мелкими в первый день и дорогими на двадцатый.
FAQ
Нужно ли, чтобы видимое имя и ID совпадали?
Иногда это удобно, но не обязательно. Совпадение — плюс, а не правило.
Когда структуры уже слишком много?
Если ID всё ещё читается одним взглядом, скорее всего всё нормально. Если строка превращается в абзац, её пора сократить.
Может ли семейство делить один visual hook?
Да, если это осознанное решение. Каталог должен показывать общие хуки явно, а не случайно.