特集：マルチプラットフォーム対応ゲーム開発環境「Unity」
開発者から見た、Unityの技術的な魅力
スマートフォン向けのゲーム開発などで人気のUnity。その人気の理由はどこにあるのか？ Unity社の筆者が「開発者から見た、Unityの技術的な魅力」をまとめる。
最近、特にスマートフォン向けのゲーム開発で、Unity（＝WindowsとMac OS X上で動作する統合型のゲーム開発環境。iOS、Android、Windows、Mac OS X、Web、Wii、PlayStation 3、Xbox 360などさまざまなプラットフォーム向けに3DアプリをC#言語などで記述できる）が多く使われだしている。なぜそれほどUnityの人気が高まっているのか。本稿では、筆者なりに「開発者から見た、Unityの技術的な魅力」をまとめ、その人気の秘密を考察する（以降、「PlayStation」は「PS」と略す）。
「PS Vita／PS4／PSM（PS Mobile）／Wii U」への対応
つい先月のことだが、「UnityがSCE（＝家庭用ゲーム機器の“PS”シリーズを開発・販売するメーカー）と戦略的提携を行うことに合意した」というニュースがあった。この提携により、Unityは上記の見出しのとおり、各PSプラットフォームに最適化した機能を今秋（予定）に提供することになり、つまり名実ともにトップ・レベルのマルチプラットフォーム対応ゲーム・エンジンに進化していくといえるだろう。
実はUnityは、前々からVita対応に挑戦していた。しかし、実用化にまでは至らず挫折を経験した過去がある。それが今度こそ、正式にVita対応することになる。ちなみに、Unityで作られたVita向けのゲームがすでに存在するのだが、そちらはUnity自体のソース・コードを購入し、独自でVita向けに改良を行ったものだ。
Unityの内容説明に入る前に、まずはUnityの利用実態を紹介しよう。
世界でUnityはどのくらい使われているのか
現在、Unityを利用したことがある開発者は180万人以上にもなる（次のグラフを参照）。2010年が30万に程度だったので、この利用者の増加ペースで行けば200万人を超えるのもそう遠くはないだろう。
Unity製のゲーム・ユーザー数についても、アジア圏を中心に拡大してきている。
Unity Web Player製のゲームでは圧倒的に中国
Unity Web Playerとは、Webブラウザー上でUnity製のゲームをプレイするためのプラグインである。その利用率は、24.6％と圧倒的に中国が多い（次のグラフを参照）。その次に多い米国が11.7％なので、中国の利用者数は2位以降と倍以上の差がある。ちなみに日本は0.7％となっており、同じアジア圏でもUnityの使われ方には大きな違いがあるのが分かる。
このほかにも、さまざまな利用率の統計情報がUnityサイト上で提供されている。例えばAndroid／iOSの国別の利用率情報を確認したりできる。ぜひともチェックしていただきたい。
それでは本題に入ろう。
なぜこんなにUnityは使われているのか
今回は、さまざまな部分からUnityの素晴らしさを開発者視点でお伝えできればと思う。
開発手法
トライ＆エラー
Unityでは、「試してエラーを見付け、修正する」というトライ＆エラーによる開発が一般的となっている。これが簡単に実現可能なのは、Unityエディターの中に、実機そのままのゲーム画面を表示する機能（次の画面を参照）が搭載されているからだ。
左下がゲーム画面、左上が編集画面となっている。この画面の上部にある再生ボタン（＝［▶］）を押せば、ゲーム画面で実際にプレイできる仕組みとなっている。
実行時にすぐ修正
Unityは、再生ボタンを押してのゲーム実行時でもパラメーターやオブジェクトを調整することができる。次の画面は実際に、ゲーム実行時に赤外線ゲートを追加しているところだ（右側の青い部分が追加されている）。
Unity Remote（Android／iOS）について
「Unityにはゲーム画面がある」といっても、そのUnityエディターはPC上で動作している。従って、モバイル端末のタッチ・イベントなどは入力できない。だが、「Unity Remote」というアプリを使えば、その問題は解決する。
Unity Remoteで、どのようなことができるかは動画を見てもらった方が早い（次の動画を参照）。
Unity Remoteのデモ動画
Unity Remoteは、AndroidはUSB経由、iOSはWi-Fi経由でモバイル端末にゲーム画面のキャプチャ画像を転送し、Unityエディターにタッチ／センサー系のイベントを転送している。このように、ある程度であれば、ビルドして.apkファイル（＝Androidアプリ用の配布パッケージ・ファイル）や.ipaファイル（＝iOSアプリ用の配布パッケージ・ファイル）を生成せずにモバイル端末特有のイベントの調整も行えるようになっている。
【参考情報】
Unityの魅力
アセット・ストア
続いては、Unity独自のマーケット「アセット・ストア（Asset Store、英語サイトのみ）」を紹介する。次の画面はアセット・ストアの表示例だ。
アセット・ストアには、Unity開発者がゲームを作るうえで必要なアセット（＝モデル、テクスチャ、スクリプト、ライブラリ、ネットワーク・サービスなどさまざまなもの）が販売されている。その価格は無料から有料まで幅広い。アセット・ストアの一番の特長は、開発者自身がアセットを売りに出せるという点だ。「ゲーム開発中に便利なものが作れたから売りに出す」ということが可能なのである。
現在（執筆時の2013年4月20日時点）で7300点以上ものアセットが登録されている。Unityのためのアセットということもあり、すぐに使えるものばかりだ。次の画面は、すぐに使えるUnity用の3Dモデルの例である。
プロファイラー
Unityがどのような処理を行っているか知りたいときもあるだろう。Unityでは、プロファイラー（Profiler）という機能を使い、処理を監視することができる。次の画面は、実際にプロファイラーを用いてCPUの利用率を監視している例だ。
Unityの最新バージョンでは、次の画面例のようにメモリについても詳しく把握できるようになった。
プロファイラー以上の情報を知りたい場合は、Xcode（＝Mac向けの開発環境）のInstruments解析ツール（次の画面を参照）の利用をお勧めする。
エディター拡張
実はUnityは完成度が常に8割程度となっている。そのようにしているのは、「これ以上のものはユーザー（つまり開発者）自らの手で実装してほしい」という狙いがあるからだ。ユーザーはスクリプトによってUnityエディターの拡張（以降、エディター拡張）を行い、残りの2割を補うことで、ユーザーごと＆プロジェクトごとに最適化されたUnityが完成する。
どのようなときにエディター拡張が必要か
実は、この質問に筆者が誰もに共通する答えを示すことはできない。「○○だから、エディター拡張が必要だ」とは言えないのである。
というのも、開発者本人が「この部分が不便だ」や「こうした方がよい」と感じた部分でないと、エディター拡張したものが十分に生かされないからだ。プロジェクトによって必要な拡張部分は違う。そのことを頭に入れておいてほしい。
エディター拡張で何ができるか
今回は全てを紹介できないのだが、主に使われるであろう機能をご紹介したいと思う。
アセットのインポート
アセットのインポート設定をスクリプトから制御できる。これについて、Unityの「Texture Import Settings」の［Texture Type］を例に紹介する。
Unityの開発者であれば、［Texture Type］を「Texture」ではなく「GUI」や「Advanced」など、ほかのTypeに変更して使用することはないだろうか。さらにそのときに「自動で［Texture Type］を変更してくれればよいのに……」と思ったユーザーも少なくはないだろう。
次の画面はインポート直後の「Texture Import Settings」の画面だ。この例を見ると分かるように、アセットのインポート直後の［Texture Type］の値は常に「Texture」になる。
この値を自動で「GUI」に変更されるようにしたい場合、インポート処理の前に［Texture Type］を「GUI」に変更するためのエディター拡張用のスクリプトを記述すればよい。具体的には下記のC#ソース・コードのようになる。
|
using UnityEditor;
public class NewBehaviourScript : AssetPostprocessor
{
void OnPreprocessTexture()
{
TextureImporter importer = assetImporter as TextureImporter;
importer.textureType = TextureImporterType.GUI;
}
}
|
上記のコードにより、テクスチャはGUIでインポートされる。
特定のテクスチャに限定したいのであれば、アセットのパスで判断を行って分岐すればよいだけだ。見てのとおり、非常に少量のコードでインポート設定を変更することができた。
アセットの移動／削除
次に、アセットを厳密に管理したいときにもエディター拡張が力を発揮する。
まずは下記のC#ソース・コードを見てほしい。
|
using UnityEditor;
using System.IO;
public class NewBehaviourScript : UnityEditor.AssetModificationProcessor
{
static AssetMoveResult OnWillMoveAsset(string oldPath, string newPath)
{
string path = "Assets/Required Assets";
if (Path.GetDirectoryName(oldPath).StartsWith(path)
&& !Path.GetDirectoryName(newPath).StartsWith(path)) {
return AssetMoveResult.FailedMove; // Don't move.
}
return AssetMoveResult.DidNotMove;
}
}
|
上記のコードは、「Assets/Required Assets」フォルダ配下からアセットを移動させないためのスクリプトだ。このようにアセットの移動を抑制することができる。アセットの削除も同様で「OnWillDeleteAsset」メソッドを使用すればアセットの削除を抑制できる。
ビルド
通常、Unityでのビルドは「Build Settings」から行う。しかし、ビルド自体はエディター拡張用のスクリプトからでも実行可能だ。例えば次のC#コードは、AndroidとiOSを連続でビルドするためのスクリプトである。
|
using UnityEditor;
using UnityEngine;
using System.Linq;
public class NewBehaviourScript
{
[MenuItem("Build/Android & iOS")]
public static void Build()
{
BuildPlayer("Android.apk", BuildTarget.Android, BuildOptions.None);
BuildPlayer("iOS", BuildTarget.iPhone, BuildOptions.None);
}
static void BuildPlayer(string location, BuildTarget target, BuildOptions options)
{
Directory.CreateDirectory("Build");
BuildPipeline.BuildPlayer(GetLevels (), "Build/" + location, target, options);
}
static string[] GetLevels()
{
return EditorBuildSettings.scenes.
Where(scene => scene.enabled).Select(scene => scene.path).ToArray();
}
}
|
上記のようなスクリプトを作成することで、手動で［Build Settings］の［Platform］を「Android」や「iOS」に切り替えて［Switch Platform］を実行し、それぞれのプラットフォームごとにビルドする必要がなくなるため、非常にスムーズな開発が実現できる。少なくとも筆者は［Switch Platform］によってコンバート完了まで待つときのストレスが無くなり、大変助かっている。
エディター拡張についてはまだまだ語りたいことがあるのだが、今回はこれくらいにしておこう。筆者としては、Unityの技術面で最も魅力的なのは、このエディター拡張だと思っている。「もうちょっとここが使いやすくなれば……」というのはプロジェクトまたは人によって違う。その部分をエディター拡張スクリプトによって自由に拡張できることは大変素晴らしいことだと思っている。読者も「もうちょっとここが使いやすくなれば……」と思っているところがあれば、エディター拡張スクリプトに手を出してみるのはいかがだろうか。
■
開発環境の技術的な側面からUnityを見てみたが、いかがだっただろうか。興味を持った方は、ぜひ一度、Unityの開発環境に触れてみてほしい。
