というのを作りました。Unityでネットワークマルチプレイヤーゲーム作るためのフレームワーク。といっても、100%自作じゃなくて、基本的にPhoton Serverというミドルウェアの上に乗っかるちょっと高級なレイヤーぐらいの位置づけです。去年の9月ぐらいに作った/作ってるよ、というのは発表していたのですが、それからかれこれ半年以上もpublicにしてないベイパーウェアだったのですが（グラニ社内では使ってました）、重たい腰を上げてやっと、やっと……、公開。
謳い文句は型付き非同期RPCフレームワークで、サーバー側はC#でasync/awaitを使ったメソッド実装、Unity側はそこから生成されたUniRx利用のメソッドを呼ぶだけで相互に通信できます。それでなにができるかというと、Visual StudioでUnity -> Server -> Unityと完全に一体化してデバッグできます。全部C#で。もうこれだけで最強でしょう。他は比較にならない。勝った。終わった。以上第一部完。
真面目に特徴、強みを上げると、以下のような感じです。
- 完全タイプセーフ。サーバー-サーバー間は動的プロキシ、クライアント-サーバー間は事前クライアント生成。
- IDLレス。C#サーバーコードのバイナリを元にして、クライアントコードを生成するので、普通にサーバーコードを書くだけ。面倒なIDLはゴミ箱ぽい。
- 高性能。サーバーはasync/awaitで、クライアントはUniRxにより完全非同期で駆動。特にサーバーのC#コードはIL直書きも厭わずギチギチに最適化済み。
- 事前生成シリアライザによるMsgPackでのシリアライズ/デシリアライズ。デシリアライズは更にマルチスレッド上で処理してUniRxでメインスレッドにディスパッチするのでフレームレートに一切影響を与えない。
- Visual Studioとの完全な統合。高いデバッガビリティと、Analyzer利用を前提にしたフレームワーク構成はVS2015時代の新しい地平線。
- 外部ツール「PhotonWire.HubInvoker」により外からAPIを直接叩ける。
HubInvokerは私にしては珍しく、ちゃんと見た目にこだわりました。これの外観の作り方はMaterial Design In XAML Toolkitでお手軽にWPFアプリを美しくで記事にしてます。
Photon Serverを選ぶ理由
Unityでもネットワーク系は色々な選択肢があると思います。
- UNET
- PUN + Photon Cloud
- Photon Server(SDK直叩き)
- モノビットエンジン
- WebSocketで自作
- MQTTで自作
このあたりは見たことある気がします。そのうちUNETは標準大正義だしAPIもProfilerも充実してる感なのですが、uNet Weaver Errorがムカつくので(コンパイルができなくなるという絶望！特にUniRx使ってると遭遇率が飛躍的に上昇！)、それが直らないかぎりは一ミリも使う気になれない。というのと、サーバーロジックを入れ込みたいどうしてもとにかくむしろそれがマスト、な状況の時にというか割とすぐにそうなると思ってるんですが、Unity純正だと、逆にUnityから出れないのが辛いかな、というのはありますね（ロードマップ的にはその辺もやるとかやらないとかあった気がしますが、まぁ遠い未来ということで）。Unity外で弄れるというのは、サーバーロジックだけじゃなくHubInvokerのようなツールを作れるっていうのも良いところですね。大事。なので、標準大正義は正しくも選べないのです。
モノビットはよく知らないので。C++でサーバーロジックは書きたくないなあ、今はC#も行けるんですっけ？
自作系は、あんまりそのレイヤーの面倒は見たくないので極力避けたい。別に動くの作るのはすぐでも、まともにちゃんと動き続けるの作るのは大変なのは分かりきってる話で。トラブルシュートも泣いちゃう。そこに骨を埋める気はない。あと、自作にするにしてもプロトコルの根底の部分で安定してるライブラリがあるかないかも大事で（そこまで自作は本当に嫌！）、Unityだとただでさえそんなに選択肢のないものが更に狭まるので、結構厳しい気がするのよね。実際。
Photonといって、Photon Cloudの話をしているのかPUN(Photon Unity Network)の話をしているのか、Photon Serverの話をしているのか。どれも違く、はないけれど性質は違うのだから一緒くたに言われてもよくわからない。さて、PUN。PhotonのUnityクライアントは生SDKが低レイヤ、その上に構築されたPUNが高レイヤのような位置づけっぽい感じですが、PUNは個人的にはないですね。秒速でないと思った。PUNの問題点は、標準のUnity Networkに似せたAPIが恐ろしく使いづらいこと。標準のUnity Network自体が別に良いものでもなんでもないレガシー（ついでにUnity自体も新APIであるUNETに移行する）なので、それに似てて嬉しい事なんて、実際のとこ全くないじゃん！もうこの時点でやる気はないんですが、更にPhoton Serverで独自ロジック書いたらそこははみ出すので生SDK触るしかないのだ、なんだ、じゃあいらないじゃん？Client-Client RPCも別になくてもいいし、というかなくていいし。
Photon Server。C++のコアエンジンってのは言ってみればASP.NETにおけるIISみたいなもので、開発者は触るところじゃない、直接触るのはサーバーSDKとクライアントSDKだけで、つまり両方ピュアC#。その上では普通にC#でガリガリと書ける。いいじゃん。両方ピュアC#というのが最高に良い。サーバーはWindowsでホストされる。それも最高に良い。プロトコルとかはゲーム専用で割り切ってる分だけ軽量っぽい。うん、悪くないんじゃないか。
また、ホスティングは結構優秀です。まず、無停止デプロイができる（設定でShadowCopy周りを弄ればOK）。これ、すっごく嬉しい。この手のは常時接続なのでデプロイ時に切断するわけにもいかないし、これ出来ないとデプロイの難易度が跳ね上がっちゃいますからねぇ。また、1サーバーで擬似的に複数台のシミュレートなどが可能です。実際、グラニでは6台構成クラスタのシミュレートという形で常に動かしていて、どうしても分散系のバグを未然に防ぐには重要で、それがサクッと作れるのは嬉しい。脚周りに関しては、かなり優秀と思って良いのではないでしょうか。
PhotonWireの必要な理由
Photon Serverがまぁ悪くないとして、なんでその上のレイヤーが必要なのか。これは生SDKを使ったコードを見てもらえれば分かるかしらん。
// 1. クライアント送信 var peer = new CliendSidePeer(new MyListener()); peer.OpCustom(opCode:10, parameter:new Dictionary<byte, object>());
// 2. サーバー受信 protected override void OnOperationRequest(OperationRequest operationRequest, SendParameters sendParameters) { switch (operationRequest.OperationCode) { case 10: // Dictionaryに詰まってる var parameter = operationRequest.Parameters; HogeMoge(); // なんか処理する // 3. 送り返す this.SendOperationResponse(new OperationResponse(opCode:5), sendParameters); // break; // 以下ケース繰り返し default: break; } }
public class MyListener : IPhotonPeerListener { // 4. クライアント受信 public void OnOperationResponse(OperationResponse operationResponse) { // 返ってきたレスポンス switch (operationResponse.OperationCode) { case 5: // なんかする break; } } }
問題点は明白です。原始的すぎる。byteパラメータ、Dictionaryを送って受け取りそれをswitch、送り返してやっぱswitch。こうなると当然長大なswitchが出来上がってカオスへ。また、クライアント送信とクライアント受信がバラバラ。コネクションで送信した結果を受け取るのが、独立した別のListenerで受け取ることになる、となると、送信時にフラグONで受信側でフラグチェック祭り、Listener側のフラグ制御が大変。送信したメッセージと戻り受信メッセージだという判別する手段がないので、並列リクエストが発生するとバグってしまう。
これをPhotonWireはHubという仕掛け(とUniRx)で解決します。
ようするにMVCのControllerみたいな感じで実装できます、ということですね。また、逆に言えば、PhotonWireはそんなに大きな機能を提供しません。あくまで、このswitchやちょっとしたシリアライゼーションを自動化してあげるという、それだけの薄いレイヤーになっています。なので、PhotonWireによるコードが素のPhoton Serverによるものと少し異なるからといって、あまり警戒する必要はありません。実際、薄く作ることは物凄く意識しています。厚いフレームワークは物事の解決と同時に、別のトラブルを呼び込むものですから……。
ちなみにPhotonWireを通すことによる通信のオーバーヘッドは4バイトぐらいです。それだけで圧倒的に使いやすさが向上するので、この4バイトは全然あり、でしょう。
Hub
HubというのはASP.NET SignalRから取っています。というか、PhotonWireのAPIはSignalRからの影響がかなり濃いので、ドキュメントはSignalRのものを漁れば20%ぐらいは合ってます（全然合ってない）
// Unityクライアント側で受け取るメソッド名はインターフェイスで定義 public interface ITutorialClient { [Operation(0)] void GroupBroadcastMessage(string message); } [Hub(100)] public class Tutorial : PhotonWire.Server.Hub<ITutorialClient> { // 足し算するだけのもの。 [Operation(0)] public int Sum(int x, int y) { return x + y; } // 非同期も行けます、例えばHTTPアクセスして何か取ってくるとか。 [Operation(1)] public async Task<string> GetHtml(string url) { var httpClient = new HttpClient(); var result = await httpClient.GetStringAsync(url); // PhotonのStringはサイズ制限があるので注意（デカいの送るとクライアント側で落ちて原因追求が困難） // クラスでラップしたのを送るとPhotonの生シリアライズじゃなくてMsgPackを通るようになるので、サイズ制限を超えることは可能 var cut = result.Substring(0, Math.Min(result.Length, short.MaxValue - 5000)); return cut; } [Operation(2)] public void BroadcastAll(string message) { // リクエスト-レスポンスじゃなく全部の接続に対してメッセージを投げる this.Clients.All.GroupBroadcastMessage(message); } [Operation(3)] public void RegisterGroup(string groupName) { // Groupで接続の文字列識別子でのグループ化 this.Context.Peer.AddGroup(groupName); } [Operation(4)] public void BroadcastTo(string groupName, string message) { // 対象グループにのみメッセージを投げる this.Clients.Group(groupName).GroupBroadcastMessage(message); } }
async/awaitに全面対応しているので、同期通信APIを混ぜてしまっていて接続が詰まって死亡、みたいなケースをしっかり回避できます。属性をペタペタ張らないといけないルールは、Visual Studio 2015で書くとAnalyzerがエラーにしてくるので、それに従うだけで良いので、かなり楽です。
プリミティブな型だけじゃなくて複雑な型を受け渡ししたい場合は、DLLを共有します。
// こんなクラスをShareプロジェクトに定義して、Server側ではプロジェクト参照、Unity側へはビルド済みDLLをコピーする public class Person { public int Age { get; set; } public string FirstName { get; set; } public string LastName { get; set; } }
// サーバーがこんなふうに戻り値を返して [Operation(1)] public Person CreatePerson(int seed) { var rand = new Random(seed); return new Person { FirstName = "Yoshifumi", LastName = "Kawai", Age = rand.Next(0, 100) }; }
// Unity側では普通に受け取れる proxy.Invoke.CreatePersonAsync(Random.Range(0, 100)) .Subscribe(x => { UnityEngine.Debug.Log(x.FirstName + " " + x.LastName + " Age:" + x.Age); });
プロジェクトの構成はこんな感じ。シームレス。
また、オマケ的に、Unity側でのエディタウィンドウではコネクションの接続状況と送受信グラフがついてきます。UNETの立派なProfilerに比べるとショボすぎて話にならないんですが、ないよりはマシかな、と。
サーバー間通信
Photon Serverはサーバーとサーバーを接続してクラスタを作れるのですが、その通信もHubを使ったRPCで処理しています。
// ServerHub(呼ばれる方) [Hub(54)] public class MasterTutorial : PhotonWire.Server.ServerToServer.ServerHub { [Operation(0)] public virtual async Task<int> Multiply(int x, int y) { return x * y; } } // ClientHub（呼ぶ方） [Hub(99)] public class Tutorial : Hub { [Operation(0)] public async Task<int> ServerToServer(int x, int y) { var val = await GetServerHubProxy<MasterTutorial>().Single.Multiply(x, y); return val; } }
この見た目、直接呼んでるかのように書けるサーバー間通信は、実行時には以下のように置き換わってネットワーク呼び出しに変換されています。
なので、ServerHubはかならず戻り値はTaskじゃないとダメです（Analyzerが警告してくれます）。昔はこの手の処理を、メソッド呼び出しのように隠蔽する場合って、同期的になっちゃって、でもネットワーク呼び出しなので時間かかってボトルネックに、みたいなパターンが多かったようですが、今はTask[T]があるので自然に表現できます。このへんも含めてTask[T]が標準であることの意味、async/awaitによる言語サポートは非常に大きい。
この辺りの詳しい話は以下のスライドに書いています。
ネットワーク構成
PhotonWireは特に何の既定もしません。Photonが自由に組める通り、どんな組み方もできるし、どんな組み方をしてもPhotonWireでの呼び出しに支障は出ません。
のはいいんですが、その時、ClientPeer, InboundS2SPeer, OutboundS2SPeerの3種類のPeerを持つように、PhotonWireもまたHub, ServerHub, ReceiveServerHubとそれぞれに対応する3種のHubを持っています。3つ、これは複雑で面倒。
しかしPhotonWireはネットワークの複雑さの隠蔽はしません。やろうと思えばできますが、やりません。というのも、これ、やりだすと泥沼だから。賢くやりたきゃあAkkaでもなんでも使ってみればよくて、自分で書いたら一生終わらない。Photonのネットワークは本当に全然賢くなくて、ただたんに直結で繋いでるという、それだけです。そんなんでいい、とまではいいませんが、そうなら、それに関しては受け入れるべきでしょうね。勘違いしちゃあいけなくて、フレームワークは複雑さを隠蔽するもの、ではないのです。
ともあれ、最低限の賢くなさなりに、スケールしそうな感じに組み上げることは可能なので、全然良いとは思ってますよ！
できないこと
ポンと貼り付けてtransformが自動同期したり、いい感じに隙間を補完してくれたりするものはありません。ただ、Client-Server RPCがあれば、それは、その上で実装していくものだと思うので（いわゆるNantoka ToolkitとかNantoka Contribの範疇）、しゃーないけれど、自前で作ろうという話にはなってきますね。↑のネットワーク構成の話も、隠蔽とまではいかなくても、決まった構成になるのだったらそれなりにバイパスするいい感じのユーティリティは組んでいけるだろうから、その辺のちょっとした増築は、やったほうがいいでしょう。
まとめ
現状実績はないです（今、公開したばかりですからね！）。ただ、グラニで開発中の黒騎士と白の魔王というタイトルに投下しています。
半年以上は使い続けているので、それなりには叩かれて磨かれてはいるかなあ、と。大丈夫ですよ！と言い切るには弱いですが、本気ですよ！とは間違いなく言えます。DLLシェアや自動生成周りが複数人開発でのコンフリクトを起こしがちで、そこが改善しないと大変かなー、というところもありますが、全般的にはかなり良好です。
ちょっと大掛かりだったり、Windows/C#/Visual Studioベッタリな、時代に逆行するポータビリティのなさが開き直ってはいるんですが、結構使い手はあると思うので試してみてもらえると嬉しいですね！あと、大掛かりといっても、知識ゼロ状態からだったら素のPhoton Server使うよりずっと楽だと思います。そもそもにPhotonWireのGetting Startedのドキュメントのほうがよほど親切ですからねぇ、Visual Studioでのデバッグの仕方とかも懇切丁寧に書いてありますし！
VR時代のマルチプレイヤーって結局どうすんねん、と思ってたんですが、Project TangoのサンプルがPhotonだしAltspaceVRもPhotonっぽいので、暫くはPhotonでやってみようかなー。という感です。
