Мобільний VR-гра на Unreal Engine: підводні камені

останнім часом технологія віртуальної реальності стає все більш популярною. А разом з популяризацією VR, більше розробників починають робити VR-ігри. При цьому ті граблі, на які можна наступити при розробці своєї VR-ігри, часто відрізняються від граблів у звичайній мобільного розробці. Під катом ви знайдете докладна розповідь про ті підводні камені, з якими може зіткнутися розробник мобільного VR-ігри на Unreal Engine 4. Стаття написана на прикладі мобільної гри 2048 VR, яку ми зробили і запустили для тестування VR-розробки зі слухачем програми "Менеджмент ігрових інтернет-проектів" і разом з компанією FurecoVR.



Перш ніж почати будь-яку мобільний розробку, необхідно визначитися з базовими речами. Зокрема, скласти концепт, віжн та іншу геймдизайнерскую документацію на ваш проект. Не буду зараз загострювати увагу на цій темі — детальніше читайте в іншій статті на хабре від викладача курсу «Проектної документації» програми «Менеджмент ігрових інтернет-проектів».

Почнемо з цілепокладання і вибору інструментів розробки
Якщо говорити про нашу гру 2048 VR зовсім коротко, то метою ми собі поставили виключно тестування процесу розробки і запуску VR-ігри. У зв'язку з цим необхідно було вибрати просту і швидку в розробці механіку, яка однак була б цікава нам самим, а також мала потенціал сподобатися аудиторії і набрати базу користувачів без маркетингових вкладень. Хоча в цю гру ми не вбудовуємо монетизацію, але для наших майбутніх VR-проектів буде корисно мати базу користувачів своєї VR-ігри. Адже, як відомо, маркетинг VR-ігор на мобільних пристроях зараз є окремою піснею і крім як переводити гравців з однієї VR-ігри в іншу, немає можливості пустити цілеспрямований трафік на людей-власників VR-очок.
Отже, виходячи з цих цілей, було прийнято рішення перенести відому і просту механіку на VR. Відому, щоб з допомогою органіки набрати базу инсталлов. Просту, щоб розробка була швидкою. Нашим рішенням в даному випадку став клон відомої мобільної гри 2048, але перенесеної VR формат з використанням 3D графіки. Управління ігровим полем відрізняється від оригінальної гри тим, що цифри на полі зміщуються не свайпом пальцем, а рухами голови вліво/вправо, вгору/вниз. Мабуть, надихнуло в тому числі те, що у знайомого в одному з клонів 2048 (не VR звичайно) без маркетингових вливань понад 1,5 млн. инсталлов з світу набралося і навіть непогано монетизировалось.
Отже, проста і потенційно популярна механіка обрана. Концепт і віжн ми написали. Настав час розробки.



Кілька слів про вибір движка. Чому саме Unreal Engine 4 (далі UE)?
  1. Підтримка VR. UE одним з перших заявив про офіційну підтримку VR. Про те, що насправді це нам не допомогло, розповімо далі.
  2. Набір безкоштовних ассетов. Ассеты — це набір стандартних моделей з налаштованими матеріалами, які йдуть в комплекті з движком. Оскільки у нас не було бюджету на створення унікального оточення, так і для наших цілей в цьому не було необхідності, наявність якісних стандартних ассетов дозволило нам сильно заощадити час і гроші.
  3. Хороший рендер «з коробки». У UE є якісний рендер, який без особливих танців з бубном видає гідну картинку, при наявності добре налагоджених матеріалів на моделях. А оскільки ми використовували ассеты, надані самим UE, ми легко отримали пристойну картинку.
  4. Ціна питання. У нас була можливість зробити все на Unity або на UE, і ми просто дали завдання на оцінку обом фахівцям. Оцінка розробки на Unity виявилася в 3 рази вище, і не маючи на той момент якихось сумнівів щодо UE, вирішили не переплачувати. Уточню, що за ціною саме в нашій команді на той момент робота доступного спеціаліста на Unity була дорожче аналогічної за обсягами роботи спеціаліста на UE.




Трохи про core-механіки
Ми перебрали кілька ідей, як саме буде здійснюватися управління ігровим полем. Спочатку хотіли використовувати бічну кнопку на шоломі, щоб підтверджувати дію зміщення поля, але швидко зрозуміли, що це занадто утомливо і для руки і в цілому. Потім хотіли використовувати Bluetooth-пульт, але теж швидко відмовилися, оскільки пристрій хоч і зручне, але вкрай погано поширене, а значить у нас не буде аудиторії.
Так ми прийшли до самого простого і очевидного вирішення — відстежувати рухи голови. Хоча відстежувати жести — це голосно сказано. Насправді, ми відстежуємо повороти ігровий камери. Коли центр екрану виходить за межі визначеної «безпечної» зони на ігровому полі, то ми вважаємо, що гравець має намір зробити жест, і залежно від того, в якому місці центр екрану перетнув межу безпечної зони, вирішуємо, в якому напрямку гравець хоче зрушити поле (вліво/вправо/вниз/вгору).
Звичайно, тут є й один недолік: якщо гравець захоче просто озирнутися по сторонах, то гра все одно зреагує і цифри на полі змістяться як при звичайному жесті. Так що вільно повертати головою хоч і можна, але не без наслідків для результатів гри. Ми вирішили, що це разовий випадок і в цілому це не страшно.



Тепер про підводні камені розробки Unreal Engine 4
  1. Мобільний VR не підтримується. Швидко з'ясувалося, що коли UE говорив про підтримку VR, мова йшла тільки про SDK для Sumsung Gear VR, Oculus Rift і Steam VR (він же HTC Vive). Офіційного SDK для Google Cardboard і інших мобільних очок, як з'ясувалося, на момент старту розробки, не було. Зате був SDK, розроблений і расшаренный Nival, який запускався під Cardboard і тільки на версії движка 4.10. Ми, повні рішучості, почали працювати з ним.

  2. Не відповідність жестів голови поворотів камери. Одна з перших проблем, з якими ми зіткнулися, це що гравець робить поворот голови по горизонталі вправо, а замість цього, камера піднімається вгору. Або гравець опускає голову вниз, а камера провертається за годинниковою стрілкою. Тобто осі і управління виявилися переплутані. SDK від Nival був мабуть розрахований тільки на андроїд пристрої, і на них все працювало як треба. А ось на iPhone при перемиканні орієнтації з портретної в альбомну Pitch, Yaw і Roll не переключалися. При цьому в залежності від того, права у нас альбомна орієнтація або ліва, вони повинні були перемикатися по різному. Рішенням було вибрати тільки одну орієнтацію (використовували тільки Landscape Left Orientation) і прибрати пряме управління камерою від HMD. Орієнтація девайса впливала тільки на контролер, ми отримували його орієнтацію і міняли її для камери: Roll в Yaw, Pitch у Roll та Yaw в Pitch.
  3. Блокування вільного перевертання телефону. Коли ми побороли проблему з осями, з'ясувалося, що якщо перевернути телефон і намагатися керувати полем, то осі знову переплутуються. Рішення цієї проблеми могло б зайняти додатковий час, тому ми вирішили просто заблокувати переворот зображення, і при завантаженні виводити картинку, яка показувала б, як правильно треба тримати телефон.
  4. Дублювання і нашарування текстових полів. У нас над ігровим полем відображаються очки за об'єднання комірок з цифрами. Кожен раз, коли гравець робив нове об'єднання, цифра очок над полем не замінювалася на нову, а перекривалася поверх новим значенням. І це могло повторюватися до нескінченності. На виправлення пішло близько 2-х днів. Як виявилося, це була помилка в самому движку. Вона полягала в тому, що на 3D віджети при збірці на девайс отрендеренный текст більше ніколи не забирався з віджета. Цю помилку успішно виправили в версії движка 4.11, але ми не могли її використовувати, так як Nival не пропатчило свій плагін. Довелося при кожній зміні рахунку перестворювати весь віджет.
  5. Недо-крос-платформеність. Розробляти єдиний крос-платформний білд, який можна було б легко билдить то на iOS, то на Android, не вдалося. Нам довелося вести і підтримувати 2 окремих білду на кожну з осей. Одночасно створювати і тестувати проект на дві платформи виявилося поганою ідеєю, так як SDK для Android і iOS працювало по різному і вимоги до складання білду для Android і iOS різні. Рішенням було продублювати проект і зосередитися на розробці гри для однієї платформи, а потім для іншої.
  6. Неправильна стартова позиція голови при запуску програми. При запуску не відбувалося вирівнювання лінії горизонту у користувача та у додатку, тобто коли гравець тисне на іконку програми на робочому столі, потім проходить завантаження, і ось у якому становищі телефон знаходився в момент завершення завантаження, це положення вважалося вихідним, і далі, все зміщення розраховувалися від цієї точки. Це призвело до того, що якщо людина запустив додаток тримаючи телефон в руках так, що, наприклад, камера телефону була спрямована в підлогу, то після завантаження програми, коли людина вже вставив телефон в шолом, чоловік намагався дивитися прямо перед собою, замість цього ігрова камера дивилася кудись вгору. Як виявилося, цю проблему можна виправити в адекватні терміни, т. к. це рішення лежить на стороні SDK. Тому все, що було в наших силах, це додати при завантаженні програми картинку, що при запуску програми гравцеві треба розмістити телефон в окулярах відразу, поки додаток ще не прогрузилось повністю. Цю проблему ми змогли вирішити тільки з виходом офіційного SDK для Google VR у версії 4.12, але про це пізніше.
  7. Накапливаемое зміщення. В процесі тестування стали помічати, що чим довше граєш, тим далі кудись в сторону йде центр камери. Могло дійти до того, що камера настільки опускалася вниз, що гравець упирався підборіддям у груди при спробі зробити чергове зміщення поля вниз. Найімовірніше, цей баг теж прийшов з SDK від Nival, т. к. в подібних розроблених VR додатках на Unity такої проблеми помічено не було, а так же з виходом апдейта UE 4.12 цей баг теж не відтворювався.
  8. Логотипи на завантаженні. Як у більшості мобільних додатків, в процесі завантаження гри, ми поставили наші логотипи. Але справа в тому, що у UE зараз в принципі немає такого способу вставки картинки або відео на завантаження, щоб воно відобразилося в VR форматі, тому логотипи показуються плоскими, як у звичайному не VR додатку. Це відбувається тому, що стандартний спосіб установки завантажувальної картинки виводить зображення ще до того, як прогрузится безпосередньо гра в VR форматі. А якщо ми перенесемо логотипи всередину гри і виведемо, щоб показати в VR форматі, тоді гравець спочатку не зрозуміло на що буде дивитися поки гра реально вантажиться, а коли гра прогрузилась, буде ще дивитися ролик з нашими логотипами, що в цілому надто відтягне момент входу в гру. Тому в одній з версій, відео з логотипами ми взагалі відключили.
  9. Вага додатки. Перші наші білди важили близько 370 мб. І це вага простої гри з одного сценкою! Очевидно, що UE за замовчуванням упакував в білд багато своїх бібліотек, які, швидше за все, не використовувалися в нашому додатку. Як виявилося, стандартно в Unreal Engine 4 дуже багато підключених плагінів. Тому ми відключили все, що нам було не потрібно: плагіни для 2D графіки, підтримку Android версії для iOS і навпаки, тощо. Але тут потрібно бути оккуратным і не відключити зайвого. В результаті Android версія зменшилася до 87 Мб, а iOS до 182 Мб.
  10. Проблеми з створенням iOS білду з сертифікатом для паблишинга. З самого початку ми зіткнулися з проблемою складання білду для iOS. Так як у нас не було під рукою Mac пристрою, довелося піднімати віртуальну машину з Mac і налаштовувати Unreal Remote Tool (для того, щоб розповісти як це зробити, потрібно писати окрему статтю). Коли ми стали релізувати версію iOS, і намагалися доповнити білд сертифікатом для паблишинга, AppStore ні в яку не брав додаток. Ми витратили близько 30 годин на пошук рішення, і, зневірившись, звернулися за допомогою в підтримку UE. На щастя, завдяки Олексію Савченку, питання було оброблено швидко. З'ясувалося, що ми працюємо на тієї єдиної версії UE 4.10, у якої є баг з створенням паблішинг білдів під iOS, в попередніх і наступних версіях проблеми немає. Ось це удача! Власне проблема була в тому, що зібраний движком білд був не правильно «підписано». Через це доводилося зібраний білд розпаковувати, перепідписувати і збирати заново.
  11. Апдейт UE і офіційна підтримка SDK Cardboard. І в той самий день, коли ми закінчили наш спринт по граблях, якісь проблеми побороли, з якимись, згнітивши серцем, змирилися, Google анонсує нову платформу Daydream, і тут же UE викочує апдейт, який підтримує цю платформу, а заодно і Cardboard. Таким чином, у UE з'являється нормальний SDK для мобіл. Не довго думаючи, ми вирішуємо випробувати цей SDK. На тестовій сцені бачимо, що тих проблем, з якими ми так довго боролися — ні. Але тут же з'ясовується і погана новина — SDK підтримує тільки Android пристрою. Ок! Нехай хоча б на Android вирішуємо ми, і починаємо процес перекладу гри на новий SDK. Це займає близько 2-х днів. В результаті отримуємо білд, в якому всі проблеми зі списку вище виявляються вирішені. Ура! Чи ні? Не зовсім. По-перше, деякі проблеми все ж таки виникли, хоча і відтворювались лише на окремих девайсах. Наприклад, на одному китайському девайсі з'явився шум, схожий на той, який з'являється при поганому сигналі телевізора. На додаток до цього, стали трохи подглючивать матеріали (матеріал сповзав з одного об'єкта і частково налазил на інший). А так само VR зображення виглядало розфокусованим, в очах двоїлося. Однак, баг не повторювався на сучасних брендових телефони типу Samsung S6, тому оцінити охоплення проблеми складно. Але критичною проблемою для нас виявилося те, що новий SDK взагалі не збирав білди на Android не нижче версії 5, хоча до цього у нас додаток запускалося на 4.1+. Вивчивши аналітику з'ясували, що на Android 5+ працює близько 43% пристроїв, що виявилося для нас нижче критичної позначки. Ми хотіли підтримувати не менше 80% пристроїв. Зваживши всі «за»і «проти», ми ухвалили рішення відкласти реліз версії на новому SDK, в користь старого, а коли охоплення пристроїв на Android 5+ збільшиться, оновимо додаток.


Висновки

Пам'ятайте, спочатку ми прикидали оцінку розробки на Unity і на Unreal? Так от, розробка на Unreal нам обійшлася не менше, а то й більше. Головна причина такого оверкилла витекла, спочатку, з-за боротьби з SDK, а потім, із-за боротьби з паблишингом iOS-версії.

Якщо ви запитаєте, чи взялися б ми знову робити мобільний VR гру на Unreal, пройшовши через все це? Якщо робити виключно під Android 5+, тоді, напевно, так. А інакше — ні. Подібне додаток на Unity команда робила за кілька вечорів, і не переживали про SDK, зосередившись на функціоналі, хоча і розробник коштував значно дорожче, але зате менше нервів і швидше результат.

Для чого ж підходить UE? Якщо ви робите VR проект на PC, або НЕ VR проект для мобіл, то UE відмінний вибір з ряду причин, на яких зараз не будемо затримуватися, т. к. стаття не про це. Але для мобільного VR він поки не готовий. Втім, напевно, з апдейтами підтримка мобільного VR покращиться.

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



Окреме спасибі за допомогу в розробці програми та складанні статті команді FurecoVR: Фільченко Євгену і Дмитру Костюкевичу.
І спасибі за консультування Kallist і Eligar

Ось посилання на гру:
iOS: https://itunes.apple.com/ru/app/2048/id1109740917
Android: https://play.google.com/store/apps/details?id=com.antarex.vr2048


Буду радий відповісти на ваші запитання та подискутувати на тему перспектив мобільного VR в коментарях!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.