VRネトゲの作り方:Mikulus Kinect OnlineにおけるPhoton Cloudの活用


この記事はOculus Rift Advent Calendarの4日目です。

はじめに

こんにちは。Oculus Rift Advent Calendar 12/4担当のNeedleです。

先日11/9に開催された第一回Oculus Game Jamで作ったMikulus Kinect Onlineの、特にネットワーク部分について書こうと思います。

Mikulus Kinect Onlineとはこんなソフトです。


なお現在、第五回ニコニコ学会β 研究してみたマッドネスセッションの投票受付中です。投票は本日12/4 23:59までですので、もし良ければこちらのページから投票をよろしくお願いいたします!

Mikulus Kinectとは

Mikulus Kinect Onlineの話の前に、まずその元となったMikulus Kinectについて説明します。

Mikulus Kinect

Mikulus Kinectは、Oculus RiftとKinectとUnity3Dを組み合わせて、プレイヤーが自分の手足や体がVR内で見える状態でミクさんと握手や頭を撫でるといったコミュニケーションが取れるアプリです。

Oculusを着けて最初に感じたのが頭の角度に対する映像の追随の滑らかさでしたが、一方で感じたのが、頭の位置移動が反映されないことや自分の体が見えない事による違和感でした。そのときKinect登場時に話題になったNao_uさんの動画を思い出し、自分でもやってみようと思ったのがきっかけです。「VR内でAIキャラの目を見る」という体験は、モニタ越しのゲームとは全く違ったものとして感じられました。

ここで作ったMikulus Kinectはあくまで 人←→AI というシングルプレイヤーのデモでした。これをマルチプレイヤー化し、複数の人が同じVR空間内に入れるようにしたのが、Mikulus Kinect Onlineになります。

オンライン化にするにあたっての課題

オンライン対応にはネットワークミドルウェアのPhoton Cloudを使いました。以前ワークショップで少しだけ触ったことがあったからというのもありますが、ゲームジャムの会場がPhotonを日本展開されているGMOさんのオフィス内で、中の人に質問をしやすかったからでもあります。Unity用のPhoton CloudはUnity自身の内蔵ネットワーク機能に似た形で使えるよう作られているので、そちらを使う場合も同じ手法を応用できると思います。

ここからはMikulus Kinectをオンライン化する際に直面した課題について書いていきます。

アバターキャラの出現(○○さんがログインしました)

シングルプレイのMikulus Kinectではプレイヤーが操作するアバターキャラを最初からHierarchyの中に置いていましたが、ネットワーク環境では誰かがログインする度にその人のアバターキャラを出現させる必要があるため、Hierarchyにおいておくわけにはいきません。アバターキャラのGameObjectはPrefabにして、ProjectのResources内に置いておきます。

ログイン時のコードはこんな感じです。
(アバターキャラPrefabの名前はここではMKMotionCaptureContainerとなっています)

void OnJoinedRoom(){
    // 参加者全員の世界に新規プレイヤーのアバターが出現する。
    // PhotonNetwork.InstantiateでInstantiateできるのはResourcesフォルダの中身のみ。
    // インスペクタでGameObjectメンバ変数にPrefabを割り当てて使ったりは出来ないので注意
    GameObject character = PhotonNetwork.Instantiate("MKMotionCaptureContainer",
        Vector3.zero, Quaternion.Euler(new Vector3(0,180,0)), 0);

    // こっちの内容は参加者全員ではなく自分の世界でだけ反映されるので、
    // 自分のアバターキャラにモーションキャプチャ&ヘッドトラッキングの関連付けを行う
    character.name ="MKMotionCaptureContainer(Me)";
    mocap.EngagedUsers[0] = character;
    character.GetComponent<HeadFollowsEyeSmoothed>().enabled = true;
    character.GetComponent<SetZigBias>().enabled = true;
    myPhotonView = character.GetComponent<PhotonView>();
    character.transform.parent = meObject.transform;
}

photonviewdetailモーションキャプチャ関節の共有

Photon CloudにはPhotonViewというスクリプトがあります。基本的には、ネットワーク越しにプレイヤー間で共有したいGameObjectにこのスクリプトを貼っておくことで、そのGameObjectの位置・角度・パラメータといった状態を共有できるようになります。キャラクターの動きを共有するにはこれを使います。

通常のオンラインゲームでは、一人のプレイヤーが動かせるのは基本的に自分のプレイヤーキャラ1体です。つまり一人あたりのPhotonViewは1個で十分でした。

これがMikulus Kinect Onlineにおいては話が変わります。全身の関節をKinectでキャプチャし、MMDモデルの関節に割り当てているため、位置・角度をPhotonViewで共有するのも、キャプチャしている関節全てで行わなければなりません。1

mikuwithskelparts2任意のキャラクターモデルへの対応

以上を踏まえて、単にミクのモデルだけを動かしたいのであれば、ミクモデルの各関節のGameObjectに黙々とPhotonViewを貼っていけばOKです。

しかし将来的にはKAITOやリン・レンなどアバターキャラ(モデル)の切替を可能にしたいので、決め打ち対応はなるべく避けたいところです。Kinectでキャプチャされる関節は24もあるので2 、モデルを変える度にPhotonViewを貼る作業を24回繰り返すのは生産的ではありません。一方で、モデルによっては関節の数が違い3 、24個全部を使わないこともありえます。

よって、PhotonViewの割り当ては初期化時に自動的に行えるとベストです。

PhotonViewスクリプトの自動割り当て

これらの問題を解決するため、当初は以下のような手順を考えました。

  • アバターキャラPrefabのInstantiate時にモーションキャプチャで動かせる関節GameObjectの一覧を作る
    • その関節GameObjectの配列をforeachでループし、それぞれにAddComponent()PhotonViewスクリプトを生成して貼り付ける

しかしこれだと動作しません。

調べて分かったのですが、PhotonViewスクリプトはPrefabのInstantiate時点であらかじめ共有したいGameObjectに貼られていなければならず、初期化時に生成するのでは間に合わないようでした。

しばらく悩みましたが、発想を逆転し、結果として以下の様な手順になりました。

  • Unityエディタを使い、PhotonViewが貼られた空GameObjectを24個作って入れておく
    jointphotonviews

    • アバターキャラPrefabのInstantiate時にモーションキャプチャで動かせる関節GameObjectの一覧を作る
    • その関節GameObjectの配列をforeachでループし、それぞれに先ほど作っておいたPhotonView付きGameObjectを関連付ける
    • モデルの関節数が24個未満だった場合、PhotonView付きGameObjectが関連付けられずに余るので、余った分はDestroy()して始末する

要は初期化時に生成するのがダメでも、初期化時に破壊するのはOKという性質を利用しています。

以下は該当部分のソース。

using UnityEngine;
using System;

public class NetworkPopulator : Photon.MonoBehaviour {
    public GameObject jointPhotonViewContainer;

    void Start () {
        MatchZigfuSkeletonToMMDModel zigfuMMDModel =
            GetComponent<MatchZigfuSkeletontoMmdModel>();
        if (!zigfuMMDModel) {
            Debug.LogError("No MatchZigfuSkeletonToMMDModel found");
            return;
        }
        // skelTransformsにはトラッキングが有効な関節の一覧が入っている
        Transform[] skelTransforms = zigfuMMDModel.trackedMMDBodyParts;

        MKNetworkCharacter[] jointPhotonViews =
        jointPhotonViewContainer.GetComponentsInChildren();

        foreach (ZigJointId jId in Enum.GetValues(typeof(ZigJointId))) {
            int joint = (int)jId; // 毎回キャストしないよう
            if (skelTransforms[joint]){
                // 該当関節があるならPhotonView割り当て
                jointPhotonViews[joint].transform.parent = skelTransforms[joint];
                jointPhotonViews[joint].transform.localPosition = Vector3.zero;
                jointPhotonViews[joint].SetTargetTransform();
            } else {
                // ないなら破壊
                Destroy(jointPhotonViews[joint].gameObject);
            }
        }
    }
}

その他参考資料

2013/12/4現在、Photon公式のドキュメンテーションページが落ちてるようです。
公式ではないですが、こちらのスライドがPhotonの基本概念を理解するのに役立ちそうです。

まとめ&今後の展望


こうしてなんとかゲームジャム終了までに動作する形にまとめる事ができ、その後のデモやTwitterにおいても好評を得ることが出来ました。(一緒に開発した@sinkukkuさん、ありがとうございます。)

Mikulus Kinectで実装した「VR内でAIキャラの目を見る」という体験も不思議な感覚でしたが、「VR内でネットワーク越しに他の人間の目を見る」というのは、生身の人間がアバターキャラの中にいると知っているだけに、また更に違う体験に感じられます。これについては、また別の機会に書ければと思います。

ただ、粗はまだまだ多いですし、当初やってみたかった事もできていないことは沢山あるので、今後少しずつやっていきたいところです。今後考えているところとしては

  • 新規に入ってきた人の立ち位置や向きを重ならないようにずらす
  • その為にPhoton, Kinect (Zigfu), Oculusそれぞれで向いている方角を揃える
  • モーションキャプチャの動きを記録し、後から再生できるようにする
  • 人間が動かすキャラとAIが動かすキャラを混在させる
  • MecanimのIKを活用して肘関節などの位置・角度情報の共有を省き、通信量を減らす
  • 表情制御(HMDかぶってるのにどうやって…?w)
  • 公開する!

などなど。

長いエントリに最後までお付き合いいただき、ありがとうございます。再度になりますが、現在、第五回ニコニコ学会β 研究してみたマッドネスセッションの投票受付中です。投票は本日12/4 23:59までですので、もし良ければこちらのページから投票をよろしくお願いいたします!

Oculus Rift Advent Calendar、明日は@blkcatmanさんです。


  1. 余談ですが、各関節に使うPhotonViewState Synchronizationタイプは、「頻繁に位置が変わる」「送信失敗したデータを再送する必要はない」事から、Unreliable On Changeにしておくのが良さそうです。 

  2. Kinect v2ではキャプチャされる関節数が更に増えているはずです。 

  3. シテヤンヨとかゆっくりとかMogg式ミクとか… 

XREA+からValue Serverへ移行


このブログのホストをXREA+からValue Serverに移行しました。ちゃんと移行出来ている事のWordPressのチェックも兼ねてこのエントリを書いています。

ここの所は相変わらずOculus Rift三昧で、Mikulus Kinectなんてソフトを公開してみたりしていますが、それについては後程。Oculus Riftについての記述は主にTwitterに書いていますので、ひとまずそちらをご覧ください。

Oculus Riftの小ネタ色々


去年の夏にKickstarterで出資していたVRヘッドマウントディスプレイOculus Riftが先日届き、ここ最近はイタリアに行ったり中世に行ったり宇宙に行ったりとバーチャル旅行三昧です。没入感が凄い、というのは各所で言われている通りなので、ここでは他で書かれていない(主に所有者向けの)小ネタを書いておこうと思います。

入手

現在「Oculus Riftを日本でも発売」という記事がいくつかのニュースサイトで出ていますが、あれは別に公式の代理店というわけではなく、単なる輸入代行のようです。製造元のOculus VR社はOculus Riftを全世界に出荷できる体制を整えているので、日本の業者を通さなくとも、Oculus VR社に直接注文することでより安く入手が可能です。

Oculus Riftの接眼レンズは使用者の視力に応じて取り外し可能となっており、健常者及び遠視・軽度近視・強度近視用の3セットのレンズが付属してきます。取り外す際には埃の侵入を防ぐため開口部を下に向けるべきという指示がマニュアルにありますが、ぶっちゃけ下に向けても埃は入ります。レンズの拡大率が強烈なだけに埃は結構目立って困りますが、この場合、レンズを外した穴にエアダスターのノズルを差し込んで1,2吹きしてやると大抵埃が飛んで綺麗になります。

ACアダプタ

Oculus Rift Devkitに付属するACアダプタはDC5V、1500mA、センタープラス、プラグ外形5.5mm・内径2.1mmです。Riftの定格消費は1000mAのようですが、Hack a dayの記事曰く、実際の消費は600mA程度のようです(ただし明度・コントラストによって変動するかも)。純正アダプタを紛失した場合やスペアが必要な場合、これに当てはまるスペックのアダプタがあれば使えるはずです。秋葉原で買えるものとしては秋月電子の5V2Aアダプタ等でしょうか。勿論推奨はされていないので、何かする際は自己責任で。

追記するかも。

ニコニコ研究合宿「電脳メガネにはあと何が足りない?」


「ニコニコ研究会 様」先週末の日曜・月曜、またも夏休みを利用して、ニコニコ学会β主催の下つくばで開催された「ニコニコ研究合宿」に参加してきました。会議は「アンカンファレンス」形式で、白紙のタイムテーブルに各々が自分の話したい議題をポストイットに書いて貼り、その場でアドホックに会議が形成されるフォーマット。

「電脳メガネにはあと何が足りない?」セッション

研究とは・学会とは・ニコニコとはといった話が多い中、僕は空気を読まずにウェアラブルコンピュータについてのセッションをやってました…w

セッション内容は、最後のまとめセッションにおいてそれぞれ短く発表しあう形でした。自分のセッションのまとめを喋る際に「MOVERIOにカンペを表示しながら喋る」というのを思いついてその場でやってみたのですが、これが思いの外便利(後でタイムシフトを観直したら早口すぎましたが)。セッションで話し合った内容=すなわち目の前に見えてた内容は、だいたい以下の通りです。

  • 電脳メガネには何が足りない?
  • OSやUIが足りないと思うのだが
  • 視神経直結(表示は出来るが入力が出来ないとコンピュータにはならない)、脳波という話が出た一方で。
  • OSやUIを考えるにしても、機能やハードから考えるのでなく、ユースケースから考える。両手が空くとできること、例えば子供を抱きながら撮影できる、とか。
  • Googleのは操作よりは大量の主観映像の入手・分析にあるのではないか。
  • あと、今の発想は実際に使ってない人の発想が多い。ヘッドマウントカメラつけて1日過ごしただけでも知見が得られた。実際に使ってみるべき。
  • ATMのパスワードが録画されちゃう、携帯電話の画面が録画されちゃう。エッチなポスターに目を奪われてるのも録画されちゃう。

これを改行無しで読める大きさの文字にして詰め込んでMOVERIOの画面いっぱい埋まるくらい。即席で作ったにしてはまあまあでしょうか。

なお、より詳しいセッションのまとめも作ろうと思ったのですが、同じく合宿に参加された湯村さんのブログにて文句なしのまとめが書かれてしまったため、リンクしてお茶を濁します。w

カンペの作成手順

カンペの作り方としては以下のようなものでした。無理矢理。

  • カンペを出すのを思いつく
  • iPadで取ってたメモをコピーしてMOVERIOから見られる場所に出そう
  • MOVERIOは文字入力が極悪でログイン操作に時間がかかるので、ログインしないと見られない所には出したくない
  • 仕方ないので自分のブログに新規エントリとしてペースト、すぐ消す前提で公開
  • MOVERIOのブラウザで自分のブログにアクセス。勿論アドレス打つのも時間かかる
  • フォントサイズを大きめに変更、キーロックON
  • 発表
  • エントリを非表示にする

即席でこんな真似が出来るのもMOVERIOだからこそです。カンペ表示専用のアプリやサービスがあればもっとスムーズに出来るはず。…こういうアプリをワンオフで実装してみるのは現状のAndroidでも出来るけど、それに適したOSか、せめて再利用できるUIツールキットくらいはやっぱり必要だよなー。

なお、アンカンファレンスの他に夜の懇親会や、JAXAなどの近隣の施設への見学も、意外な表の話・裏話を色々見たり聞いたり議論したり出来て、非常に有意義でした。もしまたあったら是非参加したいですね。

気象衛星ひまわり(実物)

電脳メガネサミットとMGOS


先週末の8月4日、福井県鯖江市で開催された「さばえIT推進フォーラム “電脳メガネサミット 〜近未来のメガネを語る〜”」に夏休みを使って行ってきました。

電脳メガネサミット

鯖江市は日本のメガネの殆どを生産するメガネの街として知られています。このイベントは現在開発が進んでいる「頭に付けるコンピュータ」、いわゆる「電脳メガネ」の現在と未来を語るという趣旨のシンポジウムでした。普及しつつあるデバイスどころか、まだカテゴリが立ち上がってすらいないものを取り上げるという、市が主催するイベントとしてはちょっと類を見ないほど先進的な題材だと思いますw。

ゲストも、「電脳メガネ」という名前やメガネ型コンピュータの概念を一躍有名にしたアニメ「電脳コイル」のプロデューサーや、エプソンMOVERIOの開発担当者さんなど架空・現実の電脳メガネにまつわる面々、また電脳メガネのアプリケーションアイデアコンテスト参加者らによる聞き応え十分な話が聞けて、はるばる行ったかいがありました。また、ゲストのみならず来場者も、懇親会で話した場ではかなり濃い面々が揃っていて、文字通り時間を忘れて話しこむほどでした。

と、全体的にとても面白いイベントだったのですが、話が展開していく中であれっ?と思った点もありました。それを抱えて会場ホールから出てきた際、地元のテレビ局に感想を求められたのですが、その場で考えをまとめきる事ができず結局コメントは辞退してしまいました。

その後、他の方の感想ツイートなども読みながらもう少し考えてみましたが、何に違和感を感じたのかまとめておこうと思います。

電脳メガネ=ハードウェアの問題?

MOVERIOのロック画面具体的には、電脳メガネ実現への課題が「通常の眼鏡は数十g程度だが、電脳メガネはまだ数百gと重い」「大きくて不恰好」など、ハードウェアの話に終始していたように感じられました。

それらハードの問題はもちろんそれぞれ重要な課題で、まさに鯖江の眼鏡に関する技術や職人芸の腕の見せ所です。しかし、電脳メガネにとって最大の問題はむしろソフトウェアやユーザインタフェース(UI)・ユーザ体験(UX)、そしてOSなのでは?と思い、それについて質問してはみましたが、「それもあるね」程度の扱いで、あまり突っ込んだ話は聞けませんでした。

アイデアコンテストに寄せられたアイデアは面白そうで、聞いていてワクワクするようなものが沢山ありました。ただ、それらを実験デバイスではなく常用できる製品として実際に実装し、更には単発の製品ではなく生態系の一要素として展開・普及させられるためには、まずそのアイデアを実装できるためのプラットフォームが存在することが前提です。

その為には、まずは現行のスマートフォンでやれている行動を満足にメガネでも出来るように、ユーザ側に向けてはハード・ソフトの統合的なUXを、開発者側に向けてはSDK/APIの設計を整備する方が先決だと思うのです。それにはUXのハードウェア面を実現するための物理的なものづくりの技術も必要ですが、UXのソフトウェア面や、開発者向けの環境を実現するための全く異なった技能もまた非常に重要になってきます。

MGOSを作る

Google Project Glass UIモックアップ過去、人とコンピュータのインタラクションのパラダイムが変わった際には、その新しいパラダイムを最初から前提とした新しいOSが産まれ、そのOSを核とした生態系が発生する事がありました。

「ウィンドウ・アイコン・メニュー・ポインタ」ベースのGUIが登場した際にはMac OSとWindows、モバイルタッチスクリーンUIの際にはiOSやAndroidが、それぞれ新たに普及したOSとして登場してきました。同様に、ヘッズアップディスプレイ(HUD)やARといったパラダイムが受け入れられるためには、HUDやARを活用する事をはじめから前提としたUI/UXを持つ新しいOSを作らなければならないのではないでしょうか。

実際、近未来で展開する「電脳コイル」の劇中登場人物たちのメガネ上で動いていたのはWindowsでもAndroidでもなく、架空のメガネ用OS「MGOS」でした。劇中の電脳メガネのハードウェアとしての祖先となるようなデバイスは現在徐々に登場しつつありますが、MGOSの祖先となるようなOSについては、少なくともあまり聞いたことがありません。

このOS(あるいはそれに値するソフトウェア基盤)をどうやって作るか?どのようなものを作るか?といった議論があまりされていなかったという点が、おそらく感じた違和感の核なのだろうと思います。UI/UX基盤を作る、OSを作る、果ては生態系を作るということは、電脳メガネのハードウェアを作るのにも匹敵する壮大なプロジェクトで、一昼夜でできることでは無いだけに余計に。

メガネの時代をもたらすのは誰になるのか

個人的には、電脳メガネをはじめとしたウェアラブルコンピュータの時代の到来はそう遠くないと思っています。ですが、それをもたらすのが誰になるのか、というのは分かりません。
正確な文を覚えていないのですが、電脳メガネサミットの中では「日本発の電脳メガネを」といった趣旨の発言がありました。また、鯖江市長さんのブログエントリには、以下のようにあります。

微細な情報機器をめがねに組み込める技術力、優れた掛け心地を実現するノウハウを持つ産地は、世界で唯一ここ鯖江にしかありません。

世界に先駆けて「めがねの電脳化」に産地をあげて取り組むことは、「産地再生の一つの鍵」になります。

この記述だけを読むと、ソフトウェア・UI・OSといった部分が言及されていないようにも受け取れてしまうのですが、杞憂であることを祈っています。

勿論、自分でそれを作る試みに取り組んでもいない癖に偉そうに、と言われるとぐうの音も出ないのですが…orz

ひとまずは出来ることから、手持ちのMOVERIOで色々実験してみようかな、と調べているところです。

オヤジとデンスケ