Unite2017 参加しました その3
「黒騎士と白の魔王」にみるC#で統一したサーバー/クライアント開発と現実的なUniRx使いこなし術
www.slideshare.net
開発環境
- Perticleの関係で、IL2CPPでビルドはしているが、unity5.3.7
- MMORPG すべてのバトルはC#サーバーにて処理
- AI・演算・結果処理はサーバー
- クライアントはコマンドを受けて、画面を更新
C#大統一理論
メリット
- コードの共有が可能
- サーバーとクライアントのエンジニア同士が互いのコードを理解できる。
- サーバーとクライアントでエンジニアを入れ替えられる。(エンジニアのレベル向上)
- DLLなどの中間プロジェクトを共有できる
- SharedLibraryという中間定義をする必要があった
- IDL(Interface Definition Language)経由の中間コード生成が不要
デメリット
- エンジニアがサーバーとクライアントを合わせたチームになるため、コミュニケーションが困難
- エンジニアには得手不得手がある。
HTTP/2
WebAPIを置き換えるために何か別のフレームワークを利用したい
gRPCとは
- Googoleの提唱するHTTP/2のフレームワーク
- HTTP/2は常時接続・バイナリ通信をサポート
- gRPCはストリーミング通信をサポート
- Unityにおいて、リアルタイム通信が可能になる!
gRPCの導入
Battle Engine
- WebAPI系とリアルタイム通信系の2つ
- リアルタイム通信にはgRPCを使ったStreamingServerを実装
- ちなみに、敵のAI部分はF#で日本語プログラミング言語を実装
UniRX
- UniRXを利用して、MVVMのようなアーキテクチャを使っているようだ。
メリット
- 通信のハンドリングとRXの親和性は高め(非同期処理向け)
- Unity2017でasync/await が実装されるためこっちの方がオススメ
デメリット
- リアクティブスパゲッティが完成
- Rxと使いまくるとChaosへ。
- 伝搬を短くしましょう。
- 循環したらやばいので、注意する。
Tips
ToYieldInstructionの場合IObservableでEmpty返しても思い通りに動かない。 Neverを返すのがオススメ
その他
JSON.NET(Unity)のシリアライズ遅い
マスタデータの生成が遅い
- MasterMemory
- In memory databaseを利用することで解決