図1 Unityのエディタ画面
ネットワークシステム研究室
指導教員 坂本 直志
15EC028 岡安 博俊
3.6 Unreal Engineでの実験用ソフトウェアと実験結果
3.7 Cocos Creatorでの実験用ソフトウェアと実験結果
近年において,様々なコンピュータゲームが作られるようになった.さらに,コンピュータゲームのハードウェアには,ゲーム機の他,パソコンやスマートフォンなども利用されている.コンピュータゲームなどのハードウェアを高度に利用するソフトウェアでは,APIを利用して操作を抽象化する.そして,コンピュータゲーム制作のために開発したAPIの集まりをゲームエンジンと呼ぶ.パソコンなどのハードウェアに対して作られたゲームエンジンは,利用限界は定められておらず,コンピュータゲーム開発者に委ねられている.しかし,パソコンゲームではハードウェアの自由度が大きい.スペックの低いパソコンと高いパソコンでパソコンゲームが同じように動作するにはゲームエンジンの性能が重要となる.
現在ゲームエンジンは有料,無料含めて様々なものが作られている.そこで,本研究では比較的有名なUnity,Unreal Engine,Cocos Creatorの3つのゲームエンジンを用意した.そして,それぞれのゲームエンジンのAPIの限界を測定するソフトウェアを作成した.さらに,これを用いてゲームエンジンの性能評価を行った.最終的には,測定結果と性能評価を元にゲームエンジンやコンピュータゲーム,それに対するハードウェアの将来について考えていく事を目標としている.
2章では各種ゲームエンジンとゲームエンジンそのものについて,事前知識等の説明を行う.
3章では実験の内容と結果を示す.
4章では実験の結果と既存の情報を合わせてゲームエンジンの評価を行う.
5章では研究の考察を行う.
6章では本研究のまとめを行う.
ゲームエンジンとは,コンピュータゲーム制作のために開発したAPIの集まりである.しかしながら,その定義は曖昧である.通常はゲームの開発作業が汎用化されたものをゲームエンジン,単にプログラミング上のライブラリを共通化するのをゲームフレームワークとして区別する.ゲームエンジンとゲームフレームワークの違いは,GUIをベースにした操作になっているかどうかである.ゲームエンジンは,GUIで操作をす出来る.一方で,ゲームフレームワークはGUIで操作を出来ない.そして,ゲームエンジンは,簡単にいえばコンピュータゲーム制作に必要な機能をまとめたものであるという事になる.今度はゲームエンジンの機能について説明をする.しかし,その前に各専門用語について説明をする.
・3次元コンピュータグラフィックス
3次元コンピュータグラフィックスは,コンピュータの演算により,立体感のある2次元画像を作る手法,もしくはその2次元画像そのものを示す.3次元コンピュータグラフィックスの一種として,入力に対して即座に映像を生成する実時間処理による動画像がある.コンピュータゲームにおいてはこの実時間処理の動画像が使われている.
・オブジェクト
オブジェクトとは,コンピュータゲームの世界に配置される物体を指す.そして,目に見える有機物や無機物から目に見えないものまで様々な種類がある.オブジェクトはコンピュータゲームにおいて基本的な構成要素となる.
・レンダリング
レンダリングは,数値データや数式等の抽象的な情報からプログラムを用いて2次元画像や映像や音声などを生成することをいう.また,レンダリングを行うソフトウェアやシステムなどをレンダリングエンジンと呼ぶ.ゲームエンジンにおいては,3次元コンピュータグラフィックスを生成する役割を持っている.
・モデリング
モデリングは,仮想の3次元空間上に物体の形状を作ることである.この物体の形状はオブジェクトの集合で表現される.また,モデリングによって作られた形状はモデルと呼ばれる.
・スクリプト
スクリプトは,テキストファイルベースで書かれたソースコードのファイルの事である.プログラムと違い実行する時にソースコードを機械語に変換する.そのため,ソースコードを変更しても逐次実行することが可能である.
ゲームエンジンは,共通する様々な機能を持っている.まず,その一つに2D/3Dのオブジェクトの抽象化がある.ほとんどの場合はゲームエンジンはDirect3DやOpenGLなどのレンダリングAPIによってレンダリングエンジンが構築されている.これによって,モデリングやレンダリングの機能が備わっている.そして,ゲームエンジン内でのオブジェクトは,座標,サイズなどの情報を持つ.さらに,ゲームエンジンは,配置されたオブジェクトや背景などの画面にグラフィックを表示する描画機能を持っている.また,当たり判定の他,物理演算の機能も備えている.よって,オブジェクトに重力や衝突判定といったものも付加出来る.その他,BGMやSE等の音を鳴らす機能やスクリプトの機能などを持つ.
Unityは,Unity Technologies社によって開発されたゲームエンジンである.世界で最も使われているゲームエンジンかつ市場の占有率は約50%である[4].先述のように,知名度の高さと資料の豊富さから,初心者でも扱いやすいゲームエンジンともいえる.そして,スクリプトの作成にはC#を使用する.2Dと3Dのコンピュータゲームを作成することが可能で,作成のモードはそれぞれで分かれている.2Dと3Dとでスクリプト等のデータを流用する事が出来る.スクリプト等も含めて,素材はアセットという呼称で共通して管理される.Unityでコンピュータゲームを作るには仮想的な3次元空間であるシーンを定義して行う.
図1 Unityのエディタ画面
図1に示したのは,Unityのエディタ画面である.これを利用して,まずはエディタの各ビューについて説明していく.
・シーンビュー(図1 a)
シーンビューは,シーンを映す部分になっている.自由な位置と角度からシーンを眺める事が出来る.
・ゲームビュー(図1 b)
ゲームビューは,シーンに設置されたカメラから見たシーンを映す部分である.
・ヒエラルキービュー(図1 c)
ヒエラルキービューは,シーン内に存在するオブジェクトの一覧が階層的なリストとして表示される部分である.現在のシーン内にあるオブジェクトに対して,コピー&ペーストや名前を付けてシーンの構造を整理することが出来る.
・プロジェクトブラウザ(図1 d)
プロジェクトブラウザは,シーンやアセットの内容が名前のリストとして表示される部分である.
・インスペクタービュー(図1 e)
インスペクタービューは,選択しているオブジェクトの属性を表示,編集するための場所である.属性には,座標やサイズの他,衝突判定や物理制御に関するパラメーターも存在する.また,スクリプトはここにソースコードを入力する.
次に,本研究で使用するUnityの専門用語について説明する.
・ゲームオブジェクト
ゲームオブジェクトは,シーン内のそれぞれの要素のことである.目に見える物理オブジェクトや目に見えないサウンドなどと,様々な形がある.しかし,任意にスクリプトを割り当てて制御できる物という共通点がある.目に見えるゲームオブジェクトは,シーン内に配置することでシーンビューにモデルが表示される.そして,カメラとなるゲームオブジェクトの視界内に配置するとゲームビューにもモデルが表示される.例えば,Sphereというゲームオブジェクトが,Unityには最初から入っている.これをシーンに配置することでシーンビューにSphereのモデルである球状の物体が表示されるようになる(図4).図1の①は,シーンに配置されたゲームオブジェクトのリストになっている.ヒエラルキービューにおいては,ゲームオブジェクトは,名前だけのリストが表示される.
・プレハブ
プレハブは,オブジェクトの構築情報を格納したものである.主に同じオブジェクトを量産したい時に利用する.また,ゲームオブジェクトはヒエラルキービューのリストからプロジェクトブラウザに移すとプレハブになる.図1の②は,プレハブにしたゲームオブジェクトのアイコンである.
・アセット
アセットは,プレハブやスクリプト等を素材として共通で管理したものを指す.フォルダを作成して整理する事が出来る.図1の③は,アセットの一覧である.
最後に,Unityにおけるコンピュータゲーム制作の流れの一部として,ゲームオブジェクトの生成手順を示す.
図2 ゲームオブジェクトの生成手順1
今回は,Unityに最初から入っているSphereをゲームオブジェクトとして生成する.図2にはシーンビューとヒエラルキービューを抜き出したものを示した.まずは,ヒエラルキービュー内で右クリックをする.
図3 ゲームオブジェクトの生成手順2
すると,図3のようにメニューが表示される.メニュー内の3D ObjectからSphereを選ぶ.
図4 ゲームオブジェクトの生成手順3
すると,図4のようにシーンにSphereが表示される.同時に,ヒエラルキービューのリストにもSphereが追加される.また,インスペクタービューにはSphereの情報が表示される.ここまでがゲームオブジェクトを生成する一つの流れとなる.このようにしてゲームオブジェクトやスクリプトの生成と配置等を繰り返していくことで,Unityにおけるコンピュータゲームを構成する.
Unreal Engineは,Epic Gamesによって開発された3Dのゲームエンジンである.システムを制作する独自の機能として,ブループリントがある.このブループリントはソースコードを書かずノードと呼ばれる様々な機能を持った要素によってシステムを構築する.よって,プログラム経験が無くてもコンピュータゲームを制作できるという利点がある.なお,Unreal Engineはグラフィックのクオリティが重視されている事などから,全体的に動作が重い.図5に通常の,図6にブループリントのエディタ画面を示す.
まず,本研究で使用するUnreal Engineの専門用語について説明する.
・オブジェクト
オブジェクトは,Unreal Engineにおける基礎的な要素の事で,基本的な内部機能を多く含むものである.
・レベル
レベルは,ユーザ定義領域になっている仮想的な3次元空間である.ビューポート内に表示される.
・アクタ
アクタは,レベル内へ配置可能な任意のオブジェクトである.様々な3D変形をサポートし,スクリプトを利用してアクタの作成と破壊をすることが出来る.そして,ビューポートパネル(図5 i)では実際に配置されたものが画面上に表示される.ワールドアウトライナーパネル(図5 j)には名前だけのリストが表示される.また,アクタのコピー&ペースト等を行うことが出来る.詳細パネル(図5 k)では,選択しているアクタの情報が表示される.図5の④は配置されたアクタのリストになっている.
・アセット
アセットは,画像や音声データ等の素材を共通して管理したものである.
・ブループリント
ブループリントは,Unreal Engineにおける独自のシステム制作機能である.使用するにあたってソースコードを書いたりする事が無い.そのため,プログラミングの知識が無くてもシステムを構築できる. また,ブループリントにおいて様々な機能を持った要素のことをノードという.ノードが持っている機能には,キーボードの入力の認識や関数の呼び出し等がある.ブループリントの使い方としては,まずグラフエディタタブ(図6 o)に対してノードを設置する.そして,設置したノードのピンという接続部を繋ぎ合わせることによってノード同士を接続する.このようにして,一連のコンピュータゲームのシステムを構築する.図6の⑤は実際にノードを繋いだものである.
図5 Unreal Engineの通常のエディタ画面
図6 ブループリントのエディタ画面
次に,画面の各パネルについて説明していく.まずは,通常の画面(図5)について説明する.
・ツールバーパネル(図5 f)
ツールバーパネルは,頻繁に使用するツールや操作へ素早くアクセスするための,コマンドの集まりになっている.具体的には,コンピュータゲームの保存や開始,ブループリントの作成と編集などがある.
・モードパネル(図5 g)
モードパネルは,エディタの様々なツールモードが存在する領域である.具体的には,アクタを配置するための配置モード.アクタを直接ペイントするためのペイントモードなどがある.
・コンテンツブラウザ(図5 h)
コンテンツブラウザは,エディタ内でアセットを作成,インポート,整理,表示,修正するための主要エリアになっている.
・ビューポートパネル(図5 i)
ビューポートパネルは,作成したレベルを表示するパネルである.自由に視点を切り替えてレベルを確認することが出来る.ツールバーのゲーム開始等をすると,実際にゲームをプレイする画面に切り替わる.
・ワールドアウトライナーパネル(図5 j)
ワールドアウトライナーパネルは,レベル内の全アクタの一覧が表示される領域である.直接アクタを選択および修正することが出来る.
・詳細パネル(図5 k)
詳細パネルは,ビューポート内から選択したアクタ等の情報が表示される領域である.ここからアクタの移動や回転等をすることが出来る.
次に,ブループリントの画面(図6)について説明する.
・ツールバー(図6 l)
ブループリントにおけるツールバーは,ブループリントを編集するコマンドに対してアクセスするためのボタンの集まりになっている.通常のエディタ画面と同様に,保存やコンピュータゲームの開始ボタンなどがある.
・My Blueprintタブ(図6 m)
My Blueprintタブは,ブループリントに含まれるスクリプトや関数などのリストを表示する領域である.ブループリントの新規作成も行うことが出来る.
・詳細パネル(図6 n)
ブループリントにおける詳細パネルは,エディタ内で選択した要素のプロパティを編集するための領域である.
・グラフエディタタブ(図6 o)
グラフエディタタブは,ノードの配置と接続を行う領域である.
最後に,Unreal Engineにおけるコンピュータゲーム制作の流れの一部として,アクタの生成手順を示す.
図7 アクタの生成手順1
今回は,Unreal Engineに最初から入っている球状のアクタを生成する.図7はアクタが何も配置されていない状態のエディタ画面である.
図8 アクタの生成手順2
まずは,モードパネルを見る.初期の状態であれば,図8のように球のアイコンが表示されている.これをビューポートにドラッグ&ドロップする.
図9 アクタの生成手順3
すると,図9のようにビューポートに球状のアクタが表示された.また,ワールドアウトライナーパネルにもリストにActorが追加された.これでゲーム内にアクタの生成が出来たことになる.後は他のアクタの生成やブループリントによるシステムの制作を繰り返していく.これがUnreal Engineのコンピュータゲーム制作の流れとなる.
Cocos Creatorは2Dのゲームエンジンである.スクリプトの作成にはJavaScriptが使用されている.2Dなので,UnityやUnreal Engine等と違い座標やサイズの指定はXとYだけでZが無い.そして,全体的に動作は軽めであるともいえる.図10にエディタの画面を示す.
まず,本研究で使用するCocos Creatorの専門用語について説明しておく.
・シーン
シーンは,仮想的な2次元空間である.シーンパネル(図10 s)に表示される.
・ノード
ノードは,シーン内に配置する基本的な要素である.テキストや画像の表示,レイアウトを制御するなど様々な役割のものがある.図10の⑥はシーン内のノードのリストである.
・プレハブ
プレハブは,ノードの構築情報を格納したものである.同じノードを複数配置する時などに使用する.図10の⑦は作成したプレハブのアイコンである.
・アセット
アセットは,スクリプト等の素材を共通して管理したものである.アセットパネル(図10 q)に一覧が表示される.
図10 Cocos Creatorのエディタ画面
次に,エディタ画面の各パネルについて説明していく.
・ノードツリーパネル(図10 p)
ノードツリーパネルは,シーンに配置された全てのノードの一覧が木構造で表示される領域である.ノードツリーパネルでは,ノードに対してコピー&ペーストや削除をすることが出来る.
・アセットパネル(図10 q)
アセットパネルは,アセットの一覧が表示される領域である.
・コンソールパネル(図10 r)
コンソールパネルは,コンピュータゲームのテストプレイ時等のログやシステムメッセージが表示される領域である.
・シーンパネル(図10 s)
シーンパネルは,シーンが表示される領域である.シーン内に配置されたノードを表示する.また,マウス操作で配置されたノードを移動させることも出来る.
・ノードライブラリパネル(図10 t)
ノードライブラリパネルは,Cocos Creatorに最初から入っているノードが格納されている領域である.具体的には,テキストやボタン等がある.
・プロパティパネル(図10 u)
プロパティパネルは,選択したノードの情報が表示される領域である.選択したノードに対して移動や回転,サイズの変更を行うことが可能である.
最後に,Cocos Creatorにおけるコンピュータゲーム制作の流れの一部として,ノードの生成手順を示す.
図11 ノードの生成手順1
図11にはシーンに何も配置されていない状態のエディタ画面を示した.今回は,Cocos Creatorに最初から入っているSpriteを生成する.そこで,図11の白枠内のSpriteをシーンにドラッグ&ドロップする.
図12 ノードの生成手順2
すると,図12のようにシーンにSpriteの画像が表示された.同時に,ノードツリーパネルにはリストにspriteが追加された.後はこのようなノードの生成とスクリプトの作成を繰り返していく.これがCocos Creatorにおけるコンピュータゲーム制作の流れとなる.
2.1章では本研究におけるオブジェクトについて述べた.各ゲームエンジンにおいて相当するものとしてはUnityのゲームオブジェクトとUnreal Engineのアクタ,Cocos Creatorのノードがあった.具体的には,これらはゲーム内に配置するものという役割を共通して持っていた.そこで,ゲームオブジェクトを基準として比較したのが表1である.なお,アクタに対してはスクリプトではなくブループリントを用いて様々な動作を付ける.ノードは2Dなため,座標やサイズの指定はXとYまでという違いがある.また,Unityのゲームオブジェクトは,3Dと2Dの両方を作成できるが,アクタは3Dのみ,ノードは2Dのみ,となる
表1 オブジェクト関連用語の比較
| 名称 | スクリプト関連 | 座標,サイズ等の指定 | 3Dか2Dか |
| ゲームオブジェクト(Unity) | コンポーネントとしてスクリプトを割り当てる. | X,Y,Z | 3D/2D |
| アクタ(Unreal Engine) | ブループリントから制御する. | X,Y,Z | 3Dのみ |
| ノード(Cocos Creator) | コンポーネントとしてスクリプトを割り当てる. | X,Yまで | 2Dのみ |
MSI Afterburnerは,MSI社によって開発された,ハードウェアの使用状況の表示と記録が出来るソフトである.本研究では,含まれている機能の中でも,ハードウェアのデータのログを行う機能を使用する.データのログは開始してから一定時間毎に行われる.そして,終了するとデータログがファイルとして出力される.なお,コンピュータの性能測定時に計測ソフトによる負荷を抑えるために,測定する値にはバラつきが出ることになる.そこで,MSI Afterburnerのデータログの機能を用いた.これにより,データのログを行った.そして,データのログをまとめることで測定の精度を上げる事が出来た.
本研究では各ゲームエンジンの性能評価を行うため,同等と見なせる負荷をかけ,動作特性を計測する.
そのため,各ゲームエンジンにおいて.同一位置に多数の基本的なオブジェクトを配置し,フレームレートと,CPU,GPUの使用率を計測した.
ゲームエンジンの性能のうち,オブジェクトの描画性能つまりフレームレートが重要である.そこで計測する大量のオブジェクトに対して10fps程度になるまでを計測範囲とした.10fpsになるオブジェクト数に対し,測定範囲を定めた.(表2)
表2 測定範囲のまとめ
| 名称 | 開始時のオブジェクト配置数 | 配置数の間隔 | 終了時のオブジェクト配置数 |
| Unity | 0 | 500 | 10000 |
| Unreal Engine | 0 | 100 | 2000 |
| Cocos Creator | 0 | 10000 | 200000 |
次に,データのまとめ方について述べる.データのバラつきは,特にデータのログの開始と終了時に,前面に出すウィンドウを切り替える行動が入るために起きやすい.例としてCPU使用率のデータの一部を図13に示す.
図13 CPU使用率のバラつき
データのまとめは,主にこのバラつきを抑えて行いたい.そこで,上位,下位の特定の割合を除外しデータの平均値を取るExcel関数TRIMMEANを使用した.
このTRIMMEANは,引数として配列と割合を入力する.配列には平均を取りたい数値の入ったセル範囲を指定する.そして,割合には除外するデータの割合を指定する.さらに,指定された割合に応じて最大と最小から数値を除外して平均化を行う.例えば,割合に0.4が指定されると,上位2割と下位2割の数値が除外される.最終的に,極端なデータを除外して平均を取る事が出来る関数である.
また,測定では,一回のデータのログで30個程のデータを収集したい.そして,データのログは,1秒毎に行われる.そのため,データのログの終了までの時間は,一回につき30秒程度である.今回のデータのまとめでは,主にデータのログの開始と終了時のブレが大きい部分の数値を除外したい.データログの開始と終了時は,合わせて5秒程度の時間である.さらに,5は,30の1.7割の数である.加えて,データのブレは,上位と下位のどちらかに偏った場合でも除外されるようにする必要がある.さらに,データのログの開始と終了時以外にもデータのブレは出る可能性がある.まとめると,データは,データのログの開始と終了時のブレの偏りと他の時に出るブレの可能性を考慮して0.17から少し大きくして,上位と下位2割を除外したい.したがって,TRIMMEANにおける除外するデータの割合は0.4に指定した.
ここでは,実験用ソフトウェアについて述べる.実験用ソフトウェアは,ゲームエンジンの性能評価を行うために作成した各ゲームエンジン用のシーン,レベルのことを呼ぶ.起動してオブジェクトを生成することで,その分パソコンのハードウェアに対して負荷をかける.そして,その負荷を測定することがこの実験の内容である
ここでは,Unityで作成した実験用ソフトウェアについての説明を行う.そして,最後に測定したデータのまとめを実験の結果として示す.この実験の結果は,ゲームエンジンに対する評価の指標の一つとなる.
先に,Unityの実験用ソフトウェアの内容と機能について述べる.Unityの実験用ソフトウェアの画面を図14に示す.
図14 実際の実験用ソフトウェアの画面(Unity)
Unityの実験用ソフトウェアは,Unityにおける性能評価を行うためのソフトになる.含んでいる機能としては図14のようにゲームオブジェクトを画面中央に重ねて生成する機能と画面左下に現在のゲームオブジェクト数を表示する機能がある.キーボードのzを押すとゲームオブジェクトが500個生成される.また,キーボードのzを60フレームの間押し続けるとフレーム毎にゲームオブジェクトが生成され始める.さらに,常時ゲームオブジェクト数の表示を行う.
次は,使用したゲームオブジェクトについて説明をする.図15にはシーンに配置されたゲームオブジェクトのリストを示した.
図15 ヒエラルキーウィンドウの状態
図15の⑧のMain Cameraは画面を映すためのゲームオブジェクトである.そして,Directional Lightはシーン内の3D環境の色等を定義するゲームオブジェクトになっている.Main CameraとDirectional LightはUnityでコンピュータゲームを制作する際に最初から生成されている.座標等の状態はその最初の状態のままである.⑨のSphereDuplicateは負荷の対象となるゲームオブジェクトのSphere(球)を生成するためのゲームオブジェクトである.⑩のCanvasはUIとなるゲームオブジェクトが配置されるものである.その中にあるSphereCountがSphereの配置数を表示するためのものになる.⑪のEventSystemはプレイヤーのUIへの入力を制御するゲームオブジェクトである.⑫のCounterがSphereの配置数を数えるためのゲームオブジェクトである.次は,各ゲームオブジェクトについて状態を図と共に説明していく.
図16 Main Camera(Unity)の状態
図16にMain Cameraの状態を示した.Main Cameraは,実験用ソフトウェアの画面を移すためのゲームオブジェクトである.後述のSphereDuplicateが視界内に無ければSphereが画面の外に生成されてしまう.そこで,Sphere DuplicateがMain Cameraの視界内に収まるように座標や角度を調整する必要がある.そのために,今回はMain CameraのZ座標を調整して-10にした.
図17 SphereDuplicateの状態
図17にSphereDuplicateの状態を示した.SphereDuplicateは,Sphereの生成とフレームレートの固定化の役割を持ったゲームオブジェクトである.スクリプトとしてSphereを生成する役割を持ったSDと最大フレームレートを調整するためのFrameを割り当てている.Main Cameraとは,先述のように座標を調整し合う必要がある.しかしながら,今回はMain Cameraの方をメインに調整した.なので,こちらは生成後の初期座標のままである.
図18 SphereCountの状態
図18はSphereCountの状態になっている.SphereCountは,数値を表示させるためにテキストの機能を持ったゲームオブジェクトである.配置等についてはなるべく見やすくすれば良い.
次に,作成したスクリプトとプレハブについて説明していく.スクリプトとプレハブ等のアセットの一覧を図19に示した.
図19 スクリプトとSphereのプレハブ
Unityの実験用ソフトウェアに対して3つのスクリプトを作成した.一つ目のCounterは,Sphereの配置された個数を数えるためのスクリプトである(付録 8.1).スクリプト内の10行目と11行目に実際に配置数のカウントと表示を行う部分がある.さらに,FindGameGameObjectsWithTag()の関数を用いることでSphereタグの付いたゲームオブジェクトについての情報を取得しLengthでその数を求めている.求めた数はToString()を用いて出力する.図19の⑬がCounterのアイコンになっている.
二つ目のframeは,最大フレームレートを60に固定するスクリプトである(付録 8.2).具体的には,スクリプト内の9行目でフレームレートの最大値を60に指定している.⑭がframeのアイコンになっている.
三つ目のSDは,Sphereゲームオブジェクトを任意の数まで大量に生成するためのスクリプトである(付録 8.3).具体的には,まず,18行目のif文でキーボードのz入力を認識する.次に,23行目のInstantiate()の関数をwhile文で500回繰り返す.そして,ゲームオブジェクトを500個生成する..また,zの入力がされ続けて１秒が経過すると変数iが60を超えてフレーム毎にゲームオブジェクトが500生成される.入力がされなくなると,ゲームオブジェクトの生成が終了してiが0に戻る.⑮がSDのアイコンである.
⑯にはSphereのプレハブのアイコンがある.Sphereのプレハブは,Sphereの構築情報を持っているものである.スクリプトのSDの複製対象に指定してSphereの大量生成に利用した.
最後に,得られた計測結果をまとめたものを表3,それをグラフにしたものを図20に示す.
表3 オブジェクト数対各種平均特性(Unity)
| オブジェクト数 | GPU使用率[%] | CPU使用率[%] | フレームレート[fps] |
| 0 | 16.9 | 9.57 | 60.3 |
| 500 | 78.8 | 9.30 | 60.3 |
| 1000 | 87.0 | 11.5 | 60.3 |
| 1500 | 99.0 | 12.7 | 49.7 |
| 2000 | 99.0 | 13.8 | 38.3 |
| 2500 | 99.1 | 14.4 | 31.0 |
| 3000 | 99.3 | 13.5 | 26.2 |
| 3500 | 99.0 | 13.6 | 22.6 |
| 4000 | 99.1 | 14.4 | 19.9 |
| 4500 | 99.3 | 15.4 | 17.7 |
| 5000 | 99.2 | 15.5 | 16.0 |
| 5500 | 99.6 | 16.9 | 14.6 |
| 6000 | 99.6 | 16.7 | 13.5 |
| 6500 | 99.2 | 15.9 | 12.4 |
| 7000 | 99.4 | 14.9 | 11.6 |
| 7500 | 99.1 | 15.9 | 10.8 |
| 8000 | 99.2 | 17.1 | 10.1 |
| 8500 | 99.3 | 16.3 | 9.51 |
| 9000 | 99.3 | 15.9 | 8.99 |
| 9500 | 99.4 | 16.1 | 8.50 |
| 10000 | 99.2 | 16.4 | 8.10 |
図20 オブジェクト数対各種平均特性(Unity)
Unreal Engineで作成した実験用ソフトウェアについての説明を行う.そして,最後に測定したデータのまとめを実験の結果として示す.この実験の結果は,ゲームエンジンに対する評価の指標の一つとなる.
先に,Unreal Engineの実験用ソフトウェアの内容と機能について述べる.Unreal Engineの実験用ソフトウェアの画面を図21に示す.
図21 実際の実験用ソフトウェアの画面
Unreal Engineの実験用ソフトウェアは,Unreal Engineにおける性能評価を行うためのソフトになる.含んでいる機能としては図21のようにアクタを画面中央に重ねて生成する機能と画面左にその時のアクタ数を短時間表示する機能がある.起動した初期状態では視点がマウスの動きに合わせて動く.そこで,キーボードの1を押すと視点を固定化する.キーボードのzを押すとアクタのフレーム毎の自動生成が開始または終了する.キーボードのxを押すとアクタが10個生成される.さらに,キーボードのcを押すと,押した時のアクタ数を1秒間表示する.
次は,使用したアクタについて説明する.図22にはレベル内のアクタのリストを示した.
図22 アウトライナパネル
図22の⑰のCameraActorは,実験をする時の視点となるためのアクタである.Unreal Engineでは特に何も設定をしないとゲーム内での視点移動がマウスの動きに影響を受ける.よって,何も設定をしないと実験中にアクタが画面外にいく可能性などにより環境が不安定になる.そのため,このCameraActorを利用して視点の固定化を行った.
図23 CameraActorの状態
図23にはCameraActorの状態を示した.CameraActorの視界内に測定対象のアクタが無ければ,ソフトウェアを起動したときの画面にも測定対象のアクタが映らなくなる.この事を踏まえて対象のアクタがCameraActorの視界に入るように位置を調整した.
図24 コンテンツブラウザの中身
図24に示したのはコンテンツブラウザの中身である.Sphereは,今回の測定の対象となるアクタである.⑱はSphereのアイコンである.Sphere_Blueprintは,Sphereをブループリント内で使用するためのものになる.⑲はSphere_Blueprintのアイコンである.
次に,システム部分について説明する.システムはブループリントのみを使用して作成している.
図25 ブループリントの一部(アクタ生成部分)
図25にはレベルのブループリント内でもSphereの生成に関する部分を示した.⑳のノードは,接続先のノードをフレーム毎に実行するノードである.㉑のノードは,キーボードのzが押された時に接続先のノードを実行するノードである.㉒のノードは,⑳のノードによって㉔のノードを実行するかしないかを㉑のノードによって実行される度に切り替えるノードである.㉓のノードは,生成されるSphereの情報を持ったノードである.㉔のノードは,㉓の情報を持ったSphereを生成するノードである.まとめると,⑳から㉔のノードは,キーボードのzを押すとフレーム毎のSphereの生成を開始または終了するシステムを構築する.㉕の部分は,中に複数のノードが格納されている(付録 9 図42,43).具体的に,㉕の部分の中には,㉓のノードに対して㉔のノードが10個接続されている.そして,この10個の㉔のノードには,キーボードのxが押された時に接続先のノードを実行するノードが接続されている.つまり,㉕の部分は,キーボードのxを押すとSphereを10個生成するシステムを構築する.
図26 Sporn Point 2の状態
Sporn Point2の実際の状態を図26に示した.この位置情報を元にSphereが生成位置が決定されるという仕組みである.
最後に,得られた計測結果をまとめたものを表4,それをグラフにしたものを図27に示す.
表4 オブジェクト数対各種平均特性(Unreal Engine)
| オブジェクト数 | GPU使用率[%] | CPU使用率[%] | フレームレート[fps] |
| 0 | 48.8 | 13.3 | 60.0 |
| 100 | 73.8 | 13.8 | 59.9 |
| 200 | 94.9 | 15.8 | 59.6 |
| 300 | 98.6 | 22.2 | 49.9 |
| 400 | 99.3 | 15.3 | 42.2 |
| 500 | 99.2 | 14.2 | 35.9 |
| 600 | 99.2 | 14.6 | 31.5 |
| 700 | 99.3 | 12.5 | 27.8 |
| 800 | 99.2 | 12.4 | 25.0 |
| 900 | 99.4 | 12.2 | 22.7 |
| 1000 | 99.3 | 11.4 | 20.8 |
| 1100 | 99.4 | 11.8 | 19.2 |
| 1200 | 99.3 | 10.9 | 17.7 |
| 1300 | 99.2 | 10.6 | 16.5 |
| 1400 | 99.2 | 12.1 | 15.4 |
| 1500 | 99.2 | 10.0 | 14.6 |
| 1600 | 99.5 | 10.3 | 13.8 |
| 1700 | 99.4 | 10.7 | 13.0 |
| 1800 | 99.5 | 11.4 | 12.4 |
| 1900 | 99.3 | 10.8 | 11.8 |
| 2000 | 99.4 | 10.6 | 11.2 |
図27 オブジェクト数対各種平均特性(Unreal Engine)
Cocos Creatorで作成した実験用ソフトウェアについての説明を行う.そして,最後に測定したデータのまとめを実験の結果として示す.この実験の結果は,ゲームエンジンに対する評価の指標の一つとなる.
先に,Cocos Creatorの実験用ソフトウェアの内容と機能について述べる.Cocos Creatorの実験用ソフトウェアの画面を図28に示す.
図28 実際の実験用ソフトウェアの画面(CocosCreator)
Cocos Creatorの実験用ソフトウェアは,Cocos Creatorにおける性能評価を行うためのソフトになる.含んでいる機能としては図28のようにノードを画面中央に重ねて生成する機能と画面の上に現在のノード数を表示する機能がある.キーボードのzを押すとノードが1000個生成される.さらに,常時ノード数の表示を行う.
次は,使用したノードについて説明する.まず,ノードツリーウィンドウの状態を図29に示す.
図29 Node Treeの状態
図29の㉖のMain Cameraは,画面を映すためのカメラとなるノードである.㉗のcounterは,現在の測定対象ノードの配置数を表示するためのノードである.㉘のGame2は,対象ノードの生成から配置数の取得など,多くの役割を持ったノードである.実際の配置等は以下に示す.
図30 Main Cameraの状態(CocosCreator)
図30にはMain Cameraの状態を示した.Main Cameraは,実験用ソフトウェアの画面を移すカメラとなるノードである.測定対象のノードとの位置関係によっては対象のノードが画面外に生成される可能性がある.今回は,ノードの生成位置側をMain Cameraに合わせる形を取った.そのため,Main Cameraの座標は初期位置である.
図31 counterの状態
図31にはcounterの状態を示した.counterは,測定対象のノードの配置数を表示する領域となるノードである.他のゲームエンジンと同様に見やすい位置に調整する.字や枠のサイズについてはノードの配置数の桁が大きくなると枠からはみ出る可能性がある.なので,枠を少し大きくなるように調整した.
図32 Game2の状態
図32に示したのはGame2の状態である.Game2は,ノードの生成や配置数の出力を行うノードである.同名のスクリプトでノードの生成とカウントを行うGame2が割り当てられている.また,スクリプトの処理対象として生成するノードのプレハブと配置数を表示するためのノードが割り当てられている.
今度はスクリプトやプレハブについて説明する.
図33 スクリプトとプレハブ
図33に示したのが作成したスクリプトやプレハブのリストである.㉙のAaはシーンのファイルである.㉚のGame2は,実験用ソフトウェアのシステム全体を担うスクリプトである(付録 10).スクリプト内22行目でif文を用いてキーボードのzの入力を認識する.そして,25行目と26行目でinstantiateとaddchildを組み合わせてノードを生成する.さらに,while文を利用することで一度の入力に対してノードの生成文は1000回繰り返される.まとめると,一回zが入力されるごとにノードは1000個生成されることになる.また,生成されたノードはこのスクリプトが割り当てられたノード内に配置される.つまり,Game2ノード内にあるノードの数がシーンに配置されているノードの数になる.これを利用して,まずは237行目でGame2ノード内のノードの個数を数える.そして,その数を238行目で測定対象ノードの配置数として表示をさせるという仕組みになっている.㉛のtestobjは,測定対象となるノードのプレハブである.測定対象のノードの構築情報を含んでいる.
最後に,得られた計測結果をまとめたものを表5,それをグラフにしたものを図34に示す.
表5 オブジェクト数対各種平均特性(CocosCreator)
| オブジェクト数 | GPU使用率[%] | CPU使用率[%] | フレームレート[fps] |
| 0 | 15.9 | 9.9 | 59.9 |
| 10000 | 50.7 | 11.7 | 59.9 |
| 20000 | 78.9 | 16.7 | 59.9 |
| 30000 | 77.1 | 23.2 | 59.9 |
| 40000 | 77.3 | 28.0 | 59.7 |
| 50000 | 83.1 | 29.7 | 54.8 |
| 60000 | 82.7 | 29.8 | 46.7 |
| 70000 | 82.1 | 29.3 | 40.4 |
| 80000 | 82.1 | 29.0 | 35.9 |
| 90000 | 81.8 | 29.0 | 32.2 |
| 100000 | 81.7 | 28.8 | 29.1 |
| 110000 | 81.7 | 29.3 | 26.5 |
| 120000 | 81.6 | 28.1 | 24.5 |
| 130000 | 81.2 | 28.4 | 22.6 |
| 140000 | 81.5 | 28.3 | 21.3 |
| 150000 | 81.9 | 28.6 | 19.9 |
| 160000 | 81.3 | 27.8 | 18.6 |
| 170000 | 82.0 | 28.3 | 17.6 |
| 180000 | 80.4 | 29.2 | 16.4 |
| 190000 | 81.4 | 28.8 | 15.7 |
| 200000 | 81.1 | 29.0 | 15.0 |
図34 オブジェクト数対各種平均特性(CocosCreator)
実験の最後に,測定環境を表6に示す.
表6 測定環境
| 名称 | バージョン,スペック等 |
| OS | Windows 10 Home 64bit |
| グラフィックボード | Intel HD Graphics 520 |
| GPU | Intel HD Graphics Family |
| VRAM | 128MB |
| CPU | Intel Core i5-6200U CPU @ 2.30GHz 2.40GHz |
| RAM | 8.00GB |
| MSI Afterburner | Version 4.5.0 |
| Unity | Version 2018.2.19f1 personal 画面サイズ:800×600 画質:Very low |
| Unreal Engine | Version 4.21.1 全グループの品質:低 画面サイズ:400×225 |
| Cocos Creator | Version 2.1.0 画質等は全て初期設定 |
ここでは,実験結果から各種ゲームエンジンの評価をしていく.まずは共通した特徴等を考える.
図35 GPU使用率の比較
図35に図20,27,34のGPU使用率の部分のみを抜き出して重ねたグラフを示す.データの不足している部分は予測値になる.これを見ていくとUnityとUnreal EngineではGPU使用率が約100%に達している.したがって,UnityとUnreal Engineでは特に高い割合までGPUを使っていることが見て取れる.一方で,Cocos CreatorはGPU使用率は約80%までしか達していない.つまり,UnityとUnreal Engineと比較すると少し低くなっていることになる.まとめると,UnityとUnreal Engineでは,負荷が大きくなった時にGPUの性能を最大まで活用できていることになる.逆にCocos CreatorはGPUの性能を引き出しきれていないことになる.
図36 CPU使用率の比較
図36に示したのは,図20,27,34のCPU使用率の部分のみを抜き出して重ねたグラフである.データの不足している部分は予測値となる.これを見るとCPU使用率は比較的傾向の違いが大きい.しかし,GPU使用率程高い割合になることは無い.具体的には使用率が一番高くなるCocos Creatorでも最大約30%と半分の50%に満たない.したがって,ゲームエンジンではGPUと比較するとCPUはあまり利用されていないことになる.
図37 フレームレートの比較
図37に示したのは,図20,27,34のフレームレートの部分のみを抜き出して,重ねたグラフである.これを見てみるとゲームエンジンによってフレームレートの減少開始のタイミングが異なっている.その一方で,減少してからは同様の傾向になっている.
ここでの評価は,表3と図20を参照して行う.GPUの部分で見ると,使用率は最大でほぼ100%の状態になっている.つまり,Unityは,必要に応じてGPUを最大まで活用できる長所を持っていることになる.それに対してCPUの使用率は最大でも約20%になっている.
ここでの評価は,表4と図27を参照して行う.GPUの部分はUnityと同様で,最大でほぼ100%まで使われている.そのため,Unreal Engineは,必要であればUnity同様にGPUを最大まで活用できる長所を持っていることになる.CPUに関しては,使用率は終始約10%に張り付いている.よって,オブジェクトに対して負荷がかかるということはほとんど無いという特徴が見て取れる.また,表3と表4のフレームレートとオブジェクト数の部分でオブジェクトの負荷をUnityと比較をしてみる.フレームレートが落ちて約50fpsの時のオブジェクト数はUnityが1500でUnreal Engineが300である.よって,フレームレートで見た時のUnreal Engineのオブジェクトの負荷は,Unityの5倍に及ぶことになる.
ここでの評価は,表5と図34を参照して行う.UnityとUnreal Engineと同じように,まずはGPUの部分から見ていく.GPU使用率はそれなりに高い割合にはなっている.しかし,最大でも約80%になっている.よって,Cocos Creatorは,負荷が大きくなってもGPUを活用しきれていないことになる.ただし,CPUと比べれば積極的に利用はしている.CPUはUnityと同様に使用率は上昇していく.ただし,最大は30%程度と多少差があることが分かる.よって,Cocos Creatorは,比較的CPUに使用率が偏ったゲームエンジンということになる.今度は,表3と表5のフレームレートとオブジェクト数の部分でオブジェクトの負荷をUnityと比較する.フレームレートが落ちて19.9fpsの時のオブジェクト数はUnityが4000でCocos Creatorが150000である.よって,フレームレートで見た時のCocos Creatorのオブジェクトの負荷に対してUnityは37.5倍でUnreal Engineでは187.5倍にもなる.
実験結果から,主に図35でGPUはどのゲームエンジンにおいても積極的に利用されていることが分かった.このことから,CPU等他のハードウェアと比較しても,コンピュータゲームにおけるGPUの性能の重要性というものが透けて見える.
先述のように,実験結果からGPUの重要性が見えてきた.それに加えて,そもそもコンピュータゲーム自体がGPUの代表的な用途という話もある.1990年代後半からは3Dのコンピュータゲームが出てくると共に,3D描画能力の向上も求められた.さらには,ゲーム機専用のGPUの開発まで行われていた.
当時のゲーム機のGPUは,同世代の下位,中位のパソコンのGPUよりも,高い画像処理性能を持っている.例えば,1994年にSCEのPlayStationが発売された.このPlayStationには,パソコン用のGPUより,4年ほど先行してハードウェアジオメトリエンジンが搭載されている.ジオメトリエンジンは,3次元コンピュータグラフィックスにおける座標変換を,専門的に行うものである.他にも,1996年には任天堂からNINTENDO64が発売された.NINTENDO64では,座標計算や音声処理を全て内臓DSPで行う構造になっている.これは,現代でいえば頂点シェーダーによるGPGPUを行う事に相当し,先鋭的なものであるといえる.また,頂点シェーダーは位置座標や法線ベクトルなど,頂点の属性を変換する機能である.そして,GPGPUは,GPUの特性を活かした一種の手法である.具体的には,GPUの演算能力をグラフィックだけでなく数値演算にも利用することがGPGPUのコンセプトである.
パソコンにおいても,1995年にVoodooというGPUが開発された.これと同時に,パソコンゲーム用に最適化されたAPIであるGlideも用意された.この組み合わせにより,当時のアーケードゲームに肉薄する品質のグラフィックを実現していた.1990年代後半は,このVoodooシリーズによって,家庭用パソコンゲームの品質向上を促した.
近年になると,ゲーム機のGPUは,AMDやNVIDIA製のものが主に使用されている.また,新しいゲーム機であるPlayStation 4とXbox Oneにおいては,GPGPUを重視したアーキテクチャになっている.したがって,ゲーム機では今まで以上にGPUを活用しているという事になる.
よって,これらの事から,コンピュータゲームにおけるGPUとその性能は,他のハードウェアと比較して極めて重要であることが伺える.
また,GPUの重要性を示したところで,今度はGPUとゲームエンジンの将来について考えてみる.性能の高いGPUは,GPGPU等の存在からグラフィック以外にその性能が回されているということになる.よって,コンピュータゲームにおけるGPUは,グラフィックに性能を回しても余る限りはGPGPUをメインにしたコストの削減能力が求められてくると考えられる.ゲームエンジンについても,特にUnityやUnreal EngineではGPUの利用は既に積極的にされていた.よって,今後のゲームエンジンは,処理の手法等を改良して効率化が図られていくことが考えられる.
本研究では各種ゲームエンジンで実験を行った.具体的には,オブジェクトによるパソコンのハードウェアへの負荷の測定という内容であった.さらに,実験結果からゲームエンジンに対する評価を行った.その結果,ゲームエンジンは,GPUを積極的に利用しているということが判明した.このことから,ゲームエンジンにおけるGPUの重要性が伺える.一方で,比較的CPUを利用しない事も分かった.
また,考察においてはコンピュータゲームにおけるGPUの重要性に対して裏付けを行った.加えて,コンピュータゲームにおけるGPUとゲームエンジンの将来についても考えた.具体的には,コンピュータゲームにおけるGPUは,GPGPUをメインにしたコストの削減がされていくと考えた.一方で,ゲームエンジンは,手法を改良した効率化が行われると考えた.
今後の課題としては,まずは測定するパソコンのハードウェアやゲームエンジンの種類を増やす事.さらに,多機種のパソコンで行うことが挙げられる.特に,測定対象のパソコンのハードウェアを増やすことで新しい特性が得られる可能性がある.また,今回はオブジェクトを多数設置するという手法で実験を行った.しかし,ゲームエンジンで出来ることは極めて多い.そのため,他のパソコンのハードウェアから特性を得る以外に,違う観点からだとどういった結果が得られるか確かめることも課題であるといえる.
[1]ゲームエンジン - Wikipedia
URL - https://ja.wikipedia.org/wiki/ゲームエンジン
[2]もう迷わない！ゲームエンジン6つと制作ツール2つを徹底比較！
URL - https://atoz-gamedia.com/2018/10/02/gameengine-osusume/
[3]Afterburner
URL - https://www.msi.com/page/afterburner
[4]Unity
URL - https://unity3d.com/jp
[5]Unreal Engine 4 とは？
URL - https://www.unrealengine.com/ja/what-is-unreal-engine-4
[6]Cocos2d-x ? World's #1 Open-Source Game Development Platform
URL - http://www.cocos2d-x.org/
[7]Graphics Processing Unit - Wikipedia
URL - https://ja.wikipedia.org/wiki/Graphics_Processing_Unit
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class Counter : MonoBehaviour {
public UnityEngine.UI.Text SphereCount;
// Update is called once per frame
void Update () {
int count = GameObject.FindGameObjectsWithTag("Sphere").Length;
SphereCount.text = count.ToString();
}
}
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class frame : MonoBehaviour {
private void Awake()
{
Application.targetFrameRate = 60;
}
}
using System.Collections;
using System.Collections.Generic;
using UnityEngine;
public class SD : MonoBehaviour {
public GameObject SpherePrefab;
int i,j;
// Use this for initialization
void Start () {
i = 0; j = 0;
}
// Update is called once per frame
void Update () {
if (Input.GetKey("z")) {
if ((i == 0) || (i > 60))
{
while (j < 500)
{
Instantiate(SpherePrefab);
j++;
}
j = 0;
}
i++;
}
else
{
i = 0;
}
}
}
図38 レベルブループリントその1
図39 レベルブループリントその2
図40 レベルブループリントその3
図41 レベルブループリントその4
図42 Collapse Graph 0の中身
図43 Sphereの生成部分
cc.Class({
extends: cc.Component,
properties: {
testobjPrefab: {
default: null,
type: cc.Prefab
},
counter: {
default: null,
type: cc.Label
},
i: 0,
},
// LIFE-CYCLE CALLBACKS:
onLoad () {
cc.systemEvent.on(cc.SystemEvent.EventType.KEY_DOWN, this.onKeyDown, this);
},
onKeyDown (event) {
if (event.keyCode == cc.macro.KEY.z) {
while(this.i < 1000){
var newTestobj = cc.instantiate(this.testobjPrefab);
this.node.addChild(newTestobj);
this.i++;
}
this.i = 0;
}
},
start () {
},
update (dt) {
let count = this.node.childrenCount;
this.counter.string = count.toString();
},
});