みくみくまうすについて&Unity で使えるコーディングノウハウ

みくみくまうすの紹介＆Unityにおけるコーディングノウハウ

とりすーぷ

12/20

プログラミング生放送勉強会

自己紹介

とりすーぷ (@toRisouP)

• 25歳

• 某Web企業でエンジニアやってる

• 趣味でいろいろ開発してる

– 一番得意な言語はC#

– 最近はずっとUnityいじってる

– あとUniRxが最近のマイトレンド

過去に作ったもの

交通事故・渋滞シミュレータ

(sm16238908)

NITORI BOX

(東方2次創作ゲーム)

ユニティちゃんゴーストマンション

（OculusGameJam2014)

今作ってるもの

みこバト～レ

• 東方2次創作ゲーム

• UnityとPhotonCloudを使ったネット対戦ゲーム

• プログラマは自分1人だけ（いろいろツライ）

本題

今回話すこと

• 「みくみくまうす」の紹介

•コーディングする上で意識すべきこと

•Unity開発で活用できるC#の機能

みくみくまうす

• ニコ生の配信支援ツール

• MMDモデルがニコ生のコメントを読み上げてくれる

• 配信ツールでクロマキー合成して映像に合成して使う

ゲーム配信で使ったり

プログラミング生放送で使ってみたり

たくさん配置してみたり

生放送を盛り上げるためのツールみんなニコ生しようぜ

機能

• コメントの読み上げ

– 棒読みちゃんの設定次第でボイスロイドも使用可能

• コメントの感情解析

– コメントの内容でキャラクタのリアクションが変わる

• 複数キャラの同時使用

– コメントカラーで読み上げのフィルタリングができる

• デスクトップマスコットモード

– ウィンドウからキャラクタが独立して表示される

作った経緯

知人同士でニコ生を配信し、

自身のニコニココミュニティのレベルを

目標値まで先に上げた人が勝ち（コミュニティレベルは自分をお気に入り登録した人の数で決まる）

※優勝者は鰻が奢りになるから「鰻レース」と呼んでた

作った経緯２

女性の方のコミュレベルがどんどん上がっていく

（ただ顔出し放送するだけで入れ食い状態）

おっさんがただ配信するだけでは華がなく絶対に勝てない

だったら画面に女の子がいれば華があって人がくる？

あと自分はエンジニアなのでそこは武器になるのでは？

MMDモデルがコメントを読み上げてくれるツールを作ろう

しくみ

コメビュ（やりますアンコちゃん／NCV)

棒読みちゃん

• みくみくまうす用プラグインを作成

• ニコ生からコメントを取得

• コメントのフィルタリング／解析

• 口パクと発声依頼

• 実際に読み上げる

• VoiceroidTalkPlusを使えばボイスロイドでも読み上げできる

TCP Socket

TCP Socket

つかったもの

• Unity Pro 4.6（βのころから使ってた）

• ユニティちゃん（とそのアニメーション）

• MMD4Mecanim

• MeCab（NMeCab)

• LitJSON

みくみくまうすは「ユニティちゃんライセンス」で提供されています

ここまでは概要

この場は「プログラミング生放送勉強会」

実装の話を少しします

実装について話すこと一覧

•MMDモデルのインポート

•コメビュとの通信

•口パク

•コメントの感情解析

•設定ファイルの読み書き

•デスクトップマスコットモード

MMDのインポート

• MMD4Mecanimを使用すると簡単にインポートできる

– 付属のスクリプトがかなり充実している

– ただしモデルの動的ロードには対応していない

• 後述のライセンスの問題もある

MMDモデルのライセンス

• ゲームで使用して良いかは作者への確認が必要

– 作者によってライセンスがバラバラ

– Readmeに明記されていないことが多い




•口パク




コメビュとの通信

• コメビュ用プラグインを作って導入

– TCP接続で待ち受ける（コメビュ側がホスト）

– 複数クライアントの同時接続に対応

– コメント情報のデータフォーマットはJSON

• コメビュとの通信Componentも作成

– コメビュからコメントを取得する

– 実際の通信を行う機構はUnityと分離してある

Unityでニコ生のコメントを取得したいとき

• CommentViewer2Unity

– コメビュプラグインからコメントを取得するComponent

– 使用にはLitJSONが必要

– https://github.com/TORISOUP/CommentViewer2Unity

【余談】UnityでJsonを使う

• Unityでは標準ではJsonが扱えない

• Jsonライブラリを入れる必要がある

– MiniJSON

– JSONObject

– LitJSON ← 自分はこれを使ってる

そもそもJsonとは

• JavaScript向けに作られたデータ記述言語– 数値

– 文字列

– Boolean

– 配列

– 連想配列

– Null

※要するに各値をテキストデータに変換する時のフォーマットの一つ

LitJSONの使い方

•オブジェクトをJSON化する

LitJSONの使い方

•JSONからオブジェクトに変換する

ToObject<T>()を使えば良い

ただし

• 変換に失敗すると例外が飛ぶ

• floatは使えない（doubleを使うこと）

• 値の中身がnullだった時の扱い（null許容型を使う）

Jsonで値が送られてこなかった時の判別方法

•Null許容型構造体（値型）にnullが入ることを許容する

「Jsonの中身にNoの要素が無かった」

・非Null許容型int → ０で初期化（０が送られてきたのか判断不能）

・Null許容型int → Nullかどうかで値が送られてないと判断できる




•口パク




口パク

• MMD4MecanimSpeechHelperで簡単にできる

– MMDモデルはこのスクリプトで口パクできる

– ただしこのSpeechHelperはMMDモデルにのみ使える

– ユニティちゃんは別にスクリプトを自作して対応

• クエリちゃんは対応できんかった……

口パク機構の管理

• インターフェースを用いて呼び出し元の処理を統一

SpeechTextController読み上げるコメントの

管理を行う

MMD4MecanimSpeechHelperMMD向け口パクComponent

インターフェースISpeechController

UnitychanLipControllerユニティちゃん専用口パクComponent

口パク用のコメントひらがな変換

• 口パクさせる為にコメントのひらがな化を行う

– NMeCabを使ってひらがな化

– KakasiはGPLライセンスだったので避けた




•口パク




コメント感情解析

•コメントの内容に応じてリアクションが変化する

リアクションするキーワードの例

• 挨拶（「わこつ」、「初見」など）

• 挙手（ノ）

• 笑い（ｗを含むコメント、「吹いた」「ワロス」など）

• 絶叫（あああああ！など）

• ツッコミ（「おまえが言うな」「やめてー＞＜」など）

• 命令（～しろ！など）

• 疑問（語尾に「？」が付いているなど）

• 感動（「泣けてきた」「切ない」など）

• 賛美（「ありがとう」「才能の無駄遣い」など）

• 返答（「おこ？」「ですよねー」など）

• 興奮（「おおぉぉぉぉぉ！」など）

• 賞賛（「すごい！」など）

※ただしそこまで精度はよくない

コメント感情解析の仕組み

• ニコニコ動画コメント＠ばっちりサーチ.net

– こちらのnode.js用モジュールをC#に移植

• https://github.com/TORISOUP/CommentAnalyzerCSharp

– 中身は鬼のような正規表現

– 正直どのコメントが何に判定されるかわからない




•口パク




設定パネル

設定ファイル

• パラメータをJsonでテキストに保存（.NETの機能）

– PlayerPrefsはレジストリに保存されるので使いたくない

– バイナリにシリアライズして保存すると後から変更しにくい

– 読み込み時にバリデーションを入れる必要がある（平文保存のため）




•口パク




デスクトップマスコットモード

• こちらのAssetを使わせて頂きました

• オススメです

みくみくまうすのまとめ

• ニコ生配信支援ツール

• フリーソフトとして配布中

• 生放送を盛り上げるのに使ってね！！！

• プログラミング生放送でも使おう！！

• 使うときは「みくみくまうす」のタグを付けてくれるとエゴサしやすくて助かります

ステッカー

• 調子に乗ってステッカーも作りました

– 数に限りがあるので欲しい人は１人１枚お持ち下さい

– 割りと安い（１００枚刷って４０００円くらい）

くぎり

•みくみくまうすについての質問とかあれば

続いて「コーディングする上で意識すべきこと」→

コーディングする上で意識すべきこと

おしながき

•名前

•機能の分離

•SOLID原則

•MVCパターン

名前

わかりやすい名前をつけろ！！！！！

例）メソッド名

• メソッド名から処理内容が判断できるべき

– メソッド名が長くなるのは構わない（限度はあるが）

– 例）GetNearestEnemyFromPlayer

• 誤解される名前をつけるな

– Get*()なのに副作用がある

• 副作用＝状態を変化させてしまう動作

• Get()は何度実行しても結果が同じになるべき（べき等性）

– GetSize()なのに計算量がO(n)

• GetSize()はO(1)であるべき

• O(n)なら「Count()」にしたほうがまだわかる

おすすめの本

リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック

おしながき

•名前

•機能の分離

•SOLID原則

•MVCパターン

機能の分離

• Unityに依存しないコードを書こう

– なんでもかんでもMonoBehaviourを継承させない

– Unityからゲームロジックを分離する

– Unity以外でもそのまま使えると良い

– 単体テスト書きやすくなる

おしながき

•名前

•機能の分離

•SOLID原則

•MVCパターン

SOLID原則

• オブジェクト指向開発を行う上での５つの原則

– 単一責任の原則(SRP)

– オープン・クローズドの原則(OCP)

– リスコフの置換原則(LSP)

– 依存関係逆転の原則(DIP)

– インターフェース分離の原則(ISP)

• あくまで原則である

– 必ず守る必要はない

– 守ったほうが良い場合の方が多い

– Unity開発も例外ではなく守った方が良い

SOLID原則

• 単一責任の原則(SRP)

• オープン・クローズドの原則(OCP)

• リスコフの置換原則(LSP)

• 依存関係逆転の原則(DIP)

• インターフェース分離の原則(ISP)

単一責任の原則

「クラスを変更する理由は１つ以上存在してはならない」

「一つのクラスに複数の責務を持たせるな」

• 馬鹿でかいクラスは管理しにくい

• １つのクラスにあれこれ機能を詰め込むな

• クラス名以上の責務は負わせるな

悪い例

• PlayerController(プレイヤキャラクタの制御）– Inputの受け付け

– キャラクタの移動処理

– キャラクタの攻撃処理

– キャラクタの体力の管理

– アニメーション再生の管理

– エフェクト再生の管理

– 効果音再生の管理

– カメラの制御

処理多すぎィ！！！！！だが初心者はやりがち

適切に分離しよう

• PlayerInputManager

– Inputの受け付け

• PlayerController

– キャラクタの移動処理

– キャラクタの攻撃処理

– キャラクタの体力の管理

• PlayerView

– アニメーション再生の管理

• CameraController

– カメラの制御

• EffectManager

– エフェクト再生の管理

• SoundManager

– 効果音再生の管理

SOLID原則






オープン・クローズドの原則

「モジュールの振る舞いの拡張に対してオープンである」

「モジュールの振る舞いの修正に対してクローズドである」

• 機能追加は簡単にできる

• 機能追加によって他のコードを書き換える必要はない

• 要するに「ポリモーフィズム」となるようにしろ

オープン？クローズド？

• あとから簡単に機能追加できるようにしろ

– インターフェースを実装すれば機能追加できる（オープン）

– 実クラスが増えても元のコードに変更はなし（クローズド）


管理を行う








管理を行う









管理を行う




ユニティちゃんを簡単に追加できる（オープン）






管理を行う




呼び出し側に修正不要（クローズド）

SOLID原則






リスコフの置換原則

「派生クラスは基底クラスで定めたルールを破ってはいけない」

• 基底クラスで定義された部分は派生クラスと置換可能である

• 派生クラスは基底クラスと全く同じ仕事ができなくてはいけない

リスコフの置換原則に違反した例

例）移動メソッドMove(Vector3 direction)

基底クラス：引数に方向ベクトルを与える（長さ１のベクトル）

移動速度は内部の状態に基づいて決まる

派生クラス：引数に速度ベクトルを与える

移動速度は与えられたベクトルで従う

基底クラスと派生クラスで振る舞いが違う

SOLID原則






依存関係逆転の原則

「上位モジュールは下位モジュールに依存してはならない。

どちらのモジュールもインターフェースに依存すべきである」

• インターフェースを使え

• 実クラスへの参照を無くしてインターフェースに依存させろ

関係の逆転？

• 上位から下位に依存した関係（ダメな例）

– 上位モジュールが下位モジュールに依存

– 実クラスそのものを参照してしまっている

– 実クラスの変更の影響を上位モジュールが受けやすい

InputManager入力を管理する

PlayerReimuプレイヤ（霊夢）

PlayerMarisaプレイヤ（魔理沙）

関係を逆転させる

• 下位から上位に依存させる

– 上位のレイヤにインターフェースを作成

– 上位モジュールはインターフェースを参照する

– オープン・クローズドの原則も同時に満たされる




PlayerYoumuプレイヤ（妖夢）

インターフェースIPlayerInput

SOLID原則






インターフェース分離の原則

「クライアントにクライアントが本来依存しないメソッドへの依存性を強制して

はならない」

• 不必要なメソッドまでクライアントに提供しない

• インターフェースを適切に分割して提供しろ

インターフェース分離の原則に違反した例






Move（）Attack（）Jump()




• IPlayerInputインターフェースを各クラスが実装

– PlayerMarisaに「盗む Steal()」を増やしたい

• IPlayerInputインターフェースを各クラスが実装

– PlayerMarisaに「盗む Steal()」を増やしたい

– IPlayerInputに追加してしまった







Move（）Attack（）Jump()Steal()




• 関係の無い他のクラスまで影響を受けてしまう

– 使わないのに実装しないといけない











インターフェースを分離する






• IStealインターフェースを新しく作る

– 必要としているクラスだけがそのインターフェースを実装する

インターフェースISteal

SOLID原則のまとめ

• 機能は分割して作れ

• インターフェースを使え

• モジュールの依存関係を疎結合にしろ

UnityとSOLID原則

• Componentは機能単位で分割して作るべき

– クラス名以上の責務は負わせるべきではない

– コードの記述量は増えるが、わかりやすくなる

• Componentはインターフェースを介してやりとりするべき

– Componentが複雑に関係しあう時は特に意識すべき

– Componentの差し替えが楽になる

• SOLID原則をいちいち守ってると逆に非効率なこともある

– 小さい規模なら無視して作ったほうがぶっちゃけ早い

– 大規模開発になった時はSOLID原則は重要になる

おしながき

•名前

•機能の分離

•SOLID原則

•MVCパターン

MVCパターン

• Model View Controller

– GUIを持つアプリケーションで用いられるデザインパターン

– 機能を以下の３つに分離する

Controller（ユーザからの入力）

Model（実データやロジック）

View（描画処理）

UnityとMVC

• プレイヤの制御がMVCパターンと相性がいい

– プレイヤ制御を以下のMVCに分離してしまう




Input周りの処理• キーボード入力• マウス入力

メイン処理• 移動• ダメージ判定• 攻撃

出力系の処理• アニメーションの再生• エフェクトの再生• 効果音の再生

プレイヤ制御とMVC

• MVC分割のメリット

– Componentの責務が明確になる（単一責任の原則）

– 入力機器の差異をControllerの差し替えで対応できる

– ネットワーク同期も簡単になる

MVC分割でSOLID原則を満たすなら

• インターフェースを切ってそこに依存させる




インターフェースIPlayerController

インターフェースIPlayerStatus

Move()Attack()Jump()

OnGroundIsRunningIsDead

実例

• ユニティちゃんゴーストマンション– MVCが分離されているのでそれぞれ個別に開発できる

– ゲームジャムで役に立った

←Controller

←Model

←View

←ネットワーク同期用スクリプト

「意識するべきこと」まとめ

• わかりやすさ最優先でコードを書くべき

• Unityへの依存は断ち切ろう

• SOLID原則を意識した設計にしよう

• インターフェースを活用しよう

• MVCパターンは割りと使えるかもしれない

Unityで活用できるC#の機能

おしながき

•拡張メソッド

•LINQ

•UniRx（※ C#の機能では無い）

おしながき


•LINQ

•UniRx

拡張メソッド

• クラスに外からインスタンスメソッドを追加する

– staticメソッドを「あたかもそのクラスが持っているメソッド」を呼び出す

かの様に記述できるようになる機能

– 実際はただのstaticメソッドの呼び出し

static class ExtensionMethods

{

public static 返り値の型メソッド名(this 追加対象の型,引数１…）

{

処理…

}

｝

拡張メソッドを使うと便利な例

• Vector3のy成分を無視した水平面での方向を計算

– 進行方向にプレイヤを向かせるときに使うことが多い

• y成分を含ませると身体が傾く

進行方向

鉛直方向を無視した水平面での方向ベクトル

拡張メソッド）水平面での方向ベクトルを取得

• Vector3型への拡張メソッドとして定義する

– 拡張メソッドを収めるstatic classを定義

– その中にstaticメソッドを追加

– 第一引数のVector3にthisを付ける

拡張メソッド）実際に使ってみる

• Vector3に最初から生えているメソッドとして振る舞う

– Vector3を継承することなく、Vector3をカスタマイズできた

拡張メソッドまとめ

• 標準で足りない機能をガンガン追加していこう

– Vector3とかMomoBehaviourとかに追加すると便利になる

– 自分なりにカスタマイズしてしまおう

• 拡張メソッドの定義はわかりやすくしておく

– どこに定義したかわからなくなる事態は避ける

– 作った拡張メソッド群は資産として再利用可能

拡張メソッド

• 自分が追加した拡張メソッド群（一部）– Vector3

• ベクトルの要素ごとの積

• ２点間の距離の計算

• 水平面での距離の計算

• 水平面での方向ベクトルの計算

• x,y,zそれぞれの上書き

– Transform• Photon ViewIDの取得

• Photon IsMineの取得

• キャラクタの中心座標を補正して取得

• CharacterControllerから速度を取得

– Animator• 値オブジェクトからAnimatorのパラメータに反映

• Animatorパラメータ書き換えと同時に差分を保存（ネットワーク同期用）

おしながき


•LINQ

•UniRx

LINQ

• 統合言語クエリ（LINQ)

– 様々なデータソースに対する操作を統合的に記述するもの

– 特にLINQ to Objects（コレクション）がよく使われる

– せっかくのC#なのになぜLINQ使わないのか！？！？！？！？

LINQ to Objectで何ができるか？

• コレクションに対する操作を簡単に記述できる

– コレクション（配列、リスト、ディクショナリとか）

– 複雑な処理をわかりやすく記述できる

LINQメソッドの例処理の内容

Where 条件を満たす要素のみにフィルタリング

Select 要素を別の形式に変換

Any 条件を満たす要素が１つもであるか

All 全ての要素が条件を満たすか

First 最初に見つかった条件を満たす要素を返す

Count 条件を満たす要素の数を数える

例）LINQを使わずに書く

• TagがEnemy

• 指定座標から半径10m未満

• Transformのリスト

をGameObject配列から取得するメソッドをLINQを使わずに定義

例）LINQを使わずに書く

• TagがEnemy

• 指定座標から半径10m未満

• Transformのリスト

をGameObject配列から取得するメソッドをLINQを使わずに定義

本当に正しいかの確認が大変これを毎回読み解くのか？

例）LINQを使った場合

例）LINQを使った場合

1. gameObjectArrayに対して2. TagがEnemyのものだけ3. 指定座標から10m未満のものだけ4. Transformに変換して5. List形式にまとめて返す

• 順番に上から読むだけで処理の内容が理解できる

– 単純に「やりたい事だけ」を記述すれば良い

– ループやif文が無く、バグが入り込む余地がない

LINQまとめ

• C#を使ってるなら是非使うべき機能

– ちゃんと使えばコード中からfor文を無くせる

– LINQを使わずして何がC#か

• 普通にループを書くより処理速度は落ちる

– LINQによって実行速度が問題になるようなことはほぼ無い

– コードの読みやすさ＞＞＞＞＞速度

– 下手に凝ったループを書いてバグを生むのとどっちが良いか？

• iOSでのLINQは不具合がある

– 詳しくはショートセッションで

おしながき


•LINQ

•UniRx

Rx（UniRx)

• ReactiveExtensions(Rx)

– LINQの概念を「非同期」「イベント」に拡張したもの

– 時間を跨いだ処理を簡単に記述できる

– UniRxはRxのUnity移植版（neueccさん作）

• ちゃんと解説すると１時間はかかる

– 今回は説明を放棄

UnityでRxを使う

Rxの概念

• イベントをストリームとして扱う

– イベントって時間軸に並んだコレクションじゃね？

– コレクションならLINQで扱えるんじゃね？

ｔ

Rxの使い道

• イベントの代わりに使う（ストリームを作る）

– Subject<T>を使えばストリームが作れる

– 既存のEventの上位互換（むしろEventはレガシー）

• ストリームの終了、エラーを通知できる

• イベントの複雑な処理

– 特定のイベントのみ処理する

– 前のイベントの値と組み合わせる

UniRxの例

• マウスのダブルクリックの検知

– 普通に書くと煩雑な処理がたった数行で終わった

– 状態の一時保管用のフィールドの定義不要

Rxのまとめ

• 時間やフレームを跨いだ処理を簡単に記述できる

• 使いこなすとUpdate()の中身が短くなる

• 学習コストは高め

とにかく便利なので使ってみるべし

「C#の機能」まとめ

• C#には便利な機能がたくさんある

– C#っぽくない書き方のコード多くて悲しい

– 使いこなすと強力な武器になるので使うべし

• Rx楽しい

– 本当に便利なのでもっと流行るべき

最後にまとめ

• みくみくまうす使ってね

– みんな生放送やろうぜ

– せっかく作ったんだから使って欲しい

• Unityの開発力は最終的にコーディング能力に行き着く

– 複雑なことやるには結局スクリプトを書かないといけない

– プログラミングスキルは高めるべき

• 動き続けるプログラムが正義

– 「動けばいいや」ではダメ

– Unityは特に適当に書いても動くので注意が必要

– 保守性やメンテナンス性も考えた開発をやろう

ありがとうございました

みくみくまうすについて&Unity で使えるコーディングノウハウ

Technology

Transcript of みくみくまうすについて&Unity で使えるコーディングノウハウ