Download as PDF, PPTX
コールバックと戦う話
- 1.
- 2. 自己紹介 • 名前 とりすーぷ（@toRisouP） •同人ゲームとか作ってます • 最近は割と忙しい – しごと – 同人ゲーム開発 – どんかつ
- 3.
- 4.
- 5.
- 6.
- 7. 使ってるフレームワークとか • Photon Cloud –ネットワークゲーム用のクラウドサーバとAPI群を 提供してくれるサービス • Photon Unity Networking(PUN) – 上記 Photon CloundのUniyt向けSDK • ニフティクラウド mobile backend (NCMB) – ユーザやデータのDB管理やオブジェクトストレージを提供してくれ るサービス（mBaaS)
- 8.
- 9. ネトゲ開発は非同期通信だらけ • 通信があるせいでほとんど非同期処理だらけになる – 「ログインしてユーザ情報を取得する」のも非同期処理 –「オブジェクトをインスタンス化する」だけでも非同期処理 – 「アイテムが今拾える状態か確認する」のも非同期処理 – 「全員の準備が完了するまで待つ」のも非同期処理
- 10. 非同期処理とコールバック • 非同期処理の面倒くさい部分ライブラリがなんとかしてくれる – スレッドの管理とか同期コンテキストとかは意識しなくてもいい •一方で、これらライブラリはコールバック処理を多用している – 非同期処理の結果を受け取るにコールバック処理を使っている
- 11. コールバック？ • 非同期処理の実行後その結果を通知するために 関数を実行する手法 – 非同期処理の制御で一番シンプルで単純な実装 –自分で任意の関数を登録するパターンや、決められた関数が実行される パターンがある • PUN、NCMBともにコールバックが大量に出て来る – ライブラリの実装が悪いとかいうわけではなく、 シンプルに作ればそうなるよね – ただしPUNテメーはだめだ
- 12.
- 13. PUNのコールバック • PUN – イベントが発生すると既定の名前の関数が実行される –例： • 誰かがゲームに参加した：OnPhotonPlayerConnected() • 部屋のリストが更新された：OnReceivedRoomListUpdate() – ちなみにPUNはコールバックの実装にSendMessageを使ってる • 旧Unity.Networkの実装に似せたのが原因 • このせいでめちゃくちゃ使い勝手が悪くなっている
- 14.
- 15.
- 16. コールバックがネストしまくる • NCMBで ログイン→ ステータス取得 → 更新して保存
- 17. コールバックがネストしまくる • NCMBで ログイン→ ステータス取得 → 更新して保存 ログインのコールバックブロック 詳細情報取得のコールバックブロック データ保存のコールバックブロック
- 18. コールバックがネストすると… • エラーハンドリングが困難になる • 処理のスコープが曖昧になってしまう •単純にインデントしまくって読みにくい • 人類の手に負えない
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 27.
- 28. この形式のやばいところ • コードを見ても処理のつながりが全く把握できない – PUNのドキュメントを片手にコードを読まないとマジでわからない •処理の文脈が途切れてしまう – 別の処理でも実行されるコールバックが同じだったりする場合、 このコールバックが何の処理に対するものなのかがわからない – そのためにわざわざフィールドに状態変数作るのめっちゃ馬鹿らしい
- 29. コールバックのやばいところ • 自分で関数登録するスタイルコールバック（NCMB) – 処理を直列に連結したり、複数並列実行しようとすると ネスト地獄になって管理できなくなる •既定の関数が呼び出されるコールバック（PUN） – 何を実行したらどの処理が次に実行されるのか？が把握しにくい – コード上から処理の文脈が失われて保守性が最悪になる
- 30.
- 31.
- 32. コールバックと戦うための道具 • Task – .NETFramework 4 から搭載された並列処理の機構の1つ • 一連の処理を「Task」というかたまりにまとめて管理する • async/await と組み合わせると強くなる – JavaScriptでいうPromise / JavaでいうFutureに似てる • Observable – Reactive Extensionsで提案された概念 – Taskをめっちゃ高機能化したイメージ（ざっくりとした説明） • 複数のイベントメッセージに対応 • Schedulerでスレッドやタイミング管理ができる • Operatorでメッセージの連結、合成、加工ができる
- 33. Taskを使う？ Observableを使う？ • 簡単な非同期処理であればTask(async/await) で十分 • そこからさらに複雑な処理が必要になるならObservable（Rx)
- 34. Taskを使う？ Observableを使う？ • 単純な非同期処理であればTaskで十分 •そこからさらに複雑な処理が必要ならObservable（Rx) と、言われているがこれはあくまで Unityを使わないピュアなC#開発の話
- 35. Unityだとどうなの？ • Task – Unity2017.1以降であれば MonoRuntimeを.NET 4.6にすれば使える • けど制約はある • それ以前のバージョンでもゴニョゴニョすれば使える – Unityでは導入に制約がある or 導入が面倒くさいのが難点 – 言語機能だけあって、async /await がめっちゃ強い • Observable – Unityなら「UniRx」を導入すれば使える – 表現力が高すぎてTaskと比べると学習コストが高い – Operatorとゲーム開発の親和性が高い
- 36.
- 37.
- 38.
- 39. コールバックをObservableにする例 • Observable.Createで コールバックごと処理を ラップしちゃう – 成功したらOnNextに結果を流す –失敗したらOnErrorに例外を流す コールバック関数の内部で Observerに値を渡す
- 40.
- 41.
- 42.
- 43.
- 44. ライブラリ化しました • NcmbAsObservable – NCMBのUniRxラッパー –https://github.com/TORISOUP/NcmbAsObservable • PhotonRx – PUNのUniRxラッパー – https://github.com/TORISOUP/PhotonRx • 両方ともgithubに公開しています – プルリクエストお待ちしております
- 45.
- 46.
- 47. コルーチンとObservable • コルーチンを使えばawaitを再現できる – Observableはコルーチン上でyieldreturnで待機できる – 記述量はTask+awaitより増えちゃうけどね – コルーチンのデメリットを引き継ぐデメリットはある
- 48.
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56. 3.これらを順番に呼び出すコルーチンを作る Observable.FromCoroutineValue<T>を使うと コルーチンが yield returnした値を取得できる ↓ コルーチンをObservableに変換し、 それをawaitすることで同期的に処理を書ける
- 57.
- 58.
- 59. まとめ • コールバックはそのまま扱うともれなく死を迎える – 仕組みが単純すぎて複雑なフローを表現できない –TaskとかObservableとかのイケてる仕組みに載せるのが吉 • TaskとObservableのどっちを使うかは考えよう – ピュアなC#開発とUnity開発は事情が違うので注意が必要 – 以前はUniRxが強かったが、 Unity 2017.1の登場で事情が変わってくるかも