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

Ми часто бачимо: коли в проєкті три художники одночасно редагують один 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%, повне зникнення конфліктів при паралельній роботі. Гарантуємо якість на кожному етапі.

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

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

VR та AR розробка

Коли ми вперше запускаємо проєкт у VR-гарнітурі, більшість команд стикається з одним і тим же: технічно все працює, але в гарнітурі або заколисує, або руки «плавають» із затримкою, або сцена виглядає сіпаною на периферії погляду. Це не баги у звичному розумінні — це наслідок того, що VR/AR розробка вимагає іншого підходу до архітектури рендеру, взаємодії та UX з самого початку проєкту. Наш досвід — понад 7 років у геймдеві, 15+ завершених VR/AR-проєктів для Meta Quest, SteamVR, PSVR2, HoloLens.

Платформи та SDK

Працюємо з усім актуальним стеком. OpenXR використовуємо як базовий шар скрізь, де це можливо — він дає кроссплатформеність між Meta, Valve Index, HP Reverb та іншими PC VR-пристроями. Поверх OpenXR будуємо на XR Interaction Toolkit (Unity) або VR Expansion Plugin (Unreal).

Як мінімізувати заколисування при локомоції у VR?

Locomotion — головне джерело motion sickness для недосвідчених VR-користувачів. Згідно з дослідженнями, близько 70% користувачів відчувають дискомфорт при неправильному налаштуванні руху (Oculus Developer Guidelines). Teleportation — стандартний спосіб навігації, коли плавне переміщення небажане.

Компоненти з XR Interaction Toolkit: TeleportationArea, TeleportationAnchor, TeleportationProvider. Базова реалізація працює «з коробки», але для продакшну доопрацьовуємо її в чотири кроки:

1. Налаштування XRRayInteractor з вигнутим променем (Bend Ray) — дуга телепортації виглядає натуральніше прямого променя, краще зчитується користувачами.
2. Додавання валідної зони приземлення — візуальний індикатор змінює колір при наведенні на перешкоду (червоний/зелений).
3. Впровадження fade transition — плавне згасання екрану (black fade) перед телепортом знижує дезорієнтацію.
4. Rotation snapping — після телепорту пропонуємо snap-поворот на 45° або 90° замість плавного, що знижує ризик заколисування.

Для проєктів, де потрібна плавна локомоція (екшн-ігри, симулятори), використовуємо comfort settings: віньєтування при русі, зниження FOV під час прискорення. Налаштування доступні користувачеві в меню — різні люди мають різний поріг чутливості.

Як зробити захоплення об'єктів у VR фізично реалістичним?

Це найнедооціненіша частина VR-розробки. Клієнти часто сприймають її як «просто анімація рук», але на практиці — складна система, де фізична коректність, відгукливість та комфорт вступають у суперечність.

Grab (захоплення)

XR Interaction Toolkit надає три типи Interactable для захоплення:

• XRGrabInteractable — стандартне захоплення, об'єкт слідує за контролером через фізичний joint або direct position/rotation
• XRSimpleInteractable — для об'єктів без фізичного переміщення (кнопки, важелі)
• Кастомні Interactable через наслідування від XRBaseInteractable

Attach Transform — часто ігнорована деталь. У кожного Interactable має бути правильно налаштований Attach Transform (точка, до якої рука «прилипає»). Без нього рукоятка пістолета опиниться по центру меша, а не там, де її тримають.

Для зброї та інструментів з дворучним захопленням — окрема система TwoHandGrab: ведуча рука визначає позицію, друга — орієнтацію. XR Interaction Toolkit підтримує це через XRTwoHandGrabInteractable або кастомну логіку з двома Attach Points.

Throw (кидок)

Чому velocity smoothing критичний для реалістичного кидка? Проблема в тому, що Rigidbody.velocity в момент відпускання контролера відображає миттєву швидкість, яка часто некоректна через дискретизацію трекінгу. Користувач робить швидкий рух зап'ястям — а об'єкт летить вдвічі повільніше.

Рішення: velocity smoothing за останні N кадрів (типово 5-10 кадрів, ~80-160 мс при 60 Гц) перед відпусканням. XR Interaction Toolkit робить це через VelocityEstimator. Додатково застосовуємо velocity scaling multiplier — невелике множення швидкості (1.2-1.5x) робить кидки суб'єктивно більш задовільними. Кутову швидкість (для об'єктів, які мають крутитися в польоті) також усереднюємо аналогічним чином.

AR: Plane Tracking та робота з оточенням

AR додає інший клас проблем — роботу з реальним, непередбачуваним оточенням. AR Foundation — кроссплатформенний шар поверх ARKit та ARCore. Більшість базових функцій (plane detection, raycasting, image tracking, face tracking) доступні через єдиний API.

Plane Detection

ARPlaneManager виявляє горизонтальні та вертикальні площини. Практичні нюанси:

• Ініціалізація займає час — користувач повинен оглянути приміщення, поки система будує карту. Потрібен явний onboarding з інструкцією «повільно водіть камерою по поверхнях».
• Площини нестабільні — їх межі та позиція оновлюються в міру накопичення даних. Об'єкти, розміщені на площині, потрібно прив'язувати через parenting до ARPlane, а не до світових координат.
• Злиття площин — два виявлені сегменти підлоги можуть злитися в один, що рухає якір. Для критичних якорів використовуємо ARAnchor замість прямої прив'язки до площини.

Оптимізація для VR: фреймрейт та комфорт

VR вимагає стабільного високого фреймрейту. Близько 60% часу розробки в мобільному VR йде на оптимізацію, а не на функціонал — ретрофіт у два рази дорожче правильної архітектури з першого спринту.

Single Pass Instanced Rendering

Головна оптимізація рендеру у VR. Без неї сцена рендериться двічі (для кожного ока), що подвоює draw calls. Single Pass Instanced рендерить обидва ока за один прохід через instancing: geometry обробляється один раз, шейдер отримує два view/projection matrix через GPU instancing. Вмикається в Unity через XR Plug-in Management > Rendering Mode: Single Pass Instanced. Важно: кастомні шейдери повинні підтримувати SPI — стандартні URP/HDRP шейдери підтримують, кастомні HLSL вимагають правки (UNITY_SETUP_STEREO_EYE_INDEX_POST_VERTEX та пов'язані макроси). Застосування цієї техніки скорочує кількість draw calls на 40-50%.

Foveated Rendering

На Meta Quest доступний Fixed Foveated Rendering (FFR) — зниження роздільної здатності на периферії кадру, де гострота сприйняття нижча. Налаштовується через OVRManager або Meta XR SDK:

OVRManager.fixedFoveatedRenderingLevel = OVRManager.FixedFoveatedRenderingLevel.High;
OVRManager.useDynamicFixedFoveatedRendering = true;

Dynamic FFR автоматично підвищує рівень при просадці фреймрейту — зручніше фіксованого в сценах зі змінним навантаженням.

IPD та Comfort Settings

IPD (Inter-Pupillary Distance) — відстань між зіницями, впливає на сприйняття глибини. На програмованому рівні в більшості пристроїв доступне лише читання IPD (OVRPlugin.GetSystemDisplayFrequency), фізичне налаштування — на гарнітурі. Для додатків з точним позиціонуванням (медичні симулятори, тренінги) враховуємо IPD у розрахунках масштабу сцени.

Haptics

Тактильний фідбек — недооцінений інструмент. Навіть простий вібраційний відгук при захопленні об'єкта або попаданні значно підвищує відчуття присутності. В середньому інтеграція тактильних патернів займає 30–80 годин на проєкт.

XR Haptics через OpenXR:

var hapticImpulse = new UnityEngine.XR.HapticCapabilities();
InputDevice device = InputDevices.GetDeviceAtXRNode(XRNode.RightHand);
device.SendHapticImpulse(0, amplitude: 0.5f, duration: 0.1f);

Для складних патернів (тактильна «текстура» поверхні при дотику, наростаюча вібрація при натягу тятиви лука) використовуємо Meta Haptics Studio — дозволяє дизайнити haptic-кліпи візуально.

Що входить у розробку VR/AR-додатку

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

• Архітектурний документ з описом стеку, логіки рендеру та системи взаємодії
• Робочий прототип (MVP) для тестування на цільовому пристрої
• Інтеграцію необхідних SDK (Meta XR, OpenXR, AR Foundation та ін.)
• Оптимізацію під цільові частоти 72/90/120 Гц з профілюванням draw calls та FPS
• Тестування на фізичному обладнанні (Quest, SteamVR, HoloLens) із залученням користувачів
• Повну документацію по збірці, деплою та підтримці
• Навчання команди замовника (воркшоп по роботі з XR Toolkit)
• Гарантійну підтримку протягом 1 місяця після здачі

Що впливає на вартість та терміни

VR/AR проєкти дорожчі за звичайні ігри аналогічного обсягу. Ітерації повільніші — кожну правку потрібно тестувати в гарнітурі, емулятор не передає реальний досвід. Motion sickness змушує переробляти частину концептуальних рішень після першого плейтесту. Оптимізація займає суттєву частку часу — для мобільного VR (Quest) до 60-70% циклу. Для проєктів під Quest починаємо оптимізацію з першого спринту.

Отримайте консультацію по вашому проєкту — оцінимо задачу, стек та терміни. Замовте розробку VR/AR-додатку під ключ з гарантією стабільного фреймрейту.