プリグラ（プリコネ！グランドマスターズ）で少し話題になったMagicOnionを試しに使ってみたいって方が環境構築するときに参考になれば幸いです。結構二番煎じだと思いますが、まだMagicOnionの文献が少ないので少しでも貢献できればいいな。

はじめに

MagicOnionは、アプリとサーバーをC#言語で統一しgRPCでつないでしまおうという通信フレームワークです。

何でC#言語かというとUnityがC#ってのが影響力大きいと思います（ただUnityのC#は「Unity独自のC#」なので厄介な問題があるんですけどね）。

Unityで使える貴重な通信フレームワーク（他には最近だと開発途上のNetcodeなど）なので詳しく知りたいという人はかなり多いと思いますし、最近は確実に企業での採用実績も増えてきています。

ただMagicOnion、環境構築が少しクセがあります。

アプリとサーバーを共通化する以上、環境構築の際に必要な知識もアプリ側、サーバー側と、今まで別々に担当者が分かれていた両面必要になるので、そこが曲者となってきます。

この記事では、その辺りも踏まえて解説していこうと思います。

ディレクトリ構成の完成予想図

まず最初に全体像を見てもらった方が分かりやすいかな。

MagicOnionは共通化という概念の自由度の高さから、各々のプロジェクトの都合に合わせて様々な構成を作ることができます。

逆に言えば千差万別になりやすく、それ故に初学者が目標を見失いやすい部分があります。

分かりやすさ重視として、私は今回こんな感じのディレクトリ構成にしました。

オレンジ：Unityプロジェクト
赤：アプリ側
黄緑：サーバー側

MagicOnion2というひとつの大きなUnityプロジェクト（3Dテンプレート）の中に、サーバー用のフォルダが内臓されている形になっています。

サーバー用のフォルダ（Server）をUnityプロジェクトの外に出して管理することも出来ますが、今回は分かりやすさ重視で。

この完成形を目指して環境構築を始めます。

Unityプロジェクトの作成

アプリ側の環境構築から行きますね。

Unityプロジェクトの作成については特に不要かと思いますが、UnityHubから「新しいプロジェクト」→テンプレート「3D」→エディタバージョン「2021.3.0f1」を選んでプロジェクト名（私のはMagicOnion2）を指定して「プロジェクトを作成」って感じです。

※今回はUnity2021での動作確認もかねていました。

プロジェクトが作成出来たら、プロジェクト設定を少し変更する。

API互換性レベルを「.NET standard 2.1」から「.NET Framework」に変更する。
（理由についてはアプリ実装の部分で解説します）

他所様では「スクリプティングバックエンドをIL2CPPにしなさい」ってあったりしますが、今回は不要です。

IL2CPPはC#をC++として変換する仕組みで、iOSビルドなどに必要になります。
（通常はMonoというUnity独自の.NET互換C#コンパイラを使います）

MagicOnionはC#で出来ているので、IL2CPPで構成する場合は同じようにC++変換する作業が必要です。その場合、コードジェネレーター（moc.zip）を使う必要があり環境構築が複雑になります。・・・ので、今回は使いません！

気付いた方もいらっしゃると思いますが、「スクリプティング ランタイム バージョン（Scripting Runtime Version）」という項目が無くなっています。

以前はそこで「.NET 4.x Equivalent」などを選択する必要がありましたが、Unity2019から「.Net3.5」が無くなったので項目が無くなりAPI互換性レベル（Api Compatibility Level）に統一されました。

つまりAPI互換性レベルを「.NET Framework」にしておけば、「.NET 4.x Equivalent」を選択するのと同じになります。

MagicOnionをプロジェクトに追加

公式ドキュメントから
https://github.com/Cysharp/MagicOnion#support-for-unity-client

MagicOnionリリースページへ
https://github.com/cysharp/MagicOnion/releases

そして「MagicOnion.Client.Unity.unitypackage」をダウンロードして、Unityプロジェクトにインポートします。

gRPCをプロジェクトに追加

公式ドキュメントからgRPC公式ページに行き
https://packages.grpc.io/

最新の「Build ID」項目にあるリンク→「C#」の「grpc_unity_package.2.47.0-dev202204190851.zip」をダウンロードして展開します。

zip展開した中の「Google.Protobuf」「Grpc.Core」「Grpc.Core.Api」だけをUnityプロジェクトのAsset/Pluginsにコピーします。

間違って全部コピーすると画像のようなエラーが発生しますが、先ほどの3つのフォルダ以外を削除すれば大丈夫です。

MessagePackをプロジェクトに追加

公式ドキュメントからMessagePackのリリースページに行き
https://github.com/neuecc/MessagePack-CSharp/releases

「MessagePack.Unity.2.3.85.unitypackage」をダウンロードしてUnityプロジェクトにインポートします。

インポートの際にMagicOnionの「System.Buffers.dll」「System.Memory.dll」「System.Runtime.CompilerServices.Unsafe.dll」「System.Threading.Tasks.Extensions.dll」の重複警告が出ますが上書きしてしまって大丈夫です。

VisualStudioCodeの環境構築

UnityプロジェクトにMagicOnionでアプリを作る準備は出来ました。

次はサーバーと行きたいところですが、その前にVSCodeでC#開発できるように環境構築をします。以下の参考サイト様とやることはほぼ同じです。

どうしてもC#をVSCodeで書きたい
https://qiita.com/_patrush/items/dc8b2f8ea4c59d49c1fd

参考サイトに従って必要な拡張機能をインストール

Unityプロジェクトのフォルダを開いて

「フォルダーをワークスペースに追加」をやって保存すればワークスペースファイルが作成されるので、サイトの内容をコピペした後、「**/Assets/Scripts/Generated」「**/Assets/Scripts/MagicOnion*」「**/Assets/Scripts/MessagePack」の行をコメントアウトします。

こうするとAssetsのスクリプトも見えるようになります。
（参考サイトでは非表示設定だけど、アプリ実装で表示する必要がある）

「extensions.json」はUnityプロジェクトの「.vscode」フォルダの中に入れます。
（VSCodeで開いたときに.vscodeフォルダが自動生成されるはず？）

これでC#の開発環境はだいたいOKだと思います。

MagicOnionサーバーの環境構築

VSCodeの設定が終わったら、そのままServerフォルダを作成して、その中にMagicOnionのサーバーを構築します。
（アプリもMagicOnionというのでややこしいです）

公式ドキュメントには「dotnet app package MagicOnion.Sever」（.NETコマンド）を使って追加すると書いてありますが、ちょっと初心者には説明不足で、そのまま実行すると失敗します。

（既に開いてるかもですが）先ほど作成したSeverフォルダを右クリックして「統合ターミナルで開く」を選択します。

メニュー「ターミナル」からでもいいですが、フォルダから開くとコマンドラインのパスがそこになるので便利です。

Severの中で「dotnet new grpc」を実行します。

MagicOnionはgRPCで作られているので、gRPCプロジェクトを指定して作成します。
（Severフォルダの中に色々追加されます）

その後に「dotnet add package MagicOnion.Sever」を実行します。

後は公式ドキュメントにある通り、Severの中に作成されたStartup.csの内容を変更します。

最後に「dotnet run」でサーバーが起動すれば完了です。

共通インタフェースの作成

ここまでお疲れさまでした。

環境構築が終わったら、いよいよ通信アプリの実装をやって行こうと思います。

まずはMagicOnionでの共通インタフェース「IMyFirstService.cs」を作成します。

IMyFirstServiceの内容は公式ドキュメントと同じで大丈夫です。

ファイルの位置だけ注意が必要で、このIMyFirstServiceをサーバーから参照設定するので、他の共通化しないファイルと別々に分ける必要があります。

また、UnityでIMyFirstServiceを使いたい場合、これをUnityコンパイルする必要があるので、Asset内に存在していないといけません。

ディレクトリ構成は自分も悩みましたが、namespaceと同じようなフォルダ構成で「Assets/Scrips/MyApp/Shared/IMyFirstService.cs」としました。ここら辺は割と自由だと思います。

アプリ部分の実装

次に通信アプリの実装を行います。

公式ドキュメントと以下のサイト様を参考に「SampleAppCall.cs」作りました。

UnityとMagicOnionの環境構築（IL2CPP）
https://zenn.dev/kumatta_ss/articles/dab376b180aa85

注意点としては、公式ドキュメントでは「GrpcChannel」を使っていますが、これはUnityでは利用することが出来ませんのでコメントアウトして、2行下の「new Channel」の方を使います。

またgRPCのssl通信が今のUnity環境では出来ないっぽい？ので、ポート番号5001を5000にして、ChannelCredentials.Insecure（安全でないセキュア）を指定します。

この辺りの問題は、Unityのプロジェクト設定「.NET standard 2.1」「.NET Framework」と密接に関係しています。

アプリのUnityコンパイルが通ったら、Unity上に空のオブジェクトを作成してコンポーネントにこの作成したスクリプトを設定して準備完了です。

サーバー部分の実装

まず共通インタフェースを参照できるようにします。

Severフォルダ内の「Sever.csproj」に「<Compile Include=”..\Assets\Scripts\MyApp\Shared\**\*.cs” LinkBase=”LinkFromUnity” />」を追加します。

これでShared以下のスクリプトを全て参照できるようになりました。

コンパイル参照が出来たら、Sever/Servicesの中に「MyFirstService.cs」を作成します。
（内容は公式ドキュメントにある通りです）

出来たらServerのターミナルを開いて、「dotnet run」を実行します。

asyncに関する警告が表示されますが、とりあえず無視でOK
（公式ドキュメント通りだもの）

サーバーを待機中にしたまま、Unityに戻ります。

最後にUnityで動作確認

後はUnityプロジェクトをテスト実行するだけです。

上手く行けば、Unityのコンソールと、VSCodeのターミナルにログが表示されます。

サーバーが起動していなかったり、何らかの問題があった時は、Unityのコンソールにエラーが表示されます。
（以下はサーバーが起動していなかったとき）

おまけ

MagicOnionの環境構築またやるか（3回目）

— 藤原工房 (@FujiwaraKoubou) April 21, 2022

Netcodeのチュートリアル的な動画を自分でも実践してみましたが、かなり苦戦したので、せっかくなので記事として記録したいと思います。内容はレベルの低い話も多いかと思いますがご容赦くださいませ。

チュートリアル動画との差異

まず初めに前提として書いておかないといけないのは、苦戦した理由の一つに、UnityのStarter Assetsで再現しようとしたことがあります。

これは動画の中のサンプルが公開されていましたが、勉強のためにもUnityの標準アセットでも再現できれば、今後応用したいと思ったときに楽になると思ったからです（結果として大苦戦しますが）

Netcodeで今回使ったやつhttps://t.co/cs4qZLz40y

— 藤原工房 (@FujiwaraKoubou) December 5, 2021

Starter Assetによる再現方法

もしかすると、この記事を見て自分で同じことをやって見たいという人がいるかもしれないので、構築方法を書いておきます。

環境
Windows10、Unity2021.2.5f1（NetcodeはUnity2021から対応）、Visual Studio Code

①Starter Assetを全てインポートしたら「Asset > Starter Assets > Environment > Prefabs > Environment_Prefab.prefab」を自分のシーンにドラッグ＆ドロップして配置します。

②元からあるMainCameraを削除して「Asset > Starter Assets > ThirdPersonController > Prefabs > MainCamera.prefab」を自分のシーンにドラッグ＆ドロップして配置します。

③「Asset > Starter Assets > ThirdPersonController > Prefabs > PlayerArmature.prefab」を自分のシーンにドラッグ＆ドロップして配置します。

④このPlayerArmatureを編集したいので、自分の「Asset > Scenes」にドラッグ＆ドロップして、バリアントとしてコピーします（コピーするときに選択肢が出ます）。

⑤最後に③で作ったコピー元のプレハブを削除します。

あとはチュートリアル動画の進む通りにNetworkManagerなどを入れていきます。

※以下は、チュートリアル動画を見た前提で書いていますのでご注意ください。

苦戦①InputSystemが動画と違う

Starter AssetのPlayerオブジェクトは、チュートリアル動画のようにUpdate()の中で入力を取得していません。

具体的には、ThirdPersonController.csで移動を、StarterAssetsInputs.csで入力を取得しています。

なので、この2つのスクリプトをMonoBehaviour→NetworkBehaviourに変更して、IsOwner、IsServerなどで制御する必要があります。

また、動画では古いInputSystem、Starter AssetはUnityの最新のInputSystemを使っています。

この新しいInputSystemには大いに苦しめられることになります。

苦戦②Visual Studio CodeがNetcodeをサポートしていない

バリアント化したプレイヤープレハブのThirdPersonController.cs、StarterAssetsInputs.csをコンポーネント削除をして、Starter Assetのプレハブからスクリプトを自分のところにコピーします。

元の名前と同じだとややこしいので、それぞれ適当にリネームして下さい。
（自分は接頭にMyを付けてリネームしました。この辺はお好みでどうぞ。）

そして、Visual Studio Codeでスクリプトを編集するわけですが、Netcode系、新InputSystem系のアセンブリ参照が見つからない問題にぶち当たります。

これに関しては、最後まで解決できませんでしが、Unity側でのコンパイルには問題ないようです。

おそらくVisual Studio Code Editor がそのうち修正されて対応されると思います。

苦戦③IsServerの解釈違い

チュートリアル動画の説明では、難しいところがあったので自分なりに考えて解釈していたところ大はまりしたので、解釈違いを起こしていた部分とその解説を入れたいと思います。

まず理解が必要だと思ったのは、ServerRpcの挙動です。

以下のリンクを見て下さい。

ServerRpc | Unity Multiplayer Networking
https://docs-multiplayer.unity3d.com/docs/advanced-topics/message-system/serverrpc/index.html

ここの図を見ていただければ口で説明するより分かりやすいと思います。

[Unity.Netcode.ServerRpc]がついたSetMoveInputServerRpc()は、呼び出されたときに直接実行されるわけではなく、リンクの図のように（別のネットワークの）Serverで実行されます。

つまり、ClientでMoveInput()は実行されません。
全てServerでMoveInput()が実行されます。

ここでややこしいと頭を悩ませるのが、このスクリプト自体がServerでも使われ、Clientでも使われることです。

そこで、スクリプトをServer、Clientで分岐させる必要があります。

そのための関連フラグを軽く説明します。

IsOwener：スクリプトが実際に操作しているプレイヤーのものかどうか

マルチ実行中は操作プレイヤーだけでなく、他のプレイヤーもオブジェクトとして同じスクリプトを使って複数生成されます。

そうなると、キーボードなどで操作したい（入力を取得したい）オブジェクトを判別する必要があるので、そのために使われます。

このフラグの管理は、NetworkManagerによって行われます。

IsClient：クライアント⇔サーバーにおけるクライアント側（操作のみ）
IsServer：クライアント⇔サーバーにおけるサーバー側（処理の集約と展開）

動画の中では、Host、Clientで説明されるので自分は誤解してしまいましたが、HostとClientは対ではありません。

Hostは、IsServerであり、IsClientでもあります。
（自分は最初、HostはIsClientではないと思っていた。）

対になっているのは、ClientとServerであり、HostもまたClient扱いになります。

IsServerを使って、Move()をServer側（Host側）にだけ実行させます。

Client側の移動はどうなるかというと、全てオブジェクトに付けたNetworkTransformによってNetworkManagerにより、まずServerに全て集約され、ネットワーク経由で各々配信され行われます。

この辺りの理解はかなり誤解していました。

苦戦①に関連して、2つのファイルにわたって動画と実装が異なっているので注意して下さい。

苦戦④新InputSystemの仕様に苦しめられる

出来たアプリをビルド実行して（ウィンドウ化設定をした方がいい）、HostボタンでPlayerArmatureを作ります。

そして次に、Unityのエミュレーターを実行して、ClientボタンでPleyerArmatureが作られると、Client側ではHostで作られたものと合わせて2つ作成されます。

この時に、PleyerArmatureに設定されているInputSystemは、2つのオブジェクトそれぞれに存在するので、それぞれが操作できるように自動で割り振りを行います。

そうすると、1つ目はキーボードになり、なんと2つ目はXboxコントローラーに割り振られます。

この現象と、Netcodeが必ずHostキャラから生成する仕様と合わさり、Clientボタンで2番目に作成されたPleyerArmatureが操作できないという問題にぶち当たりました。

これには大いに苦しめられました。
（操作できない理由にたどり着くまでに紆余曲折がありました）

https://t.co/XOIE5apT2q
↑を自分でやってたけど、クライアント側が動かない（単体だと動かせる）。煮詰まってしまった。ちょっと休憩かな。何か間違ってるんだろうなぁ。 pic.twitter.com/teXJ737mms

— 藤原工房 (@FujiwaraKoubou) December 4, 2021

Netcode現状まとめ
新しいInputSystem（PlayerInputManager）に大苦戦中
WindowsアプリでHostを起動し、UnityでClientを起動すると、Client側が動かせなくなる。
これは、操作Playerが生成されると自動的に操作可能なキーボードを割り振るが、2人目が生成されるとキーボードを禁止するため pic.twitter.com/A0Ywtk7kWq

— 藤原工房 (@FujiwaraKoubou) December 5, 2021

2つ目がXboxコントローラーになる件については、厳密には「操作無効になった状態をXboxとしてデバッグ出力していた」です。

この状態を何とかするために、関係ないオブジェクト（Client側から見たらHost側のオブジェクト）にInputSystemは必要ないので、プレハブのPlayerInputのenabledチェックを外しておいて、スクリプトの中でtrueにすることで解決しました。

まとめ

やった対応自体は、ほんの一握りのことですが、これにたどり着くまでに数十のサイトで調べに調べたので丸一日ぐらいの時間がかかりました。

疲れた。

願わくば、この記事が何かの役に立てばいいな

ちなみにチュートリアル動画のリレーサーバー以降は、ノーヒント状態なので再現するのは諦めました。

ひと昔前までは、Unityの公式チュートリアルといえば以前解説したような、動画形式の簡素なものでしたが、今は新しくチュートリアル専用のサイトとして「Unity Learn」があります。

Roll-a-ball – Unity Learn（英語版）玉転がし – Unity Learn（日本語版）

で、今回は、この玉転がしの解説ではなく、新しく作られたチュートリアルサイトで初学者が「これってどこから手を付けたらいいの？」「入り口はどこにあるの？」という素朴な疑問を解消するために、サイトでの最初の道筋を解説してみたいと思います。

サイトの日本語化

まず初めに、英語に拒否反応を示す方のために、サイトの日本語化（一部だけ）のやり方を説明します。まずはトップページを開き

トップページを一番下までスクロールすると、言語指定が出来るところがあります。そこで「日本語」を選択します。

サイトのログイン

チュートリアルを始めようとすると「ログインして下さい」的なことを言われるので、まずはアカウント作成とログインについて軽く説明します。

トップページの右上のアイコン（人影の形です）をクリックすると、「Unity ID を作成する」というのがあるので、それをクリックして下さい。

Unity ID はこのサイトだけでなく、この先での Unity Hub や Unity 本体でも使うので、パスワードは忘れないように。掲示板とかに表示される「ユーザーネーム」の設定だけは気を付けた方がいいかもしれません。

Getting Started with Unity という入り口　

ログイン出来たら、早速チュートリアルを探してみましょう。

まずは、メニュー欄の「コース」をクリック

コースをクリックすると画面中段に「コース」と表示されて、検索欄やタグ、そしてコース一覧が表示されるようになります。

そこで「レベル」タグを「Foundational」にして、絞り込み検索（フィルター）をします。Foundational は「基礎」って意味ですね。

すると、2つのコースが表示されます。その内、右側の「Getting Started with Unity」がどうやら Unity 入門コースになっているようです。こんなやや小難しい手順を踏まないといけないのは「どうなんだろ？」と思いますが、おそらくこれが初学者の入り口かと思います。

Unity は優れたゲーム開発ツールですが、Unity 公式チュートリアル内容は英語で、しかもゲーム開発者には馴染みが深くとも業界初心者には難解な部分が結構あります。そこで、チュートリアルを噛み砕いて少しでも分かりやすく解説を追加してみようと思います。自分はプログラマですが Unity は初心者なので、この記事によって自身の復習としたいです。

この記事は以下の環境で開発しています。
Windows10
Visual Studio Community 2015
Unity 5.5.0f3

同じ環境を構築する場合は、Visual Studio をインストールした後にUnityをインストールするべきです。そうすることで、Unityインストール時に、Visual Studio に Unity 用プロジェクト設定が追加されると思います。

では、さっそく解説していきます。
内容は全翻訳ではなく、あくまで補足という形になりますのでご注意ください。

1. Environment and Player

01. Setting up the Game

00:39　新規プロジェクト作成

5.5では新規プロジェクトの表示画面がかなり変わっていたので念のため補足しておきます。

チュートリアルの表示

Unity 5.5の表示（2段階）

Enable Unity Analytics は「ゲームがどれくらい遊ばれているか」を解析できる機能です。
デフォルトONになっていますが気にせずこのままでも大丈夫です。

指定した Location （保存場所）に、指定した Project name のフォルダーが作られてゲームプロジェクトが保存されます。

Organization は Unity に登録したアカウントを使います。
逆に言えば、アカウントを登録しないと Unity を使うことはできません。

Unity 初回インストール時にアカウント登録とライセンス登録とがあります。
無料の Personal ライセンス登録の選択肢は上から以下のようになっています。

The company or organization I represent earned more than $100,000 in gross revenue in the previous fiscal year.
私が代表する会社または組織は、前年度の総収益が10万ドル以上でした。

The company or organization I represent earned less than $100,000 in gross revenue in the previous fiscal year.
私が代表する会社または組織は、前年度の総収益が10万ドル未満でした。

I don’t use Unity in a professional capacity.
私はプロの立場でUnityを使用しません。

10万ドル以上の収益がある場合は Personal を使うことができません。
個人開発者であれば、ほとんどの人が2つ目の選択肢を選ぶことになるでしょう。
3つ目の選択肢は、いわゆる学生、アカデミーでの利用を意味します。

ライセンスの選択画面

01:03　シーンの保存

シーンを保存する解説で「Scenes」とする場面がありますが、これは別にアンダースコア（←これのこと）を付ける必要はありません。
解説者は、「アンダースコアを付けるとフォルダーの並びで先頭に来るから」と言っている通り、Scenes フォルダ並びだけの問題なので、付けないと不味いというわけではありません。

_Scenes

01:49　3D Object のリネーム

3D Object を作成して名前を変更する場面、Windows10 ではシングルクリックで少し待つか、F2キーを押して変更します。
F2キーはファイル名の変更や、Excelの入力内容の変更など、Windows 上の様々な場面で押すキーなので変更キーとして覚えておくといいでしょう。

名前の変更

02. Moving the Player

01:13　コンポーネントの並び

Sphere Collider （球体の当たり判定）を Rigidbody （物理演算エンジン）の下に並び替える場面がありますが、これは Unity のシステムがコンポーネントを上から順に実行していることを解説しています。

これは、Script (プログラム）を実行するときに、頭の片隅に入れておかなければいけない規則で、例えば、Script 内で当たり判定を使う場合、Collider コンポーネントをその Script よりも手前（上）に配置しなければ使うことができません。

Script が思うように動かない場合、この並びが間違っていることがあります。Script コンポーネント同士でも順序によって結果が変わるので気を付けなければなりません。

コンポーネントは上から順に実行される

03:53　Script のプログラミング

Unity は物を動かしたりするために、Script コンポーネントを使います。
この Script は、Javascript 言語か、C# 言語によってプログラミングされます。

Javascript

Internet Explore、Microsoft Edge、Google Chrome、Firefox などインターネットブラウザなどで主に利用されているプログラミング言語

プログラムされた内容をそのまま逐次実行する動的言語と呼ばれる言語で、処理速度が遅い反面、書いた内容を即実行できるお手軽さがあります。

C#

「Java は著作権問題があるから自分たちで新たに言語を作る」という感じで誕生した Microsoft が C 言語を元に、Java 言語を参考にして作ったプログラミング言語

プログラムされた内容は、コンパイルという機械語に変換作業が行われるので、即実行はできない反面、処理速度は速いという面があります。

特別な理由が無い限り、C# で Script をプログラムすることをおすすめします。
Javascript は処理速度よりも、Visual Studio などのプログラミング開発ツールで「コード補完」が難しいという難点があります。

コード補完

Visual Studio などプログラミングを支援するツール上で、プログラムを書き込んでいるときに、漢字変換のようにコンピューターが入力したい文字を予測して、候補を表示してくれる機能です。

下の図では、「Ga」とだけ入力したときに、その下に「GameObject」「gameObject」と候補と、その簡易解説が左に表示されています。これがコード補完機能です。
これが出来るのと出来ないのとでは、プログラミング速度や楽さが全然違ってきます。
ちなみに、これでリターンを押すと、「Ga」は「GameObject」に自動変換され入力されます。

Visual Studio でのコード補完

ついでに、この上の図のコード内容について解説をします。
Unity を使いたいユーザーの大半は、このプログラムコードが意味不明で拒絶反応を起こしてしまうのではないかと思いますので、この解説で意味をイメージしてもらえれば幸いです。

ネームスペース（名前空間）

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

一番上に、「using」に続いて何か英単語が並んでいますが、これは「ネームスペース（namespace）を利用します」という宣言です。
ネームスペースとは、プログラムファイルの集合体につけた総称で、「using UnityEngine」で言えば、UnityEngine という名のプログラム群です。

ネームスペースのイメージ
UnityEngine

ネームスペースの中にいるプログラムたちのイメージ

UnityEngine というプログラム達が実際どこにいるかという設定は、Visual Studio ではプロジェクトの参照というところで見ることができます。
Unity から Script を開けば、自動的にネームスペースやコンパイル設定などを行った状態のプロジェクトが開くので、細かい設定は気にしなくても大丈夫です。

UnityEngine のネームスペースのファイル設定など
D:\Unity\Roll a Ball\Library\UnityAssemblies\UnityEngine.dll

ちなみに、Visual Studio のコード補完の図では、「using System.Collection」と「using System.Collection.Generic」が灰色になっていますが、これはこれらのライブラリを現在このプログラム内で使っていないので、「必要ないですよ」と色で表現してくれています。

このようなプログラム全体を解析して、不要な所であったり、エラーだと思われる部分を表示してくれるのは、Visual Studio などのプログラミング開発ツールの強みです。

クラス（class）

public class Test : MonoBehaviour {

}

この部分は「{」から「}」までの部分が、「Test」という名前の、参照可能なクラス（public class）であることを示しています。

クラスについては、オブジェクト指向というプログラミングの独特な考え方などを理解しないといけない難解な概念なので、ここでは詳細を省きます。
このクラスが、プログラムファイルひとつひとつの単位みたいなものです。
このクラスがたくさん集まって、ひとつのネームスペースになります。

「: MonoBehaviour」は「MonoBehaviour というクラスを継承しています」という宣言です。
継承についてもオブジェクト指向なので、砕いて説明すると「MonoBehaviour が持っている技を使えるようにします」という感じです。

MonoBehaviour クラスを継承する Test クラスのイメージ

ちなみに、宣言とは誰にしているのかというと、相手はコンピューターです。
「MonoBehaviour 使います」とコードで書くことで、Visual Studio が MonoBehaviour のプログラムをコンパイルしたり、コード補完を支援できるようになったりします。

メソッド（関数＝ファンクション）とコメント

	// Use this for initialization
	void Start () {

	}

	// Update is called once per frame
	void Update () {

	}

クラスの中身についての解説です。
「void Start ()」はメソッドです。
クラスがプログラムファイルの単位だとすれば、メソッドはファイル内にある個々のプログラム本体と言えます。
「()」が付くことでメソッドであることを宣言しています。
また、Start メソッドは MonoBehaviour クラスにあるメソッドで、それを使っています。

「//」が付いている行はコメントです。コメントはプログラム対象から除外されます。
「// Use this for initialization」は「void Start ()」に対してのコメントで、「この下のプログラムは初期化のために使います」と説明書きがされています。

Visual Studio でコメントにしたい所は、Ctrl + K、Ctrl + C と2回入力、逆にコメントを解除したい行は、Ctrl + K、Ctrl + U と2回入力します。

余談
Visual Studio がイケてないと思う理由の1つに、このショートカットキーを2回入力させる問題があります。
他のイケてる開発ツールとかだと、Ctrl + / でコメントにして、コメントになっているところで Ctrl + / とすればコメントを解除できるといった感じで、Microsoft は、もっとスマートにショートカットキーを設定するべきだと思います。

メソッドの入力（引数）

この()の間には、メソッドの入力値が設定できます。
Start メソッドのカッコ内に何も書いてないので入力値は無いということになります。
例えば、整数値（int）の入力（inputという名前）がある場合は、以下のように記述します。

void Start (int input) {
}

メソッドの出力（返値）

void は、このメソッドの出力値が void である、つまり空であることを宣言しています。
int Start () であれば、int の出力値、つまり整数の出力値が、
float Start () であれば、float の出力値、つまり小数点の出力値が、
といった感じになります。

void でなければ、Start メソッド内に出力値を設定する「return」を加える必要があります。

int Start () {
	return 0;
}

float Start () {
	return 0.0f;
}

といった感じです。
ちなみにセミコロン（;）は、プログラムのひとつの処理を区別するために文末に付けます。
文章の句点みたいなものです。

余談
Java 言語では同じ内容を以下のように記述します。
「using」が「import」、「:」が「extends」に変わっただけです。
C# が Java によく似ているのが分かると思います。

import System.Collections;
import System.Collections.Generic;
import UnityEngine;

public class Test extends MonoBehaviour {

	// Use this for initialization
	void Start () {

	}

	// Update is called once per frame
	void Update () {

	}
}

長くなりましたが、プログラミングコードの意味不明な部分について、少しは理解できたでしょうか。プログラムは、短い文字や記号とルールによって、非常に深い意味をコードに持たせています。これは入力量を減らすためにやっていることで、覚えるまでが大変です。

04:26　Script のライフサイクル

動画で PlayerController という Script を作成し、その編集を行う場面で、Update と FixedUpdate という2つのメソッドが作成されますが、これについて Unity とどんな関係性があるのかを解説します。

そのためには、まず Unity がどういった流れで動いているかを知る必要があります。
下の図は、その流れの一部、Script のライフサイクルを表したものです。

Script のライフサイクル（Script Lifecycle Flowchart）

これは Unity の Script コンポーネント単体の処理の流れです。
実際ゲームを動かすとき Unity は、シーンの持つ各オブジェクト＞オブジェクトの持つ各コンポーネント、といった感じに関連するものを順番に処理していきます。

例えば PlayerController は、Player オブジェクトの処理の順番が回ってきて、コンポーネントを順番に、Transform、Sphere (Mesh Filter)、Mesh Renderer、Rigidbody、Sphere Collider、と実行されて行って、そして PlayerController (Script) で上の図のような処理が実行されます。
それが終わったら、他のオブジェクト、そのオブジェクトのコンポーネント、といった感じに流れて行って、全部のオブジェクトが終わったら、また最初からやり直します。

このループを繰り返すことで、実際のゲーム画面が動いているわけです。
この1つのループのことを、1フレームと言います。

さて、このライフサイクルは MonoBehaviour クラスの中に既にプログラムされています。
PlayerController は MonoBehaviour を継承して作成されます。
そうすると、PlayerController は上の図をプログラムしなくても言いわけです。
Update と FixedUpdate しかプログラムしなくても、実際は見えないところで上の図のプログラムが実行されているわけです。

そして、PlayerController に Update と FixedUpdate メソッドを書くことで、MonoBehaviourの Update、FixedUpdate が実行されたときに、一緒に PlayerController の物も追加で実行されるというわけです。

ちなみに、Start は Script で最初の1度だけ実行され、FixedUpdate は物理演算が実行されたときに呼び出され、Update は Script が実行されたときに毎回実行されます。
そのため、動画内では Update を消して FixedUpdate を使うという形になります。

この Script のライフサイクルは、他のゲームエンジンなどでも一般的な処理の流れです。
ほとんどのゲームプログラムは、入力検知、動作処理、描画を1フレームとして無限ループによって成り立っていることを覚えておくといいでしょう。

05:03　クラス、メソッドのヘルプの呼び出し

Input というクラスが、一体どういった構成なのか知りたいときには、APIと呼ばれる、プログラムの構成情報に特化した書式のヘルプを呼び出します。

Visual Studio では検索したい単語を選択状態にしてから、 Ctrl + Alt + M 、Ctrl + H と2回ショートカットキーを入力します。

動画内ではブラウザで表示

Visual Studio ではタブ内に表示

Description は、このクラスがどういった構成がされているかという大まかな概要が書かれています。
「こんな感じで他のプログラムで利用するといいよ」といったサンプルプログラムも載っていたりします。

ちなみに、Input の Description には「キーボードやマウスなどのデバイス入力情報を扱っているクラスです」みたいな感じで書かれています。

Static Variables は変数、つまり他のプログラムで使えるデータ一覧です。
例えば、Input クラスはacceleration という変数を持っていて、acceleration にはジャイロからの入力情報が入っています。

他のプログラムから Input.acceleration と呼び出せば、他のプログラムでジャイロセンサーのデータが取得できるというわけです。
そういった、他のプログラムから利用できるデータの一覧情報みたいなものが並んでいます。

Static Functions は関数、つまり他のプログラムで使えるメソッドの一覧になります。変数はデータを持っていて、メソッドは特定の処理を実行します。

例えば、Input.GetKey(“up”) というGetKey メソッドの処理は、キーボードの上キーが押されたかどうかを調べる処理を実行します。
GetKey の出力値は boolean、つまり真か偽、押されたか押されてないかを出力します。

ちなみに、変数とメソッドを判別できるようにするため、変数は単語の先頭を小文字、クラスやメソッドは単語の先頭を大文字にしないといけないという C# プログラムのルールです。

12:50　変数と Vector3 の補足

動画内で PlayerController のプログラムが完成していますが、これについて補足しておきます。

PlayerController が Player を動かすプログラム

変数の型

using UnityEngine;
using System.Collections;

public class PlayerController : MonoBehaviour {

    private Rigidbody rb;

    void Start ()
    {
        rb = GetComponent<Rigidbody>();
    }

    void FixedUpdate()
    {
        float moveHorizontal = Input.GetAxis("Horizontal");
        float moveVertical = Input.GetAxis("Vertical");

        Vector3 movement = new Vector3(moveHorizontal, 0.0f, moveVertical);

        rb.AddForce(movement);
    }
}

まず、「private Rigidbody rb;」について、「rb」は変数です。

変数はデータを持っておけます。
データに関しては数値だけでなく、クラスも持つことできます。
この「持っておく」で一体どこにデータを置いておくのかというと、コンピューターのメモリになります。パソコンのスペック表に出てくる CPU や メモリ（RAM）のそれです。

ゲームを遊ぶためにメモリが必要というのは、このようにプログラムの中で変数が使われて、変数のデータ保持のためにメモリが必要になるからです。

private は外部から非公開（非参照）であることを宣言しています。
このクラスでしか使わない変数であるとあえて宣言することで、メモリを節約したりできます。
オブジェクト指向的には、参照できてしまうと外部からデータ内容を変更できてしまうので、それを防止するために非参照にするという意味もあります。

Rigidbody rb は rb が Rigidbody クラスのデータだけしか持ちませんという意味があります。
変数は予めどんな種類のデータを持つのかをコンピューターに宣言しなくてはいけません。
これは「変数の型」という C# におけるルールなので覚えておきましょう。
Rigidbody 型の変数 rb という感じに言います。

ちなみに、プログラム言語によっては、この変数の型を宣言しなくても良かったり、何でも持てますよ型みたいな型を宣言できる言語もあります。

変数の初期化

    void Start ()
    {
        rb = GetComponent<Rigidbody>();
    }

Start の中身を見ていきましょう。

先ほどの「private Rigidbody rb」というのは、あくまで宣言だけでデータがありません。
ならば、どうやってデータを追加するのかというとイコール（=）で追加します。

イコールの左側に変数、右側にデータを書くことで、変数にデータを入力できます。
ここでは Component クラスが持つ、GetComponent () というメソッドを使っています。
Component クラスは using UnityEngine で宣言したネームスペース中のクラスです。

このメソッドは、この Script コンポーネント（Component）が参照できる他のコンポーネント、この場合で言えば、Player オブジェクトに設定されている コンポーネントを呼び出しています。

「<Rigidbody>」の部分はジェネリクス（ジェネリック）と呼ばれる、メソッドの () の前に <> を付けることで、メソッドの出力値の型を呼び出す側が自由に指定できるようにするためのもので、Rigidbody 型のデータをメソッドに指定しています。

同じ意味で、以下のように書くこともできます。
こうやって書くのが長くて面倒だから、ジェネリクスみたいな書き方が生まれたようなものです。

    void Start ()
    {
        rb = GetComponent("Rigidbody") as Rigidbody;
    }

Start メソッドの中に、変数のデータ入力を書いておくことで、この Script が実行された最初のタイミングで、変数の中に Rigidbody のデータが初期化されます。

こうすることで、他の FixedUpdate で変数 rb を使っても、常に最新のデータが設定されているので、データが空で問題が起きるということがありませんし、Start は一度しか実行されませんので無駄な処理をしないという意味で、このメソッドの中で変数の初期化を行っています。

Vector3の概念

    void FixedUpdate()
    {
        float moveHorizontal = Input.GetAxis("Horizontal");
        float moveVertical = Input.GetAxis("Vertical");

        Vector3 movement = new Vector3(moveHorizontal, 0.0f, moveVertical);

        rb.AddForce(movement);
    }

FixedUpdate の中身を見ていきましょう。

「float moveHorizontal」と「float moveVertical」の行は、float 型の変数の初期化を行っています。ここでキーボードの上下左右の入力量を変数に設定しているわけです。

「Vector3 movement」の行も、Vector3 型の変数の初期化を行っています。
Vector3 とは三次元空間の X 軸、Y 軸、Z軸それぞれの座標を指定することで、三次元の方向量を表したものです。
これは Unity の Scene 表示で赤、緑、青の3色で方向表示されているあれと同じ意味です。
Transform コンポーネントの X、Y、Z の値もこの Vector3 のことです。

Unity の3D表示

コンストラクタ

「new Vector3(moveHorizontal, 0.0f, moveVertical)」の部分で、new とありますが、これは new を付けることで、これはコンストラクタですよと宣言しています。

コンストラクタとはクラスデータ（インスタンス）を新しく作成するメソッドを意味していて、入力値を指定することで、データを設定したクラスデータを作ることができます。

「new Vector3()」とすれば、空の Vector3 インスタンスを作成できます。
「新しく作成する」というのがポイントで、違うデータ設定がされたクラスを複数使うためにこの仕組みがあります。

「rb.AddForce(movement)」は、宣言されていた Rigidbody 型の変数 rb、そしてその rb に設定された Rigidbody クラスの AddForce メソッドが実行されています。

入力値は Vector3 型の変数 movement、それには Vector3 インスタンスが設定されています。この方向値を AddForce は受け取って、その方向に物理演算を実行します。

出力値は void なので何も出力されません（出力されませんが、処理は実行されます）。

14:33　パラメーターの設定と Script との連携

Unity の特筆すべき機能に、Script で書いた内容が Unity と連携するというのがあります。
この機能が「デザイナーやディレクターが直接ゲーム開発をコントロールできる」と話題になりました。

動画内で PlayerController （Script コンポーネント）に、Speed というパラメーターが追加されていて値を入力することができるようになっています。

これは PlayerController 内に、speed という名前の変数を用意したからです。

public class PlayerController : MonoBehaviour {

    public float speed;
}

Unity は　参照可能（public）な変数を自動的に見つけて、コンポーネントの項目として表示し、編集することができるようにします。

Script に public float speed を追加することで
Speed という項目が追加されている

また、Unity 上で設定した値は、プログラム実行時、自動的に PlayerController に伝わり、　PlayerController に Speed が設定された状態でプログラムが動きます。
これは素晴らしいシステムだと思います。

2. Camera and Play Area

01. Moving the Camera

04:27　カメラを移動させるタイミング

Main Camera を Player に追従させようとするために、初期位置の Main Camera と Player の位置関係を offset に持たせて、Player が移動したら Player の移動後の位置 + offset に Main Camera が移動するように Script を作成する所です。

using UnityEngine;
using System.Collections;

public class CameraController : MonoBehaviour {

    public GameObject player;

    private Vector3 offset;

	// Use this for initialization
	void Start () {
            offset = transform.position - player.transform.position;
	}

	// Update is called once per frame
	void LateUpdate () {
            transform.position = player.transform.position + offset;
	}
}

なぜ Update ではなく LateUpdate を使っているのかというと、Script のライフサイクルの図を思い出してください。図では、以下のように並んでいるはずです。

Update
Internal animation update
LateUpdate

これは「Internal animation update」が内部的アニメーション更新、つまり、Update は移動前に実行され、LateUpdate は移動後に毎フレーム実行されるということです。
Main Camera の移動は Player が移動した後に行いたいので、Update だとダメだと言うことになります。

02. Setting up the Play Area

特筆すべきことはないと思います。オブジェクトの複製は Ctrl + D です。

3. Collecting, Scoring and Building the game

01. Creating Collectable Objects

04:00　クラスの乗算と1秒間を正確に知るための方法

浮遊したキューブを自動的に回転させるために、Rotator という Script を作成します。

using UnityEngine;
using System.Collections;

public class Rotator : MonoBehaviour {

	// Update is called once per frame
	void Update () {
            transform.Rotate(new Vector3(15, 30, 45) * Time.deltaTime);
	}
}

演算子のオーバーロード

まず、何気に説明無しに使用されている「new Vector3(15, 30, 45) * Time.deltaTime」、Vector3 型と float型の乗算、これは演算子のオーバーロードという特殊なことをしています。

乗算は数値同士でしか行えませんが、クラスに乗算する方法があります。
それは「クラスに演算子（ * など）が使われたときに、クラス内部でどういう計算するか」をクラスでプログラムすることで可能になります。

この場合で言えば、Vector3 クラスの中に、おそらく以下のような特殊なメソッドが用意されているはずです。（実際に Unity のソースコードを見たわけでないので間違っているかも）

public class Vector3 {

    public static Vector3 operator *(Vector3 a, float d)
    {
        a.x = a.x * d;
        a.y = a.y * d;
        a.z = a.z * d;
        return a;
    }
}

このクラスに対して、演算子「*」が使われたときに、このメソッドがオーバーロードされて、通常の四則演算ではなくこのメソッドの内容が適用されます。

入力値は、
a が計算式の左辺、つまり先ほどの例で言えば「new Vector3(15, 30, 45) 」、
d が計算式の右辺、つまり「Time.deltaTime」が割り当てられます。

そして出力値は、
左辺と右辺をプログラムされたように計算して、a を出力します。

こういったプログラムがあるからこそ、Vector3 型と float 型の乗算が行うことができるわけです。
ちなみに、演算子のオーバーロードは C#、C++、Ruby などでしかできない結構特殊な方法です。

1フレームあたりの秒数

キューブを回転させるために毎フレーム実行される Update を使っています。
では1フレームは何秒なのでしょうか。それは、このゲームが実行される環境によります。

シューティングゲームの用語に「60FPS」みたいなものがありますが、あれはこのフレームと関連があります。シューティングゲームのジャンルのひとつである　FPS = first person shooting と同じ略称なのでややこしいですが、60FPS とは「60 frame per second」の略です。

つまり、直訳すると「1秒間に60フレーム」という単語になります。
「60FPS だとぬるぬる動く！」というのは、1秒間に Update が60回実行されているため、ゲームキャラクターの移動などがスムーズに動いているということになります。
これがパソコンが重かったりで 5FPS などだと、1秒間に5回しか移動しないため、キャラクターの移動がカクカクするわけです。

このように、フレームはパソコンの環境や状態によって常に実行される回数が変動しているため、時間をフレーム内で計測するのが困難になります。

そこで、Time.deltaTime があります。この deltaTime は1フレームが何秒で実行されたかをデータとして持っています。

60FPS ならば、deltaTime は 1/60 = 0.01667 という値になっていて、1秒間に60回 Update されるので、Update ごとに 0.01667 すれば、1秒後に1になるわけです。
30FPS ならば、deltaTime は 1/30 = 0.03333 という値になっていて、1秒間に30回 Update されるので、Update ごとに 0.03333 すれば、1秒後に1になるわけです。

このように、ぬるぬる動く状態だろうと、カクカク動く状態だろうと、フレームの状態に合わせて deltaTime の値が1秒間に合わせて変動することで、一定の時間間隔（秒速）を求めることができます。

この辺りのフレームと実時間の関係は難解なので、きっちり理解するには少し追加で勉強が必要かもしれません。

難解な場合、今は Time.deltaTime を乗算することで、1秒間に動かす量（秒速）を求められるというのを暗記するだけでいいと思います。

02. Collecting the Pick Up Objects

07:53　if による条件分岐プログラミング

どんなプログラミング言語でも、ほぼ必ず出てくる条件によってプログラムを分岐させる「if 文」というのがあります。

if (true か false を出力するプログラム)
{
    この{}内は true なら実行し、false なら実行されない
}

このように、「()」内の値が true （真）か false （偽）かを判定して、プログラムを分岐させることができます。

if 文はプログラミングの基本的な部分で必ず出てきます。
プログラミング言語によって、書き方が微妙にことなったりしますが、分岐させるところはどの言語も同じなので覚えておくといいと思います。

では、実際の PlayerController の実装を見てみましょう。

    void OnTriggerEnter(Collider other)
    {
        if (other.gameObject.CompareTag("Pick Up"))
        {
            other.gameObject.SetActive(false);
        }
    }

「other.gameObject.CompareTag(“Pick Up”)」が true か false かで分岐させています。

この場合、gameObject のCompareTag メソッドは、Tag が Pick Up という文字列ならば true、違うなら false を出力します。
つまり、ぶつかった物体（other）のゲームオブジェクトのタグが「Pick Up」かどうかを判定しているわけです。

この CompareTag の出力結果が true なら、SetActive (false) を実行して、そのゲームオブジェクトのアクティブフラグを Off にします（true なら On）。
そして Off になることで、その物体は非表示になるというプログラムになるわけです。

逆に CompareTag の出力結果が false なら、{}内のプログラムは飛ばされるので、物体のアクティブフラグは On のまま（初期状態は On）というわけです。

12:53　衝突フラグ

PlayerController に衝突時に実行する OnTriggerEnter メソッドを作りましたが、これは衝突した物体のうち片方（あるいは両方）の「Is Trigger」フラグが On でないと実行されません。
そして Is Trigger が On のときは、衝突した後に反発せずそのまますり抜けるようになります。

もし、すり抜けさせず、その上で衝突時に実行したい場合は、OnCollisionEnter を使いましょう。ただし、これを使うと逆に Is Trigger が On の物体と衝突しても何も起こらなくなります。

微妙にややこしいですが、この違いは覚えておくと後々困らないと思います。

Is Trigger にチェックを入れると
衝突時にすり抜けて OnTriggerEnter が実行される

15:17　Rigidbody による Collider 最適化

Pick Up に Rigidbody コンポーネントを付ける理由として、Collider の処理速度に影響するので付けますといった感じの説明がされています。

これは動かすオブジェクトには、Rigidbody を付けないと処理が重くなるということを意味しています。

オブジェクトを動かすと Collider の当たり判定を再計算しなければいけませんが、Rigidbody が付いていない物を動かしてしまうとシーン全体のオブジェクトが再計算されてしまいます。これはUnityがあえてそうしています。

逆にオブジェクトに Rigidbody が付いていれば、動かしたときに再計算されるのは、そのオブジェクトと影響する周りのオブジェクトだけになります。なので処理が軽くなるというわけです。

Use Gravity が On だと Pick Up は床を抜けて落ちていきます。
これは Pick Up の Is Trigger が On のためです。
ちなみに Is Trigger が Off のときは、床にコテンと落ちて回転の影響でズリズリ移動します。

床をすり抜けないようにするために、Is Kinematic を On にします。
これによって、Rigidbody による移動（Transform）をさせないようにします。

Collider の負荷軽減のため Rigidbody を加える

03. Displaying the Score and Text

07:41　文字列の連結と ToString メソッド

文字列は「+」演算子によって、文字をつなげることができます。
これも実は String クラスの演算子のオーバーロードになります。

countText.text = "Count: " + count.ToString();

ToString は Int32 クラスのメソッドです。
「int count;」は整数値を宣言していましたが、これは「Int32 count;」という Int32 型のクラスを宣言していることと同じです。
この辺りは少しややこしいので細かい説明は省略しますが、ようは数値や文字列もクラスであってメソッドを持っているということです。

04. Buiding the Game

特筆すべきことはないかと思います。
Unity は様々な環境に合わせてビルドすることができます。

終わりに

ものすごく長文になってしまいましたが、主にプログラミングの知識について補足できたのではないかと思います。

この補足量から考えると、Unity と言えど全くのプログラミング初心者には難しい代物だと言えるでしょう。

チュートリアルの最初も最初で難しすぎて挫折する人も多いかと思います。
その助けに少しでもこの記事が役に立てれば幸いです。