Android向けUnityアプリケーションのクラウド化

修 士 論 文 の 和 文 要 旨 研究科・専攻 大学院 情報理工学研究科 情報・通信工学専攻 博士前期課程 氏 名 高橋 悠 学籍番号 1331060 論 文 題 目 Android 向け Unity アプリケーションのクラウド化 要 旨 本研究では，ゲーム開発エンジンであるUnity3D をクラウド化するシステムを開発し，スマー トフォンやタブレットなどのモバイル端末用のゲームアプリケーションを快適に動作させること を目的とする．Unity Mobile Streaming と名付けたこのクラウド化システムは，Unity で作成さ れたゲームをサーバとクライアントに処理を分け，Android クライアントからの入力を受けてサ ーバ上で演算処理を実行し，その結果を映像として返すことでクラウド化を実現する． スマートフォンやタブレットといった多機能型モバイル端末の普及が急速に進んでおり，同時 にそれらのモバイル端末でゲームを遊ぶユーザも増えている．また，ゲーム開発環境の整備も進 んでおり，特にゲームエンジンおよび統合開発環境であるUnity3D は，「マルチプラットフォー ムに対応している」，「直感的な編集操作が可能である」，「簡単に物理演算が使える」といった利 点から，企業・個人を問わず多くの開発者に支持されている．一方で，モバイル端末 OS として 最もシェアを持つAndroid には，製品によって処理性能に大きな差があり，Unity の特徴である 3D グラフィックや物理演算が活かしきれない事が多い．そこで，Unity Mobile Streaming によ ってクラウドゲーム化することにより AndroidOS 搭載端末の問題による影響を軽減し，ゲーム 開発者はより自由に開発が行えるように，ゲーム利用者はより高品質なゲームを楽しめるように なることを目指す．

Unity Mobile Streaming の性能について，Unity で開発したアプリケーションを Android 端 末単独で実行した場合とUnity Mobile Streaming を通して実行した場合で比較し，実用性の評 価を行った．アプリケーションの実行速度については多粒子の剛体衝突シミュレーションによっ て性能評価を行ったところ，1024 粒子までは通信による遅延時間の影響が大きかったが，2048 粒子では1.28 倍，4096 粒子では 2.8 倍高速に実行できることが示せた．また，通信による遅延 時間による影響については，現状では270 ミリ秒と大きく，快適にゲームがプレイできるとは言 いがたい．しかし，通信遅延を肥大化させている原因は開発環境の制約によるところが大きく， その制約を受けないWindows8.1 端末で実験したところ，140 ミリ秒まで削減することが出来た． すなわち，本システムによって，厳密なリアルタイム性の必要ないゲームジャンルであれば，十 分快適にプレイ出来る性能が出ていると言える．

平成

26

年度修士研究論文

Android

向け

Unity

アプリケーション

のクラウド化

電気通信大学 情報理工学研究科

情報・通信工学専攻

コンピュータサイエンスコース

1331060

高橋悠

指導教員 成見 哲 教授

副指導教員 沼尾 雅之 教授

平成

27

年

1

月

30

日

概要

本研究では，ゲーム開発エンジンである Unity3D をクラウド化するシステムを開 発し，スマートフォンやタブレットなどのモバイル端末用のゲームアプリケーショ ンを快適に動作させることを目的とする．Unity Mobile Streaming と名付けたこの クラウド化システムは，Unity で作成されたゲームをサーバとクライアントに処理を 分け，Android クライアントからの入力を受けてサーバ上で演算処理を実行し，そ の結果を映像として返すことでクラウド化を実現する． スマートフォンやタブレットといった多機能型モバイル端末の普及が急速に進ん でおり，同時にそれらのモバイル端末でゲームを遊ぶユーザも増えている．また， ゲーム開発環境の整備も進んでおり，特にゲームエンジンおよび統合開発環境であ る Unity3D は，「マルチプラットフォームに対応している」，「直感的な編集操作が可 能である」，「簡単に物理演算が使える」といった利点から，企業・個人を問わず多 くの開発者に支持されている．一方で，モバイル端末 OS として最もシェアを持つ Android には，製品によって処理性能に大きな差があり，Unity の特徴である 3D グ ラフィックや物理演算が活かしきれない事が多い．そこで，Unity Mobile Streaming によってクラウドゲーム化することにより AndroidOS 搭載端末の問題による影響を 軽減し，ゲーム開発者はより自由に開発が行えるように，ゲーム利用者はより高品 質なゲームを楽しめるようになることを目指す．

Unity Mobile Streaming の性能について，Unity で開発したアプリケーションを Android 端末単独で実行した場合と Unity Mobile Streaming を通して実行した場合 で比較し，実用性の評価を行った．アプリケーションの実行速度については多粒子の 剛体衝突シミュレーションによって性能評価を行ったところ，1024 粒子までは通信 による遅延時間の影響が大きかったが，2048 粒子では 1.28 倍，4096 粒子では 2.8 倍 高速に実行できることが示せた．また，通信による遅延時間による影響については， 現状では 270 ミリ秒と大きく，快適にゲームがプレイできるとは言いがたい．しか し，通信遅延を肥大化させている原因は開発環境の制約によるところが大きく，そ の制約を受けない Windows8.1 端末で実験したところ，140 ミリ秒まで削減すること が出来た．すなわち，本システムによって，厳密なリアルタイム性の必要ないゲー ムジャンルであれば，十分快適にプレイ出来る性能が出ていると言える．

目 次

第 1 章 はじめに 5 1.1 背景 . . . . 5 1.2 目的 . . . . 7 1.3 本論文の構成 . . . . 8 第 2 章 既存技術 9 2.1 シンクライアント . . . . 9 2.1.1 画面転送によるモバイルシンクライアントの一検討 . . . . 9 2.1.2 本研究の差異 . . . . 9 2.2 クラウドゲーミング . . . 10 2.2.1 NVIDIA GRID . . . 10 2.2.2 PlayStation Now . . . 11 2.2.3 本研究の差異 . . . 11 2.3 アプリストリーミング . . . 12 2.3.1 Amazon AppStream . . . 12 2.3.2 本研究の差異 . . . 13 第 3 章 Unity 14 3.1 概要 . . . 14 3.2 Unity の利用技術 . . . 14 3.2.1 レンダリング . . . 14 3.2.2 物理演算 . . . 14 3.2.3 スクリプティング . . . 15 3.3 用語の解説 . . . 15 3.4 ゲーム開発の流れ . . . 16 第 4 章 システムの概要 23 4.1 Unity Mobile Streaming . . . 23

4.2 システム全体の構成 . . . 23 4.2.1 サーバ側アプリケーション . . . 24 4.2.2 クライアント側アプリケーション . . . 30 4.3 システムのサポートする範囲 . . . 34 第 5 章 システムの評価 36 5.1 動作確認環境 . . . 36

5.2 性能評価 . . . 37 5.2.1 画面出力の際に発生する遅延 . . . 37 5.2.2 操作入力の際に発生する遅延 . . . 40 5.2.3 アプリケーション実行速度の比較 . . . 43 5.2.4 描画フレームレートと転送速度 . . . 44 5.3 実用性の考察 . . . 46 5.3.1 実行速度 . . . 46 5.3.2 遅延時間 . . . 47 第 6 章 まとめ 49 6.1 本論文のまとめ . . . 49 6.2 今後の課題と展望 . . . 49 6.2.1 入出力の同期 . . . 49 6.2.2 遅延時間の削減 . . . 50 6.2.3 音声出力への対応 . . . 50 6.2.4 GUI 入力への対応 . . . 50 6.2.5 Android 以外のモバイル OS 版クライアントアプリ . . . 50 6.2.6 ライセンスによる制限 . . . 50

第

1

章 はじめに

1.1

背景

近年，多機能型携帯電話スマートフォンやタブレット端末の普及が急速に進んで いる（図 1.1）．総務省による平成 26 年版情報通信白書の報告によると，平成 25 年で のスマートフォン世帯保有率は 62.6 ％，タブレット端末世帯保有率は 21.9 ％となっ ている [1]．スマートフォンやタブレットといった多機能型端末では，電話や E メー ル，ショートメッセージなどの情報通信端末としての用途に限らず，オーディオプレ イヤーや web ブラウジング，ゲームアプリケーションといった娯楽目的で利用する 場面も増えている．特にゲーム分野に関しては，以前のように専用のゲーム機器を 用意しなくても遊べるようになった事で，今までゲームに興味のなかったユーザも 手軽に遊ぶようになったため，著しい成長が見られる．CyberZ 社の調査によると， 2013 年の東アジアのスマートフォンゲーム市場は 9168 億円で，これは前年比 191.3 ％と急速に拡大しており，2017 年には 2 兆円規模まで成長すると予測している [2]． また，スマートフォンやタブレット端末の普及やゲームユーザの増加にともない， ゲームアプリケーションの開発環境の整備も進んでおり，個人開発者によるゲー ムの開発も活発になっている．特に，ゲームエンジンおよび統合開発環境である Unity3D[3]（以下 Unity）は，GUI による直感的な編集操作や簡単に物理演算が利用 できるといった特徴から，企業・個人問わず多くの開発者から好まれている．Unity は，個人開発者であれば殆どの機能を無料で使えるうえ，公式のアセットストアで ゲーム開発のための様々な素材をユーザ同士で配布・販売することが出来るため，手 軽に高品質なゲームを開発できる事からも高い注目を浴びている． 一方で，スマートフォンやタブレット端末の OS としては Android が最もシェア が多い（図 1.2）が，AndroidOS を搭載している端末にはゲームを遊ぶユーザ視点 としても，ゲームを作る開発者視点としてもいくつかの問題がある．AndroidOS を 搭載している端末は，製品によって性能や画面解像度に大きく差がある．また，モ バイル製品全体の性能としても，急速に高性能化しているとはいえ，特にゲームア プリにおいて重要となるグラフィック性能などは，まだ一般的なコンピュータには 及ばない．そのため，発売から時間が経ち型落ちモデルとなった製品や廉価版の低 性能端末を持っているユーザは最新のゲームアプリが快適に動かせないという問題 が多く見受けられる．逆に，ゲーム開発者からすると様々な解像度にアプリを対応 させるには手間がかかり，多くの人に遊んでもらおうと思うと低性能な端末でも動 くように作る必要が出てくるため，表現の幅に制限がかかってしまう．前述の Unity は 3D グラフィックスや物理演算が手軽に使える事が大きな利点の一つであるが，ど のような Android 端末でも動くゲームアプリを作ろうと思うと，これらの利点が活

図 1.1: 主な情報通信機器の世帯普及状況（参考文献 [1] の図 5-3-1-1）

かしきれなくなってしまうという問題がある．

1.2

目的

本研究では，Unity で開発された Android 向けゲームアプリケーションをクラウド ゲーム化するシステムを開発することを目的とする．このシステムによって，ユーザ が端末性能に左右されずに高品質なゲームアプリケーションを楽しめるように，か つ個人開発者がより手軽に Unity で Android 向けゲームアプリケーションを開発で きるようになることを目指す． 開発するシステムでは，ゲームアプリケーションは高性能なサーバ上で実行する． そのサーバに接続したクライアントとなる端末では，ユーザによる操作入力を検知 してサーバに送信，およびサーバ上のゲーム実行の結果となる画面情報を受信し端 末画面に描画を行う．これにより，見かけ上はその端末でゲームアプリケーションが 動作しているように見えるが，実際は高性能なサーバで実行することによって，端 末の性能差による影響を下げる事が期待できる．

1.3

本論文の構成

本論文の構成は以下のようになっている． • 1 章 はじめに 本研究の背景，目的を述べる． • 2 章 既存技術 クラウドゲーミングやアプリケーションストリーミングを実現する既存の技術 を紹介し，本研究との差異を挙げる． • 3 章  Unity 本研究にて利用するゲームエンジンである Unity について説明する． • 4 章 システムの概要 本研究で開発したシステムの概要を述べる． • 5 章 システムの評価 本研究で開発したシステムの動作確認・性能評価を行う． • 6 章 まとめ 本研究において得られた結果や今後の課題，展望について述べる．

第

2

章 既存技術

本章では，本研究の目的であるアプリケーションのスマートフォン向けクラウド 実行を実現する既存の技術について紹介する．また，その既存技術と本研究の差異 を挙げ新規性を主張する．

2.1

シンクライアント

シンクライアントとは，ユーザの使うクライアント端末は最低限の処理のみを行 い，ソフトウェアの処理はサーバ側に集中させるという構造およびそのクライアン ト端末そのものの事を指す [5]．シンクライアントは「薄い（thin）クライアント」 の意味であり，一般的にはアプリケーション単位ではなく OS レベルで処理をサー バに任せ，クライアントは完全に入出力のみを扱う事が多い．セキュリティ上の利 点などから，企業の社内情報システムなどで利用されている．

2.1.1

画面転送によるモバイルシンクライアントの一検討

水野らは，Android 端末をクライアントとするモバイルシンクライアントシステ ム（図 2.1）の検討と評価を行った [6]．モバイル端末のシンクライアント化により， 個人データ保護やコンテンツ保護といったセキュリティ強化，モバイル端末の形式 や性能の制限を超えたサービスの提供などが期待されるとしている．このシステム では，シンクライアントサーバ上で仮想 Android を実行させ，シンクライアント化 した Android 端末からネットワークを通じてサーバ上の仮想 Android を操作する． 仮想 Android によって生成された画面を画面転送エンコーダによって圧縮しクライ アントへ送信，クライアントはこれを受信してデコーダによって復号，画面表示を 行う．画面転送コーデックには独自形式の物を用いており，JPEG と同等以上の画 質と，JPEG に比べ 1.7 倍のエンコード速度，1.3 倍のデコード速度を実現している． この性能によって，テキストメール，web 閲覧，メニュー操作といったアプリケー ションにおいて問題のない性能であることを示している．ただし YouTube の再生に おいてはフレームレートの低下が見られたとしている．

2.1.2

本研究の差異

水野らのモバイルシンクライアントは，一般的なシンクライアントと同じく，An-droidOS 全体を仮想化している．そのため，クライアント端末単体でも十分な実行

図 2.1: モバイルシンクライアントシステム（参考文献 [6] の図 1） 速度が得られるような操作である web ブラウジングやメールといった処理において は，通信遅延によるデメリットが目立ってしまう．また，シンクライアントサーバ は OS 全体を仮想化する大型のシステムとなっている点や，クライアントの利用者 も全ての情報が一元管理される点などから，モバイルシンクライアントは企業シス テム向けであると言える． 本研究では，スマートフォンなどのモバイル端末では処理できないような負荷の 高いゲームアプリケーションのみに焦点を当てる．すなわち，アプリケーション単 位でクラウド化を行うことで，モバイル端末のみでも簡単に処理できるアプリケー ションは通常通り実行できるようにする．また，サーバ運用，クライアントユーザ としての利用ともに個人の開発者やユーザが手軽に利用できるシステムを目指す．

2.2

クラウドゲーミング

クラウドゲーミングは，クラウド上でゲームアプリケーションを実行し，クライ アントへストリーミング配信するサービスである．ゲームの処理はクラウド上で行 われるため，クライアント端末の性能に依存しない．そのため，従来のようにゲー ム専用機を用いずとも，PC やスマートテレビ，スマートフォンといった端末で高品 質なゲームを楽しめるとして注目を集めている．

2.2.1

NVIDIA GRID

NVIDIA GRID[7] は NVIDIA が提供するゲーム，仮想デスクトップ，クラウドア プリケーション向けの GPU アクセラレーションである．NVIDIA GRID GPU を搭 載したサーバをクラウドとして稼働することで，高品質なクラウドゲーミングサー

表 2.1: NVIDIA GRID ボード

製品名 GRID K340 GRID K520

対象市場 高デンシティのゲーミング 高パフォーマンスのゲーミング

同時ユーザ数 1 4∼24 2∼16

ドライバのサポート GRID Gaming GRID Gaming

合計 GPU 数 4 GK107 GPUs 2 GK104 GPUs

NVIDIA CUDA    合計コア数 1536 (384/GPU) 3072 (1536/GPU) クロック周波数 950 MHz 800 MHz メモリサイズ 4 GB GDDR5 (1 GB/GPU) 8 GB GDDR5 (4 GB/GPU) 最大電力 225 W 225 W 補助電源 8 本ピン パワーコネクター 8 本ピン パワーコネクター ボードの幅 デュアルスロット ATX デュアルスロット ATX ボードの長さ 10.5 ” 10.5 ” ボードの高さ 4.4 ” 4.4 ” 冷却ソリューション パッシブ パッシブ

PCI-E x16 Gen3 (Gen2 と互換性) x16 Gen3 (Gen2 と互換性)

ビスを提供出来るとしてる．NVIDIA GRID GPU ボードの性能は表 2.1 の通りであ る．実際に NVIDIA GRID を導入しクラウドゲーミングを提供しているサービスと しては，G-cluster[8] などがある．

2.2.2

PlayStation Now

PlayStation Now[9] は Sony Computer Entertainment の発表したゲームストリー ミングサービスである．このサービスでは同社の PlayStation3 向けゲームソフトウェ アをダウンロードすること無くストリーミング配信によって遊ぶことが出来る．ク ライアントとなる端末は，PlayStation3，PlayStation4 は当然のこと，クライアン ト側の処理能力は必要ないため，PlayStation Vita や SONY 製のテレビなども利用 することが出来る．また，今後 Blu-ray プレイヤーなども対応する予定である．

2.2.3

本研究の差異

本研究で開発するシステムもクラウドゲーミングの一環であると言える．しかし， 既存のクラウドゲーミングサービスは商業サービスとして展開されているもので， 個人で開発したゲームなどを手軽に配信できるようなサービスは無い．そのため， 本研究では個人開発者が自作のゲームアプリケーションをクラウド化し配信出来る ようにするシステムを開発する．

図 2.2: Amazon AppStream のワークフロー（参考文献 [11]）

2.3

アプリストリーミング

ゲームアプリケーションに限らず，様々なアプリケーションをクラウド上で実行 し，PC やスマートフォン，タブレットといった端末へストリーミング配信を行う サービス．3D レンダリングなど高い処理能力を求められるようなアプリケーション で利用される事が多い．

2.3.1

Amazon AppStream

Amazon AppStream[10] は Amazon Web Services が提供する，アプリケーション のストリーミングサービスである．Amazon AppStream を利用したい開発者は，専 用の開発キット（Amazon AppStream SDK）を用いてアプリケーションを開発する． また，アプリケーションはサーバ側とクライアント側の両サイドを開発する必要が ある．開発したアプリケーションは，Amazon AppStream に登録することによって， Amazon Web Services のクラウド上で実行されるようになる．アプリケーションを 利用したいユーザは，そのアプリケーションの対応する専用クライアントアプリケー ションを端末に導入することによって，ストリーミング配信を利用できる．アプリ ケーションが実行される際の全体の流れは図 2.2 のようになる．

2.3.2

本研究の差異

Amazon AppStream では個人開発者でも自作のアプリケーションをスマートフォ ン向けにストリーミング配信することが可能である．しかし，Amazon AppStream 用のアプリケーションを開発するためには専用の SDK を用いて開発する必要があ り，Unity を用いてのアプリケーション開発には対応していない．また，各アプリ ケーションごとにクライアントアプリは対応する専用のものを用いる必要があるた め，開発者はサーバ・クライアント双方のアプリケーションを開発する必要があり， 利用者も逐一専用クライアントアプリを自身の端末に導入する必要がある． 本研究では，スマートフォン向けゲーム開発に広く活用されている Unity で開発 されたアプリケーションをクラウド化出来るようにする．また，本研究で開発する システムでは専用のクライアントアプリが一つあれば，開発システムに対応する全 てのクラウドゲームを遊ぶ事ができるため，開発者はサーバ・クライアントといっ た通信を考えること無くゲーム開発することができ，利用者も 1 つのアプリを導入 するだけで様々なゲームを遊ぶことができるようにする．

第

3

章

Unity

本章では，本研究で開発したシステムの動作基盤となるゲームエンジンおよび統 合開発環境である Unity について説明する．

3.1

概要

Unity とは Unity Technologies 社が開発・提供するゲームエンジンおよび統合開発 環境である．Unity はマルチプラットフォームのゲーム開発が可能であり，開発した ゲームは Windows，MacOS X，Linux，iOS，Android，WindowsPhone，Windows ストアアプリ，ウェブブラウザプラグイン，Flash やコンシューマゲーム機など非常 に多くのプラットフォーム向けにビルド可能である．また，物理演算エンジンを内 蔵しており，物理演算が簡単に利用可能であるという特徴もある． Unity を利用するにはライセンスが必要となるが，無償ライセンスでも多くの機 能を利用することができ，個人であれば開発したゲームの営利目的での配布，販売 も可能である．企業が商用目的で利用する場合や，より高品質なゲーム開発のため に全ての機能を利用したい場合は，有償の Unity Pro ライセンスを購入する必要が ある．

3.2

Unity

の利用技術

3.2.1

レンダリング

Unity のグラフィックのレンダリングエンジンには，Windows 環境では Direct3D と OpenGL，その他 PC・コンシューマ機環境では OpenGL，スマートフォン環境 では OpenGL ES を利用している．通常，レンダリングは Unity のレンダリングパ イプラインを用いて描画し，Unity が各プラットフォームに合わせて自動的に最適 化を行うが，必要であれば OpenGL などの低レベル API を直接利用して自分で描画 することも可能である．

3.2.2

物理演算

物理演算エンジンには NVIDIA 社の PhysX[12] が採用されている．ゲーム内のオ ブジェクトに，大きさや質量，摩擦係数など，剛体としてのパラメータを設定するこ とによって，プログラミング不要で物理演算を利用することができる．また，剛体

に限らず，布や液体，回転するタイヤやバネなどの挙動も用意されているコンポー ネントを利用することで実現できる．

3.2.3

スクリプティング

Unity 内のスクリプトはオープンソースのプラットフォームである Mono[13] の上 で実行される．Mono は.NET フレームワークに基づく，クロスプラットフォームア プリケーションを構築するための仮想環境である．Unity では C ♯，JavaScript，Boo のいずれかの言語を用いてスクリプトを記述出来るが，これらのスクリプトは Mono 環境上で実行されるため，.NET フレームワークを利用することが可能で，どのプ ラットフォームであっても一つのソースプログラムから同様に実行できる．

3.3

用語の解説

本節では Unity で使われている用語のうち，本論文を読むにあたって必要になる ものについて簡単に説明する． • GameObject Unity のゲーム内で扱われるあらゆるオブジェクト．ゲーム内空間に配置され ているあらゆる物体，ライティングを行う光源，ゲーム画面を写すカメラ，実 体を持たない空のオブジェクトなど，様々なものが GameObject として扱われ る．GameObject は複数のコンポーネントから構成されており，このコンポー ネントの組み合わせによってそのオブジェクトの役割が変化する． • プレハブ GameObject の設計図にあたるファイル．任意の GameObject をプレハブ化す る事ができる．プレハブはその元となった GameObject と同じコンポーネン ト，パラメータを持っており，プレハブから GameObject を生成することで， 全く同じ属性を持った GameObject を生成できる．例えば，プレイヤーキャラ クターが弾を発射する時，その弾のプレハブを用意しておき，ゲーム中で実際 に弾が発射される度にプレハブから GameObject を生成する，といった使い方 が出来る． • アセット ゲーム中で使うあらゆる素材のことを指す．3D モデル，テクスチャ，アニメー ション，サウンド，スクリプト，フォント，プレハブなどゲームを構成する素材． • Unity パッケージ 複数のアセットを一つのパッケージとしてまとめてエクスポート，またはイン ポートすることが出来る．Unity 用の素材は大抵の場合，この Unity パッケー ジ形式で配布される．

図 3.1: Unity のエディタ画面 • UnityEngine スクリプトから参照できる Unity のゲームエンジンに関するライブラリ．Unity スクリプトにおける標準ライブラリと言える．様々な API を提供している． • Input クラス UnityEngine に含まれるクラスの 1 つ．プレイヤーの入力を取得するためのプ ロパティ，メソッドが含まれている． • グラフィッククオリティ グラフィックに関するクオリティ設定をいくつかのレベルについて事前に設定 できる．実際にビルドされたアプリケーションを実行する際に，プレイヤーは グラフィッククオリティを選択できる．標準では，速度重視低画質なレベルか ら順に，Fastest，Fast，Simple，Good，Beautiful，Fantastic がプリセットさ れている．

3.4

ゲーム開発の流れ

Unity のゲーム開発は主に GUI 上のエディタ操作によって行われ（図 3.1），簡単 なゲーム開発であれば難しいプログラミングも必要ない．ここでは，Unity でゲー ム開発を行う際の流れを簡単に説明する． • GameObject をシーンに追加する Unity ではゲーム内にある全てのオブジェクト（物体，カメラ，光源など）は GameObject として管理されている．これらの GameObject をゲームのシーン

（ゲーム内の仮想的な空間）に追加していくことで，現在のシーンの状態を定義 していく．球体や立方体，円柱形などのプリミティブな形の物体や，オブジェク トとしての実体を持たない空の GameObject などは，メニューの GameObject から生成・追加できる．現在のシーンに追加されている GameObject は，エ ディタの Hierarchy タブ（図 3.2）で確認することが出来る． • GameObject を配置する GameObject が実体を持つオブジェクト（地形や障害物，プレイヤーキャラク ター，敵キャラクター，アイテムなど）の場合は，その GameObject の配置 する位置を決める必要がある．その際，座標を数値で指定することもできる が，Scene タブで実際に現在のシーンの様子を視覚的にプレビューしながら， ドラッグアンドドロップによってオブジェクトを移動させることができる（図 3.3）． • スクリプトを記述する スクリプトによる制御が必要であれば，スクリプトを記述する．プレイヤーの 操作入力の受付や，物理的な要因以外によるオブジェクトの挙動の変化などに 利用する．基本的にスクリプトは GameObject に紐付いて実行される．Start() メソッドに記述した内容は，その GameObject が読み込まれた際に実行され， Update() メソッドに記述した内容はその GameObject が存在している間毎フ レーム実行される．下記例では，このスクリプトが追加された GameObject は 毎フレーム Y 軸に対して 5 度回転するようになる．   using UnityEngine; using System.Collections;

public class ItemObject : MonoBehaviour { void Start () { } void Update () { transform.Rotate(0,5,0,Space.World); } }   • GameObject にコンポーネントを追加する GameObject に様々なコンポーネントを追加することでそのオブジェクトの挙 動を変更することが出来る．コンポーネントの追加は Inspector タブで行う（図 3.4）．前述のスクリプトもコンポーネントの一つである．他にも代表的なも ので，GameObject の位置，向き，大きさを表す Tranform，物理的な当たり 判定の大きさを表す Collider，レンダリングの設定を表す Renderer，物理的な 剛体のパラメータを表す Rigidbody などのコンポーネントがある． • デモ実行することでデバッグを行う

図 3.2: Hierarchy タブ エディタ上部の再生ボタンを押すことで，その場で現在のシーンをデモ実行す ることが出来る．この時，Game タブで実際にゲーム中のカメラの映像を確認 できる（図 3.5）．同時に，Scene タブではゲーム実行中の様子をエディタカメ ラから自由な角度で確認することも出来る．これにより，実際のゲーム中での 動作をビルドすること無く確かめながら開発を進められる． • アセットを入手する アセットは自分で作成するほか，アセットストア（図 3.6）を通じて入手する 事ができる．アセットストアには世界中の Unity 開発者によって作られた様々 なアセット（テクスチャ，3D モデル，スクリプトなど）が無料または有料で 配布・販売されている．これらを活用することで，例えばテクスチャを自作出 来ない開発者であっても，高品質なグラフィックのゲームを開発することが出 来る．現在の Unity プロジェクトに追加されているアセットは Project タブで 管理する事ができる（図 3.7）．

図 3.5: Game タブ

第

4

章 システムの概要

本章では，開発したシステムの概要や，想定する利用方法について説明する．

4.1

Unity Mobile Streaming

本研究で開発したシステムを「Unity Mobile Streaming」と呼称する．Unity Mobile Streaming は Unity を用いて開発された Android 向けゲームアプリケーションをク ラウド化するためのシステムである．通常は Android 端末内にて実行されるアプリ ケーションを，アプリケーションの処理を行うサーバサイド，端末の入出力を行うク ライアントサイドに分けることで，アプリケーションの処理自体は端末側のスペッ クによる影響を受けなくする．よって，クライアント側となる Android 端末よりも 十分に高性能なコンピュータをサーバとして利用することによって，ゲームアプリ ケーションがスクリプト処理や物理演算，レンダリングといった点で比較的高い処 理性能を求める内容であったとしても，Android 端末はクライアントアプリケーショ ンの動作要件を満たすスペックさえあれば，ユーザがゲームアプリケーションを快 適に遊べるように出来る．

4.2

システム全体の構成

Unity Mobile Streaming のシステム構成図を図 4.1 に示す．Unity Mobile Streaming はサーバ・クライアント型のシステムである．サーバとクライアント間の通信は IP によるソケット通信を用いて行う．クライアントとなる Android 端末，すなわちユー ザの利用する端末には，Unity Mobile Streaming の専用クライアントアプリを導入 する．クライアントアプリはタッチ情報やセンサ情報といったゲームの操作に必要 となる入力情報を端末から取得し，接続しているサーバへ送信する．サーバ側は送 信された入力情報を元にゲームアプリケーションを動作させる．また，実行してい るゲームアプリケーションの画面を定期的に画像としてキャプチャしクライアント に送信する．クライアントアプリは送信されてきた画像を端末のディスプレイに出 力することで，ユーザは自分の操作しているゲームの画面を確認できるようになっ ている．

図 4.1: Unity Mobile Streaming のシステム構成図

 

・スクリプト

namespace MobileStreaming

├ public class MobileStreamingManager : MonoBehavior ├ public static class Input

├ public static class ScreenCapture ├ public class Gyroscope

└ public struct Touch ・プレハブ

UnityMobileStreaming

 

図 4.2: Unity Mobile Streaming プラグインの構成

4.2.1

サーバ側アプリケーション

ゲーム開発者は開発したゲームの Unity プロジェクトに Unity Mobile Streaming プラグインを導入することによって，そのアプリケーションをサーバ化する事がで きる．Unity Mobile Streaming 用サーバアプリケーションとなったプロジェクトは サーバの OS に合わせて Unity のスタンドアローンプログラムとしてビルドする．

Unity Mobile Streaming プラグインの構成

Unity Mobile Streaming プラグインの構成は図 4.2 のようになる．C ♯言語による スクリプト群と一つのプレハブから構成されている．名前空間 MobileStreaming 内 に必要なクラス，構造体がまとめてある．各クラスの主な公開メンバ，公開メソッ ドと動作を以下に示す．

• public class MobileStreamingManager : MonoBehavior 公開メンバ int controllerPort 操作入力のためのポート int imageviewPort 映像出力のためのポート bool viewNetworkSpeed 通信速度の表示 各種クラスの管理を行うマネージャクラス．シングルトンモデルに基いて実 装されており，常に 1 つのインスタンスしか生成されない．このスクリプトを ゲーム内の適当な空オブジェクトに適用することで，サーバ化を行う各クラス が実行されるようになる．このスクリプトが適用されたオブジェクトはシーン の読み込みの際に破棄されなくなる．

• public static class Input 公開メンバ Vector3 acceleration 加速度センサ値 DeviceOrientation deviceOrientation 端末の画面の向き Gyroscope gyro ジャイロスコープの値 int touchCount タッチ数 Touch[] touches 全てのタッチ情報 公開メソッド void Start() 通信を開始する

bool SetPort(int port) ポート番号を設定する

void Stop() 通信を終了する Touch GetTouch(int i) i 番目のタッチ情報を返す クライアントからの入力情報を扱うクラス，およびゲーム内のスクリプトか ら各種入力情報を取得するためのクラス．通信用のスレッドを生成，UDP で ソケットを開き，クライアントから送信されてきた入力情報をクラス内のプロ パティとして保持する．ゲーム内のスクリプトからは公開プロパティや公開メ ソッドを参照することでクライアントの入力情報を取得できる．

• public static class ScreenCapture 公開メソッド

void Start() 通信を開始する

bool SetPort(int port) ポート番号を設定する

void Stop() 通信を終了する

void CalcNetworkSpeed

(ref float fps,ref float kbps) 通信速度とフレームレートを計算する ゲーム画面のキャプチャとその画像のクライアントへの送信を扱うクラス．毎 フレーム画面のスクリーンショット撮影を行う．撮影した画像を png 型のバイ ナリデータとして読み込む．通信用のスレッドを生成し，TCP のソケットで クライアントからの接続を待機する．クライアントと接続されたら，クライア

ントとサーバ間で画像の解像度やデータサイズが含まれたヘッダ情報をやりと りした後，画像を送信する．

• public class Gyroscope 公開メンバ Quaternion attitude 端末の姿勢を表す bool enabled ジャイロスコープの有効化（未使用） Vector3 gravity 重力センサ値 Vector3 rotationRate 端末の回転速度 Vector3 rotationRateUnbiased 未補正の端末回転速度 float updateInterval センサ値取得頻度（未使用） float userAcceleration ユーザによって与えられた加速度値 ジャイロスコープセンサの値を扱うためのクラス．Input クラスの gyro メンバは このクラスのインスタンスを持っている．名前空間 UnityEngine の Gyroscope クラスと基本的には同じように扱える．ただし，enabled の値に関わらずジャ イロスコープは常に有効になっている．クライアント端末がジャイロスコープ に対応していない場合は各メンバは初期値が格納されている．

• public struct Touch 公開メンバ TouchPhase phase タッチの状態を表す int fingerId タッチのインデックス Vector2 position タッチのピクセル座標 Vector2 rawPosition タッチを開始したピクセル座標 Vector2 deltaPosition 最後に変更された位置からの差分 float deltaTime 最後に変更された時間からの経過時間 int tapCount タップした数

タッチ情報を扱うための構造体．Input クラスの touches メンバや GetTouch() メソッドでこの構造体の変数を取得できる．名前空間 UnityEngine の Touch 構 造体と同じように扱える．

Unity Mobile Streaming プラグインの導入法

ゲーム開発者は以下の手順によって Unity Mobile Streaming プラグインの導入， およびサーバの稼働を行える．ただし，プロジェクトのスクリプトは C ♯にて書か れており，Android 向けを想定して開発されているものとする．

• 手順 1   Unity Mobile Streaming パッケージのインポート（図 4.3）

開発している Unity プロジェクトのアセットへ Unity Mobile Streaming パッ ケージを追加する．

図 4.3: プラグイン導入手順 1

図 4.5: プラグイン導入手順 3

図 4.7: プラグイン導入手順 5

図 4.9: Unity Mobile Streaming クライアントアプリの初期画面 • 手順 2   MobileStreaming プレハブのシーンへの追加（図 4.4） 基本的にはゲームが開始して一番最初に読み込まれるシーン，すなわち Unity エディタのビルドセッティングにて 0 番に設定されているシーンに追加する． • 手順 3  ポート番号の設定（図 4.5） 手順 2 で追加したオブジェクトに操作入力を受け付けるポート，映像出力を行 うポートの 2 つを設定する．また，View Network Speed にチェックを入れる と実行中に通信速度とフレームレートを画面に表示するようになる．

• 手順 4  スクリプト内の Input クラスに関わる部分を書き換える（図 4.6） 名前空間 MobileStreaming の Input クラスを利用する．Input クラスの他，Touch 構造体や Gyroscope クラスも書き換える． • 手順 5  サーバの OS に合わせたスタンドアローンプロジェクトとしてビルド （図 4.7） • 手順 6  ビルドした実行ファイルを実行（図 4.8） 解像度は低めに設定するとフレームレートが落ちにくい．クオリティはサーバ 側のスペックによって調整する．

4.2.2

クライアント側アプリケーション

Unity Mobile Streaming サーバ化されたアプリケーションを遊ぶためには専用の クライアントアプリを用いる．このアプリはサーバの IP アドレスとポートを指定し 接続する（図 4.9）ことで，そのサーバで稼働しているアプリケーションを遊ぶ（図

図 4.10: Unity Mobile Streaming クライアントアプリのゲーム画面

4.10）ことが出来る．クライアントアプリ自体は操作入力情報のサーバへの送信と， サーバから送られてきた映像の描画しか行わないため，1 つのクライアントアプリで Unity Mobile Streaming サーバ化されたアプリケーションは全て遊ぶことが出来る．

Unity Mobile Streaming の動作を図 4.11 に示す．クライアントアプリは初期画面 で接続先サーバの IP アドレスとポート番号を指定する．接続ボタンが押されると ゲーム画面へ遷移し，サーバとの接続をリクエストする．この時，接続に失敗した 場合は再び初期画面へ戻る．ゲーム画面では，メインスレッドで画面の描画とセン サ値やタッチ情報の取得を行い，通信はそれぞれ専用のスレッドで非同期的に行う． 操作入力情報を送信するスレッドでは，UDP によるソケット通信を用いて定期的に サーバに各種センサ値とタッチ情報をバイナリ列に変換し送信する．画面情報の通 信を行うスレッドでは，まず TCP による接続をサーバと確立する．接続を確立した 後は，クライアントとサーバでヘッダ情報をやりとりしたのちサーバから画像を受 信，を繰り返し行う．ヘッダ情報は受信する画像の解像度，およびファイルサイズ が含まれた 16 バイトのバイナリ列である．画像は png 形式の静止画としてエンコー ドされたデータで送られてくるため，受信したバッファをそのまま描画する事で画 面の表示ができる．ゲーム画面は元のアスペクト比を維持して表示するか端末側に 合わせてフルスクリーンで表示するかが選べる． Java による実装

まず，クライアントアプリを Java と AndroidSDK によって Android アプリとし て実装した（図 4.12）．アプリそのものの動作が軽快である点，画像をソケットの ストリームから直接ビットマップとして描画可能でありメモリ効率が優れているな どの利点がある．しかし，取得できるセンサ値の形式やタッチ情報の扱いが Unity 内で取得する場合と異なるため Unity の形式に合わせて変換が必要であり，それら

図 4.12: Java による Unity Mobile Streaming クライアントアプリ の入力情報を扱う際にゲーム開発者が通常の Unity アプリケーションと同じように は使用出来ないという問題があった． Unity による実装 そこで，クライアントアプリ自体も Unity によって実装を行い，Android アプリと してビルドした（図 4.9，図 4.10）．Unity で実装しているため，センサ値やタッチ情 報の変換は必要なく，そのまま値を送信すれば良いという利点がある．Java での実 装と比較すると，画像を表示する際に，一度バッファに保持してからテクスチャを 生成・描画するためメモリ効率は落ちてしまうが，実行速度に大きな差は見られな かった．ここで，Unity スクリプトでソケット通信を行う場合.NET フレームワーク のソケット通信を使うことになるが，この機能を Android 向けにビルドして使う場 合，UnityPro ライセンスおよび Unity Android Pro ライセンスが必要になる．その ため，ソケット通信部分だけ Java コードの Android プラグインとして実装し，Unity から外部 Java コード呼び出し機能を使って通信を行わせた．しかし，外部呼び出し にはその度に 1 フレームの遅延が発生するため，通信の遅延が Java での実装よりも 大きくなってしまう問題がある．この問題は UnityPro 環境での開発なら容易に解決 できると考えられる． Windows タブレット向けクライアントアプリ Unity で実装したクライアントアプリは Android プラグイン部分を除き，他はそ のままでマルチプラットフォームに対応できる．そこで，OS に Windows8.1 を搭載 したタブレット端末向けのクライアントアプリの開発も行った（図 4.13）．Windows のスタンドアローンアプリケーションであれば.NET フレームワークのソケット通

図 4.13: Windows8.1 向け Unity Mobile Streaming クライアントアプリ 信が利用できるため，通信部分を Android プラグインから Unity スクリプトでの実 装に書き換えた．しかし，現時点の Unity4 では Windows8.1 タブレットのタッチ入 力やセンサ情報を取得することが出来なかったため，操作入力が出来ずクライアン トアプリとしては動作しなかった．この問題は，将来的に Unity のアップデートに よって解決する可能性がある．

4.3

システムのサポートする範囲

Unity Mobile Streaming は，Unity で Android アプリとして実装・利用できる全 ての機能をサポートしてはいない．表 4.1 に Unity Mobile Streaming のサポートし ている機能，していない機能をまとめた．

表 4.1: Unity Mobile Streaming の機能 機能 サポート可否 入力 加速度センサ ○ コンパス × キーボード × マウス × ジャイロスコープ ○ タッチ ○ マルチタッチ ○ デバイスの傾き ○ GUI 入力 × 出力 画面 ○ GUI 出力 ○ 音声 × その他 Android プラグイン × カスタムアクティビティ ×

第

5

章 システムの評価

本章では，Unity Mobile Streaming の性能評価を行い，本システムの実用性を考 察する．

5.1

動作確認環境

動作の確認や性能評価は以下の環境で行った．サーバとクライアントは同一のロー カルネットワークによって接続されている．また，クライアントアプリは Unity に よって実装した Android アプリ（節 4.2.2）を使用する． • サーバマシン OS Windows7 64bit

CPU Intel Core i3 530 2.94GHz GPU NVIDIA GeForce 8800 GT メモリ (RAM) 4GB

• クライアント端末（Android）

機種 Nexus7（2013 年版）

OS Android4.3

CPU Qualcomm Snapdragon S4 Pro 1.5GHz

GPU Adreno 320 400MHz

メモリ (RAM) 2GB

ネットワーク Wi-Fi IEEE 802.11 a/b/g/n

リンク速度 65Mbps

搭載センサ 加速度，GPS，周囲光，コンパス，ジャイロスコープ

• クライアント端末（Windows8.1）

機種 geanee EDP-71

OS Windows8.1 with Bing

CPU Intel Atom Z3735G 1..33GHz GPU Intel HD Graphics

メモリ (RAM) 1GB

ネットワーク Wi-Fi IEEE 802.11 b/g/n

リンク速度 65Mbps

• ネットワーク

無線 LAN ルータ BUFFALO Airstation WZR-HP-AG300H 準拠規格 IEEE 802.11 a/b/g/n

データ転送速度 最大 300Mbps

• Unity のグラフィッククオリティ レンダリング

   Pixel Light Count 2

   Texture Quality Full Res    Anisotropic Texture Per Texture    Anti Aliasing Disabled    Soft Particles false シャドウ

   Shadows Hard and Soft Shadows    Shadow Resolution Medium Resolution    Shadow Projection Stable Fit

   Shadow Cascades Two Cascades    Shadow Distance 40

その他

   Blend Weights 2 Bones    VSync Count Every VBlank

   Lod Bias 1

   Maximum LODLevel 0    Particle Raycast Bud 256

5.2

性能評価

Unity Mobile Streaming の性能について各項目について実験評価を行った．

5.2.1

画面出力の際に発生する遅延

画面を出力する際にネットワークの通信によって発生する遅延を計測した．ここ では，ゲーム画面のレンダリングが終わった時点から，実際にクライアント端末の 画面に描画されるまでの時間を計測する．すなわち，サーバ側でゲーム画面のレン ダリングが終了してから，画面のキャプチャ，画像の送信，クライアント側の画面 描画にかかる時間が含まれている． この実験は操作入力について問題がある Windows 版クライアントアプリでも同様 に行うことが出来るため，Android クライアント端末と Windows8.1 クライアント 端末の両方について行った．

図 5.1: 画面出力遅延の測定方法

実験方法

アプリケーションが実行されてからの時間をミリ秒単位で表示するゲームアプリ ケーションを実装する．このアプリケーションを Unity Mobile Streaming を使用し て実行し，サーバ側のゲーム画面とクライアント側のゲーム画面が同時に写るよう に外部からビデオ撮影を行う（図 5.1）．この時，サーバ側ゲーム画面に表示されて いる時間とクライアント側ゲーム画面に表示されている時間の差が画面出力の際に 発生する遅延である．約 20 秒間 30fps のカメラで撮影した全 586 フレームのうち， 任意の 120 フレームについて遅延を計測した．また，サーバ側のゲーム画面解像度 は 720_{× 480 で実験を行った．} 結果 フレームごとの画面出力遅延時間について，Android 版クライアントの結果を図 5.2 に，Windows8.1 版クライアントの結果を図 5.3 に示す．また，120 フレーム全体 での結果は表 5.1，表 5.2 のとおりとなった．

Android 版クライアントと Windows8.1 版クライアントの遅延時間の差は，主に.NET フレームワークのソケット通信を利用しているか否かによる影響が大きいと考えら れる．そのため，Unity Pro ライセンスのある環境下で.NET フレームワークのソ ケット通信が利用できれば，Android 版クライアントも Windows8.1 版と同等の性 能になることが期待できる．

図 5.2: 画面出力の遅延（Android） 図 5.3: 画面出力の遅延（Windows8.1） 表 5.1: 画面出力の遅延（Android） 遅延時間（秒） 平均 0.24 最大 0.37 最小 0.13 標準偏差 0.04 表 5.2: 画面出力の遅延（Windows8.1） 遅延時間（秒） 平均 0.11 最大 0.22 最小 0.08 標準偏差 0.03

図 5.4: 操作入力遅延計測アプリ

5.2.2

操作入力の際に発生する遅延

ユーザがクライアント端末で操作入力を行ってからサーバ側でゲーム内に反映さ れるまでのネットワークの通信によって発生する遅延時間を計測した．ここでは，ク ライアント端末がタッチ入力を検知してからサーバ側のゲーム内スクリプトがその 入力を取得するまでの時間を計測する． 実験方法 ランダムなタイミングで画面に「Touch」の文字が表示され，文字が表示されてか らタッチされるまでの時間を計測するゲームアプリケーションを実装する（図 5.4）． 非常にシンプルなアプリケーションのため，ゲーム内でのスクリプト処理やレンダ リングにかかる時間は十分小さく無視できるものとする．このアプリケーションを， Unity Mobile Streaming を利用して実行した場合の結果と，Android のスタンドア ローンアプリケーションとしてビルドして実行した場合の結果から，入力遅延時間 を求める．Unity Mobile Streaming を利用した場合と，クライアント端末単独で実 行した場合で，それぞれ 30 回づつ試行した．また，サーバ側のゲーム画面解像度は 720× 480 で実験を行った．

結果

Unity Mobile Streaming を利用した時のの計測結果を表 5.3 に，クライアント端 末単独で実行した時の計測結果を表 5.4 にまとめた．

この時，Unity Mobile Streaming を利用した場合の結果には，「タッチと表示されて から実際にタッチする，被験者の認知にかかる時間」と「入出力通信の遅延時間」が

表 5.3: Unity Mobile Streaming 利用時の計測結果 A B B-A 試行回 表示開始時間 入力検知時間 経過時間 (秒) (秒) (秒) 1 59.55 60.05 0.50 2 63.90 64.50 0.60 3 69.93 70.53 0.60 4 73.60 74.21 0.61 5 78.10 78.76 0.67 6 85.55 86.25 0.70 7 91.90 92.56 0.67 8 99.48 100.20 0.72 9 107.50 108.06 0.57 10 115.21 115.76 0.55 11 139.98 140.59 0.62 12 144.71 145.56 0.85 13 152.43 153.06 0.63 14 159.76 160.43 0.67 15 164.01 164.66 0.65 16 168.69 169.31 0.61 17 173.87 174.54 0.67 18 179.69 180.29 0.60 19 187.39 188.07 0.68 20 192.97 193.71 0.73 21 219.10 219.90 0.80 22 225.82 226.42 0.60 23 230.75 231.34 0.59 24 237.59 238.32 0.73 25 242.47 243.17 0.70 26 249.32 249.96 0.63 27 256.49 257.07 0.58 28 260.46 261.16 0.70 29 264.55 265.22 0.67 30 269.34 270.02 0.69 平均 0.65

表 5.4: クライアント端末単独実行時の計測結果 A B B-A 試行回 表示開始時間 入力検知時間 経過時間 (秒) (秒) (秒) 1 17.80 18.18 0.37 2 21.62 21.94 0.32 3 28.74 29.10 0.36 4 32.12 32.43 0.31 5 35.47 35.79 0.32 6 42.51 42.84 0.33 7 50.52 50.87 0.36 8 57.44 57.86 0.42 9 60.88 61.23 0.35 10 69.16 69.50 0.33 11 110.80 111.16 0.36 12 118.89 119.30 0.41 13 127.04 127.42 0.38 14 134.29 134.70 0.40 15 142.55 142.96 0.41 16 147.52 147.90 0.38 17 154.31 154.71 0.41 18 160.64 161.00 0.37 19 165.91 166.48 0.56 20 170.87 171.27 0.41 21 256.72 257.08 0.37 22 261.56 261.98 0.41 23 266.12 266.52 0.41 24 270.14 270.56 0.42 25 273.58 273.95 0.37 26 280.18 280.59 0.41 27 284.86 285.29 0.43 28 290.00 290.36 0.35 29 297.91 298.31 0.40 30 302.81 303.23 0.41 平均 0.38

含まれている．また，Android 単独実行した場合には「被験者の認知にかかる時間」 のみが含まれている．よって，Unity Mobile Streaming を利用した場合の結果から， 単独実行した場合の結果と節 5.2.1 で求めた出力遅延を引いた値が，Unity Mobile Streaming の入力遅延の値となる．

よって，

Unity Mobile Streaming 利用 0.65 秒

- Android 単独実行 0.38 秒

- 出力遅延時間 0.24 秒

0.03 秒

となるため，Unity Mobile Streaming の操作入力通信にかかる遅延時間は 0.03 秒と 言える．

5.2.3

アプリケーション実行速度の比較

ゲームアプリケーションを，クライアント端末単独で実行した場合と Unity Mobile Streaming を通じてサーバマシンで実行した場合の実際の動作速度を比較した．ゲー ム内のスクリプトや物理演算処理，レンダリングなどによってある程度の負荷がか かっている状況を想定する． 実験方法 ある程度の演算処理の負荷がかかる Unity アプリケーションとして，瀬戸口らの 研究 [14] 内で開発された，「Unity による剛体の衝突シミュレーション」を利用した． この剛体シミュレーションは，一辺の大きさが 128 である立方体の空間内において， 大きさ 1 質量 1 を持つ球体によって行われる．球体および空間の端となる壁の跳ね 返り定数は 1 であり，静止摩擦および動摩擦ともに存在しない．実験では，まず初 めに n 個の粒子に初速度を x, y, z の各軸方向に-50 から 50 の間でランダムに与え生 成する．それ以降，各粒子が等速直線運動をする中で，粒子同士または壁との衝突 を繰り返す．このプログラムを 1000 フレーム実行するのにかかった時間 t を計測し， 1000/t によってフレームレート（fps）を求める． 粒子数 n は 128，256，512，1024，2048，4096 の 6 通りを，各 5 回づつ試行する． この実験を Android 端末単独での実行，サーバマシン単独での実行，Unity Mobile Streaming を利用しての実行それぞれで行う．また，サーバ側のゲーム画面解像度 は 720× 480 で実験を行った．

結果

Android 端末単独で実行した場合の結果を表 5.5，サーバマシン単独で実行した場 合の結果を表 5.6，Unity Mobile Streaming を利用して実行した場合の結果を表 5.7 に示す．

また，各粒子数毎の平均値をグラフに示すと，図 5.5 となる．グラフより，Android 端末で実行する場合，実行速度が大きく落ち込んでいる事がわかる．また，Unity

表 5.5: Android 端末単独で実行した場合のフレームレート（fps） 粒子数 1 回目 2 回目 3 回目 4 回目 5 回目 平均 128 59.97 59.95 59.98 59.99 59.99 59.97 256 49.38 49.42 49.34 49.16 49.51 49.36 512 28.87 28.87 28.87 28.91 28.92 28.89 1024 12.63 12.75 12.76 12.71 12.44 12.66 2048 2.85 2.65 2.68 2.70 2.70 2.72 4096 1.17 1.19 1.19 1.21 1.21 1.19 表 5.6: サーバマシン単独で実行した場合のフレームレート（fps） 粒子数 1 回目 2 回目 3 回目 4 回目 5 回目 平均 128 60.00 60.01 60.00 60.00 60.00 60.00 256 60.00 60.00 60.00 60.00 60.00 60.00 512 60.01 60.01 60.00 60.00 60.00 60.00 1024 60.01 60.01 60.01 60.01 60.01 60.01 2048 60.01 60.01 60.01 60.01 60.01 60.01 4096 37.28 31.23 37.10 31.67 37.59 34.98 Mobile Streaming を利用した場合の実行速度はサーバマシン単独で実行した場合と 殆ど同じであるが，画面キャプチャ処理が加わることによって若干実行速度が落ち ている．

5.2.4

描画フレームレートと転送速度

Unity Mobile Streaming を利用する場合，ゲームの実行速度とは別に描画フレー ムレートがユーザの体感に影響をおよぼす．Unity Mobile Streaming は毎フレーム 画面をキャプチャするが，通信はゲーム動作とは非同期で行われるため，実際にク ライアントに送信している画像は通信時の最新の画面のみである．そのため，クラ

表 5.7: Unity Mobile Streaming を利用して実行した場合のフレームレート（fps）

粒子数 1 回目 2 回目 3 回目 4 回目 5 回目 平均 128 59.94 60.00 60.01 60.00 59.99 59.99 256 59.88 60.00 60.00 60.04 60.00 59.99 512 60.00 60.00 60.01 60.00 60.01 60.00 1024 59.97 60.02 59.94 60.00 60.01 59.99 2048 60.04 60.07 58.97 60.05 60.03 59.83 4096 32.44 32.20 33.04 33.87 32.96 32.90

図 5.5: 動作速度の比較

表 5.8: Unity Mobile Streaming の描画フレームレートと転送速度

粒子数 フレームレート 転送速度 (fps) (kbps) 128 11.0 1310.2 256 11.4 1513.6 512 10.9 1723.6 1024 11.0 2201.5 2048 10.6 2708.6 4096 10.5 3712.0 イアントで描画されるフレームレートは実行フレームレートより低くなる．Unity Mobile Streaming では約 0.5 秒毎にその間実際にクライアントに送信した画像の数 からフレームレートを，送信した画像の合計バイト数から転送速度を求めている．節 5.2.3 の実験の際に，実行中の描画フレームレートと転送速度を記録し，各粒子数の 時の実行時平均を求め表 5.8 にまとめた．このアプリケーションでは，描画フレーム レートはおよそ 11fps で安定している．転送速度は，粒子数の多いほどより複雑な 画像となりファイルサイズが大きくなるため，より高い転送速度となっている．転 送速度によって描画フレームレートは変化していないため，転送速度がネットワー クの通信速度を超えない限り，描画のボトルネックにはならないと考えられる．

表 5.9: 1 フレーム処理するのにかかる時間（ミリ秒） 粒子数

128 256 512 1024 2048 4096

Android 端末単独 16 20 34 78 367 840

Unity Mobile Streaming 16 16 16 16 16 30

表 5.10: 操作入力からレスポンスの出力までにかかる時間（ミリ秒） 粒子数

128 256 512 1024 2048 4096

Android 端末単独 16 20 34 78 367 840

Unity Mobile Streaming 286 286 286 286 286 300

5.3

実用性の考察

5.3.1

実行速度

Kuan-Ta Chen ら [15] によると，ユーザがゲームを遊ぶ際に感じるアプリケーショ ンの実行速度は，ユーザの操作入力からそのレスポンスの出力までにかかる時間に よって表せる．すなわち，Unity Mobile Streaming によって，サーバ上で高速に演 算処理やレンダリングを行うことによって減った処理時間が通信の遅延よりも大き い時，Unity Mobile Streaming は有効なシステムであると言える．

ここで，節 5.2.3 の結果より，Android 端末単独で実行した場合と Unity Mobile Streaming を利用して実行した場合のフレームレートから，1 フレーム処理するのに かかる時間を計算する．1000/フレームレートによって 1 フレーム処理するのにか かった時間（ミリ秒）を求めると表 5.9 のようになる．また，節 5.2.1 より画面出力 にかかる時間は 240 ミリ秒，節 5.2.2 より操作入力にかかる時間は 30 ミリ秒とする と，Unity Mobile Streaming の通信によって増える遅延時間は 270 ミリ秒と言える． そのため，表 5.9 の Unity Mobile Streaming の値に 270 を加えた値が，Unity Mobile Streaming を利用している時の操作入力からレスポンスの出力までにかかる時間で あると言える．なお，クライアント端末そのものが入力を検知するのにかかる時間 と画面を描画するのにかかる時間は十分小さく，また Android 端末単独で実行する 場合も Unity Mobile Streaming を利用する場合も同等の時間がかかるため，無視す る．表 5.10 より，2048 粒子のときおよそ 1.28 倍，4096 粒子のとき 2.8 倍高速である． よって，2048 粒子以上相当の負荷がかかる場合において Unity Mobile Streaming が 有効である事が示せた．

図 5.6: 遅延時間と fEMG ポテンシャルの関係（参考文献 [16] の Fig.4）

5.3.2

遅延時間

一方で，最も理想的な実行速度，すなわち 60fps でゲームが動作している場合，レ スポンスの出力までにかかる時間は 16 ミリ秒であるため，通信によって増える遅延 時間の 270 ミリ秒は小さいとは言えない．Yeng-Ting Lee らの研究 [16] では，クラ ウドゲームにおける遅延時間の増加は体感品質の低下を招くとしている．この研究 では，どのようなジャンルのゲームがクラウドゲーミングとの相性が良いかを，筋 電図によるアプローチで評価している．実験では，アクションゲーム，ファースト パーソンシューティング，ロールプレイングゲームの 3 ジャンルに対し各 3 タイトル の計 9 タイトルのゲームについて，任意の時間の遅延を発生させるエミュレータを 通して被験者にプレイさせる．被験者は，各タイトルを遅延時間 0，50，100，200， 400 ミリ秒加えた状態でプレイし，その時の表情筋の状態を筋電図によって測定す る．この結果から，被験者の体感品質を数値化している．被験者には，19 歳から 28 歳でゲーム経歴平均 4.6 年の男女 15 人が選ばれた．実験結果より，遅延時間と顔面 筋電図（fEMG）ポテンシャルの関係は図 5.6 のようになったとしている．ここで， 緑色のデータはアクションゲームの，赤色はファーストパーソンシューティングの， 青色はロールプレイングゲームのタイトルを表している．fEMG ポテンシャルの値 が高いほど不快感が強い，すなわち体感品質が低いとしている． 図 5.6 より，遅延時間 270 ミリ秒の時を見ると，殆どのゲームタイトルにおいて， fEMG ポテンシャルの値が大きくなっている．よって，現状の Unity Mobile Streaming では快適に遊べるとは言いがたい可能性がある．しかし，節 5.2.1 で Windows タブレッ ト端末を用いた実験での結果を考えると，Android 版クライアントアプリでも.NET フレームワークのソケット通信を利用できれば出力遅延は 110 ミリ秒まで削減出来 ると思われる．そうすれば，入力遅延と合わせて通信にかかる遅延時間は 140 ミリ

秒となる．遅延時間が 140 ミリ秒の場合，ファーストパーソンシューティングのよ うな厳密なリアルタイム性の求められるゲームジャンルでは，やはり快適に遊ぶの は難しいようであるが，アクションゲームやロールプレイングゲームでは fEMG ポ テンシャルの値に大きな変化の見られないタイトルもあるため，ある程度快適に遊 べるのではないかと思われる．