Raspberlyのブログ

Raspberlyのブログ

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

トップ > 勉強会/イベントレポ > 勉強会レポ : Roppongi.unity #1

勉強会レポ : Roppongi.unity #1

勉強会/イベントレポ 勉強会/イベント-Roppongi.unity

勉強会のレポート(メモ)です。
参加したのはこちら、「Roppongi.unity #1」
会場提供、懇親会支援は「メルカリ」さんです。

connpass.comハッシュタグ : roppongiunity

 

動画はこちら

www.youtube.com

 

 

 

メリカリさんには一昨日も「VRM勉強会」の会場提供をしていただきました。

raspberly.hateblo.jp

 

 

 

 

 

f:id:Raspberly:20190222005419j:plain

 

 

 

時間(予定) タイトル 発表者
19:30-19:40 会場説明など @nkjzm
19:40-19:50 Humble Objectパターンな話 @adarapata
19:50-20:00 Unityエディタ拡張でノードベースのシンセサイザーを作った話 @rn49rn49
20:00-20:10 GUID参照を素早く洗いたくて試行錯誤した話 @v9129
20:10-20:20 データサイエンティストから見たUnityの可能性 @Keijipoon
20:20-20:30 Zenjectのススメ @notargs
20:30-20:40 Unityでオニオンアーキテクチャ @toRisouP
20:40-20:50 キャラが8人同時にしゃべるんだけど...とPに言われたときの戦い方 @Takaaki_Ichijo
20:50-21:00 みんなに使ってもらうUnityライブラリの作り方 @taptappun

 

 

 

 

 

 

LT1. Humble Objectパターンな話

スライド

www.slideshare.net

ごたゆに10で話せなかった、スライドの後半にフォーカスした内容になっています。
HumbleObjectPaternについて

テストが書きたくて手が震えている

テストのしにくさには原因があります

密結合な話や入力イベントが絡んだ時などはしにくい。
リファクタリングしてもテストしにくいことがある。

ただテストを書けない理由は明らかにすべき。

 

ピラミッドの境界をまたぐような書き方はしんどい。
なので分割したような書き方をする必要があります。
ではどうやるのか、それがHumble Object パターンになります。

 

つまりHumble Object Paternはテストしやすいものとしにくいものをすみ分ける実装パターン。


入力がからむ　MonoBehaviourがからむとめんどくさい。
テストが書きにくい原因はだいたいMonoBehaviour。なのでロジックから抽出します。

 

 

 

 

 

 

接続の関係でLTの順番入れ替えました

LT3. GUID参照を素早く洗いたくて試行錯誤した話

話す内容

プロジェクトにある大量のアセットを消したい。
消せないものはどこで参照されているかを知りたい。簡単にいうとゴミデータを削除したい。

Reference Viewer

もともとReferenceViewerを使っていました。

これは初回実行時に参照データ生成を行います。
小さいプロジェクトならまだしも、大きいプロジェクトだとまあまあ時間かかる。
ブランチ切り替えでもおきちゃう。

なので早くしたい、プログレスバーを表示してメインを止めないようにした。
結果的に早くなったがもっと早くしたい。

 

最終的にチェックツールを作成しました。
UnityAPIを使用した普通の実装、15秒くらいでおわるくらいまで早くなりました。

GUIDについて

metaの中にはGUIDが入っていて読むことができます。
Scene、Prefabも中で使われているGUIDも読めばわかります。
一部gitgrep に置き換えました。結果1~2秒まで早くなりました

まとめ

git grepは最高、windowはがんばれ

GitHub - anchan828/ReferenceViewer: Unity5対応する予定

 

 

 

 

 

 

LT2. Unityエディタ拡張でノードベースのシンセサイザーを作った話

スライド

www.slideshare.net

ノードをつないで音をつくるおもちゃを作りました。
音の周波数を変えたり、それらを加算したりできます。

どういう風に実装したか

xNodeというフレームワークを使うと、ノードベースのエディタが簡単に作れるんです。
作ったものはgithubで公開しています。

xNode - Asset Store

GitHub - Siccity/xNode: Lets you view and edit node graphs inside Unity

 

 

 

 

 


LT4. データサイエンティストから見たUnityの可能性

なぜデータサイエンティストがunityをやっているのか

最初やっていたこと

フライトシュミレーターの整備をやっていました。
当時、上司からARデバイスについて調べて何か作れという指示がありました。
この時、いろいろ調べましたが、いろいろなデバイスでいろいろなものが作れるんだと気づきました。

今はデータサイエンティストとして働いています。

可視化の部分を専門にやっています。
ビッグデータを地図上に可視化し、VRでも見ることができます。

Unityでは

VRのガンシューティングゲームを作っていました。
Unityは物理挙動もかってにやってくれて、Assetも充実していたのですごくびっくりしました。

Unityという武器を手に入れました、

次は何をしたいか

Unityでビッグデータの可視化をしたい。GoogleMapのAPIでいろいろできそう。
ただ、今は申請制のようで作るハードルがやや高い。

今までは地図上にデータをマッピングしたりしていましたが、
これからは3Dの街並みにデータをマッピングしたり、ビックデータとのインタラクション。
ビッグデータの理解というものも広がるんじゃないかなと思います。
Unity ML-Agentで企業の取引最適化も。(今と最適化の違いを見て、分析ができる)

まとめ

Unityのおかげで開発のハードルはだいぶ下がり、個人でも作れるようになった。
異分野（ゲーム以外でも）でUnityを使えるようになった
いままでビッグデータとかやってる人がいなかったので自分がやっていきたいなと思います。

 

 

 

 


LT5. Zenjectのススメ

スライド

notargs.hateblo.jp

Zenjectはいいぞ

Zenjectとは

オブジェクト同士の依存関係を簡単に定義できるアセットです。
依存関係はZenjectを使いましょう。
FindやGetConponentだったところを変数にように定義し、シーン内でバインディングするだけ。
もっと疎結合にしたい時はインターフェースを挟もう。

シングルトンのマネージャークラス

シングルトンの記述はなんかダサいし、使うときがっつりインスタンスしている。
ここもZenjectに治せます。
普通のクラスのように作るだけ、シングルトンの情報も持たせない。

Zenjectはいいぞ

 

 

 

 


LT6. Unityでオニオンアーキテクチャ

スライド

https://niconare.nicovideo.jp/watch/kn4031

 

オニオンアーキテクチャとは何か

設計指針としてはドメイン駆動設計(DDD)が根幹

ドメイン駆動設計とは何か

今から作るアプリが本質的にやりたいことをドメインといいます。
このドメインを中心に考えるやり方がドメイン駆動設計です。
実装する時に仕方なくそうなったところをわける。

例えばセーブデータの保存だと、データの保存と復元がドメイン。
他の部分はどうでもいい。

 

4層で構成されるアーキテクチャ

・Domain層
　本質的にやりたい処理、ロジック、データ構造

・Infrastructure層
　実装を置くところ、機能追加や修正などはここで変更する。

・Application層
　処理の手続きを書くところ

・Presentation層
　UnityとApplication層そうをつなげるところ

DIがないとまわらないのでZenjectは必須。

クリーンアーキテクチャとは本質的にはまったく同じ。
とっつきやすいほうからやりましょう。

実装の手順

下準備

層ごとにディレクトリをわける。
AssemblyDefiniionを使うと便利なのでオススメ。

Domain

名前が大事、名前には意味をもたせましょう。
構造体とクラスどっち使うかはよく考えて。
インターフェースだけ定義(こういう操作ができますよというもの)

Infra

実装を書く。

Application

手続きを書く、まあ薄くなる。

Presentation

UnityでUIとかとつなぐ。


Zenjectのインストーラーに書く・
自動でインスタンス化してくれるようにします。

仕様変更がきてもいじるところは少ない。

デフォルト値は定義

この言葉の意味はよく議論すること。

まとめ

メリット

・機能変更修正にめちゃくちゃ強い。
・アウトゲーム部分と相性がいい。
・レイヤーがわかれているので明確。
・テストとも相性がいい。

デメリット

・インゲームには適応しにくい。
・処理に対しコード記述量が増える。
・Domainの設計が難しい。
・インタフェースなど知らないとだめ。
・Zenjectがむずかしい。

 

 

 

 

 


LT7. キャラが8人同時にしゃべるんだけど...とPに言われたときの戦い方

スライド

www.slideshare.net

８人同時にしゃべるといわれた、これは何がやばいのか。

サウンドの再生部分についての問題

・CPU、メモリの問題
・再生時の管理
・ボイスデータの管理

ボイス再生時には制御が必要、同時再生数を制限したりとか。
じゃあこれはどこで判定するのか・・・

ボイスデータの管理の問題

エクセル管理の場合、管理用と実際のデータで差異が生まれてしまう。

ここでADX2

ADX2ではAudioClipを再生とはやらない。
キューというものを作って情報を埋め込み、キューを再生して動かす。

 

 

ここでデモ

キューの中でダッキング処理ができる

 

まとめ

・大量の音データの管理が得意
・同時再生時の負荷軽減もできる
・冒頭の無茶ぶりにも対応できます

書籍もでます、よろしくお願いします。

 

 

 

 

 

 

LT8. みんなに使ってもらうUnityライブラリの作り方

スライド

docs.google.com

いままでいろいろ作ってきたのでそのノウハウを共有します。

大前提

使う人のことを考えよう

 

 

その1 Exampleをまず作る

ドキュメントやテストよりも大事。
ゲーム買ったら説明書とか読まないよね、それと同じでライブラリを落とした人はドキュメント読まない。
とりあえずExmapleを動かしてみてみる人が多い。
なので即動かすことができるように整えておきましょう。

一応テストやドキュメントも大事、書いてあると動くという証明になります。

その2 UnityPackage化しよう

つまりエクスポート。
ダウンロードしてすぐ使うので簡単にしたほうがいい。
インストールに手間取ることもない。


その3. Namespaceを作ろう

開発中はいろいろなライブラリが入る、なので明示的にわかるようにするために必要。
処理の衝突をさけるためでもある。


その4. ディレクトリは1つにまとめる

いらなくなったらすぐに消せるようにする
バージョンアップさせる時の依存関係がわかりやすくなり、バージョンアップするとき楽。


その5. ラッパーを作るのはやめよう

ラッパー（Wrapper）って何？《サンプルケース付き》 - Qiita

使ってるライブラリが他にあると、本家が更新されたらライブラリも更新しなければならない。
メンテナンスも大変、そのまま使うようにした方がいい。


まとめ

上の5点は守ろう。
ライブラリ作るときは参考にしてみて

 

 

 

 

 

 

 

タイムライン

 

 

 

 

 

 

 

 

懇親会、展示の様子

 

 

 

VRM勉強会の時はドミノピザでしたが、今回はピザハット。

f:id:Raspberly:20190222005449j:plain

f:id:Raspberly:20190222005452j:plain

f:id:Raspberly:20190222005759j:plain

 

 

 VRM勉強会の時にも展示していたおもちゃラボさんの展示レポートです。

toylabo.tech

 

 

 

 

LT7の@Takaaki_Ichijoさんは昨日の「ゲーム開発におけるサウンド実装の勘所」についても講演いただきました。

raspberly.hateblo.jp

 

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