Raspberlyのブログ

Raspberlyのブログ

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

勉強会レポ : いまさら聞けないネットワーク基礎!

 

勉強会のレポート(メモ)です。
参加したのはこちら、「いまさら聞けないネットワーク基礎!」。
会場はサポーターズです。

supporterzcolab.comハッシュタグ : #spzcolab

 

 

 https://img.supporterzcolab.com/thumbs/31/ec/31ece49c622f9d2856687f646cc08f8c.png

 

 

 

 

 

講師紹介

のなめしゃちょー @noname0326

いっとねっとで情報発信などをしています。

it-networking.jp

 

 

 

初めに

今はネットワークエンジニアでなくてもネットワークを知っていると得です。
ネットワークの概念だったり表面的なところを話すので抑えてください。
わからないところやメモした内容は後で調べるといいでしょう

 

 

 

ネットワークとは

バイスとサーバーをつなぐ道をネットワークと例えることができます。

通信は次のような流れで行われます。

・ 送る側がデータを作ります。(この時、マトリョーシカのようにデータをくっつけていく)
・データを電気信号として送ります。
・ 受信側は受け取った電気信号をデータに戻し、マトリョーシカを開けるようにして取り出します。

 

データをマトリョーシカのようにくっつけていきましたが、これはTCP/IPのルールに従って行われます。
TCP/IP通信プロトコル(通信を行う際のルール)です。

(なぜTCP/IP層という名前がついているのかというと、もっとも使われるのがTCP/IPなため)

OSI参照もある、実際の通信ではTCP/IP階層モデルが使われますが。
話し言葉としてOSI参照モデルが使われます。
今回はこのうちデータリンク層ネットワーク層の話をします。

 


IPアドレスとルーティング

IPアドレスはインターネット上の住所のようなものです。2種類存在します。

IPv4
32bitで構成される。
一般的にIPというとこっちを指す。

IPv6
128bitで構成される。
IPv4の枯渇のため新しく定義された。
docomoなどのバックボーンで使われ始めたりしています。

 

 

IPv4はネットワーク部とホスト部で分かれます。

ホスト部が0であるアドレスをネットワークアドレスと呼びます。

 

現実で例えると、
ネットワークアドレスがマンション名。ホスト部が部屋番号を表しています。
ホスト部は8bitと1~254まであるので254台デバイスを接続できます。

 

 

 

ルーティング

住所を調べて、最適な道を示す仕組み。
これはルーティングテーブルに従って行われています。
ルーティングテーブルは地図のようなものです。

この地図にのっていないものは、「おおよそこっちにあるよ」とおおまかな道を示します。
この機能をデフォルトゲートウェイといいます

 

 

 

 

ARPMACアドレス

ここからデータリンク層の話。

MACアドレスはベンダーコードとノード番号で構成される原則的に1意のアドレス。
同じネットワーク内の通信に使用されます。

ベンダーコードを検索すると、その機器のメーカーを調べることができます。
試しに以下のサイトで「78:4f:43」で検索するとメーカーがAppleだとわかります。

uic.jp

これはトラブルシューティングなどで使われます。
実際に同ネットワーク内ではIPアドレスMACアドレスで指定します。

 

 

 

じゃあMACアドレスはどう調べるのか

ARPを使って調べます。ARPIPアドレスからMACアドレスを割り出します。
調べる時は、全員に「教えてください」と送ります。


MACアドレスは同じネットワークでしか使えないが、ネットワークをまたぐ時はどうするのか。
ネットワークが違う時は、MACアドレスの宛先はルータになります。
するとルータは、一旦MACアドレスまで開けて、新しくMACアドレスをつけなおし転送します。

 

 

まとめ

今日話したのはネットワーク、データリンク層に注目してお話しました。

・通信はTCP/IP階層モデルに従います。
IPアドレスはネットワーク上の住所。
・ルーティングは目的地までの最適な道を示す仕組み。
MACアドレスはベンダーコードとノード番号で構成される一意のアドレス。(同じネットワーク内で行われる)

 

 

 

 

ネットワークの知識はどのポジションでも活用できます。
詳しくなっておくとネットワークエンジニアでなくても活かせると思います。
ぜひネットワークを勉強して 上位エンジニアになろう。


ねこのイラスト めちゃくちゃかわいいのでオススメです。

twitter.com

 

質問

Q1. ルーティングテーブルで、地図に載っていない宛先の場合はどうしておおまかな道がわかるのか。

地図自体は持っています。ただしルータは地図として持っているだけで間違った地図を持っていると届かなくなることもある。
MACアドレスとして前後の位置だけ持っていればよい。

 

Q2. IPアドレスは変更したらどうするのか?

ルーティングはマンション単位で地図を持っています。同じネットワーク上なら問題ない。
ただし新しくマンションを用意したら全部通知しなければならない。
これはGARPを使って検知しています。

 

 

もっと深く知りたい場合は「三分間ネットワーキング」で調べてみましょう。

www5e.biglobe.ne.jp

がっつり勉強したいときはマスタリングTCP/IPを読むことをオススメします。

www.amazon.co.jp

 

 

 

過去の公演

raspberly.hateblo.jp

 

 

勉強会レポ : Indie Games Festival 2019 キックオフ イベント [Unity セミナー]

 

勉強会のレポート(メモ)です。
参加したのはこちら、「Indie Games Festival 2019 キックオフ イベント」、
の午前に開催されたUnityセミナー「ゲーム制作に集中するための便利サービス & 時間節約術」です。

events.withgoogle.comハッシュタグ : #indiegamesfestival

 

 

 

ゲーム制作に集中するための便利サービス & 時間節約術

f:id:Raspberly:20190303155801j:plain

スライドは後日公開されます。
公開されました。

t.co



対象者

・個人開発者
・自作するのがめんどうな方
・ゲーム以外に時間をかけたくない方


話すこと

開発時困ることやビルド時間の節約方法。

まれによくある困ることについて

 

 

 

 

 

Unity Collaborate

ありがちな問題点

・ファイルの同期、バージョン管理ができない。
・名前に日付を含めて保存する。
USBメモリクラウドで受け渡し。
こういう問題に対しみんなはgitを使っているらしい。
しかしgitは学習コストが高い・・・


そこで簡単なバージョン管理方法にcollaborateがあります。

できること

・チームメンバとプロジェクトを共有(エディタの中で完結します)
・ただしこれはgitのように分散管理ではなく一元管理になります。
・さらにリアルタイムで別の人が編集しているファイルを知ることができる。

ただし無料でできる範囲は限られている注意。

できないこと

分散管理ではない、ブランチもきれない。

使いどころ

・プロトタイプ作成
・短期開発
・特に学習コストはない

もっと機能が欲しい時はgitを覚えた方がいい。
こちらのテラシュールブログを読んでおくといいでしょう。

tsubakit1.hateblo.jp

 

 

 

 

Unity Cloud Build

効率よくビルドしたい。しかし実機ビルドは長くなる。
プロジェクトサイズが大きくなると当然長くなる。
しかもビルド中は操作できないため開発が止まる。

これをなんとかして節約したい

 


ビルド専用マシンを用意するという対策もある。
しかしコストがかかるし手間。


いい感じにビルドしたい・・・そういう時にCloud Build
クラウド上でプラットフォームごとのビルドができる機能です。

できること

・開発用のPCを使わずビルドできる
・複数のビルドが同時にできる
・自動ビルド、さらのビルド完了のメールも送ってきてくれる。

しかしそもそも有料、同時ビルド数増やすのもお金がかかる

できないこと

・バージョン管理されてないソースコードからビルドはできない
・そのままストアにアップロードはできない


使いどころ

・環境を用意できない、めんどくさい方
・ゲーム制作に集中したい方に

もっと先のことがしたい

JenkinsなどCI(継続的インテグレーション)について勉強しましょう。
つよつよビルドマシンを買う。
Cloud Buildエンタープライズを使ってみる。

 

 

 

 

 

 

 

Remote Settings

リリース後のお話。

ゲーム内の設定や値を変えたい。
しかしいちいち書き直して再ビルドは時間と手間がかかる。


ではどうするか。
外部のサーバーを用意して、値を取得するようにする。
そういう手段もあるが、これもいろいろ考えることがふえる。つまりめんどくさい。

手軽にやる方法としてRemoteSettingsがあります。
ゲーム内の設定をダッシュボードからリアルタイムに書き換えることができる。
KeyValue形式で値で操作する。

具体的な利用例

・ライフやHPなどで難易度調整
・セリフの差し替え(季節ごとに変えるなど)
・ランダム性のあるくじびきの確率変更(ほんとはやらないほうがいい

できること

・ゲーム内の値をリアルタイムで更新できる
・アプリ更新しなくてもよい
・地域、国ごとに設定できる(IAPを使っている場合は課金勢、無課金勢で値をわけることがきでる)

できないこと

・値の変更はスケジュール管理ができない(自動で値の管理はできない)
・画像を登録することはできない
・ユーザデータの保存はできない

使いどころ

・プレイヤーの反応を見ながら値を調整したい時
・簡単なお知らせメッセージを表示、頑張ればJSONをいれることもできる
・ゲーム内のフラグをダッシュボードから操作する
効果的な利用案募集中です。

もっと先のことがしたい

・結果を分析すること
  値を変更したことによってユーザの動きはどうかわるのか
  ゲーム内のKPIはどう推移したか
・次に生かすためにちゃんと記録しましょう
・ちなみに無料で使えます

 

 

 

 

Unity Diagnostics

エラーやクラッシュのレポートを取得したい

アプリ公開後のユーザからの不具合報告で、
「エラーが出る」「アプリが落ちる」などいろいろレビューがきても、ログをもらえることは少ない。
再現の条件がわかりづらくもっと情報がほしい時にどうするか、自動化できないか。

 

そこで登場するのがDiagnostics(ダイアグノースティックス)です。
クラッシュレポートや例外、任意のフィードバックをもらうことができる機能。
まだpreview版だが使うことはできます。

Crashes and Exceptions

クラッシュと例外のレポートをクラウド上から取得。メタデータを含めることもできる。
シンボルファイルもダッシュボードで設定できる。

User Reporting

ユーザが任意でレポートを送信できる機能、スクショも含めることができる。
レポートはダッシュボードから見ることができる。


できること

・レポートの収集ができる
・ユーザレポートの収集もできる
・起きた瞬間に自動でレポートが送信される(ネットにつながった瞬間)

ただしライセンスによって上限が設定されているので、そこはお財布と相談。

できないこと

・レポートが送られていても返信できない、完全一方通行。
・質問がきても回答できない。

使いどころ

・とりあえずONにしておけばデータが集まる
・不具合報告の機能を簡単にいれることができる

公式のドキュメントにはない(preview版なので)、詳細はgithubに書かれています。
含まれているサンプルをいじっていくといいでしょう。

 

 

 

本日のまとめ

 

 

 

タイムライン

 

 

参考資料

近い内容を取り扱った講演

learning.unity3d.jp

 

 

 

 

 

 

Collaborateは昔コロプラさんの1dayインターン内のゲームジャムで使った記憶。
当時はGitなんてコミットプッシュプルくらいしか知りませんでしたがとても簡単に扱えました。
Gitが使えるのならGitでいいかと思いますが、他の人が編集中のファイルを知ることができるのは便利。
いちいち「これからこのファイルいじります」宣言などしなくていいのも楽ですね。

 

RemoteSettingは大変便利そうですね。
画像を含めることはできないので、画像は最初から入れてフラグ変数の書き換えで表示を切り替えるみたいな処理が必要みたい。
同じ感じで任意のタイミングでステージ解放とかも。

 

【Humble Bundle】ファンタジーゲームアセットを格安で入手しよう

  

今回はゲーム用のアセットを入手できるお得情報の紹介です!
たびたびお世話になるHumbleBundleさんからゲーム素材の登場。
717ドル相当のゲーム用素材が合計20ドルで手に入っちゃいます!
Unity使いの人には特にオススメですよ!

f:id:Raspberly:20190226234051p:plain




ページはこちら 残り7日ほどです。

www.humblebundle.com

 

 

 

 

過去のHumble Bundle情報

www.asset-sale.net

www.asset-sale.net

raspberly.hateblo.jp

 

 

 

パブリッシャー様

パブリッシャーは「REXARD」、アイコンやスキンなど、UI素材を販売しているアーティストチームです。
今まで多くのアセットを輩出しております。

assetstore.unity.com



AssetStore平成最後のセール時に、Unity AssetStoreまとめさんの読者投票で上位に食い込む人気っぷり。

www.asset-sale.net

f:id:Raspberly:20190226232339p:plain

この「TCG Card Design」もBundle内に含まれています。

 

 

Bundle一覧

1ドル

f:id:Raspberly:20190222155055p:plain

 

 

平均以上(17ドル)

f:id:Raspberly:20190222155219p:plain

 

 

20ドル

f:id:Raspberly:20190222155306p:plain

今回はアイコン素材が多めです。
20ドルがオススメですが、コスパ的には1ドルが良い!

 

ちなみにAssetStoreと表示されるものと、Marketplaceと表示されるもので分かれています。

f:id:Raspberly:20190222152053p:plain

f:id:Raspberly:20190222151913p:plain

 

実際に購入してみましたが、バウチャーコードを取得するタイプではなく、直接ダウンロードするタイプなのでUnityでもUEでも問題ないようです。

f:id:Raspberly:20190226225704p:plain



 

 

購入方法

Unity AssetStoreまとめさんの過去の記事で詳しく解説されているので参照してください。
初めての場合、ここで躓いたりするかも・・・

www.asset-sale.net

購入する時にお金の振り分けを購入者が指定することができます。
パブリッシャーさんに還元するにはREXARDの値を大きくするといいでしょう。

f:id:Raspberly:20190226225724p:plain

 

 

 

 

おまけ

残り時間僅か!
UnityAssetStoreJapanさんTwitterアカウントでAssetStoreのバウチャーコードが抽選で当たるキャンペーン中!
フォロワー7000人記念とのことです。ハッシュタグをつけてリツイートしておきましょう!

 

 

 

他、わからないところがあればコメントでお願いします。

勉強会レポ : Unity道場 2月 ~シェーダを書けるプログラマになろう~

勉強会のレポート(メモ)です。
参加したのはこちら、「Unity道場 2月 ~シェーダを書けるプログラマになろう~」

meetup.unity3d.jpハッシュタグ : #Unity道場

 

f:id:Raspberly:20190225233016j:plain

 

 

f:id:Raspberly:20190226000204p:plain

 

 

放送アーカイブはこちらから
このブログ記事だけでなく、動画も視聴することをオススメします。

www.twitch.tv

 

今回のUnity道場の解説記事。

qiita.com

qiita.com

 

 

 

 

 

 

シェーダを書けるプログラマになろう
三部構成にしました。大事なのはpart1、寝ないで聞きましょう。

 

そもそも理解とは

これは境界の把握だとぼくは思っています。
理解するコツは、それができないことはなにかを知ることです。
人に質問すると、「あれができる」「これができるだけ」だけ返ってくる。
それだと境界がぼやっとしてくる、なのでできないことを知らないとだめです。

特徴を抑える話をします


part1 シェーダを理解しよう

今回は8つのステップに分けて説明します。

f:id:Raspberly:20190226000531p:plain



〇〇シェーダはたくさんありますが、今回は頂点シェーダとフラグメントシェーダについて。
シェーダというのはこの2つから始まっていて、シェーダの中心となるため。

描画とは

 モニタ上の画素に点を打つこと。これを8ステップで行います。

 

ステップ1

3Dモデルの準備、これは絶対必要。
3Dモデルとは、どの頂点を結んで面にするのかという三角形の情報。
これを準備します

ステップ2

transformの値を4x4行列に変換します、この行列モデル行列といいます。
結構複雑ですが、一番下は[0001]固定です。

ステップ3

描画位置を決定する。
どの辺に頂点がいくか計算する。

ステップ4

3頂点の処理をしたら右回りか左回りか確定する。
そしてどっちが裏か表か決める。裏なら描画しない。
逆にいうと裏側でもステップ4までくるということです。

ステップ5

描画の点を確定する。
3頂点をつないだ三角形の内側の画素を調べるて確定する。

ステップ6

描画すると決まった時、デプスバッファと比較して既に書いた点より後ろにあるかを調べる。
後ろにあるなら描画しない。

ステップ7

打つべき色を確定する。
テクスチャや影、他からの影やフォグなどを考慮する。

ステップ8

点を打つ。ブレンド関数が使える。
ここでデプスバッファを更新する。

 

このうち、上の2つのステップをCPU、他をGPUが担当しています。
ステップ3が頂点シェーダ、ステップ7がフラグメントシェーダの仕事になります。

 

 

一発では覚えられないのでぜひ復習してください。


シェーダでできない例

2点間で線を引きたい

これはステップ1の話になるのでできない。シェーダーではできない。

半透明描画をしたい

これはステップ8で対応するもの。
そもそも半透明とは、すでに書いてある点と書こうとしている点を足して割らないとできないこと。
シェーダーで何かする話ではない。
blend関数で設定可能だが、これは設定を書いているだけで厳密にはシェーダーではない。

余談

半透明とデプスバッファの問題

不透明を半透明の後に描画するのは難しい。
透明度のデプスバッファが更新されるため、奥に書かれ半透明にならない。
かといって更新しないと、半透明の部分より手前に来てしまう。
現在は半透明は不透明のあとに描画するようにどのゲームエンジンもやっています。


シェーダを観察していこう

頂点シェーダは大体vert、フラグメントシェーダはfragになります。
Unityと普通のシェーダーと何が違うのかというと、どのゲームエンジンでも共通の部分があります。
Unityでは、コードの上の方にいろいろ書けて楽になっている。

重要ポイント

セマンティクス

POSITIONなどのマーキングはセマンティクスとよばれるものです。
これはGPUにこの変数はポジションである情報を伝える。
これがないとGPUは動きようがなくなる、

補完

二つの線分の途中の値を計算し選出すること。これはGPUがすごい頑張る。
頂点シェーダは3つしか出力されていないので、その補完を行います。


サーフェスシェーダーとは

頂点シェーダとフラグメントシェーダがないと絵がでない。
頂点シェーダは大体同じようなことを書くため省略したくなる。
フラグメントシェーダは複雑なわりにいつも同じような書き方になる。
そのため、楽な記述で生成してくれるのがサーフェイスシェーダです。
これはUnity専用の機能。

ただしサーフェスをいきなり見るとなにがなんだがわからなくなる。
頂点シェーダとフラグメントシェーダを生成しているものと覚えておきましょう。

設定を変えれるのとプログラマブルは違うということを理解しましょう

 

 

 

 

 


part2 GPUの神秘

tex2Dという関数があります。
これはけっこうおもしろい関数でここにシェーダーの神秘があります。

テクスチャ・画像は縮小に課題がある

拡大はただボケるだけだが縮小は難しい。
縮小するアルゴリズムはいろいろあるが、時間をかけるときれいに縮小できる。

シェーダーでそれをやるのは厳しい。
tex2Dはテクセルを拾ってくることしかできないので、どうしてもだめな縮小になってしまう。

 

無限平面を作る話

地面が書きたい時。どういう風に書いていくか。
必ずカメラに入るように拡大して行う。

テクスチャ座標は大きさにかかわらず01で表現される。
では01をオーバーしたら何が返ってくるのか。
実は折り返された値が返ってくる、つまり繰り返される。


この辺はテクスチャのインポート設定で自動的にrepeatするようになっている。
なのでuv座標にワールド座標など大きな値を入れると繰り返される。

ここで疑問、遠くのものがきれいに縮小されている理由

これはmipmapのおかげです。これは勝手に生成されます。(インポート時の設定)
高品質な縮小画面をあらかじめ作っておきます(ランタイムではなくインポート時に作られる)

 

ここでまた疑問
フラグメントシェーダはtex2Dを呼んでいるだけ、じゃあどうやって最適なmipmapを選択しているのか。
これはちょっと頭に浮かべておいてください。


それはさておき、テクスチャの繰り返しが気になる

整然とテクスチャが繰り返されているのはありえない、不自然すぎてつらい。

なので工夫してみよう
単位範囲ごとにuv座標をずらしてしまう、これを乱数のような概念(ハッシュ)でずらしていく。

地面にはるテクスチャは繰り返される用に作られているが、バラバラにしても意外と大丈夫だった。
これはテクスチャによる。

ただし、これをやるとちらつきが発生する。
なぜちらつくのか、それは間違ったmipmapを引いてきてしまうため。


衝撃の事実

フラグメントは4ピクセル同時に実行している。
必ず4x4で実行するため、シェーダーの同時実行は一歩ずつ完全に同期して行われる。
tex2Dは隣の値も取得している

どうやってmipmapを取得しているのか。
これは4つのuvを取得しているので、適切なmipmapがとれる。

 

なのでさっきの問題を解決するにはddx、ddyをとりtex2Dgradを使う。
ddxは横の隣の差(uvの変化値)を取得する。
ddyは縦との差を取得する。


fwidth

絶対値をとって足す関数がシェーダには用意されている。
縁取りなどけっこうおもしろいことができる。

 

類似の話がunity blogでまとめられています。

blogs.unity3d.com

 

GPUを扱うときの心構え

・完全に同期されていることを知る

・if文はなるべく書かない方がよい
 隣がelseの方にいっていたりすると、true/false両方実行されたりする。

 

 

 

 

 

 

 

 


part3数学講座 行列編

上でもリンクを張りましたがここは動画を見てください。

www.twitch.tv

 

前方ベクトルについて話します。シェーダーで使う行列は全体のほんの一部。


行列には逆行列がある、逆行列は大変ということを感覚的に覚えてください。

モデル行列は回転行列、移動行列で成り立つ。
ではどっちが先なのか、実はrotationが先。
回転してから移動する、なので移動結果が回転によらない。

 

 

ホワイトボードを使った授業形式の講演

f:id:Raspberly:20190226015128j:plain

 

 

ディレクショナルライトがないのでスポットライトで絵作りしている様子。

f:id:Raspberly:20190226015223j:plain

ライトが複数あると描画負荷が高い。

f:id:Raspberly:20190226015322j:plain

 

 

 

タイムライン

 

 

 

 

懇親会の様子

 

GINZAのお寿司

f:id:Raspberly:20190226020050j:plain

徹底的に整列された飲み物達。

f:id:Raspberly:20190226020129j:plain

 突如始まるLookingGlassの展示

f:id:Raspberly:20190226020435j:plain

Unityロゴ付きの提灯、味のあるやさしい明かり。

f:id:Raspberly:20190226020639j:plain

 

 

 

シェーダの基礎から大変わかりやすい内容でした。
(私の中では)シェーダはかなり難しそうな印象で、内部的にどういうプロセスで動いているのかイメージしにくいものでしたが、図と詳しい解説でおおよそ人に説明できるくらいには理解できた気がします。

後は実際に少しずつ書いたり、復習していきましょう。

 

 

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

 

 

過去のUnity道場のまとめ

raspberly.hateblo.jp

 

勉強会レポ : Roppongi.unity #1

勉強会のレポート(メモ)です。
参加したのはこちら、「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

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

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

・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

 

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

勉強会レポ : ゲーム開発におけるサウンド実装の勘所

勉強会のレポート(メモ)です。
参加したのはこちら、「ゲーム開発におけるサウンド実装の勘所」

過去にもお邪魔させていただいたTECHxGAME COLLEGEさんです。

techxgamecollege.connpass.com

f:id:Raspberly:20190221002546j:plain

 

 

 

 

ゲーム開発におけるサウンド実装の勘所

 

イントロ

みなさんどのタイミングでサウンド実装しますか?
結構後回しになりがち、参考本での扱いが悪いため(情報量が少ない)


サウンド実装で考慮すべきこと

考慮すべき三大要素
・CPU
・メモリ
・再生レイテンシー(スクリプトで再生させてから音が鳴るまでのタイムラグ)
CPUの負荷を抑えるとメモリレイテンシが、
レイテンシを抑えるとCPUメモリが犠牲になるなど三すくみの関係です。

なので音の特性を知りましょう

 


ゲーム内の音はたくさんありますがそれぞれに特徴があります。

f:id:Raspberly:20190221002709j:plain



音の長さや優先度、同時にならされる数など。
使うポイントでよくわけましょう。

f:id:Raspberly:20190221002717j:plain

さらに作るゲームの特性においても大事になる音は変わってくる(ボイスやヒット音など)
なので分類してどの音を最優先するかが大事。

 

 


モバイルゲームのオーディオは大変

以下の問題がでてくる。
・端末の制限が大きい
・データ容量の問題
・再生遅延
・再生の負荷

運営型の場合、大量のボイスデータをどう管理するかの問題も。
ところがゲームエンジンサウンド機能はプリミティブかつ足りないことが多い。

 

やらなければならないサウンド実装

みなさんが作らなければならないこと
・負荷を軽減する
 同時再生数の制限、CPU・メモリの管理。

・管理
 ボイスデータがいっぱいあるときどういうワークフローで管理するのか。

・演出設計
 フェード処理、ダッキング処理。

 


UnityAudio基礎

Unityがどのように音を鳴らしているのか、
AudioClipをSourceで読み込み再生し、Listenerで処理し最終的にスピーカーから音がでる。
プラスAudioMixerで音の種類を分類する、ミキサーに流してグループ化しボリューム調整する。


Audio特性

AudioClipのLoadTypeに気を付けましょう。LoadTypeは読み込んでから再生するまでの方法です。
Unityに音素材をインポートした時は、デフォルトでDecompressOnLoadになります。
しかしこれは少し重い。(なんでこれがデフォルトなの・・・)

LoadTypeはCompressedInMemoryにしましょう。
ほとんどの音はこの設定でいい。(ただし、早く再生したい音には向いてない)

 


音のタイプごとに再生方式を変えていきたいが、ボイスやBGMが多いと大変になってくる。
(ファイル名の変更、AssetBundleなど)
さらに音の情報をExcelで管理していると実際のデータとずれがでてくる。

 

特定の状況下での、音の再生に問題がでてくることも。

 

 

本題 CRI ADX2を使って解決しよう

採用実績がたくさんあり、会社用と個人用があります。

ADX2の効能

androidサウンドの遅延対策
・音声データの暗号化
・イントロ付きループ再生の実現

いろいろありますが、性能面だけじゃない。

ボイスデータの管理

ADX2のAtom Craftでデータ管理ができます。
BGMごとに「どのようにならすかの情報」を埋め込むことができる。

ここでデモタイム

ダッキング処理などはデータとして音の中に埋め込むので、スクリプトの方ではただ鳴らすだけで実現できる。

 

音のランダム再生や、ランダムでピッチを上げ下げするなど、ADX2内で複数の表現を作ることができる。

ツール上で音が重なった時どうなるかを確認できる。
スマホ上で再生しながら調整できるモードもある。

 

 

ほかにもいろいろあるが
のちほど資料を見てください

 

 

まとめ

オーディオは考えることがいっぱい。
複雑になるようならADX2を試してみて。
ADX2で大量の音データの管理が容易になります。

 

 

 

過去のTECHxGAME COLLEGE

raspberly.hateblo.jp

raspberly.hateblo.jp

 

 

勉強会レポ : 第1回 VRM勉強会

 

 

勉強会のレポート(メモ)です。
参加したのはこちら、「第1回 VRM勉強会」
会場提供は「メルカリ」さん。懇親会は「VRMコンソーシアム設立準備会」さん提供です。

connpass.com

ハッシュタグ : #VRM勉強会

 

f:id:Raspberly:20190220115312j:plain

 

 

動画はこちら(複数本に分かれてるっぽい?)
xR Tech Tokyoチャンネルで確認してください。

www.youtube.com

 

スライドのまとめはこちら

https://niconare.nicovideo.jp/events/44

 

 

時間(予定) タイトル 発表者  
19:00-19:10 Luppetで分かったVRMアプリ開発Tips @ CST_negi  
19:10-19:20 VVRMを使ったAR/MR撮影アプリを試作開発してみた話 @sotanmochi  
19:20-19:30 アバター生放送支援アプリ「アバれぽ」の紹介 @toRisouP  
19:30-19:45 休憩 ---  
19:45-19:55 おめめのうごき @miyumiyuna5 バーチャル登壇
19:55-20:05 誰でもできる!VRMモデルセットアップ小技集 @m2wasabi  
20:05-20:15 VRM対応スマホアプリ開発Tips集 @ yashinut  
20:15-20:30 休憩 ---  
20:30-20:40 VRM姉妹のGLTF(GLB)はやればできる子! セルフビルド狐おじさんが教える動く背景データの作り方と対策 @ichitarok バーチャル登壇
20:40-20:50 VRMSpringBoneをJobSystem&ECSで最適化してみた話 @ TEST_H_  
20:50-21:00 (個人で)VRM対応のアダルトアプリを作っている話 @nkjzm  

 

 

目次

 

 

 

LT1. Luppetで分かったVRMアプリ開発Tips

スライド

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

開発の勘所について話します。

Luppetとは

ノートPCとLeepMotionで完結するVtuberシステムです。
・セットアップが簡単。
・バストショットに特化(頭表情手指のみ)
VRM対応

開発者視点から見るVRM

VRMはいろんなモデルがいる。

・複数モデルの使用が見込まれる
・モデルごとに体格が違う
・モデルごとに見た目が違う

これを考慮したワークフローと工夫点

・複数モデルの使用が見込まれる

モデルとモデルの情報だけのシーンと、キャラを動かすシーンで分ける。
役割を分割し開発を楽にする。キャラ選択ではモデルを全て生成せずメタ情報だけにしましょう。

・モデルごとに体格が違う

Humanoidモデルの各ボーンを取得する。
首の位置を取得して、そこにカメラの位置を設定する。
ただし、自動だと限界があるので手動調整をする機能を入れましょう。

・モデルごとに見た目が違う

背景色 PostProcessingのブルームなどを調整できるようにする。
明るさ調整 背景色ブルームなど。

まとめ

モデルの生成とメインでシーンは分ける。
調整はある程度自動化するとユーザにやさしい、でも手動も必要。

 

 

 

 

 

 

LT2. VVRMを使ったAR/MR撮影アプリを試作開発してみた話

スライド

VRMを使ったAR/MR撮影ツールを試作開発してみた話 / Prototype of Mobile Mixed Capture - Speaker Deck

 

やりたいこと

屋内外でAR/MRの動画を撮影したい。
実は業務用ですが事例がありますがこれを個人でワンオペでやりたい。

試作したツール

動画を合成して撮影、ケーブルなしで動いています。
構成はスライドを見てください。

開発Tips

姿勢の動機はHumanPoseを送受信。 
ただしこれだけだとうまく合わなかった、なぜならキャラクターによってスケールが違うため。
別途位置を同期するオブジェクトを用意しました。

 

冗長かもしれませんが、上半身と下半身で分けています。
上半身はモーションキャプチャ、下半身はアニメーションで動かしています。

 

まとめ

個人で購入できるハードウェア、ソフトウェアで実現しました。
モーキャプの制度とかを改善していけば遊ぶ分には問題ないでしょう。

 

 

 

 

 

 

LT3. アバター生放送支援アプリ「アバれぽ」の紹介

スライド

https://niconare.nicovideo.jp/watch/kn4017?nicorepotwitter_upload_knowledge

アバれぽとは

アバター生放送を支援するwindows向けアプリ。
VRMの表示、ツイッターや生放送のコメントをメッセージで表示できる。
生放送で使え、登壇時にリアルタイム読み上げができる。

APIを公開するのでいろいろ試してみてください。

技術的な話

使ってるライブラリいろいろあります。

UniVRM、UniRx、UniWinApi、CoreTweet、UnityBoyomichanClientなどなど
オニオンアーキテクチャを採用しています。

今後の予定

開発者向けにAPIを提供します。
VRMの連携、表情の自動制御やキーボードやパッドの入力を反映も予定。

4月くらいまでにリリースします。体験版、有償版を用意します。

 

 

 

 

 

LT4. おめめのうごき

 

これから目を動かすニーズは高まる。
実はVRMは標準で目の制御ができます。
しかしパラメータがたくさんあってわからないと思うので実演を交えて解説します。

ここでデモ(動画を見てね)


試行錯誤したら、縦15横23くらいがいい感じ、パラメータをいじるとそれっぽい感じになります。

 

最後に一言
ちょっとぐらい大げさな方がいいと思います。
自分のモデルを使うときは限界ギリギリを算出してみてください。

 

 

 

 

 

LT5. 誰でもできる!VRMモデルセットアップ小技集

スライド

docs.google.com

小さなTipsを話していきます。

4月16日はVRMリリース1週年です。
記念にセットアップ本を無料で公開します。

MToon編

MatCapとリムライトについて。
MtoonのMatCapは乗算ではなく加算である、なので白色にびかびかになるので注意。

Mtoonには4つのRenderingTypeがありVRM/Untilよりも使いやすい。
半透明の処理などができるようになります。

 

SpringBone編

セットアップはニコニ立体ちゃんを参考にしましょう。
左右対称のVRMSpringBoneColliderGrouoはコピペしてxの+-を入れ替えればok。
JSONでのインポートエクスポート機能は、ボーン構造が少しでも変わっていると使えないので、コピペがおすすめです。

Boneのコライダーの生え方

基本的にRigの配置にそって生える。ただし方向は関係なく位置関係のみで配置されます。
長さ0のボーンについては、親から延長された直線状に生えます。
重力0なら関係ないが、あるとそのコライダーが影響を受ける。

misc編

標準以外のマテリアルはスクリプトを改造、使いたいシェーダーの名前を追加しないといけない。

 

 

 

 


LT6. VRM対応スマホアプリ開発Tips集

スライド

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

 

VRMはいいぞ

 

IOSのダウンロード事情

IOSはダウンロードする場所を選ぶことができる。(Androidはダウンロードフォルダへ)

zipはスマホ側でインポートするのが大変。専用のアセットを使いました。

プリセットキャラのロード

デフォルトキャラが入っています。StremingAssetに置けばロードはできるがVRMのランタイムロードはすごく重い。
prefabで配置したほうがいい。

バグ対応

・一部端末で描画が死ぬ、体が消える
・一部端末で落ちる
・一部端末で読み込みができない
これらで言いたいのは、Android端末は多様性があるのでデバッグ端末を用意しておくといいです。

おまけ

OculusGoは中身がAndroidなので同じようにできます。
Webを開いたりもできましたが、ダウンロードフォルダのvrmを消せない、
アプリ内から消せる仕組みが必要。

 

VRMはいいぞ

 

 

 

 

LT7. VRM姉妹のGLTF(GLB)はやればできる子! セルフビルド狐おじさんが教える動く背景データの作り方と対策

スライド

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

 

内容盛りだくさんなのでスライドを見てください。

 

アニメーションなど

世界は不順な動きで満ちている、これを作ることで現実に近づけることができる
アニメーションはユニティ内で作りましょう。確認しながら作れるため。

階層はうまく使いましょう
空のオブジェクトを作ってグループ化していきましょう。
ただし階層は途中で変更すると動かなくなります、注意しましょう。

.animはavaterに入れましょう、これはよく忘れます。

フレームレート

多ければいいという問題ではない、1でもいい。 
回転する時はquatinonを選びましょう。

出力時の注意

animationのpreviewを解除しないで出力しようとするとだめ。
フレームレートは回転が速すぎてできない場合はフレームレートを増やす。

 

 

 

 

LT8. VRMSpringBoneをJobSystem&ECSで最適化してみた話

スライド

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

ニコニ立体ちゃんを256体を同時に動かして負荷テストします。

JobSystem

・モデルごとに処理

 モデルの持つボーンを一箇所で全て平行処理します。
mainスレッドは5msいないに収まった Jobの処理がまばらなのかスパイクがあった。

 

・全モデルを一括で処理

ボーンをモデルごとではなく全モデルの情報一括で処理します
キャラが何体いようと全てまとめて処理できます。

処理自体は一番良い結果となった。
データをまとめることでジョブの発行を抑えることができるようになりましたが、
動的なモデルの追加削除の負荷はそれなりにかかります。

ECSとjobsystem

ESCとGameObjectがかかわってくるのでHybridが必要。
増減はJobベースよりもマシになる。
ここで時間切れ、続きはスライドを見てください。

 

 

 

 

 

 

LT9. (個人で)VRM対応のアダルトアプリを作っている話

スライド

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

開発したきっかけ

ドワンゴ利用規約で許可されているため

開発思想

健全なアダルト文化を作りたい。
社会的な意義があり、安全なものを作っていきたい。
現実よりもアバターの方が自分を表現できる人たちがいる。その人たちを支援したい。

安全なアダルトアプリ

アバター時代のリベンジポルノになるのを防ぎたい->性的表現を許可してるモデルだけを通すようにする。

アバターを生み出す人は、配布やライセンスには要注意。悪用されるリスクがでてきます。

作ってみた知見

有償でも買ってもらえる。
反応がわかりづらい、聞きづらい。
イベントで門前払いされる、アダルトOKな会場がない。

今後

マルチプラットフォーム
任意のモーションを読み込む
複数人対応

まとめ

アダルト系の開発者イベントがやりたい

 

 

 

 

 

 

 

 

 懇親会&展示会の様子

 

 

 

 

 

 

 

 

 

ピザがたくさん出ました。ポテトやソーセージなどいろいろありますが、
とろとろのチーズピザが一番おいしかった。

f:id:Raspberly:20190220115638j:plain

f:id:Raspberly:20190220115644j:plain

f:id:Raspberly:20190220115650j:plain

f:id:Raspberly:20190220115714j:plain

f:id:Raspberly:20190220115726j:plain

f:id:Raspberly:20190220115730j:plain

 

 

他の方のメモ、感想ブログ

platoronical.hatenablog.com

qiita.com

 

 

 

次回は5月頃のようです。

 

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

 

誤字や、校正忘れを修正しました。