Unity

[アーティクル]
01/02/2015

Unity と C# を使用した初めてのゲーム開発 (第 4 部)

Unity ゲーム開発シリーズもいよいよ最終回です。アプリ市場が初めて爆発的に広がったときのことを覚えていますか。だれもがその流れに乗ろうとし、あらゆるものを対象にしたアプリが生み出されました。しかし、何億兆にも上るアプリがリリースされたことで、ユーザーは目的のアプリをなかなか見つけられなくなりました。市場のどこにアプリがあるかわからないのは、開発者にとって深刻な問題です。Windows ストア/Windows Phone ストアは、地球上で他を圧倒する市場とは言えません。しかし、これらのストアをターゲットにアプリを開発しても意味がないと考えるのは、まったくの間違いです。この市場には、アプリを見つけてもらう絶好のチャンスが用意されています。この市場でアプリがお勧めとして取り上げられたという話をよく耳にします。あらゆるプラットフォームの多くの開発者と話をしてきましたが、他のプラットフォームでお勧めに取り上げられたという開発者は 3 人しか知りません。

そこで、今回は、Unity で開発したゲームを Windows に移植するプロセスを取り上げます。プロセスは非常に単純で、すばらしいプラットフォーム統合が可能になり、比較的簡単にゲームに実装できます。Unity 4.5 からは、新しいユニバーサルプロジェクト (Windows Phone と Windows ストアのパッケージを共有コードと一緒に生成するソリューション) をサポートするすばらしいツールもいくつか用意されています。

作業中は、「テストは早い段階で頻繁に繰り返す」というよく知られた言葉を肝に銘じます。ソフトウェア開発に関するこの優れた格言を耳にしたことがないとしても、これはゲーム開発に当てはまる貴重な格言です。ただし、今回は少し変更して、「テストは早い段階にデバイスで行い、デバイスで頻繁に繰り返す」とします。どのプラットフォームをターゲットにするにしても、デバイスごとに動作は予想以上に異なります。

プラットフォーム

マガジンの読者であれば、おそらく Windows エコシステムについてご存じでしょう。このエコシステムの中で Unity がサポートするプラットフォームは、Xbox 360、Xbox One、Windows Phone 8/8.1、Windows 8/8.1 (Windows ストアアプリ)、およびデスクトップです。Xbox を除くこれらすべてのターゲットを無料バージョンの Unity で選択できます。ビルドオプションに Xbox が表示されますが、Xbox One の ID プログラムに参加しない限りビルドできません。Xbox 360 の場合は、承認された発行元を通じて登録する必要があります。魅力的なゲームに取り組んでいる方は、xbox.com/Developers/id の ID プログラムを確認してください。Windows Phone と Windows ストアのビルドプロセスは非常によく似ています。

Windows Phone と Windows ストアのビルドオプションには、Silverlight を使用する Windows Phone 8 アプリ、Silverlight または Windows ランタイム (WinRT) を使用する Windows Phone 8.1 アプリ、Windows 8 アプリ、Windows 8.1 アプリ、および Windows Phone 8.1 と Windows 8.1 を対象とするユニバーサルアプリがあります。

Windows 向けのビルド

Unity でのビルド作成はかなり簡単です。ローカルにテストするには、ビルドダイアログ ([File] (ファイル)、[Build Settings] (ビルド設定)) を表示して、[Build] (ビルド) をクリックし、出力フォルダーを選択するだけです。[Build and Run] (ビルドして実行) オプションを選択すると、コンパイル後、選択したプラットフォームに応じて、接続された携帯電話またはローカルシステムでゲームが起動します。基本はこれだけです。ビルドに成功すると、選択したフォルダーが開きます。このフォルダーには、実行可能ファイルか、Visual Studio ソリューションが含まれます。エラーは [Console] (コンソール) ウィンドウに表示されるので、[Window] (ウィンドウ) メニューで設定して、このウィンドウを必ず開いておくようにします。[Console] ウィンドウを開いていない場合は、エディターウィンドウの一番下のステータスバーに 1 行表示される赤いメッセージに注意します。これはあまり目立ちませんが、一度その存在に気付けば、忘れることはありません。

すべてのビルドに共通: Unity ではビルドを "プレーヤー" で実行します。Unity は、前述のさまざまなプラットフォームすべてに対してプレーヤーをサポートします。ゲームのビルドを作成する際、必要なシーンをすべてビルドに追加する必要があります。ゲームにさまざまなシーン (既定で読み込まれる最初のシーンを除く) を読み込むには、Application.LoadLevel を使用して、Application.LoadLevel("Level1") のようにシーン名を渡すか、Application.LoadLevel(2) のようにインデックスを渡します。後ほど説明しますが、シーンの順序は簡単に変わるため、個人的には、インデックス手法を好みません。

コードで読み込むステージはすべてビルドに追加します。ビルドに追加するシーンは、[Build Settings] ダイアログで [Add Current] (現在のシーンを追加) ボタンをクリックするか、ビルドダイアログにシーンファイルをドラッグアンドドロップします。ここでは、シーンの並べ替えも可能です (繰り返しになりますが、シーンは簡単に並べ替えられるため、インデックスを使用してシーンを読み込むのは危険です)。シーンのチェックボックスをオンまたはオフにすることで、ビルドでのシーンの有効/無効を切り替えられます。その手順は次のとおりです (図 1 参照)。

シーンをビルドに追加します。
必要なシーンのチェックボックスをオンにします。通常は、ローカルビルドではテストシーンをオンにし、最終ビルドではオフにします。
ビルド対象のプラットフォームを強調表示します。
[Switch Platform] (プラットフォームの切り替え) をクリックします。これにより、Unity は選択したプラットフォームに合わせてアセットを準備し、UNITY_METRO、UNITY_IPHONE、UNITY_WEBPLAYER などのプラットフォーム固有のプリプロセッサ定数を有効にします。
プラットフォーム固有のパッケージにゲームをビルドします。

図 1 ビルドにシーンを追加する

Windows デスクトップの場合: Unity を開くと、スタンドアロン (デスクトップ) ビルドが既定で設定されています。このビルド設定を使用すると、Unity は Mono を使用してゲームアセンブリをコンパイルし、ランタイムエンジンと一緒にパッケージ化します。その結果、すべてがパッケージ化されたフォルダーと実行可能ファイルが得られます。このビルドは、ほとんどのデスクトップビルドと同様、シンプルです。

Windows ストアと Windows Phone の場合: お楽しくみはここからです。Windows ストアと Windows Phone にエクスポートすると、実にすばらしいプラットフォーム統合を体感できます。ライブタイルに無料ゲームのクレジットを表示してユーザーを引き込む、テキストメッセージを送信する、位置認識を使用するなど、さまざまなことが可能です。注目すべき点は、プラットフォーム固有の機能をゲームに統合するのが比較的簡単なことです。

ダイアログで簡単に [Build and Run] を実行して、動作する Windows ストアアプリや Windows Phone アプリをすばやくテストできるのは同じですが、デスクトップビルドとはビルドプロセスが若干異なります。

プラットフォーム固有のコードが Unity ゲームのどこに組み込まれるかを理解するため、Unity でコードがコンパイルされるしくみをみてみましょう。Unity エディターで実行されるコードは、ライセンス版の Mono によってコンパイルされます。そのため、エディターでゲームを実行しているときは、GeoLocation などの WinRT (Windows ストア/Windows Phone 8.1) API 呼び出しはできません。これは Mono に存在しない WinRT 固有のメソッドがあるためです。同様に、Hashtable や System.IO を使用する従来の .NET ファイルアクセスなど、Windows ランタイムに存在しない Mono の機能もあります。Mono と Windows ランタイムには共通部分が多数ありますが、これらは別の API であるため、異なる部分もあると考えてください。

Windows ストア用にプロジェクトをビルドすると、Unity はゲームアセンブリのコンパイルに Microsoft .NET Framework を使用します。アセンブリのコンパイルには、既定で .NET Core が使用されます。.NET Core は、事実上 WinRT .NET そのものです。プラットフォーム固有のコードをコンパイルする場合、その特定のプラットフォーム用にコンパイルするときにその方法を Unity に指定します。

プラットフォーム固有のコードを使用する方法は、主に 2 つあります (Unity と Visual Studio ソリューションコード間の操作を結び付ける、ブリッジと呼ばれる 3 つ目の手法もありますが、使用頻度がはるかに少ないため、ここでは説明しません)。1 つ目の手法では、プラグインを使用します。プラグインは独自に作成することも (非常に簡単です)、いくつかの優れたソースからダウンロードすることもできます。本稿執筆時点では、Windows ストアと Windows Phone 用の prime31.com プラグインが無償で提供されています。事実上、Unity を使用するすべての大手発行元がゲームプロジェクトでプラグインを使用しています。今のうちにプラグインを入手してください。これは非常にお得です。

プラットフォーム固有のコードの使用

プラグインを使用: Unity のプラグインモデルでは、同じメソッドシグネチャを持つ 2 つのバージョンのライブラリを使用します。1 つは、.NET Framework 3.5 に対してコンパイルされる、事実上スタブバージョンのライブラリです。Assets\Plugins\YourPlugin.dll に配置されます。ゲームをエディターで実行する際に Unity が使用するのがこのバージョンです。もう 1 つは、ターゲットプラットフォーム (Windows ストアまたは Windows Phone) 用にコンパイルされるライブラリで、Unity からビルドを作成する際にゲームにパッケージ化されます (図 2 参照)。

図 2 プラグインによってプラットフォーム固有のコードを使用してビルドする

プラットフォーム固有のライブラリは、Assets\Plugins\<プラットフォーム>\YourPlugin.dll に配置されます (<プラットフォーム> には Windows 8.x、iOS、Windows Phone 8 などが入ります)。既に公開されている多数のプラグインの 1 つをダウンロードするのではなく、プラグインを自作する場合は、bit.ly/1EuLV1N (英語) で基本手順を参照してください。各プラグイン（当然ながらプラットフォーム API 以外）の主な違いは、プラットフォーム固有の dll を配置する場所です。プラグインの場所は bit.ly/1v2ml1m (英語) で確認できます。

ここで prime31 プラグインの 1 つを使用してライブタイルを設定するには、シーン内の任意の GameObject に 図 3 のコードをアタッチするだけです。SettingsPane と Tiles クラスは、プラットフォーム固有のコードを実装する機能を含むプラグインです。

図 3 Prime31 プラグインのコード

public class WindowsStoreAppSettings : MonoBehaviour
{
  private void Start()
  {
#if UNITY_METRO // A preprocessor directive to run when Windows Store
                // build is selected in Unity.
  SettingsPane.registerSettingsCommand("Privacy Policy",
    "This is my privacy policy. Consider a url as well to bring you to the site.");
  // Set the live tile. You can set a source as an Internet URL, as well.
  // This is not the Unity assets folder.
  // You'll want to make sure this image appears in the
  // generated Visual Studio project because it won't get
  // pushed from Unity in any way.
  var images = new string[] { "ms-appx:///assets/WideLiveTile.png" };
  Tiles.updateTile(TileTemplateType.TileWideImage, null, images);
#endif
  }
}

プリプロセッサディレクティブを使用: プリプロセッサディレクティブを使用して、インラインコードのコンパイルを有効または無効にすることもできます。これは、さまざまなテクノロジをプラットフォーム間でコード共有する場合によく使用される手法で、Unity ゲームでも頻繁に使用されています。この手法は、コードクラスでディレクティブを使用するだけです。プリプロセッサディレクティブはさまざまな目的に使用できます。忘れてはならない重要な規則は、プラットフォーム固有のプリプロセッサディレクティブを使用してプラットフォームごとにコードを分けること、一部のプリプロセッサディレクティブは Unity ビルド設定を切り替えるときにアクティブになること (UNITY_METRO など)、一部のプリプロセッサディレクティブはエディター外でのコンパイル時にのみアクティブになること (NETFX_CORE)、およびそれ以外のプリプロセッサディレクティブは常にアクティブであること (Unity バージョンの確認 (UNITY_4_5)、その他のユーザー定義のカスタムディレクティブなど) です。

Windows プラットフォーム固有のコードを使用する例を示します。Windows ランタイムの GeoLocation にアクセスする場合、MonoBehavior 派生クラスをこのコードに直接含めることができます (図 4 参照)。これは、任意の GameObject に割り当てることができます。このコードは、エディターで Mono を使用してコンパイルされるため、コードがプリプロセッサディレクティブにラップされず、エラーになります。Unity に、このコードをエディター以外でのみコンパイルするよう指定する必要があります。NETFX_CORE と UNITY_METRO の違いを疑問に思うかもしれません。前者はコンパイル設定で、ゲームアセンブリが Windows ランタイム用にコンパイルされる場合にのみ使用されます。後者は、Unity ビルド設定でプラットフォームに Windows ストアを選択した場合に使用されます。これは、C#、UnityScript、または Boo コードでアクティブにできます。個人的には、WinRT コードのラップには UNITY_METRO ディレクティブよりも NETFX_CORE ディレクティブの使用をお勧めします。NETFX_CORE はエクスポート/ビルドでのみ使用可能であり、UNITY_METRO は [Build Settings] でプラットフォームを切り替えたときにエディターでアクティブになるためです。つまり、エディター内でコードを実行できるので、コードにプラットフォーム固有の API が含まれる場合、問題が発生する可能性があります。他の && !UNITY_EDITOR などのディレクティブを同じ行に追加できますが、ここでは NETFX_CORE だけを使用しています。

図 4 地理位置情報を使用する

public class FindLandTarget : MonoBehaviour
{
// If you’re compiling for the Windows Runtime, use this code
// to GeoLocate on object collision.
#if NETFX_CORE
  void OnCollisionEnter(Collision collision)
  {
    Debug.Log("Collided with " + collision.gameObject.name);
    GetGeoLocation();
  }
  async void GetGeoLocation()
  {
    // Must call geolocation on the UI thread, there's a UI piece to be shown.
    UnityEngine.WSA.Application.InvokeOnUIThread(
      async () =>
        {
        var locator = new Windows.Devices.Geolocation.Geolocator();
        var position = await locator.GetGeopositionAsync();
        Debug.Log(string.Format("{0}, {1}  Accuracy: {2}",
          position.Coordinate.Latitude, position.Coordinate.Longitude,
          position.Coordinate. Accuracy));
        }, false
            );
    /**/
  }
#else // When you’re not using the Windows Runtime, use this collision code instead.
  void OnCollisionEnter(Collision collision)
  {
    // Non-Windows Runtime platforms, no geolocation.
    Debug.Log("Collided with " + collision.gameObject.name);
  }
#endif
}

ビルド

Unity は、.NET Framework (具体的には Windows ランタイム) を使用して Windows ストアおよび Windows Phone 8.1 のコードをコンパイルします。Silverlight for Windows Phone 8.1 は使用しません。ただし、Windows Phone 8 コードは想定どおり、HH (Windows Phone 用 Silverlight パッケージ) としてコンパイルされます。

Unity はゲームアセンブリをコンパイルし、Visual Studio ソリューションを作成します。このソリューションは、最終ビルドの作成に使用します。つまり、デスクトップビルドを行う場合は別として、Windows ストアや Windows Phone ストアにゲームを送信する前に、Visual Studio で最終コンパイルを行う必要があります。生成された Visual Studio ソリューションには、ゲームアセンブリと基本的な XAML/C# または C++ ホストアプリと一緒にパッケージ化された Unity バイナリが含まれます。Unity でビルドするたびに Unity によって上書きされるのは Data フォルダーだけです。カスタムコードや Visual Studio ソリューションへの変更は、Unity でのその後のビルド中に上書きされません。

Windows ストアとユニバーサルアプリのビルド

図 5 に示す Windows ストア用のビルドオプションを見ていきます。Unity の Windows ストアのビルドの種類には、Windows 8、Windows 8.1、Windows Phone 8.1、およびユニバーサルソリューションがあります。ユニバーサルソリューションには、Windows Phone 8.1 プロジェクト、Windows 8.1 プロジェクト、および共有プロジェクトが含まれます (図 6 参照)。また、図 5 の [Unity C# Projects] (Unity C# プロジェクト) チェックボックスに注目してください。これは使用を強くお勧めする非常に便利な機能です。このチェックボックスをオンにすると、Visual Studio ソリューションが Unity コードを含む追加のプロジェクトと一緒に作成されます (図 7 参照)。これらのプロジェクトのコードは多少変更してもかまいません。コンパイル時に Visual Studio では Unity に対してゲームアセンブリの再処理が要求されるので、Unity でフルビルドを行う必要はありません。つまり、最終的な Visual Studio ソリューションで Unity コードを編集できます。コードを変更するたびに Unity でソリューションをリビルドする必要がないので、プラットフォームのデバッグにとってすばらしい機能です。

図 5 Windows ストア用にビルドする

図 6 共有プロジェクトのあるユニバーサルアプリ

図 7 追加プロジェクト

Unity で Visual Studio ソリューションを生成する場合の注意点がいくつかあります。まず、Windows ストアプロジェクトの既定値は (本稿執筆時点で) ARM ビルドプラットフォームであり、x86 ではありません。ビルドして実行しようとすると、システムが ARM アーキテクチャではないというエラーが発生するため、混乱するおそれがあります。ARM と x86 の両方のビルドを作成することをお勧めしますが、ローカルテストでは x86 を選択して ARM エラーを回避します。また、本稿執筆時点で、Unity には Windows ストアや Windows Phone 用の 64 ビットプレーヤーがありません。Surface 1 や Surface 2 (Pro ではなく RT。Pro は x86 ベースシステム) などの数少ない ARM Windows 8 デバイスの 1 つを所有している場合は、もちろん ARM を選択して、リモート配置を行い、デバッグできます。しかし、ほとんどの開発者がローカルテストに使用しているのは、x86 ベース PC です。

次に注意するのは、[Debug]、[Master]、および [Release] オプションが含まれるビルド構成の種類です。これは、[Debug] と [Release] のみが含まれる一般的な .NET アプリケーションとは対照的です。Debug ビルドは最も時間がかかります。このビルドにはデバッグ情報が含まれ、Unity Profiler (Pro バージョンに含まれるゲーム最適化のためのパフォーマンスツール) もサポートします。Release ビルドは、完全に最適化されますが、Unity Profiler もサポートします。Master ビルドは、各ストアに提出するビルドです。このビルドは、最適化され、運用可能なバージョンであり、Unity Profiler をサポートしません。最初にゲームをテストする際は、Master ビルドを選択すると、デバイスでの正確なパフォーマンスを把握できます。

Windows Phone の場合、Windows Phone 8 用のビルドと Windows Phone 8.1 用のビルドの 2 つの主な選択肢があります。Windows Phone 8 アプリは、Windows Phone 8.1 デバイスで問題なく動作します。ただし、Windows Phone 8.1 では、プラットフォーム固有のコードをコード共有する方法のほうが、API の約 90% を Windows ストアアプリと共有するユニバーサルアプリに対応できるので適しています。しかし、一般的なゲームの場合、プラットフォーム固有のコードを自作していない限り、このコード共有はあまり意味がありません。

Visual Studio でソリューションを作成したら、パッケージ化とストアへの送信方法はどの Windows Phone/Windows ストアアプリも同じです。これには Windows ストア開発者アカウントが必須です。一度登録費用を支払えば、アカウントを使い続けることができます。この提出プロセスについては何度も説明されていますが、簡単な概要については、「Windows ストアへの公開」(bit.ly/Za0Jlx)、「Windows Phone 用に公開する」(bit.ly/1rdDCwR)、および「Unity ゲームを Windows と Windows Phone に移植する理由と方法」(bit.ly/1ElzrcL、英語) を参照してください。

プレーヤー設定: Unity から Windows にビルドする基本的なプロセスを説明しましたが、アイコン、スプラッシュスクリーン、アプリ名などの必要な項目を設定する方法については確認しませんでした。これらの項目はすべて、[Player Settings] (プレーヤー設定) にあります。これは、[Build Settings] 画面から読み込んで、Windows ストアアプリや Windows Phone アプリの主要な設定をすべて構成できます (図 8 参照)。ここで、スプラッシュスクリーン、アプリ名、発行元、コンパイル設定、アイコン、位置情報サービスなどのアプリ機能の他に、いくつかの設定を指定できます。これらの設定は、Unity でソリューションを初めてビルドするときに Visual Studio ソリューションにプッシュされます。

図 8 Windows ストア用のプレーヤー設定

アプリアイコン: Unity にはアプリ用の既定アイコンがいくつか用意されており、それが Visual Studio でビルドされます。これらの既定アイコンを変更しないと、認定を受けられないおそれがあります。Unity ではプロジェクトに設定できる画像を非常に簡単に確認できますが、各プラットフォームの認定ドキュメントを参照して、必要な画像を判断してください。(Windows ストアアプリおよびユニバーサルアプリの場合) 開発者自身の画像で置き換えずに削除する必要のある既定の画像がいくつか Unity によって設定される可能性があるので、Visual Studio で Package.appxmanifest の [ビジュアル資産] を確認する必要があります。

Windows デベロッパーセンター (msdn.microsoft.com/ja-jp/library/windows/apps/hh846296.aspx) によれば、Windows ストアアプリには最低でも、50 x 50 のストアロゴ、150 x 150 の正方形ロゴ、30 x 30 の正方形ロゴ、および 620 x 300 のスプラッシュスクリーンが必要です。Windows デベロッパーセンター (bit.ly/1oKo8Ro) によれば、Windows Phone 8 アプリには、アプリ一覧の画像とスタート画面用の中サイズおよび小サイズの既定のタイル画像が必要です。Windows Phone 8.1 アプリにも、アプリ一覧の画像と既定のタイル画像が必要です。また、Windows ストアと Windows Phone ストア (Windows 10 で統合されるそうです) では、提出中にそれ以外にもスクリーンショットなどの画像を求められる場合があります。

スタート画面タイル用に用意する画像が 1 つのみの場合は、Windows デベロッパーセンター (msdn.microsoft.com/ja-jp/library/windows/apps/hh781198.aspx) に従って、Windows Phone ストアアプリには 240% に拡大した画像を、Windows ストアには 180% に拡大した画像を用意する必要があります

ちなみに、しばらく前に Windows ストアアプリ用の画像生成に役立つシンプルなユーティリティを作成しました。bit.ly/ImageProcessor (英語) で公開していますのでご利用ください。

リビルドと上書き: Unity によって Visual Studio プロジェクトの Data フォルダーが上書きされると説明しました (図 9 参照)。これは、諸刃の剣です。Unity ではいつでもスプラッシュスクリーン、アイコンなどを設定できます (また、設定することをお勧めします) が、Visual Studio ソリューションを生成済みの場合、それらの設定が含まれる Package.appxmanifest ファイルは、次に Unity でビルドするときに上書きされません。そのため、Package.appxmanifest ファイルで Visual Studio ソリューションのビジュアル資産や機能などを手動で設定するか、新しいフォルダーにビルドしてから BeyondCompare などの差分ツールを使用してフォルダー構造の差分を取得するか、Visual Studio ソリューションにカスタムコードがない場合はソリューションを削除して Unity で再生成する必要があります。通常は、Unity 内にアイコンやスプラッシュスクリーンの画像を保持しているので、3 つ目の方法を使用します。必要なのは、Visual Studio ソリューションにカスタムライブタイル画像を忘れずに設定することだけです。Windows Phone 8 (8.1 ではない) 用アプリを作成している場合、アイコンを Visual Studio で設定する必要があります。これは Unity からプッシュされない数少ないものの 1 つです。

図 9 Visual Studio プロジェクトの Data フォルダー

まとめ

ビルドプロセスは非常に単純です。ビルド設定を表示し、[Build] をクリックして、ソリューションを開き、配置します。ビルドをカスタマイズするオプションとして、プラグインとプリプロセッサディレクティブを使用する方法を示しました。Mono の外部からプラットフォーム固有のコードを呼び出すことができるので、すぐにその機能を使用できます。Windows プラットフォーム用に現在無償で提供されている Unity プラグインを prime31.com で確認することを忘れないでください。プラグインによって、コードを数行追加するだけでプラットフォームの機能を簡単に統合できます。Channel 9 には新しい短い Unity トレーニングコンテンツ (10 分程度のビデオ) がいくつか公開されています。また、私の Channel 9 ブログでは、このプラットフォーム用のゲーム構築のちょっとしたヒントを多数紹介しているので、併せて確認してください。次回お会いできるのを楽しみにしています。

その他のラーニングリソース

Adam の Channel 9 ブログ: bit.ly/AdamChannel9 (英語)
Microsoft Virtual Academy: Unity を使用した Windows 向け 2D ゲームおよび 3D ゲームの開発: bit.ly/FreeUnityTraining (英語)
Unity リソース: unity3d.com/learn (英語)

Adam Tuliper は、南カリフォルニア在住のマイクロソフトのシニアテクニカルエバンジェリストです。彼は、インディーズゲーム開発者であり、Orange County Unity Meetup の共同管理者であり、Pluralsightの著者でもあります。Tuliper 夫妻には間もなく第 3 子が生まれます。連絡がある場合は、彼に時間の余裕がある間に、adamt@microsoft.com (英語のみ) または Twitter (twitter.com/AdamTuliper、英語) に連絡してください。

この記事のレビューに協力してくれた Unity の技術スタッフの Tomas Dirvanauskas、Ignas Ziberkas、および Tautvydas Žilys に心より感謝いたします。