IVRC2026メタバース部門の振り返り

初めに

こんにちは！トクリンと申します。私は大学内VRサークルの一部部員をメンバーとして、IVRC2026メタバース部門に応募しました。この記事では、作品を作った流れから完成後の反省をまとめています。全体として備忘録となっているので、ご了承ください

IVRC参加の理由

私の所属しているサークルでは、過去複数回IVRCに参加しました。それを機会として各メンバーが大きく成長していました。そのため、今回のIVRCにも参加し後輩たちに大いに参加し成長を促そうと考え、参加に至りました。また、話題となっている「メタバース」をいう概念に対して私なりの解釈があったため、それを表現したいと思いました。

作品の企画

メンバー集め

自身の所属しているVRサークル内Discordの募集掲示板にて、興味のある人を誘ったり、サークル活動中で積極的に声をかけてメンバーを集めました。

企画出し

軸となるアイディアを決めるために、回に分けてオフラインでのMTGを開きました。

１回目のMTGでは、とにかく案を出すため各メンバーに付箋を渡してとにかくアイディアを書きました。その後、机にそれらをすべて開いて、各アイディアについて発表し合うということを行いました。そして、それをグラフにして整理しました。
横成分として、「対決＜－＞協力」
縦成分として、「２人orグループに分かれる＜－＞みんなで」
という風にして、整理を行いました。

これを行ったおかげで、内容が重複しているアイディアどうしを近づけたり、重ねることでまとめました。

２回目のMTGでは、それらの案をもとに少しづつアイディアを絞りました。判断するうえで大切にしたことは、

• プレイヤーが何もしない(待ち)になる時間が発生しないか
  • プレイヤーの遊びを考えた際に"遊びに参加している感"を出せずに、面白さを保証できないと考えました
• MTGで、企画を説明するときに細かくプレゼンできるか
  • 作品を作成していく中で、その人が軸に細かい設定決めが行われると考えました

メタバースの捉え方

私は、メタバースという概念に対して、「同じ目的を持ったユーザーが集まる空間」に着目しました。というのも、普段自分はMMORPGをよくプレイしているので、メタバースを問われたときに思い浮かぶのがあの空間でありました。討伐・採取・クラフト・ハウジング・ギルド・フレンドとの交流など...。それを見て感じるメタバース空間は「共通の目的を持った集団」でした。多くのコンテンツが介在する世界で、コミュニティが形成されるのは、何かしらの共通の思いが存在しているからであり、それがあるからこそそれぞれの世界を形成しているのだと感じました。そのため、私はそれを体現化できる"遊び"を作りたかったのです。コミュニケーションの手段で、その空間にいる人とだけでなく、世界(コミュニティ)構築には、誰かの功績・行動があったからこそ成長していく。そして、それが「メタバース」と捉えらる形に成長していくのだと考えました。

作品の軸

"目的の体言化"をするために考えたゲームの軸は、「非同期型ゲーム」です。

そしてゲームのコンセプトは、屍を越えてゆけ！！ ということです。

例を出すのであれば、Death Stranding(以下デススト)作品をイメージしてください。デスストでは、基本的にはソロプレイとなるが、マップには他のプレイヤーの残した梯子・立てた橋・高速道路が存在します。これによって攻略が進んだり他のプレイヤーの軌跡をたどることができます。これはずばり、非同期的であるが、時空を越えた共通の目的を持った他プレイヤーとの協力プレイであると思いました。目的達成のための手段の共有というのが、私の中で刺さり、これを大きなゲームロジックとして組み込もうと決めました。

技術選定

実装するにあたりUnityネイティブアプリ か VCC(VRChat Creator Companion) のどちらを使用するかを検討して、以下のように判断しました。

Unityネイティブ

メリット：Unityネイティブであり、メンバー全体が使い慣れている・今回表現したい非同期的な交流を実現できる
デメリット：VCCのようにオンライン機能(アバター・ギミックなどの同期)が完全には備わってない

VCC

メリット：オンライン機能が整備されている
デメリット：使用経験者が誰もいないため、学習コストが高すぎる・非同期的システムを実装できない

その他の部分

オンラインの機能：Netcode for GameObjects(以下NGO)
非同期のシステム：Unity Cloud、Cloud Code
VR実装：Meta XR SDK
必要アセット作成：各モデラーにお任せ(Blenderなど)
上記は基本的に、学習コストを考え期間内の実現可能性を踏まえて採用しました。
Meta XR SDKは、1年以上の経験がありました。NGOは、今年の春で作成したオンラインVRゲームを作成した際に使用した経験があったが、非同期に関する技術は今回初めて使用しました。
VR実装の部分を除いて、基本的にはUnityが公式でサポートしているものを採用しました。
理由としては、アカウントを複数用意する必要がなく、基本的にUnityで完結しているため採用しました。
※Stearmworkers API(同期+非同期+ボイスチャット)、Firebase(非同期)、Vivox(ボイスチャット)なども検討しましたが、今回はコア部分になる機能実装・上記の理由のため除外しました。

作品の制作

大学のテスト期間があり、6月8日から始動しました。コンセプトは決まっていたため、Blender班はステージ部屋制作をお願いしました。Unity班に関しては、各自「残されたアイテムを使った攻略」を軸にギミックの企画・実装をお願いしました。
しかし、すべてがうまくということはなく多くの問題を抱えながらプロジェクトは進行しました。

作品制作のためにやったこと

Figmaによる世界観の設定

Figmaに備わっているFigJamを使用してゲームの中身を関係づけました。
写真のようにギミック同士の関係づけや、ゲームでの死亡という概念の細かな設定やテーマ性についてまとめました。チームメンバーへの共有ももちろんのこと、私の中で考えたアイディアがどういう形になっているかという整理にもなり、大変役立てることができました。

週1以上でのMTG・メンバーとのコミュニケーション

基本的には週1でMTGを行いました。進捗共有・それによる全体の進行度の整理・疑問点などの共有ができました。また、週のどこかではなくこの日のこの時間をあらかじめ決め、集まることができました。もし、その日集まることが困難でも、事前に進捗や疑問点などを共有しました。

また、私は大学内でメンバーに会う機会があった時や別のプロジェクトでメンバーと集まる機会があった時に積極的にコミュニケーション、ミニMTGをすることを心掛けました。オンラインMTGは確かに場所を気にせずできるが、 オフラインにかなうものはない！
対面で話すことで、オンラインでは話しにくい内容やカジュアルにメンバーと話すことで状況を整理することができました。大きな進展として、後ほどまとめてあるがゲーム内容についての大きな疑問・面白くないということに対して、直接伝えてくれました。これにより、もう一度ゲーム内容について考えなおし、全体が納得する形に落としむことができた。これにより、メンバーのモチベーションや制作に参加することへの積極性を上げることができたと感じました。

反省点

"学生"という壁

私は、当初のタスクはオンラインロジックの構築に多くの時間を割いていました。そのため、ギミックの内容は他のメンバー依存となっていました。しかし、状況は好転することはなく多くの山場がありました。
テスト対策・迫りくる授業の課題・テスト対策・サークルの活動・テスト対策・テスト対策...。
IVRCのプロジェクトにフルコミットすることができたのは、テストが終了した8月8日以降でした。私がそれに対して軽率な判断をとっていたために、適切なスケジュール付けができず、私自身の中でも「今週何もできてないです」「来週やります」が続き、何かスケジュールに対して何とかなるという不確実な判断が続いていました。本来であれば、この状態であれば、こういうMVPにするというのがあるが、それを怠っていました。

不十分なMVPの設定

ミニマムなゲームを大きく見誤っており、それにより自分たちが真っ先に行うタスクについて整理をできていませんでした。もし、定まっていたのであれば早期での必要技術の検証・最低限の実装を行えたと反省をしています。原因としては、メンバー全体のペース配分を把握できていなかった・オンラインロジック部分の検証にかかる時間的コストの把握が考えられます。

オンラインロジックのための設計を怠っていた

UnityのNGO実装が今回で初めてというわけではありませんでした。今年の春ごろに実際にコードを書いての実装経験はありました。しかし、前回と違う点として「各ギミックの多くのフラグを管理しないといけない」問題などがありました。一言でえいば、「プロジェクトが大きすぎて自分が管理しきれていない状況でそのまま進行していた」。また、私自身はUnity MCPを使い、他メンバーが実装したギミックに対してオンライン実装をお願いしていました。しかし、ここに大きな問題があり、AIではVRのゲームの検証はできず、実際の挙動を確認できない。それにより、2,3日1つのギミックに対してオンライン実装を行ったこともありました。また、コード量がどんどん肥大化していくのに対して管理者である私が把握できていなことも大きな問題となっていました。

ゲーム企画の不十分さ

全体を振り返ってみて以下のようなスケージュールで進行していました。

• 6/8：制作開始
• 7/11：全体として密に内容を練れていなかったため、一度リセットし各ギミックを練り直し
• 7/18：ギミック案の最終締め切りとして各ギミックの相互作用を構築
• 7/25：図を作成し、それに基づいたゲーム制作開始
• 8/16：オフライン版の最終構築
• 8/19：非同期層の構築
• 8/21：最終締め切り

見ての通り、あまりにも企画・設計に時間をとっており、実際の作業・デバックをする時間があまりにも少なすぎました。これは、私が各メンバーに対して半ば抽象的なタスクを振っていました。この狙いとして全てを決めてタスクを渡すよりも各メンバーの創造性を入れてほしかったのです。しかし、これはただの大きな理想であり・大きな私のエゴでもありました。自分でどういう形になればきれいな流れになるのかという理想形を決めておらず、各メンバーのどうしたらいいかという対して明確タスクの指示を送れず、抽象的な表現での指示になることもありました。

そのため、メンバーの一人から長い時間をかけて「今何を作ろうとしているのか」というのを聞かれました。そのおかげで、自分の中でも決め切れていなかった細部までの設定・新しいギミック同士の結合というアイディアをまとめることができました。「残されたアイテムを使った攻略」を軸に対して、ゲーム内容の変更やそれに伴った各ギミック・アイテムの相互作用について考えなおしました。その結果メンバー全体での納得するゲーム内容に落としこむことができました。

作品提出までにできなかったこと

上記の問題を抱えながら、以下の問題を残して終わることとなりました

• 同じセッション内でのアイテム継承が、失敗するケースが発生する
• サーバー側にPushするデータがの座標が不整合であり、検証・修正が間に合わなかった
• すべてのイベントに対するデバックをできてない

全ては、時間による検証が必須となっており、私がデバックに多くの時間を割くないがことが起因していました。

一次審査の結果

今回のIVRCでは、一次審査落選となってしまいました。
審査員の方々からのコメントでは、コンセプトについては好評をいただけましたが、面白さについての追及やデバック関連のご指摘をもらいました。主に、私がマネジメントをしていく中でのスキル不足が大きく起因していたと感じました。

まとめ

今回の大きなミスとして、

• 早期段階での同期・非同期のシステム実装、それに伴うMVPを作成できなかった
• ゲーム全体の内容について細かく決めることはできたが、時間がかかりすぎてしまった
• 概念的な理解はできていたが、細部のコード理解ができていなかったことによる設計の怠り
• 時間的コストを重要視して考える

また、新しい発見として、

• 作品を作るときには、メンバーに企画の細部について聞かれたら答えられる形にする
• 企画内容は、メンバーが理解できる形まで分解して表現する

おわりに

内容自体は、私自身に対する備忘録となっています。最適なPMの動きというのは経験が浅いと難しい点が多く、今回は私にとって良い経験になった思います。