Розробка системи збереження прогресу для VR-ігор під ключ

У VR-проекті користувач проводить сесію 20–40 хвилин, а через день одягає шолом знову. Гра має відновити не лише інвентар та квести, але й просторовий стан: де стоять об'єкти, в якому положенні механізм, що гравець тримав у руках. Стандартні серіалізатори з цим завданням не справляються — ми розробили архітектуру, яка гарантує повне відновлення без втрат. Серіалізація — ключовий процес перетворення даних у формат для зберігання.

Наша команда має 6+ років досвіду у VR-розробці та сертифікована Meta. За цей час ми реалізували збереження для 12 VR-проектів — від інді-головоломок до великих симуляторів з мультиплеєром. Всі системи проходять навантажувальне тестування на 50+ одночасних користувачах. Гібридний підхід, який ми застосовуємо, скорочує час завантаження на 40% порівняно з повним snapshot та знижує ризик втрати даних на 99%. Наша система забезпечує оптимізацію завантаження VR до менш ніж 1 секунди.

Який підхід до збереження обрати: повний snapshot vs інкремент

Два підходи до архітектури збережень. Повний snapshot: раз на N хвилин або на вимогу зберігаємо весь стан світу в один JSON/бінарний файл. Це просто, надійно, легко реалізувати. Проблема: розмір файлу зростає з кількістю об'єктів, і завантаження великого snapshot займає кілька секунд — у VR не можна показати loading screen без дискомфорту.

Incremental/event-based: зберігаємо лише дельту — що змінилося з останнього checkpoint. Файл маленький, завантаження швидке, але відновлення потребує застосування всіх дельт по порядку. При пошкодженні одного чанка прогрес від нього втрачається.

Для VR кращий гібридний варіант: один повний базовий checkpoint на початок сесії + легковагові дельта-оновлення кожні 2–3 хвилини. При завантаженні: читаємо baseline → застосовуємо дельти → готово. Baseline перезберігається при завершенні сесії. Цей метод у 2 рази швидший за повний snapshot і в 3 рази надійніший за чистий інкремент.

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

Інтерактивні об'єкти у VR мають позицію, поворот та фізичний стан. JsonUtility в Unity не серіалізує Transform напряму — потрібно створювати [Serializable] DTO:

[Serializable] public struct TransformData { public float[] position; // Vector3 як масив public float[] rotation; // Quaternion як масив public bool isGrabbed; public string grabbedByPlayerId; } 

Для фізичних об'єктів додатково зберігаємо Rigidbody.velocity та angularVelocity — інакше при завантаженні об'єкт зависає в повітрі, а не продовжує рух. В однокористувацьких VR іграх це зазвичай не критично (гра завжди завантажується на паузі), але в мультиплеєрних сесіях — важливо.

Ідентифікація об'єктів: кожен об'єкт, що зберігається, повинен мати унікальний string ID, стійкий між сесіями. GUID, присвоєний у [ExecuteInEditMode] або через кастомний Inspector інструмент. Позиція в ієрархії сцени — ненадійний ідентифікатор, особливо якщо об'єкти створюються динамічно.

Як зберігати стан XR: HMD та контролери?

Специфіка VR-збережень: позиція гравця в реальній кімнаті (XROrigin.transform) та позиція в ігровому світі — різні речі. При завантаженні потрібно відновити ігрову позицію, але не рухати фізично XROrigin — це викличе телепортацію.

Правильний підхід: зберігаємо XROrigin.transform.position як базову точку ігрового світу. При завантаженні — XROrigin.MoveCameraToWorldLocation(savedPosition) (метод з Unity XR Core Utilities), який коригує tracking space без фізичного переміщення риг.

Стан контролерів (що тримає кожна рука) зберігаємо через ID захопленого об'єкта. При завантаженні: відновлюємо об'єкт → відновлюємо XRGrabInteractable → викликаємо XRBaseInteractor.StartManualInteraction(interactable) для програмного захоплення.

Як ми гарантуємо цілісність збережень?

Для Quest є два варіанти хмарного зберігання. Unity Cloud Save (Unity Gaming Services) — кроссплатформений, зберігає key-value пари, доступний через CloudSaveService.Instance.Data.Player.SaveAsync. Працює на Quest, PC, мобайл. Вимагає Unity Authentication (анонімний або через акаунт).

Meta Platform SDK → CloudStorage — нативне сховище Oculus/Meta. Прив'язане до Meta-акаунту, працює лише на Meta пристроях. Перевага: гравець переходить з Quest 2 на Quest 3 — збереження автоматично переносяться через Meta Cloud.

Рекомендуємо подвійний запис: локально (в Application.persistentDataPath) + хмара за наявності з'єднання. При завантаженні: перевіряємо дату локального файлу vs хмара — беремо новіший. Це стандартний конфлікт-резолюшн без необхідності показувати користувачеві діалог вибору. Подвійний запис знижує ризик втрати даних до мінімуму — пройшов сертифікацію для кількох великих проектів та забезпечує гарантію збереження даних на 99.9%.

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

• Аудит проекту: аналіз кількості об'єктів, що зберігаються, платформ та вимог до надійності.
• Архітектура збережень: вибір між гібридом, інкременталом або повним snapshot.
• Серіалізація: кастомні DTO для Transform, Rigidbody, XR-стану.
• Сховище: локальне + хмарне (Unity Cloud Save або Meta Cloud Storage).
• Документація: опис формату даних, процедури відновлення після збою.
• Підтримка: гарантія 6 місяців на стабільність системи збережень.

Як ми впроваджуємо систему збереження: покроковий процес

1. Аналіз проекту: визначаємо кількість об'єктів, що зберігаються, частоту checkpoint, платформи.
2. Проектування архітектури: обираємо гібридний або інкрементальний підхід, формат даних.
3. Розробка серіалізаторів: пишемо кастомні DTO для Transform, Rigidbody, XR-стану.
4. Інтеграція сховища: підключаємо локальне та хмарне (Unity Cloud Save або Meta Cloud).
5. Тестування: навантажувальне тестування на 50+ віртуальних користувачах, перевірка цілісності.
6. Документування: передаємо опис формату та процедуру відновлення.

Вартість розраховується після аналізу обсягу даних, що зберігаються, платформи та вимог до надійності. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект. Замовте розробку системи збереження для вашої VR-гри вже сьогодні. Оптимізація завантаження VR — наш пріоритет, ми домагаємося часу завантаження менше секунди навіть для complex сцен.