Чому архівація вихідників — це інвестиція, а не витрата
Ми регулярно стикаємося з ситуацією: студія закрила проект, а через пару років потрібно випустити DLC або портувати на нову платформу. Відкривають NAS — і бачать хаос: папка art_final_FINAL_v2, 12 000 файлів без дат, Substance Painter свариться на зниклі linked textures, Photoshop-файл важить 2 ГБ, половина шарів без імен. Відновити роботу можна, але це займає тижні замість годин. Наш досвід показує: правильно організована архівація на старті окупається як мінімум вдвічі швидше. Ми зберігаємо не лише файли, а й контекст: версії софту, налаштування, залежності. Це перетворює архів на робочий зліпок проекту, а не звалище бінарників. Ми стикалися з проектами, де арт-директор звільнявся і ніхто не знав, як збирати сцену.
«Хороший архів дозволяє відкрити проект через 5 років без жодного дзвінка колишньому співробітнику» — принцип інженерної збереженості.
Що загрожує за відсутності архівації
- Втрата зв'язків між вихідниками та фінальними ассетами. Наприклад, текстура в грі виглядає інакше, ніж у
.spp— згадати, який матеріал використовувався, неможливо. - Час на пошук файлів зростає до 30% від загального часу роботи. За нашими вимірами, структурований архів економить до 40% часу при поверненні до проекту.
- Критичні файли можуть не відкритися в нових версіях софту. Особливо це стосується бінарних форматів на зразок
.mb.
Яку інформацію обов'язково зберігати
Substance Painter (.spp)
Найпроблемніший формат. Файл посилається на Smart Materials з бібліотеки Substance. Якщо бібліотека оновилася — зовнішній вигляд зміниться. Ми архівуємо: .spp + експортовані Baked Textures + .sbsar всіх використаних матеріалів. Це гарантує відтворюваність через будь-які оновлення.
Photoshop (.psd)
Смарт-об'єкти можуть посилатися на зовнішні .psb. Функції Package немає, тому ми вручну збираємо linked шари в одну папку або flatten. Обов'язково перевіряємо шрифти — прикладаємо OTF/TTF.
Blender (.blend)
Достатньо включити File > External Data > Pack Resources — вся картинка пакується всередину .blend. Просто, але файл стає важчим. Для довгострокового зберігання це виправдано.
Maya (.ma/.mb)
Використовуємо File > Optimize Scene Size, потім File > Archive Scene — створюється zip з усіма залежностями. Надаємо перевагу .ma (ASCII) — його можна відкрити текстовим редактором навіть без 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 — фактичний стандарт, але він пропрієтарний. Як доповнення використовуємо glTF 2.0 — відкритий формат, який підтримується Blender, Unity, Unreal. glTF 2.0 легший за FBX в 1.5-2 рази і краще підходить для обміну даними між пайплайнами.
Як перевірити цілісність архіву перед упаковкою?
Перед упаковкою виконуємо три кроки:
- Перевірка broken references у Substance:
File > Check Baked Maps Links. - Чистка невикористовуваних шарів у PSD.
- Експорт усіх текстур з
.spp.
Кастомний Python-скрипт обходить дерево папок, збирає CSV з розміром, датою, розширенням. Це знаходить дублі (одна текстура в трьох копіях), застарілі версії (_old, _backup) та файли-кандидати на оптимізацію. За статистикою наших проектів, до 20% файлів виявляються сміттям. За нашими підрахунками, правильна архівація економить до $5000 на кожному проекті середнього масштабу.
Кроки архівації
- Інвентаризація — збір всіх вихідників, виявлення пропущених ланок.
- Структурування — організація файлів за шаблоном:
project_name/characters/hero/sources/тощо. - Пакування — упаковка залежностей і конвертація в довгострокові формати (FBX/glTF, PNG, .ma).
- Верифікація — перевірка цілісності посилань, читання файлів у свіжих версіях софту.
- Звіт — створення CSV-інвентаризації та README.
Що входить у роботу з архівації (deliverables)
- Структурований архів за описаною схемою.
- CSV-інвентаризація з дублями та рекомендаціями.
- README з версіями інструментів та контактами.
- Запасний комплект на зовнішньому носії — гарантія від втрати.
- Консультація з вибору форматів та налаштувань проекту. Ми враховуємо особливості рендерингу, шейдерів та нормал мап, щоб архів був повноцінним.
Терміни та як ми працюємо
| Обсяг роботи | Термін |
|---|---|
| Аудит та інвентаризація існуючого архіву | 2–5 днів |
| Структурування та архівація проекту середнього масштабу | 1–2 тижні |
| Повна архівація великого проекту (50+ ассетів, 5+ художників) | 3–6 тижнів |
Вартість розраховується після первинного аудиту обсягу — це безкоштовно. Наша команда має 10+ років досвіду в геймдеві та більше 50 завершених проектів з архівації. Оцінимо ваш проект, надішлемо план і терміни. Зв'яжіться з нами, щоб не втратити роки роботи. Замовте консультацію з архівації — ми підкажемо, з чого почати.
Поширені питання про архівування графіки
На основі нашого досвіду ми зібрали відповіді на часті запитання — вони допоможуть уникнути типових помилок.