VR 酔い対策の事例
Robin Boucherこのエントリーは GREE Advent Calendar 2015 5日目の記事です。
はじめに
こんにちは、GREE VR Studio の Robin です。元々 Wright Flyer Studios でスマートフォン向けネイティブゲームの開発をしていましたが、同僚に見せていただいた VR ゲームに度肝を抜かれたのをきっかけに VR に興味を持つようになり、現在は新設された VR 専属チームに所属しています。
開発面では、TGS2015 展示用の「サラと毒蛇の王冠 (Win + Oculus Rift DK2)」、及びハコスコ・Google Cardboard 等のスマートフォン用 VR Viewer 向けの「シドニーとあやつり王の墓 (iOS・Android)」に参加しました。開発は Unity で行っています。
VR ゲームの分野は非常に新しく、ノウハウがまだ蓄積されていません。VR 特有のチャレンジがいくつもあるのに対し、一貫した「これだ」という答えがまだ確立されておらず、あれこれ試行錯誤を繰り返すことになります。今回は、「サラと毒蛇の王冠」「シドニーとあやつり王の墓」を快適な VR 体験として一般向けに公開できる状態に持って行くまでにぶつかったハードルの中で「VR 酔い対策」の事例の一部を紹介したいと思います。
TL;DR
VR に飛び込むなら、まず Oculus が提供している一般的な VR 開発におけるベストプラクティスを集約した Oculus Best Practices (日本語) に目を通すことをお勧めします。酔い対策以外にも様々なトピックについて解説しています。今回紹介する事例も、基本的にこのガイドや Oculus の講演などで既にカバーされている内容です。この分野を長く研究し続けているエキスパートの知見が公開されているので、これらのベストプラクティスを理解して初めて VR ゲーム開発の土台に立てると言えます。
ただ、あくまで「一般的な」ガイドなので、手掛けているゲームの仕様によってはガイドラインが当てはまらないケースも少なくありません。ガイド自体も多くの課題と解決法を紹介していますが、大抵「ユーザーテスト等を行い、ご自身のプロダクト体験に最適な実装方法を見出すことが重要」といった注意書きが追記されています。なので、ガイドは参考にしつつも、実際に他人にプレイしてもらい、試行錯誤して何がワークするか・しないかを自分で判断することが大事です。
そもそもどんなゲーム？
「サラ」は TGS 専用なので今はプレイできませんが、公式の紹介動画があるので、こちらで雰囲気を感じ取ってください。
「シドニー」は iOS・Android のストアに公開されているのでダウンロードしてプレイできます。
簡単に説明すると、ステージ内のギミックを作動させて先へ進んで行くアドベンチャーゲームです。コントローラーはなく、ギミックは一定時間頭の向きを合わせることで作動させます。VR 空間内で視線を使った point-and-click アドベンチャー、と言うと分かりやすいかもしれません。「サラ」も「シドニー」もシステムは同じですが、「サラ」がステージを見回して探索する謎解き寄りなのに対し、「シドニー」は出現する敵を撃退するアクション寄りになっています。
「サラと毒蛇の王冠」
「シドニーとあやつり王の墓」
VR 酔いについて
では本題に入りましょう。
VR 開発で真っ先に挙がる課題のひとつが VR 酔い (a.k.a. シミュレーター酔い) です。現実世界から遮断された VR 空間内のカメラ制御等によって、ユーザーに乗り物酔いに似た症状を引き起こしてしまいます。
VR 酔いは非常に不快で、プレイ中の楽しみを削ぐのはもちろん、中断してもしばらく余韻が残ります。いくらゲームの出来が良くても酔いを誘発させた瞬間に全てが台無しになります。一度酔うとそのゲームは二度とプレイしない場合がほとんどです。VR ゲームのプレイ経験のある方なら、酔ったゲームは (あまりの不快さ故に) 明確に覚えているのではないでしょうか。
そもそもなぜ酔うのか、になると 3D 酔い等と同様に人によって様々で、同じゲームの同じ場面をプレイさせてもすぐに酔う人もいれば全く酔わない人もいます。
Oculus Best Practices より
. . . the primary feelings of discomfort associated with simulator sickness occur when visual information from a simulated environment signals self-motion in the absence of any actual movement.
つまり、「視界 (カメラ) の動きと身体の動きが一致していない」場合に酔いやすくなります。筆者の経験も含めてもう少し突き詰めると、「ユーザーが意図していない、または予期していない視界の動きがある場合に酔いやすい」というのが基本的なルールだと考えています。
フレームレート関連
まず最初に、VR ゲームはフレームレートが対象デバイスの画面リフレッシュレートに常に達している必要があります (e.g. Oculus Rift DK2 は 75FPS、製品版 Oculus Rift は 90FPS、スマートフォンは 60FPS 等)。理由は単純で、フレーム落ちが発生するとその分頭の動きに対して視界が遅れるので、頭の動きと視界の動きに差異が発生して酔いやすくなります。対応は処理負荷や描画負荷を見直すことになるので、いつもやるようなパフォーマンスチューニングをすれば OK です。
理想のケース
ユーザーの身体の動きと視界の動きを 100% 一致させるとなると、カメラ操作を完全にユーザー (ヘッド・ポジショントラッキング) に委ね、ゲームロジック側では一切カメラを動かさないのが酔い対策観点から見たベストケースになります。
が、当然ながらゲームデザイン側から表現できることが極端に限られてしまいます。ステージ内の何かを見せるために特定の方向へ向かせたい・ステージ内のユーザーの視点の位置を変えたい・そもそも先へ進ませるためにステージを切り替えたい等、ゲーム側でカメラを動かすのは基本的に避けられないと言えます。
では、カメラを動かす場合はどうすればいいのか？
視点切り替え (ワープ移動)
最も安全かつ手のかからないカメラ移動方式は、目的の位置までシュパッとワープしてしまうことです。視界が切り替わる瞬間は混乱しますが、一瞬なので新しい視界に比較的素早く慣れることが可能です。
が、一瞬であれユーザーが意図していない視界の移動になるので、ワープの瞬間は酔いの要因になります。しかし、事前に「今から視界が切り替わる」というのをユーザーに伝え、心構えをさせれば混乱を和らげることができます。ユーザーが意図しない動きであっても、予期できる動きであれば酔いにくくなります。
シンプルなのは、視点切り替えの際に画面フェードなどの予兆演出で画面を隠す方法です。画面がブラックアウトすれば「場面が変わるかもな」とユーザーが察知し、視界が開けた際に風景が変わっていても混乱しにくくなります。ステージ内の視点切り替えはもちろん、ステージ自体を切り替える時 (Unity のシーンチェンジ) にも必ず予兆演出を入れるようにしましょう。
「シドニー」では視点切り替えやシーンチェンジの間に瞬きの演出を挟んでいます。
視点移動前
瞬きで画面を隠す
視界が開いて別視点へ
また他社様だと、Unreal Engine 開発元の Epic Games が Oculus Rift + Oculus Touch 用に製作した VR デモ「Bullet Train」がワープ移動のとても良い例となっています。ステージ内の決まったポイント間をコントローラー操作で任意にワープ移動できるというものですが、こちらはワープの間に演出を挟んでいるうえ、ユーザーの意思による移動なので更に酔いにくくなっています。
等速移動
視点切り替えだけだと、移動可能な位置や範囲が制限されてしまうので、ゲームによってはやや味気ない VR 体験に終わってしまうかもしれません。ルームトラッキング設備による自由移動を前提としているならともかく、演出としてユーザーの操作なしでカメラをスムーズに継続的に動かしたい場面もあると思います。
カメラをユーザーの意思なく動かすと、頭の動きとの差異が発生するので酔いやすくなります。しかし、いくつかカメラの動きにルールを設けることで、ある程度酔いを抑制することができます。ただし、あくまで「ある程度」なので、どんなに気を使ってとしても人によってはカメラを勝手に動かした時点で酔ってしまうのは覚悟しましょう。
「シドニー」はワープ移動のみになっていますが、「サラ」ではステージ間をシームレスに移動できるようにするため、ワープ移動ではなくカメラを直接動かしています。その中でなるべく酔いにくくするためのポイントをいくつか紹介します。
ゆっくり動かす
カメラを動かす場合、遅ければ遅いほど頭と視界の動きの差異が小さくなり、酔いにくくなります。「サラ」では人間の平均的な歩行速度である 1.4m/s くらいを目安にしています。
加速させない
カメラ移動の速度を速くすると確かに酔いやすくなりますが、更に酔いやすいのが加速させることです。
Oculus Best Practices より
. . . the real enemy to beware is acceleration, the stimulus to which the vestibular organs inside the inner ear respond. Acceleration (linear or angular, in any direction) conveyed visually but not to the vestibular organs constitutes a sensory conflict that can cause discomfort.
歩いたり走ったり、乗り物に乗ったりすることで身体が動く際、内耳の中にある前庭器官が加速に反応します。VR 空間内で視界のみを加速させても、身体が加速していなければ前庭器官は反応せず、視界と身体の動きに不一致が発生し、酔いやすくなります。
また、
The vestibular organs do not respond to constant velocity, so constant visual motion represents a smaller conflict for the senses.
前庭器官は等速の動きには反応しないので、カメラを動かす場合は加速させずに一定の速度をキープすることが大切です。
同じ理由で、どうしてもカメラ移動の速度を移動中に変えたい場合、ゆっくりと時間をかけて加速させるよりも一気に目的の速度までバーストした方が酔いにくくなります。
一直線のみ
カメラの移動方向ベクトルを移動中に変えた場合、それは「新しい方向へ加速した」ということになり、酔いやすくなります。移動は一直線に絞るようにしましょう。
なお、一直線というのは前後のみの話ではなく、全方向に当てはまります。例えば、前方向に一直線に進んでいたとしても、ジャンプ移動のような演出でふんわりと上下にカメラを動かすと Y 軸の加速となり、酔いやすくなります。
「サラ」でカメラを動かす際には必ず固定の方向へ等速移動するように心がけています。
なお、一直線にカメラを動し、加速を一切していなくても、人によって酔いやすい移動方向が存在します。例えば、筆者は横方向にカメラを動かされると酔います。ある同僚は横方向は平気ですが、下方向だと酔います。また別の同僚はどの方向も特に問題なかったりします。「サラ」のユーザーテストでは、前方向・上方向は比較的平気な人が多く、下方向は苦手な人が多い結果になりました。
「サラ」ではクライマックスに滝の上から落ちるシーンがあります。一人称視点で等速に下方向へ一直線に落ちる演出です。VR 体験としておいしい一方、ユーザーテストでやや酔いやすい場面でもありました。しかし、酔わずに楽しんでいただけた方も多かったため、酔いやすいからとカットするよりも、ゲーム自体を「ノーマルモード」「エキサイティングモード」から選択するようにして、酔いやすい方にはノーマルモードを推奨する注意書きを追加しました。ノーマルモードでは落ちる演出は一人称視点にならず、固定位置の三人称視点で落下していく主人公たちを眺める形になっています。
モード選択
「エキサイティングモード」の落下シーン
このように、酔い対策は必須ですが、最終的には提供したい体験に何が最適かを自分で判断するのが重要です。
回転させない
視界が映っている状態でカメラを勝手に回転させると非常に酔いやすくなります。
カメラの位置をコントロールできない VR 環境は普通にあるので (スマートフォン用 VR Viewer の他、Samsung Gear VR など)、勝手に動かしても受け入れてもらえる場合があるのに対し、カメラの回転 (向き) をコントロールできない VR 環境はほとんどありません。勝手にカメラを回転させた場合、視界がユーザーの意思と全く違う動きをしてしまい、かなり不快です。
狭所では避ける
視界が動く際、パララックスによって遠くの景色よりも近くの景色が早く通り過ぎていくのは当たり前ですが、VR ゲーム内では重要になってきます。例えば、広く開けた砂漠と狭いトンネル内を同じ速度で移動している場合、近くの壁しか見えないトンネル内の方が体感的な移動速度が速くなります。前述のように、移動速度が速ければ速いほど酔いやすくなるので、あまり狭い場所では移動を避けた方が良いかもしれません。
予兆を挟む
何の前触れも無しにいきなりカメラを動かし始めると、動き始めた瞬間は加速となるので酔いやすくなります。ワープ移動と同じく、「今から動かす」とユーザーに心構えをさせることが重要です。
「サラ」ではカメラ移動の前後に瞬きで画面を隠す演出を挟んでいます。また、視界が開けた時点でカメラが既に動いている状態にし、移動を止める際も必ず画面を隠してから止めるようにしています。画面を隠すことでユーザーに「場面が変わるかも」と心の準備をする猶予を与えています。また、最初のシーンから既にカメラ移動があるので、「場面が変わるかも」と同時に「視界も動くかも」という心構えをユーザーにすり込むようにしています。
世界観による工夫
足を動かさずに視界のみが動いていても違和感がないような世界観を構築するのも工夫のひとつです。
シンプルな理由付けのひとつに「乗り物に乗せる」があります。車・電車・トロッコ・ケーブルカー・スキーリフトなどなどです。「サラ」ではキャラクター (とユーザー) を小型のモーターボートに乗せています。ただ、現実だとかなり揺れる乗り物なので (そして実際にカメラを揺らすのは NG)、本当にワークしたかはちょっと微妙なところです。
ボート乗船中の様子
その他
ダメージを受けた時にカメラを揺らす・一人称視点での移動時に頭の動きを再現させるためにヘッドボブを導入するといった、近年のゲームにありがちなカメラ演出は軒並み NG となります。
ゲームにポーズ機能があり、ポーズウィンドウを半透明にして裏で地形が見えたままにしたい場合、ヘッドトラッキングごと止めるのは NG です。ゲームの timeScale を 0 にしても、ヘッドトラッキングは有効のままにしましょう。「シドニー」ではこの手法でポーズを実装しています。演出でスローや早送りを導入する場合も同様です。
ポーズ画面。敵の動きは止まっているが、この間も周囲を見回すことが可能
落とし穴
さて、ここまで VR 酔い対策を書きましたが、ひとつ大きな罠があります。
Oculus Best Practices より
The more experience a user has had with a virtual environment, the less likely they are to experience simulator sickness. . . . developers who test their own games repeatedly will be much more resistant to simulator sickness than a new user, and therefore need to test the experience with a novice population with a variety of susceptibility levels to simulator sickness to assess how comfortable the experience actually is.
単純に、VR 経験があればあるほど、身体が慣れて酔いに耐性がついてしまうということです。開発メンバーはどんどん酔いにくくなっていくので、ユーザーテストをする際には、普段 VR ゲームをプレイしない初心者を含めることがとても重要です。
最後に
VR 酔い対策の事例、いかがでしたでしょうか？特に初見の方には、VR ゲームは絶大なインパクトを与えます。しかし、そのインパクトが「盛大に酔ってしまった」だと、二度と VR ゲームに手を出さない恐れがあります。それではあまりにもったいないので、ぜひ Oculus Best Practices (日本語) を読んで、快適な VR 体験を目指してください。
また、今回は酔い対策に絞った事例を紹介しましたが、VR 開発では酔い以外にも様々なハードルがあります。UI やメニューの表現方法・カメラがモデルにめり込んだ場合の対処・没入感の維持・高フレームレートを維持するための負荷対策・VR 空間内でのサウンドデザイン・マルチプレイしたい場合の実装方法等、課題を挙げればキリがありません。とにかく試行錯誤を繰り返して提供したい体験に何が合っているかを自分で判断することが重要です。そして、一貫した答えがないからこそ、いろいろ試して自分で答えを発見する楽しみがあります。
最後まで読んでいただき、ありがとうございました。
明日はデータエンジニアリングチームの長谷川さんと田畠さんの「DynamoDB を使った KPI 保存システム」になります。