Розробка системи управління версіями для ассетів графіки
Коли в проекті три художники одночасно редагують один FBX-файл персонажа, а система контролю версій — це папка assets_FINAL_v2_NEW_fixed, проблема не в дисципліні команди. Проблема в відсутності інфраструктури. Бінарні файли — меші, текстури, аудіо — це не код: їх не можна змішати через diff, та звичайний Git без розширень справляється з ними погано.
Чому стандартний Git не підходить для графічних ассетів
Git зберігає кожну версію файлу цілком. Текстура 4K у форматі PSD важить 80–120 МБ. Після 50 ітерацій один файл займає 4–6 ГБ в історії репозиторію. Клонування проекту через рік займає годину. git checkout на гілку художника — 20 хвилин.
Git LFS (Large File Storage) розв'язує проблему зберігання: бінарники зберігаються на окремому сервері, в репозиторії тільки покажчики. Але Git LFS не розв'язує проблему lock'ів: якщо художник A та художник B одночасно відкрили один FBX — один з них втратить зміни при спробі commit. Git LFS File Locking (через git lfs lock) додає механізм еклюзивних блокувань, але він не інтегрований в DCC-інструменти (Maya, Blender, Substance Painter) — художник повинен пам'ятати про lock через CLI, що на практиці не працює.
Саме тому для графічних ассетів у крупних проектах використовують спеціалізовані рішення.
Perforce Helix Core для графіки
Perforce — стандарт де-факто у AAA-розробці. Його preemptive locking (checkout before edit) ідеально підходить для бінарників: художник «бере» файл на редагування, система блокує його для інших. Це не заважає потоку роботи — навпаки, всі знають, хто що редагує саме зараз.
Інтеграція з DCC: Perforce plugin для Maya, плагін для Houdini, P4V (візуальний клієнт) працює з будь-яким приложением через filesystem. Substance Painter підтримує Perforce через P4 plugin. Для Unity — P4Unity або вбудована підтримка Version Control у Unity Editor (з'явилась у Unity 2021.2+).
Для проектів на 3–15 художників Perforce Helix Core можна розгорнути самостійно на Linux-сервері (безплатна ліцензія до 5 користувачів та 20 workspace'ів) або використовувати Helix TeamHub (хмарний варіант).
Обмеження: Perforce — це не Git. Розробники, звикші до git workflow, адаптуються близько тижня. Та це хороше вкладення: втрата роботи художника через merge conflict у бінарнику коштує дорожче.
Git LFS + DVC для змішаних команд
Якщо команда не готова до повного переходу на Perforce, робоча альтернатива — Git LFS для ассетів + DVC (Data Version Control) для великих датасетів та наборів ассетів.
DVC зберігає ассети у S3/GCS/Azure Blob/локальному NAS, а в Git-репозиторії зберігаються тільки .dvc-файли-покажчики. dvc pull скачує потрібні версії ассетів. Це дає можливість працювати з ассетами як з кодом (гілки, теги, історія) без раздування Git-репозиторію.
Для управління lock'ами поверх Git LFS — Anchorpoint (десктопний клієнт з visual locking), або кастомний сервер блокувань через Git LFS Locking API.
Структура системи для ігрового проекту
Типова архітектура для Unity/Unreal проекту з командою 5–20 чоловік:
Source repository (код): Git + GitHub/GitLab. Все, крім бінарників. .gitignore агресивно виключає PSDs, FBXs, WAVs, великі PNGs.
Asset repository: Perforce або Git LFS + DVC. Структура: assets/characters/, assets/environments/, assets/audio/, assets/vfx/. Версіонуються і вихідники (PSD, FBX, MA), та фінальні експорти (PNG, glTF, OGG).
Asset pipeline: скрипти автоматичної конвертації та оптимізації при commit. Maya → FBX export через Mayapy, PSD → compressed PNG через ImageMagick, аудіо → platform-specific формати. Запускається через CI hook.
Naming convention: суворий, задокументований. CH_Goblin_Body_Diffuse_D.png (CH = character, Body = mesh part, Diffuse = map type, D = diffuse). Без цього через пів року ніхто не знає, що означає texture_v3_USE_THIS_ONE.png.
На одному проекті перехід з «папки на мережевому диску» на Perforce зайняв два тижня (встановлення, конвертація історії з NAS в Perforce depot, навчання команди). Перший місяць — запитання та непривичка. Через два місяці — «чому ми не зробили це раніше», тому що зникла проблема «хто останній зберіг файл» та з'явилась повна історія змін кожного ассета з авторством.
Терміни впровадження
| Масштаб | Ориентировочні терміни |
|---|---|
| Git LFS настройка для існуючого проекту | 3–5 днів |
| Git LFS + DVC + pipeline для команди 5–10 чел. | 1–2 тижня |
| Perforce Helix Core + DCC інтеграції | 2–3 тижня |
| Повна asset pipeline з CI автоконвертацією | 3–5 тижнів |
Вартість розраховується після аналізу поточної інфраструктури та розміру команди.