Drecom Tech Espresso #6 "おなかソフトのDontDestroyOnLoad" に行ってきました #おなかソフトのドンデス

ドリコムさんで開催された『Drecom Tech Espresso #6 "おなかソフトのDontDestroyOnLoad"』に行ってきたので雑なメモ。

伊藤周さん、@toru_inoueさん、女子大生のとりすーぷさん、西村拓也さんのパネルディスカッション形式で進行されました。写真撮ってなかったけどこんな感じで進行。

#おなかソフトのドンデス
ヤバい絵面 pic.twitter.com/ELfbVz1WrA
— izm (@izm) 2018年7月30日

とりすーぷさんは若干遅延のある系？女子大生でした。すばらしい。

https://t.co/h1OaEdp3iv

そういやボイチェンこれね
#おなかソフトのドンデス
— とりすーぷ (@toRisouP) 2018年7月30日

西村さんの新刊

捨てるコードとか、逃げ場があるところだと使うけど、テスト書きにくいのでまともなコードでは使わない（井上さん）
SceneManagerとか、もともとUnityでstaticなものをラップしたSingletonは使う（とりすーぷさん）
- 急ぐときは仕方ないときもある
Sigletonなしで作ってみたら、めんどくさい（西村さん）
シーンをまたいで引き継ぐとき、サウンド、オーディオには使う
Zenjectの機能でSingletonなオブジェクトを持てるので、いわゆるSingletonMonoBehaviour的なものは使わない
- [8/1 追記] 問題なのはSingletonなオブジェクトそのものではなくstatic変数による参照保持なので（テストが書けない原因）、Zenjectを使えばテストではモックに差し替えることも容易で問題ない、という話。とりすーぷさんから補足いただいて追記。
MainThreadDispatcherみたいなものとか、よくあるパターン
.NET 4.6ではLazy<T>が使える。C# in Depthに書いてあるパターン
テストしなければよい（暴論）
ステートを持たせなければよい、シーンをまたいで引き継がなければよい
Singleton自体は悪くないが、他の人に色々追加されてしまう

オブジェクトの引き継ぎ、管理コストを減らしたいので、1シーンで実装しよう、という本になってる（西村さん）
- DontDestroyOnLoadしたオブジェクトの管理がたいへん
- チーム開発だが、Sceneのヒエラルキーは触らないのでコンフリクトは発生しない
- prefabで切り替ている
- テストプレイのための工夫をしないと常に最初から実行になる
MultiSceneを使っている。ViewのシーンとModelのシーンを分けて重ねる（とりすーぷさん）
Zenject便利

チームによる（井上さん）
MとVが密結合になると壊れやすい。今はMVPに統一している（とりすーぷさん）
- 個人開発であってもルールがあると迷いがなくなる
コンシューマーから来たので馴染みがない考え方だったが、気づいたらMVPになってた（西村さん）
- アウトゲームはPassive ViewのMVP
- インゲームはSupervising Controller
uGUIはMVP、インゲームはそうでなくイベントをReactiveXで扱っている（とりすーぷさん）

画面に写ってたのたぶんこれ