Почему это становится нужно раньше, чем кажется
Почти ни один сервер не стартует с формальным реестром. Обычно всё начинается с пары пропов, одной валюты, квестового пропуска и уверенности, что команда как-нибудь запомнит, какой hidden ID к чему относится. Эта уверенность ломается гораздо раньше, чем библиотека предметов начинает казаться большой.
Каталог нужен не ради красивой бюрократии. Он нужен потому, что память — первое, что плохо масштабируется. Как только одни и те же предметы трогают билдер, сценарист и pack-редактор, нужен один стабильный ряд данных на предмет, а не ещё один потерянный чат.
Минимальная строка, которая должна быть у каждого предмета
| Поле | На какой вопрос отвечает | Почему это важно |
|---|---|---|
| Internal ID | Под каким логическим именем живёт предмет. | Не даёт двум объектам тихо делить одну идентичность. |
| Visible name | Что увидит игрок. | Отделяет атмосферное имя от технического. |
| Base item | Какой ванильный предмет лежит underneath. | Полезно для pack-side проверок и быстрых sanity check. |
| Visual hook | К какой ветке item_model или CMD привязан предмет. | Не даёт визуальной стороне оторваться от логики. |
| Status / owner | Кто сейчас работает с этим предметом. | Снижает случайные пересечения во время правок. |
| Notes | Что у этого предмета особенного. | Удерживает исключения вне исчезающей истории чатов. |
Командный workflow, который не разваливается
- Сначала набросайте предмет в custom item builder или в заметках по дизайну.
- Создайте строку в каталоге до того, как предмет расползётся на команды, арт и скрипты.
- Используйте теги и notes, чтобы отметить: это валюта, проп, квестовый объект, награда или временный мусор для тестов.
- Экспортируйте JSON, CSV или Markdown в тот момент, когда набор предметов должен выйти из одного браузера и стать видимым для команды.
Этот порядок важен. Каталог сильнее всего тогда, когда фиксирует решения рано, а не пытается восстановить их уже после хаотичной релизной недели.
Что на самом деле значат предупреждения о дублях
Предупреждение о duplicate hidden ID означает, что две строки пытаются жить в одном логическом слоте. Это опасно: команды, награды и скрипты могут начать указывать не туда, куда вы думаете.
Duplicate visual hook мягче, но тоже важен. Часто это значит, что два предмета делят один внешний вид — либо специально, либо случайно. И в обоих случаях лучше оставить note, чтобы следующий человек не “исправил” осознанный выбор.
Локальный черновик в браузере всё ещё нормально вписывается в командную работу
Browser-local storage здесь не враг, а черновой стол. Важный момент в другом: экспорт — это граница, на которой личный черновик превращается в командную инфраструктуру. Рабочий процесс вполне может начинаться локально, а потом уходить в каналы планирования, документы и ревью.
Именно поэтому import и export так важны. Каталог может начинаться как личная рабочая поверхность, но не должен навсегда остаться запертым в одном браузере, если предмет стал реальной частью сервера.
Типичные ошибки
- Записывать только красивое имя и надеяться, что техническая сторона потом восстановится сама.
- Держать несколько временных прототипов на одном hidden ID со словами “потом почистим”.
- Не отмечать, совпадает visual hook намеренно или случайно.
- Относиться к каталогу как к музею после релиза, а не как к живому рабочему документу.
- Экспортировать слишком поздно, когда логика предмета уже разошлась по нескольким людям.
FAQ
Каталог нужен только большим серверам?
Нет. Обычно он начинает окупаться очень рано — в тот момент, когда кастомные предметы перестают помещаться в памяти одного человека.
Visible name и internal ID должны совпадать?
Не обязательно. Видимое имя может оставаться атмосферным, а internal ID лучше держать стабильным и читаемым для команды.
Почему не оставить всё в таблице навсегда?
Можно, но отдельный каталог быстрее показывает дубли и лучше стыкуется с остальным item workflow сайта.
Каталог заменяет custom item builder?
Нет. Каталог организует библиотеку, а builder по‑прежнему отвечает за генерацию команд.
Это помогает и при миграции паков?
Да. Когда у каждого предмета записаны base item и visual hook, pack-side миграции становятся намного спокойнее.