こんにちは、エンジニアのオオバです。
CEDEC2021 VRプロダクト開発ラウンドテーブルに参加。
ラウンドテーブルとは、
決められたお題について話し合う、
情報交換を眺めるセッションだ。
CEDECは値段設定高めの有料イベント。
有料だけど比較的ラフな会では
貴重な情報を得られることがよくある（今までの経験的に）。
あまり世に出てくることのないVR開発の
現場ノウハウを知れたらラッキーかなと思って参加した。
ツイートの通り大きく4点の学びがあった。
- QuestとPSVRは抑えておく
- Oculus App Labだけはやめておけ
- Zenjectでプラットフォーム補完テク
- Quest1で動けばパフォーマンス的にOK
実務のVR開発が未経験の人にとって、
とても有益だったのではないかと思う。
またぼくの通常業務であるスマホゲーム開発と
同じような苦悩もあった。
今回の参加レポートをぼくなりにまとめてみた。
VR開発に興味ある方はぜひ最後まで読んでもらいたい。
→11万文字で徹底解説した「DOTweenの教科書」Unityアニメーションの超効率化ツールはこちら
Quest、PSVRを抑えておけばOK
さまざまなデバイスが登場する中、
プラットフォームの選定は悩みどころ。
売上を考えるとシェア率から考える。
どのOSのスマホ端末まで対応するか？
みたいなスマホゲー開発と同じ。
デバイスは2種
- 2020年でPSVRは500万台
- 2021年Quest2はアメリカだけで400万台（リコールで発覚）
このシェア率で考えると、
こちらの2つに対応すれば1000万台にリーチ。
- Quest1・2
- PSVR
プラットフォームは4つ
- SteamVR
- PlayStation Store
- Side Qust
- Oculus AppLab
Oculus AppLabだけのリリースは止めた方が無難
- 検索に引っかからない
- URL直入力が必要
- ストアページで「開発中の可能性がある」といった注意文言表示
全体的に導線の難易度が高く、
ユーザーがインストールまで
至らない可能性の高いプラットフォーム。
メインのプラットフォーム開発のついでで、
且つ低コストで対応できるなら選択肢としてありかも。
マルチプラットフォーム対応
OpenXRによる共通化が進んでいる。
XR Interaction Toolkit
というパッケージがUnityから提供されていて、
OpenXRプラグインと組み合わせることで、
プラットフォームの差異を意識することなく
VR開発が可能。
ただしデバイス特有機能は個別対応が必要。
具体的なデバイス特有機能例
- パススルー
- ハンドトラッキング
- Viveのトラッカー
など
実際の現場では、
抽象レイヤーやラッパーAPIを自作。
プラットフォームの差を気にせずに
開発できるようにしている。
開発メンバーが余計な事を考えなくても良くする環境構築は、
スマホゲームを開発しているぼくも大いに共感。
また、実機に繋がなくともテストできる環境が大事。
要するに、まずはUnityエディタだけで完結できるようにしておく。
1回のテストに実機を挟むと、
時間がかかりすぎてしまうため。
Unityエディタだけで開発できるというのは、
マスト要件だと思った。
スマホゲーム開発も同じですね。
ダブルタップをUnityエディタ上で
シミュレートできるようにしておく。
みたいなことと同じ。
他PFのSDKはデプロイ時に削除必要
Steam VR SDKをバイナリに含んだ状態で、
Oculusにアップロードはバリデーションが通らず不可。
CIでSDKを削除するといったジョブを作成している。
Unityの話にはなるけど、
Zenjectで各プラットフォームごとの
実装を注入するといったテクニックも紹介された。
FirebaseがQuestで使えない問題
QuestはAndroidだけど、
GooglePlayServiceがなく
Firebaseが使えない問題の共有。
ただFirebaseはRestAPIを利用すると大丈夫とのこと。
ラウンドテーブルならではの知見ですね。
パフォーマンス問題
VRアプリは常時フレーム落ちしてはいけないため、
パフォーマンスチューニングは非常に重要。
チューニングをする上で、
どのデバイスを基準にすればよいのか？
結論: Quest1でパフォーマンスがOKならOK
Quest1がスペックの下限。
例えばQuest2の場合は、
GPUだけでいえばQuest1の約2倍の性能。
とりあえず、Quest1で動けばパフォーマンスはOK。
チューニング方法としては、
デバイスをUnityにつないで
Unityプロファイラなどを使ってチューニング。
このあたりはスマホゲーと同じ。
コントローラーの違い問題
QuestとViveのキーマッピングに落とし穴。
「Questでは傾ける」は「Viveではタッチ」と同じ。
SteamVRは一通りのVR機器に対応する必要ありで、
機種を実際に所持しておかないと、
VRアプリを世には出しづらい。
実際に個人で開発もしているコリンさんの部屋は、
VR機器でいっぱいとのこと。
海外では一定層 Windows MRユーザーもいるため、
そのあたりも注意。
なるほど。。。
チュートリアル => 普通にボードを出す
そもそも没入感を大事にしているVRで、
システマチックなチュートリアルってどうなの？
という疑問もある。
ただ、どうしてもユーザーに伝えたいことがある。
そんな時は普通にダイアログウィンドウ的なものを表示させる。
まあ、仕方ない。
今後新しい見せ方が登場するかも知れない。
ユーザーテストの厳しい時代
プロモーション込みで企画される実際のユーザーテストは、
コロナで厳しい状況。
アルファ版リリースで遊んでもらうのが定番。
海外勢は文字嫌い、日本人は日本語必須
多言語対応って難しい。
ただ置き換える、字幕を付けるではダメ。
海外では字幕をやめてほしいというレビューが一定数ある。
シェア率的に海外だけに絞ると、
日本語対応しないとやってくれない日本人で困る。
どちらかに振り切るというのも手だが、
日本と海外どちらもリリースしたいよね。
っていう気持ちはスマホゲーム作ってる身として
むちゃくちゃ分かる。
まとめ
実務でVR開発をしているメンバーの
開発トピックスの共有は非常に有意義だった。
冒頭のまとめに加えたまとめはコチラ。
- QuestとPSVRは抑えておく
- Oculus App Labだけはやめておけ
- Zenjectでプラットフォーム補完テク
- Quest1で動けばパフォーマンス的にOK
- Unityエディタだけで完結できるアプリ設計
- XR Interaction ToolkitとOpenXRに期待（とりあえず使ってみる）
- シェア率的に海外は外せない現実あり
- デバイスごとのコントローラマッピングは注意（デバイスを揃える必要あり）
- チュートリアルに発明が求められる
- VR多言語って難しい
またCEDECのラウンドテーブルは、
タイムシフト（録画）がない。
参加しなければ、聞けない話なのだ。
そういった意味でも貴重。
今日得た知見を、
今後のVR開発に活かしていきたい。
参加セッション
この記事が気に入ったらフォローしよう
