みくみくまうすについて&Unity で使えるコーディングノウハウ
•Télécharger en tant que PPTX, PDF•
18 j'aime•9,117 vues
2014/12/20 プログラミング生放送勉強会 第32回＠GMO Yours で発表した講演資料です ・ニコ生配信支援ツール「みくみくまうす」についての紹介 ・コーディングする上で意識すべきこと -名前の付け方 -機能の分離 -SOLID原則 -MVCパターンとUnity ・C#の便利機能 -拡張メソッド -LINQ -UniRx
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à みくみくまうすについて&Unity で使えるコーディングノウハウ
Similaire à みくみくまうすについて&Unity で使えるコーディングノウハウ (20)
Plus de torisoup
Plus de torisoup (20)
Dernier
Dernier (11)
みくみくまうすについて&Unity で使えるコーディングノウハウ
- 2. 自己紹介 とりすーぷ (@toRisouP) • 25歳 • 某Web企業でエンジニアやってる • 趣味でいろいろ開発してる – 一番得意な言語はC# – 最近はずっとUnityいじってる – あとUniRxが最近のマイトレンド
- 4. 今作ってるもの みこバト～レ • 東方2次創作ゲーム • UnityとPhotonCloudを使ったネット対戦ゲーム • プログラマは自分1人だけ（いろいろツライ）
- 5. 本題 今回話すこと • 「みくみくまうす」の紹介 • コーディングする上で意識すべきこと • Unity開発で活用できるC#の機能
- 7. みくみくまうす • ニコ生の配信支援ツール • MMDモデルがニコ生のコメントを読み上げてくれる • 配信ツールでクロマキー合成して映像に合成して使う
- 8. ゲーム配信で使ったり
- 10. たくさん配置してみたり
- 12. 機能 • コメントの読み上げ – 棒読みちゃんの設定次第でボイスロイドも使用可能 • コメントの感情解析 – コメントの内容でキャラクタのリアクションが変わる • 複数キャラの同時使用 – コメントカラーで読み上げのフィルタリングができる • デスクトップマスコットモード – ウィンドウからキャラクタが独立して表示される
- 15. しくみ コメビュ （やりますアンコちゃん／NCV) 棒読みちゃん • みくみくまうす用プラグインを作成 • ニコ生からコメントを取得 • コメントのフィルタリング／解析 • 口パクと発声依頼 • 実際に読み上げる • VoiceroidTalkPlusを使えばボイスロ イドでも読み上げできる TCP Socket TCP Socket
- 16. つかったもの • Unity Pro 4.6（βのころから使ってた） • ユニティちゃん（とそのアニメーション） • MMD4Mecanim • MeCab（NMeCab) • LitJSON みくみくまうすは「ユニティちゃんライセンス」で提供されています
- 18. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 19. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 20. MMDのインポート • MMD4Mecanimを使用すると簡単にインポートできる – 付属のスクリプトがかなり充実している – ただしモデルの動的ロードには対応していない • 後述のライセンスの問題もある
- 21. MMDモデルのライセンス • ゲームで使用して良いかは作者への確認が必要 – 作者によってライセンスがバラバラ – Readmeに明記されていないことが多い
- 22. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 23. コメビュとの通信 • コメビュ用プラグインを作って導入 – TCP接続で待ち受ける（コメビュ側がホスト） – 複数クライアントの同時接続に対応 – コメント情報のデータフォーマットはJSON • コメビュとの通信Componentも作成 – コメビュからコメントを取得する – 実際の通信を行う機構はUnityと分離してある
- 24. Unityでニコ生のコメントを取得したいとき • CommentViewer2Unity – コメビュプラグインからコメントを取得するComponent – 使用にはLitJSONが必要 – https://github.com/TORISOUP/CommentViewer2Unity
- 25. 【余談】UnityでJsonを使う • Unityでは標準ではJsonが扱えない • Jsonライブラリを入れる必要がある – MiniJSON – JSONObject – LitJSON ← 自分はこれを使ってる
- 26. そもそもJsonとは • JavaScript向けに作られたデータ記述言語 – 数値 – 文字列 – Boolean – 配列 – 連想配列 – Null ※要するに各値をテキストデータに変換する時のフォーマットの一つ
- 28. LitJSONの使い方 • JSONからオブジェクトに変換する ToObject<T>()を使えば良い ただし • 変換に失敗すると例外が飛ぶ • floatは使えない（doubleを使うこと） • 値の中身がnullだった時の扱い（null許容型を使う）
- 29. Jsonで値が送られてこなかった時の判別方法 • Null許容型 構造体（値型）にnullが入ることを許容する 「Jsonの中身にNoの要素が無かった」 ・非Null許容型int → ０で初期化（０が送られてきたのか判断不能） ・Null許容型int → Nullかどうかで値が送られてないと判断できる
- 30. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 31. 口パク • MMD4MecanimSpeechHelperで簡単にできる – MMDモデルはこのスクリプトで口パクできる – ただしこのSpeechHelperはMMDモデルにのみ使える – ユニティちゃんは別にスクリプトを自作して対応 • クエリちゃんは対応できんかった……
- 33. 口パク用のコメントひらがな変換 • 口パクさせる為にコメントのひらがな化を行う – NMeCabを使ってひらがな化 – KakasiはGPLライセンスだったので避けた
- 34. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 36. リアクションするキーワードの例 • 挨拶 （「わこつ」、「初見」など） • 挙手 （ノ） • 笑い （ｗを含むコメント、「吹いた」「ワロス」など） • 絶叫 （あああああ！ など） • ツッコミ （「おまえが言うな」「やめてー＞＜」など） • 命令 （～しろ！ など） • 疑問 （語尾に「？」が付いているなど） • 感動 （「泣けてきた」「切ない」など） • 賛美 （「ありがとう」「才能の無駄遣い」など） • 返答 （「おこ？」「ですよねー」など） • 興奮 （「おおぉぉぉぉぉ！」など） • 賞賛 （「すごい！」など） ※ただしそこまで精度はよくない
- 37. コメント感情解析の仕組み • ニコニコ動画コメント＠ばっちりサーチ.net – こちらのnode.js用モジュールをC#に移植 • https://github.com/TORISOUP/CommentAnalyzerCSharp – 中身は鬼のような正規表現 – 正直どのコメントが何に判定されるかわからない
- 38. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 39. 設定パネル
- 40. 設定ファイル • パラメータをJsonでテキストに保存（.NETの機能） – PlayerPrefsはレジストリに保存されるので使いたくない – バイナリにシリアライズして保存すると後から変更しにくい – 読み込み時にバリデーションを入れる必要がある（平文保存のため）
- 41. 実装について話すこと一覧 • MMDモデルのインポート • コメビュとの通信 • 口パク • コメントの感情解析 • 設定ファイルの読み書き • デスクトップマスコットモード
- 43. みくみくまうすのまとめ • ニコ生配信支援ツール • フリーソフトとして配布中 • 生放送を盛り上げるのに使ってね！！！ • プログラミング生放送でも使おう！！ • 使うときは「みくみくまうす」のタグを付けてくれるとエゴサしやすくて助かります
- 44. ステッカー • 調子に乗ってステッカーも作りました – 数に限りがあるので欲しい人は１人１枚お持ち下さい – 割りと安い（１００枚刷って４０００円くらい）
- 47. おしながき • 名前 • 機能の分離 • SOLID原則 • MVCパターン
- 48. おしながき • 名前 • 機能の分離 • SOLID原則 • MVCパターン
- 50. 例）メソッド名 • メソッド名から処理内容が判断できるべき – メソッド名が長くなるのは構わない（限度はあるが） – 例）GetNearestEnemyFromPlayer • 誤解される名前をつけるな – Get*()なのに副作用がある • 副作用＝状態を変化させてしまう動作 • Get()は何度実行しても結果が同じになるべき（べき等性） – GetSize()なのに計算量がO(n) • GetSize()はO(1)であるべき • O(n)なら「Count()」にしたほうがまだわかる
- 52. おしながき • 名前 • 機能の分離 • SOLID原則 • MVCパターン
- 53. 機能の分離 • Unityに依存しないコードを書こう – なんでもかんでもMonoBehaviourを継承させない – Unityからゲームロジックを分離する – Unity以外でもそのまま使えると良い – 単体テスト書きやすくなる
- 54. おしながき • 名前 • 機能の分離 • SOLID原則 • MVCパターン
- 55. SOLID原則 • オブジェクト指向開発を行う上での５つの原則 – 単一責任の原則(SRP) – オープン・クローズドの原則(OCP) – リスコフの置換原則(LSP) – 依存関係逆転の原則(DIP) – インターフェース分離の原則(ISP) • あくまで原則である – 必ず守る必要はない – 守ったほうが良い場合の方が多い – Unity開発も例外ではなく守った方が良い
- 56. SOLID原則 • 単一責任の原則(SRP) • オープン・クローズドの原則(OCP) • リスコフの置換原則(LSP) • 依存関係逆転の原則(DIP) • インターフェース分離の原則(ISP)
- 57. 単一責任の原則 「クラスを変更する理由は１つ以上存在してはならない」 「一つのクラスに複数の責務を持たせるな」 • 馬鹿でかいクラスは管理しにくい • １つのクラスにあれこれ機能を詰め込むな • クラス名以上の責務は負わせるな
- 58. 悪い例 • PlayerController(プレイヤキャラクタの制御） – Inputの受け付け – キャラクタの移動処理 – キャラクタの攻撃処理 – キャラクタの体力の管理 – アニメーション再生の管理 – エフェクト再生の管理 – 効果音再生の管理 – カメラの制御 処理多すぎィ！！！！！ だが初心者はやりがち
- 59. 適切に分離しよう • PlayerInputManager – Inputの受け付け • PlayerController – キャラクタの移動処理 – キャラクタの攻撃処理 – キャラクタの体力の管理 • PlayerView – アニメーション再生の管理 • CameraController – カメラの制御 • EffectManager – エフェクト再生の管理 • SoundManager – 効果音再生の管理
- 60. SOLID原則 • 単一責任の原則(SRP) • オープン・クローズドの原則(OCP) • リスコフの置換原則(LSP) • 依存関係逆転の原則(DIP) • インターフェース分離の原則(ISP)
- 61. オープン・クローズドの原則 「モジュールの振る舞いの拡張に対してオープンである」 「モジュールの振る舞いの修正に対してクローズドである」 • 機能追加は簡単にできる • 機能追加によって他のコードを書き換える必要はない • 要するに「ポリモーフィズム」となるようにしろ
- 62. オープン？クローズド？ • あとから簡単に機能追加できるようにしろ – インターフェースを実装すれば機能追加できる（オープン） – 実クラスが増えても元のコードに変更はなし（クローズド） SpeechTextController 読み上げるコメントの 管理を行う MMD4MecanimSpeechHelper MMD向け口パクComponent インターフェース ISpeechController
- 63. オープン？クローズド？ • あとから簡単に機能追加できるようにしろ – インターフェースを実装すれば機能追加できる（オープン） – 実クラスが増えても元のコードに変更はなし（クローズド） SpeechTextController 読み上げるコメントの 管理を行う MMD4MecanimSpeechHelper MMD向け口パクComponent インターフェース ISpeechController UnitychanLipController ユニティちゃん専用 口パクComponent
- 64. オープン？クローズド？ • あとから簡単に機能追加できるようにしろ – インターフェースを実装すれば機能追加できる（オープン） – 実クラスが増えても元のコードに変更はなし（クローズド） SpeechTextController 読み上げるコメントの 管理を行う MMD4MecanimSpeechHelper MMD向け口パクComponent インターフェース ISpeechController UnitychanLipController ユニティちゃん専用 口パクComponent ユニティちゃんを 簡単に追加できる （オープン）
- 65. オープン？クローズド？ • あとから簡単に機能追加できるようにしろ – インターフェースを実装すれば機能追加できる（オープン） – 実クラスが増えても元のコードに変更はなし（クローズド） SpeechTextController 読み上げるコメントの 管理を行う MMD4MecanimSpeechHelper MMD向け口パクComponent インターフェース ISpeechController UnitychanLipController ユニティちゃん専用 口パクComponent 呼び出し側に修正不要 （クローズド）
- 66. SOLID原則 • 単一責任の原則(SRP) • オープン・クローズドの原則(OCP) • リスコフの置換原則(LSP) • 依存関係逆転の原則(DIP) • インターフェース分離の原則(ISP)
- 69. SOLID原則 • 単一責任の原則(SRP) • オープン・クローズドの原則(OCP) • リスコフの置換原則(LSP) • 依存関係逆転の原則(DIP) • インターフェース分離の原則(ISP)
- 71. 関係の逆転？ • 上位から下位に依存した関係（ダメな例） – 上位モジュールが下位モジュールに依存 – 実クラスそのものを参照してしまっている – 実クラスの変更の影響を上位モジュールが受けやすい InputManager 入力を管理する PlayerReimu プレイヤ（霊夢） PlayerMarisa プレイヤ（魔理沙）
- 72. 関係を逆転させる • 下位から上位に依存させる – 上位のレイヤにインターフェースを作成 – 上位モジュールはインターフェースを参照する – オープン・クローズドの原則も同時に満たされる InputManager 入力を管理する PlayerReimu プレイヤ（霊夢） PlayerMarisa プレイヤ（魔理沙） PlayerYoumu プレイヤ（妖夢） インターフェース IPlayerInput
- 73. SOLID原則 • 単一責任の原則(SRP) • オープン・クローズドの原則(OCP) • リスコフの置換原則(LSP) • 依存関係逆転の原則(DIP) • インターフェース分離の原則(ISP)
- 76. • IPlayerInputインターフェースを各クラスが実装 – PlayerMarisaに「盗む Steal()」を増やしたい – IPlayerInputに追加してしまった インターフェース分離の原則に違反した例 InputManager 入力を管理する PlayerReimu プレイヤ（霊夢） PlayerMarisa プレイヤ（魔理沙） PlayerYoumu プレイヤ（妖夢） インターフェース IPlayerInput Move（） Attack（） Jump() Steal() Move（） Attack（） Jump() Move（） Attack（） Jump() Steal() Move（） Attack（） Jump()
- 79. SOLID原則のまとめ • 機能は分割して作れ • インターフェースを使え • モジュールの依存関係を疎結合にしろ
- 80. UnityとSOLID原則 • Componentは機能単位で分割して作るべき – クラス名以上の責務は負わせるべきではない – コードの記述量は増えるが、わかりやすくなる • Componentはインターフェースを介してやりとりするべき – Componentが複雑に関係しあう時は特に意識すべき – Componentの差し替えが楽になる • SOLID原則をいちいち守ってると逆に非効率なこともある – 小さい規模なら無視して作ったほうがぶっちゃけ早い – 大規模開発になった時はSOLID原則は重要になる
- 81. おしながき • 名前 • 機能の分離 • SOLID原則 • MVCパターン
- 82. MVCパターン • Model View Controller – GUIを持つアプリケーションで用いられるデザインパターン – 機能を以下の３つに分離する Controller （ユーザからの入力） Model （実データやロジック） View （描画処理）
- 83. UnityとMVC • プレイヤの制御がMVCパターンと相性がいい – プレイヤ制御を以下のMVCに分離してしまう Controller （ユーザからの入力） Model （実データやロジック） View （描画処理） Input周りの処理 • キーボード入力 • マウス入力 メイン処理 • 移動 • ダメージ判定 • 攻撃 出力系の処理 • アニメーションの再生 • エフェクトの再生 • 効果音の再生
- 84. プレイヤ制御とMVC • MVC分割のメリット – Componentの責務が明確になる（単一責任の原則） – 入力機器の差異をControllerの差し替えで対応できる – ネットワーク同期も簡単になる
- 86. 実例 • ユニティちゃんゴーストマンション – MVCが分離されているのでそれぞれ個別に開発できる – ゲームジャムで役に立った ←Controller ←Model ←View ←ネットワーク同期用 スクリプト
- 87. 「意識するべきこと」まとめ • わかりやすさ最優先でコードを書くべき • Unityへの依存は断ち切ろう • SOLID原則を意識した設計にしよう • インターフェースを活用しよう • MVCパターンは割りと使えるかもしれない
- 89. おしながき • 拡張メソッド • LINQ • UniRx（※ C#の機能では無い）
- 90. おしながき • 拡張メソッド • LINQ • UniRx
- 91. 拡張メソッド • クラスに外からインスタンスメソッドを追加する – staticメソッドを「あたかもそのクラスが持っているメソッド」を呼び出す かの様に記述できるようになる機能 – 実際はただのstaticメソッドの呼び出し static class ExtensionMethods { public static 返り値の型 メソッド名(this 追加対象の型,引数１…） { 処理… } ｝
- 92. 拡張メソッドを使うと便利な例 • Vector3のy成分を無視した水平面での方向を計算 – 進行方向にプレイヤを向かせるときに使うことが多い • y成分を含ませると身体が傾く 進行方向 鉛直方向を無視した 水平面での方向ベクトル
- 93. 拡張メソッド）水平面での方向ベクトルを取得 • Vector3型への拡張メソッドとして定義する – 拡張メソッドを収めるstatic classを定義 – その中にstaticメソッドを追加 – 第一引数のVector3にthisを付ける
- 95. 拡張メソッドまとめ • 標準で足りない機能をガンガン追加していこう – Vector3とかMomoBehaviourとかに追加すると便利になる – 自分なりにカスタマイズしてしまおう • 拡張メソッドの定義はわかりやすくしておく – どこに定義したかわからなくなる事態は避ける – 作った拡張メソッド群は資産として再利用可能
- 96. 拡張メソッド • 自分が追加した拡張メソッド群（一部） – Vector3 • ベクトルの要素ごとの積 • ２点間の距離の計算 • 水平面での距離の計算 • 水平面での方向ベクトルの計算 • x,y,zそれぞれの上書き – Transform • Photon ViewIDの取得 • Photon IsMineの取得 • キャラクタの中心座標を補正して取得 • CharacterControllerから速度を取得 – Animator • 値オブジェクトからAnimatorのパラメータに反映 • Animatorパラメータ書き換えと同時に差分を保存（ネットワーク同期用）
- 97. おしながき • 拡張メソッド • LINQ • UniRx
- 98. LINQ • 統合言語クエリ（LINQ) – 様々なデータソースに対する操作を統合的に記述するもの – 特にLINQ to Objects（コレクション）がよく使われる – せっかくのC#なのになぜLINQ使わないのか！？！？！？！？
- 99. LINQ to Objectで何ができるか？ • コレクションに対する操作を簡単に記述できる – コレクション（配列、リスト、ディクショナリとか） – 複雑な処理をわかりやすく記述できる LINQメソッドの例 処理の内容 Where 条件を満たす要素のみにフィルタリング Select 要素を別の形式に変換 Any 条件を満たす要素が１つもであるか All 全ての要素が条件を満たすか First 最初に見つかった条件を満たす要素を返す Count 条件を満たす要素の数を数える
- 100. 例）LINQを使わずに書く • TagがEnemy • 指定座標から半径10m未満 • Transformのリスト をGameObject配列から取得するメソッドをLINQを使わずに定義
- 101. 例）LINQを使わずに書く • TagがEnemy • 指定座標から半径10m未満 • Transformのリスト をGameObject配列から取得するメソッドをLINQを使わずに定義 本当に正しいかの確認が大変 これを毎回読み解くのか？
- 102. 例）LINQを使った場合
- 103. 例）LINQを使った場合 1. gameObjectArrayに対して 2. TagがEnemyのものだけ 3. 指定座標から10m未満のものだけ 4. Transformに変換して 5. List形式にまとめて返す • 順番に上から読むだけで処理の内容が理解できる – 単純に「やりたい事だけ」を記述すれば良い – ループやif文が無く、バグが入り込む余地がない
- 104. LINQまとめ • C#を使ってるなら是非使うべき機能 – ちゃんと使えばコード中からfor文を無くせる – LINQを使わずして何がC#か • 普通にループを書くより処理速度は落ちる – LINQによって実行速度が問題になるようなことはほぼ無い – コードの読みやすさ＞＞＞＞＞速度 – 下手に凝ったループを書いてバグを生むのとどっちが良いか？ • iOSでのLINQは不具合がある – 詳しくはショートセッションで
- 105. おしながき • 拡張メソッド • LINQ • UniRx
- 106. Rx（UniRx) • ReactiveExtensions(Rx) – LINQの概念を「非同期」「イベント」に拡張したもの – 時間を跨いだ処理を簡単に記述できる – UniRxはRxのUnity移植版（neueccさん作） • ちゃんと解説すると１時間はかかる – 今回は説明を放棄
- 107. UnityでRxを使う
- 108. Rxの概念 • イベントをストリームとして扱う – イベントって時間軸に並んだコレクションじゃね？ – コレクションならLINQで扱えるんじゃね？ ｔ
- 109. Rxの使い道 • イベントの代わりに使う（ストリームを作る） – Subject<T>を使えばストリームが作れる – 既存のEventの上位互換（むしろEventはレガシー） • ストリームの終了、エラーを通知できる • イベントの複雑な処理 – 特定のイベントのみ処理する – 前のイベントの値と組み合わせる
- 110. UniRxの例 • マウスのダブルクリックの検知 – 普通に書くと煩雑な処理がたった数行で終わった – 状態の一時保管用のフィールドの定義不要
- 111. Rxのまとめ • 時間やフレームを跨いだ処理を簡単に記述できる • 使いこなすとUpdate()の中身が短くなる • 学習コストは高め とにかく便利なので使ってみるべし
- 112. 「C#の機能」まとめ • C#には便利な機能がたくさんある – C#っぽくない書き方のコード多くて悲しい – 使いこなすと強力な武器になるので使うべし • Rx楽しい – 本当に便利なのでもっと流行るべき
- 113. 最後にまとめ • みくみくまうす使ってね – みんな生放送やろうぜ – せっかく作ったんだから使って欲しい • Unityの開発力は最終的にコーディング能力に行き着く – 複雑なことやるには結局スクリプトを書かないといけない – プログラミングスキルは高めるべき • 動き続けるプログラムが正義 – 「動けばいいや」ではダメ – Unityは特に適当に書いても動くので注意が必要 – 保守性やメンテナンス性も考えた開発をやろう
- 114. ありがとうございました