Архівування файлів графіки та проектних файлів ігор
Ігрова студія закрила проект три роки тому. Тепер потрібно повернутися: розробити DLC, портувати на нову платформу або просто відповісти на питання «чому у персонажа така топологія на ногах?». Відкривають NAS — папка art_final_FINAL_v2_use_this_one з 12 000 файлів без дат та без зв'язку між вихідниками та тим, що потрапило до гри. Substance Painter відкриває файл .spp і повідомляє, що не знайдені пов'язані текстури. PDF-файл важить 2 ГБ, половина шарів без імен.
Це стандартна ситуація для студій, які не займалися архіванням під час виробництва.
Що потрібно зберігати та в якому вигляді
Архів графіки — це не просто «покласти все у ZIP». Це структуроване сховище зі відтворюваним станом: відкрив файл через два роки — отримав той же результат.
Вихідники Substance Painter (.spp). Найпроблемніша категорія: файл посилається на базові матеріали з бібліотеки Smart Materials компанії Substance. Якщо бібліотека оновиться — старі матеріали можуть виглядати інакше. Правильне архівування: .spp + експортована папка з Baked Textures + файли .sbsar використаних матеріалів з бібліотеки.
Photoshop (.psd). Вбудовані смарт-об'єкти можуть посилатися на зовнішні файли .psb. При архіванні: File > Package не існує в PS — потрібно вручну об'єднати пов'язані шари або зібрати у папку поруч. Шрифти: якщо використовується нестандартний шрифт, його потрібно включити до архіву або вказати точну назву + версію.
Blender (.blend). File > External Data > Pack Resources упаковує всі зовнішні текстури всередину файлу — архівування одного .blend достатньо. Але він тоді буде значно більш важким.
Maya (.ma/.mb). File > Optimize Scene Size + File > Archive Scene — створює zip зі всіма залежностями. .ma (ASCII) кращий за .mb (двійковий) для довгострокового зберігання — читається текстовим редактором навіть без 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 без об'єднання |
| 3D-меші | FBX 2019, OBJ | .mb (двійкова Maya) |
| Відеовихідники | ProRes 4444, TIFF sequence | Premiere .prproj без медіа |
| Шрифти | OTF/TTF | Ліцензійні без файлу |
| Звук | WAV 24-bit/48kHz | .mp3 (lossy) |
FBX — не ідеальний формат (власне Autodesk), але де-факто стандарт. glTF 2.0 як доповнення для mesh-даних — відкритий стандарт, підтримується Blender, Unity, Unreal.
Інструментарій для аудиту перед архіванням
Перед архіванням: перевірка порушених посилань (Substance: File > Check Baked Maps Links), очищення невикористаних шарів у PSD, перевірка що всі текстури в .spp запечені та експортовані.
Кастомний Python-скрипт для інвентаризації: проходить дерево папок, збирає список файлів з розміром, датою, розширенням → CSV. Це дозволяє знайти дублікати (одна текстура в трьох місцях з різними іменами), застарілі версії (файл _old, _backup), надто великі файли-кандидати на оптимізацію.
Терміни
| Обсяг роботи | Термін |
|---|---|
| Аудит та інвентаризація існуючого архіву | 2–5 днів |
| Структурування та архівування проекту середнього масштабу | 1–2 тижня |
| Повне архівування великого проекту (50+ ассетів, 5+ художників) | 3–6 тижнів |
Вартість розраховується після первинного аудиту обсягу та стану матеріалів.