Raspberlyのブログ

Raspberlyのブログ

Unityネタをメインとした技術系ブログです。にゃんこ大戦争や日常なども。そろそろブログタイトル決めたい

トップ > 勉強会/イベントレポ > 勉強会レポ : 【Unity / .NET Core】 MagicOnion勉強会

勉強会レポ : 【Unity / .NET Core】 MagicOnion勉強会

勉強会/イベントレポ 勉強会/イベント-その他Unity関係

勉強会のレポート(メモ)です。
参加したのはこちら、「【Unity / .NET Core】 MagicOnion勉強会」
会場はドワンゴさんです。

connpass.com

ハッシュタグ : #MagicOnion

 

 

f:id:Raspberly:20190604235120j:plain

 

 

動画はこちらから。

www.youtube.com

 

 

 

 

 

 

 

 

今回は実演が多い箇所があるので別途スライドと動画を見てください。

#1. MagicOnionライブコーディング+α

 

 

 


 

#2. The Patterns of MagicOnion

MagicOnionとは

gRPCベースでなんでもできるネットワークエンジン
できるのはサーバーを通したRPC
RPCとははネットワークごしにメソッドをよぶこと

MagicOnionは究極の土管

どこまでも応用がきいてなんでもできる。

重要なのはサーバープログラムを透明にしないこと
どっちも大事です。クライアントだけで完結などはナンセンス。

クラウドサーバー間のRPCをどれだけ書きやすくできるかということをMagicOnionは追求しています。

P2Pじゃない

P2Pは結構複雑
サーバーを通して通信すると考えるだけで結構シンプルになります。

実装パターン

サーバーとクライアントをどうシェアするかがはまりどころ
コピペで済ませていいんです

ホスティング

ホスティング用のパッケージが専用に用意されています
これを使えば全部やってくれます
ASP.Net Coreなど標準のしくみに乗っかっています

コンテナカット

コピペでOKです

デプロイ

CIを使えばおおむねOK(CircleCIをオススメ、いい感じに処理してくれます)
ここも意味わかんなくてもコピペすればOK

リアルタイムサーバー

ストリーミングハブを使いましょう

マッチングサービスは自分で作る必要があります(Open Matchがおすすめ)
ただ現状微妙、自前で作った方がいいでしょう。
MagicOnionは外部のミドルウェアやサービスに全乗りできるのがいいところ。
他のシステムに乗っかって、組み合わせて作ることができます。

これからのロードマップ

Pure C#
コードジェネレートの改善
サーバーサイドのゲームループ
テレメトリ改善
サーバーレス対応

まとめ

オレオレフレームワークにしないようにしています
UniRxのようにほかのところでも使える知識を得られるようにしたい

 

 

 

 

#3. 明日から使えるMagicOnion

MagicOnionはHTTP/2を使っています(前は1を使っていた)
2はコネクションを張りっぱなし
指定のアドレスを聞きに行くのではなくgRPCなどのライブラリを使います
gRPCは見慣れない部分が多いがMagicOnionならC#の構文で書くことができます

MagicOnionの使用目的

Unity以外でも使えます、デスクトップアプリでも

MagicOnionはPhotonWireをベースに洗練されたものです
それぞれの特徴を生かして使っていきましょう

MagicOnionの強み

・定義がC#で完結します
・VisualStudioのサポートを受けることで実装速度が向上します
・.NET Core対応
・Unity対応
・作っている人が日本にいます

MagicOnionの弱み

・実績がまだない
・会社で導入するには実績がないとつらい
・C#がきらいな人にとってはつらい
・ノウハウの情報が少ない

MagicOnionの勘違い

・通信は遅いということはない
モバイル用だとどうやってもかかる
・サーバーサイドC#は遅いということはない
・全部C#なら実装速度早いのでは
MagicOnionで得られるのはサーバー・クライアントの透明性
両方C#なのでクライアントエンジニアがサーバーを読みやすい
C#は実装の速度は速くなるがリリースの速度が速くなるというわけではない

UniRxとMagicOnion

・一部コンポーネントが被る
・MVRPを使うならHub/ReceiverはModelが持つべき
Hub/Receiverはクライアント視点でどこで使うのかを見てわけるとよい

チームの話

サーバーとクライアントが同じ言語ならチームメンバーが両方やるべきか？
サーバーはサーバーで専用の知識が必要だったりする、ただチーム構成は広がります

Unityエディタ拡張

gRPCがよくUnityを殺します
gRPCがゾンビ化するので寿命管理はしっかりやりましょう

リアルタイム通信

多少の遅れが認められるもの
毎フレーム状態が変わるものはオンメモリでやったほうが楽

mocとmpc

メッセージパックのresolverの作成
本来はリフレクションを使うところだが、IL2CPP向けにこういうのがあります

まとめ

こういうプロジェクトを作りました

 

 

 

 

#4. MagicOnionでの共通処理の挟み方

サーバーサイド

２つやりかたがあります
・MagicOnionFilter
・gRPCInterceptor
どっちもgRPCの前後に処理を挟むものです

どっちを使えばいいのかというと、それぞれできることが違います。

クライアントサイド

gRPCでやるしかないです
戻り値がasyncじゃないので作る必要があります

エラーハンドリング

gRPCではAggregateExceptionが発生します
ただしInterceptorを複数重ねるとその数だけラップされ取り出しづらくなってしまう
そのため1クラスにまとめて書いた方がいいです

リトライ処理

リトライをする方法がなさそうなので拡張メソッドをつくる必要があります

まとめ

サーバーは要件に合うほうを使いましょう
クライアントはgRPCのみ
できないことは頑張って実装しましょう

 

 

 

 

 

LT1. MagicOnionをContainer化してkubernetesで動かしてNew Relicで監視する

 

 

 

LT2. MagicOnionを使う場合と使わない場合

MagicOnionとgPRCはうまく使い分けようというお話

 

 

 

LT3. リアルタイムなゲームの開発でコンテナを使ってみたら簡単便利で激安だったのでオススメしたい！

リアルタイムなゲームはサーバーでコンテナで動かしましょう
最初はローカルでやっていくとあとからつらくなる

コンテナの敷居は高くない

コンテナ化は簡単
Qittaに記事にしました。

qiita.com

コンテナの起動めんどそう

実際めんどいです
apiで操作しましょう
私はazureを使っています

個人開発だしサーバーにお金かけたくない

コンテナを動かす構成は非常に安い
私の場合だと91円

コンテナは安くて便利で手軽
ぜひ使ってみてください

 

 

 

 

 

 

タイムライン

 

 

f:id:Raspberly:20190605010451j:plain

 

 

 

間違っている箇所、消してほしいツイートがありましたらコメントにお願いします。