Архивация исходников графики и проектных файлов игр
Игровая студия закрыла проект три года назад. Теперь нужно вернуться: сделать DLC, портировать на новую платформу или просто ответить на вопрос «почему у персонажа такая топология на ногах?». Открывают NAS — папка art_final_FINAL_v2_use_this_one с 12 000 файлами без дат и без связи между исходниками и тем, что попало в игру. Substance Painter открывает .spp файл и сообщает, что не найдены linked textures. Photoshop-файл весит 2 ГБ, половина слоёв без имён.
Это стандартная ситуация для студий, которые не занимались архивацией в процессе производства.
Что нужно сохранять и в каком виде
Архив графики — не просто «положить всё в ZIP». Это структурированное хранилище с воспроизводимым состоянием: открыл файл через два года — получил тот же результат.
Исходники Substance Painter (.spp). Самая проблемная категория: файл ссылается на базовые материалы из Smart Materials библиотеки Substance. Если библиотека обновилась — старые материалы могут выглядеть иначе. Правильная архивация: .spp + экспортированная папка с Baked Textures + .sbsar файлы использованных материалов из библиотеки.
Photoshop (.psd). Встроенные смарт-объекты могут ссылаться на внешние .psb файлы. При архивации: File > Package не существует в PS — нужно вручную flatten linked или собрать в папку рядом. Fonts: если использован нестандартный шрифт, его нужно включить в архив или указать точное название + версию.
Blender (.blend). File > External Data > Pack Resources запаковывает все внешние текстуры внутрь файла — архивировать один .blend достаточно. Но весит он тогда существенно больше.
Maya (.ma/.mb). File > Optimize Scene Size + File > Archive Scene — создаёт zip со всеми зависимостями. .ma (ASCII) предпочтительнее .mb (binary) для долгосрочного хранения — читается текстовым редактором даже без Maya.
Структура архива
Плохой архив: art/, внутри 5000 файлов по алфавиту.
Рабочий архив:
project_name/
characters/
hero/
sources/ # .psd, .spp, .blend
exports/ # .fbx, .png, .tga — то что шло в движок
references/ # референсы, концепты
VERSIONS.md # краткая история изменений: дата, автор, что изменилось
environments/
ui/
vfx/
README.md # версия движка, версии инструментов, контакты авторов
VERSIONS.md на уровне каждого ассета — звучит как излишество, но это единственный способ понять через год «почему текстура персонажа переделывалась три раза».
Технические требования к форматам для долгосрочного хранения
Закрытые форматы с привязкой к ПО — риск. Предпочтительные форматы:
| Тип данных | Предпочтительный формат | Избегать |
|---|---|---|
| Текстуры (финал) | PNG, TIFF 16-bit | PSD без flatten |
| 3D-меши | FBX 2019, OBJ | .mb (binary Maya) |
| Видео-исходники | ProRes 4444, TIFF sequence | Premiere .prproj без медиа |
| Шрифты | OTF/TTF | Лицензионные без файла |
| Звук | WAV 24-bit/48kHz | .mp3 (lossy) |
FBX — не идеальный формат (проприетарный Autodesk), но де-факто стандарт. glTF 2.0 как дополнение для mesh-данных — открытый стандарт, поддерживается Blender, Unity, Unreal.
Инструментарий для аудита перед архивацией
Перед архивированием: проверка broken references (Substance: File > Check Baked Maps Links), очистка неиспользуемых слоёв в PSD, проверка что все текстуры в .spp запечены и экспортированы.
Кастомный Python-скрипт для инвентаризации: обходит дерево папок, собирает список файлов с размером, датой, расширением → CSV. Это позволяет найти дубли (одна текстура в трёх местах с разными именами), устаревшие версии (файл _old, _backup), слишком большие файлы-кандидаты на оптимизацию.
Сроки
| Объём работы | Срок |
|---|---|
| Аудит и инвентаризация существующего архива | 2–5 дней |
| Структурирование и архивация проекта среднего масштаба | 1–2 недели |
| Полная архивация крупного проекта (50+ ассетов, 5+ художников) | 3–6 недель |
Стоимость рассчитывается после первичного аудита объёма и состояния материалов.