読者です 読者をやめる 読者になる 読者になる

なんとかするから、なんとかなる

エンジニア関係のことを書きます

Unite2017 参加しました その3

「黒騎士と白の魔王」にみるC#で統一したサーバー/クライアント開発と現実的なUniRx使いこなし術

www.slideshare.net

開発環境

  • Perticleの関係で、IL2CPPでビルドはしているが、unity5.3.7
  • MMORPG すべてのバトルはC#サーバーにて処理
    • AI・演算・結果処理はサーバー
    • クライアントはコマンドを受けて、画面を更新

C#大統一理論

メリット

  • コードの共有が可能
  • サーバーとクライアントのエンジニア同士が互いのコードを理解できる。
  • サーバーとクライアントでエンジニアを入れ替えられる。(エンジニアのレベル向上)
  • DLLなどの中間プロジェクトを共有できる
    • SharedLibraryという中間定義をする必要があった
  • IDL(Interface Definition Language)経由の中間コード生成が不要
    • JSONなどの中間形式が不要
    • VisualStudioとの親和性が高い(リファクタやシンタックスハイライト機能が便利)

デメリット

  • エンジニアがサーバーとクライアントを合わせたチームになるため、コミュニケーションが困難
  • エンジニアには得手不得手がある。

HTTP/2

WebAPIを置き換えるために何か別のフレームワークを利用したい

gRPCとは

  • Googoleの提唱するHTTP/2のフレームワーク
  • HTTP/2は常時接続・バイナリ通信をサポート
  • gRPCはストリーミング通信をサポート
  • Unityにおいて、リアルタイム通信が可能になる!

gRPCの導入

  • gRPCはC#フレームワークなので、Unityに対応ライブラリを作った。
  • MagicOnionという名前でOSSで公開中

Battle Engine

  • WebAPI系とリアルタイム通信系の2つ
  • リアルタイム通信にはgRPCを使ったStreamingServerを実装
  • ちなみに、敵のAI部分はF#で日本語プログラミング言語を実装

UniRX

メリット

  • 通信のハンドリングとRXの親和性は高め(非同期処理向け)
    • Unity2017でasync/await が実装されるためこっちの方がオススメ

デメリット

  • リアクティブスパゲッティが完成
    • Rxと使いまくるとChaosへ。
    • 伝搬を短くしましょう。
    • 循環したらやばいので、注意する。

Tips

ToYieldInstructionの場合IObservableでEmpty返しても思い通りに動かない。 Neverを返すのがオススメ

その他

JSON.NET(Unity)のシリアライズ遅い

  • ZeroFormatter
    • FlatBuffers を真似たデシリアライザ。
    • ただし、通信上大きくメモリが辛い
  • MessagePack-C#

マスタデータの生成が遅い

  • MasterMemory
  • In memory databaseを利用することで解決

参考URL

github.com

github.com

github.com