Розробка системи керування версіями для графічних асетів у геймдеві

Ми часто бачимо: коли в проєкті три художники одночасно редагують один 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 не вирішує проблему блокувань: якщо художник A і художник B одночасно відкрили один FBX — один із них втратить зміни при спробі commit. Git LFS File Locking додає механізм ексклюзивних блокувань, але він не інтегрований в DCC-інструменти (Maya, Blender, Substance Painter). Артист повинен пам'ятати про lock через CLI — на практиці це не працює.

Як Git LFS справляється з блокуваннями?

Насправді, Git LFS не надає автоматичних блокувань. Команда git lfs lock вимагає від художника вручну викликати її перед редагуванням. Якщо забути — конфлікт неминучий. Додавання зовнішніх рішень на кшталт Anchorpoint частково вирішує проблему, але без інтеграції в DCC це тимчасовий костиль. В результаті при паралельній роботі над одним асетом конфлікти виникають у 30–40% випадків.

Perforce Helix Core для графіки

Perforce — стандарт де-факто в AAA-розробці. Його preemptive locking (checkout before edit) ідеально підходить для бінарників. Художник бере файл на редагування, система блокує його для інших. Це не заважає потоку роботи — навпаки, всі знають, хто що редагує прямо зараз.

Інтеграція з DCC: Perforce plugin для Maya, Houdini, Substance Painter. Для Unity — вбудована підтримка Version Control в останніх версіях. Для проєктів на 3–15 художників Perforce Helix Core можна розгорнути самостійно на Linux-сервері (безкоштовна ліцензія до 5 користувачів і 20 workspace'ів) або використовувати Helix TeamHub.

Недолік: Perforce — це не Git. Розробники, звиклі до git workflow, адаптуються близько тижня. Але втрата роботи артиста через merge conflict коштує дорожче.

Чому Perforce краще Git для асетів?

Порівняння за ключовими параметрами:

Perforce ефективніший за Git LFS у 3 рази за часом блокування та повністю виключає конфлікти при паралельній роботі над одним файлом.

Git LFS + DVC для змішаних команд

Якщо команда не готова до Perforce, робоча альтернатива — Git LFS для асетів + DVC (Data Version Control) для великих датасетів. DVC зберігає асети в S3/GCS/Azure Blob/локальному NAS, а в Git — лише .dvc-файли-вказівники. dvc pull завантажує потрібні версії. Це дає можливість працювати з асетами як з кодом (гілки, теги, історія) без роздування репозиторію.

Структура системи для ігрового проєкту

Типова архітектура для Unity/Unreal проєкту з командою 5–20 осіб:

• Source repository (код): Git + GitHub/GitLab. Все, крім бінарників. .gitignore агресивно виключає PSD, FBX, WAV, PNG вище 1 МБ.
• 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 експорт через Mayapy (конвертація 100+ асетів на годину), PSD → compressed PNG через ImageMagick (стиснення до 80% без втрат), аудіо → 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, навчання команди). Через два місяці — «чому ми не зробили це раніше» — зникла проблема авторства і з'явилася повна історія змін кожного асета. Економія часу артистів склала 30%.

Як впровадити систему: покроковий план

1. Аудит поточної інфраструктури. Оцінюємо об'єм асетів (від 50 ГБ до 2 ТБ), розмір команди, використовувані інструменти.
2. Вибір рішення. Git LFS для малих проєктів (до 5 артистів), Perforce для середніх і великих.
3. Налаштування сервера. Встановлення та налаштування сховища, користувачів (1–2 дні).
4. Інтеграція з DCC. Плагіни для Maya, Blender, Substance Painter (2–4 дні).
5. Налаштування pipeline. Скрипти автоконвертації та CI hooks (3–5 днів).
6. Навчання команди. Проведення тренінгів, написання документації (1–2 дні).
7. Запуск і підтримка. Перші дні — моніторинг, коригування правил (2 дні).

Отримайте консультацію інженера та точний план впровадження за один день.

Що входить в роботу

Наша команда надає:

• Аудит поточної інфраструктури та рекомендації.
• Розгортання сервера Perforce або налаштування Git LFS + DVC.
• Інтеграцію з DCC-інструментами (Maya, Blender, Houdini, Substance Painter).
• Розробку asset pipeline з автоконвертацією.
• Написання документації з іменування та workflow.
• Навчання команди та супровід протягом двох тижнів.

Строки впровадження

Метрики нашої роботи

Наш досвід: 6 років у геймдеві, понад 20 впроваджень систем контролю версій для асетів. Ми сертифіковані партнери Perforce. Середня економія часу артистів після впровадження — 30%, повне зникнення конфліктів при паралельній роботі. Гарантуємо якість на кожному етапі.

Ви можете впровадити систему керування версіями асетів. Оцінимо ваш проєкт за один день. Зв'яжіться з нами для консультації.

Замовте оцінку проєкту — отримайте детальний план впровадження.