もんりぃ is undefined.

育児ネタとか、技術ネタとか。

Unity Case-Study / アニメーションあれこれ

はじめに

  • Unity で「アニメーション」をする方法って色々あって、「正直どれが最適なのか分からん!」って声が聞こえた気がするので、 個人的な見解 を紹介してみる。

Animator

  • 恐らくアニメーション用途として最も利用されている機能かな?
  • ステートマシンを用いてアニメーションの状態遷移を管理できる。
  • メニュー上で Assets > Create > Animator Controller を選択すると作られる Animator Controller (拡張子: .controller) というファイルに Animator のステートマシン情報が記載される。
    • どういう条件でアニメーションを再生するのか?みたいな。
  • アニメーションの実態は Assets > Create > Animation を選択すると作られる Animation Clip (拡張子: .anim) というファイルに記載される。
    • どのプロパティを、どういうカーブでアニメーションさせるのか?みたいな。
  • (その昔、 Animation という単独の機能があったが、 Obsolete 状態になっており、 Animator が代替と言える。)

メリット

  • アニメーションの定義を Unity Editor 上で完結できる。
  • MonoBehaviour.Update() メソッドとかでアニメーションさせるよりも(多分)パフォーマンス的に有利。
  • 中間補完やアニメーションブレンディングなど「よしなに」アニメーションしてくれる。
  • AnimationEvent を用いたイベント処理もできる。
    • ただし、コードから追いづらいため、バグの温床になったりもする。

デメリット

  • Unity Editor 上での操作に対する学習コストが高い。
    • Animation Clip 編集用の Dope Sheet とか Animation Curve 編集画面とかは、 Flash 経験者なら馴染みがあるかも?
  • ステートマシンがゴチャゴチャになりがち。
  • スクリプトでの操作と組み合わせたアニメーションを行おうと思うと柔軟性に欠ける。
    • Animator Controller 内に含まれる Animation Clip が操作する対象のプロパティはスクリプトから(原則)いじれない、とか。

Reference

MonoBehaviour.Update()

  • 毎フレーム呼び出されるメソッドなので、初期値とか終了値とか経過時間とかを巧いこと管理できればアニメーションの実装もできる。
  • DOTween とかの Tween ライブラリは、本質的には Update() での実装と言えるかも。
    • 内部実装読んだわけじゃないから分からんけど、多分最終的にはフレーム毎にゴリゴリ計算してるはず。
  • シンプルな移動とかに使う分にはアリっちゃありかも。

メリット

  • 実装力があれば、最強に柔軟な手法。
  • 世の中に優れたライブラリが存在している。

デメリット

  • Easing Curve とかも考え出すと自前実装は沼でしかない。
  • メッセージングによる呼び出しになるため、他に比べるとパフォーマンス的に不利。
  • それなりに数学的な知識を必要とする。
    • まぁ、他も本質的にはそうなんだけどねw

Reference

物理演算

  • スクリプトベースでサッとやるなら、割とアリな手法かも。
  • 程よいパラメータを見つけ出せれば、記述量は減らせる。
    • 基本的には Rigidbody.AddForce() なり Rigidbody.AddTorque() なりのメソッドを叩く感じになると思うので、加える力を調整する感じかな?

メリット

  • 巧くやれば自然なアニメーションになる。
  • スクリプトベースでありながら、計算を全て Unity (というか Physics)に丸投げできる。

デメリット

  • 小回りが効かない。
    • 途中で処理を介入させたりすると、思わぬ挙動をしたりするので、結構ヤバみある。
  • FixedUpdate() という Update() のサイクルとは別のメッセージングサイクルになるため、他のスクリプト実装とぶつかるコトがあり得る。
  • 「良い感じ」のパラメータを見つけるのが大変。
  • アニメーションそのものに対するイベント処理がやりづらい。
    • 「移動が終わったとき」みたいなイベントフックは面倒。

Reference

まとめ

  • 適材適所ではあるが、学習コストを飲み込んでも Animator でアニメーションするのがベターかな。
  • メンテナンス性が必要ないようなプロジェクトであれば、物理演算でサッと書き捨てるのも良いかも。

「ハンズオンズ / 「Unityとは?」から始める実践入門」で講師をしました

はじめに

KPT

Keep

  • 座学はほぼ予定通りの時間で進められた。
  • 実践も完全脱落した人は居なかったっぽい。
  • 概ね好意的な感想を頂戴できた。
  • 初学者向けとしては、ほどよい分量の資料が作れた。
    • これは、今後(?)に活かせそうな気がしている。

Problem

  • やろうと思っていたカリキュラムの半分も終わらなかった。
    • 無償のハンズオンってトコに甘えてしまった感は否めない…。
    • 蛇足的な作業を受講者の皆さんにさせすぎた。
    • エディタの使い方とハンズオンを一緒に考えない方が良かったのかも?
  • 開始前とか締め方とかの段取りがグダグダになってしまった。
    • 主催の方の挨拶とか会場説明とかすっ飛ばして始めてしまったのは猛省。
  • 登壇を詰め込みすぎた。
    • コレは、このイベントに限った話ではなく。
    • 2週間で3本のド新規ネタはしんどかった…。

Try

  • ハンズオンは必ず壁打ちをする!
    • 社内のメンバーとかを実験台にして壁打ちしないと、ペース配分が全く読めない。
    • Schoo の時に同じ轍を踏まないようにせねば。
  • もっと余裕を持って会場入りする。
    • 段取り周りの相談とかをする時間を取れなかったので、独演系の時は特に気をつけねば。
  • 資料作りをもっと早くやる。
    • 夏休みの宿題を8/31にやるマンを脱しないと…。
    • ひと頃よりはマシになったが、うーん…。

所感

  • 総じて楽しかったけど、かなり多くの課題を感じた。
  • 第2回をやる機会があれば、リベンジしたい所存。
  • 何事も経験あるのみ、だなぁ…。

Unity LT 大会で喋ってきました

はじめに

  • 2017/12/09 (Sat) に開催された「【年末だよ】Unity お・と・な のLT大会 2017【ポロりしてもいいのよ】」というイベントで喋ってきた。
  • それについて KPT する。

KPT

Keep

  • 割とウケた。
  • あるあるネタの時とかは皆さん「ウンウン」という感じに頷いてくれてた。
    • やはり、みんな悩んでいるんだよね。
  • ほぼ時間通りに収められた。

Problem

  • 時間通りに収めるために、ちょっと端折ったり早口になってしまったりした。
  • Keynote でのプレゼンだと資料を作るのに時間がかかる。
  • 補足記事とかがない。

Try

  • やはり、最初から10分に収まるような資料にすべきだった。
  • 次回は GitPitch とか esa とかでの発表を試してみよう。
  • Clean Architecture 解説ブログ書かねば…。

所感

  • 総じて楽しい LT 大会だった!
  • 馴染みのメンツと深い話も出来たりしたので、満足度高い。
  • 割と若いエンジニアさんも多い感じで、エネルギーをもらえた気がした。

Patch Release の翻訳始めてます。

はじめに

  • 個人活動として、(勝手に)Unity の Patch Release の日本語訳をする「Unity ReleaseNotes 勝手翻訳」というブログをやっています。
    • ブログタイトルに何のヒネりもないというツッコミは甘んじて受け入れますw
    • 活動開始のきっかけとかは初稿記事をご覧ください。
  • 今回は、このブログを書く中での KAIZEN の歴史とか今後なんかをダラダラと綴ります。

歴史

~ 2017/09/24

  • ブラウザで「ページのソースを表示」をして該当箇所をコピペ
  • Visual Studio Code で <li> タグとかを正規表現で置換
  • Google 翻訳とかに掛けつつ1つずつ翻訳

~ 2017/10/29

  • 結構過去に翻訳した内容と同じモノが挙がってくるケースが多いコトに気付いて、どうにかデータベース化しようと思い始める
    • 仕組み上、 Unity Issue Tracker で起票された Issue が複数のエディタバージョンに影響するコトが多い
    • 2017.1.x と 5.6.x にパッチ、とかザラにある
  • 一瞬 Rails で作ろうかなぁ?とか思うが、まだそのフェーズではないと判断し Google SpreadSheet に転記を始める
  • しかし、Patch Release の Release Notes のフォーマットが微妙に揃っていないため、結局手作業が結構多くなりヘコタレはじめるw
    • Issue ID が記載されていないモノが全体の5%〜10%くらいあるため、英文を見て「これ、過去に訳した記憶あるぞ…?」みたいな記憶依存な状態が発生する
    • 極稀に、HTML が崩れていたり、本文のフォーマットが異なっていたりする

~ 2017/11/26

  • 元の HTML を食わせて、SpreadSheet 貼り付け用の TSV を生成する PHP スクリプトを書く
  • SpreadSheet 関数の GOOGLETRANSLATE() の存在を知り、膝をつくw
    • 一個ずつ Google 翻訳のフォームに入力してた自分がバカらしくなった
  • パッチリリースの重さとして、マイナーリリース直後のパッチリリースは結構重くなる傾向があるコトに気付く
    • 2017.2.0p1 とかが激重だった(2017.2.0p2 も直しきれなかったアレコレがあったのか重かったけど)

今後

  • モチベーションを維持するのが結構大変なので、その辺をどうコントロールしていくかが課題
  • うまいこと GitHub とかで公開・管理できればコントリビュータ集められるかも?とか思っては居る。
    • 内容の粒度的に難しいんだよなぁ…。

リモートワーク Rev.10 / ゾーン

はじめに

  • 2017/10/08 (水) はリモートワーク。
  • 普段は木曜にリモートワークしているが、今回はミーティングの関係などから水曜にした。
  • もはや何回目か分からなくなってきたので、記事のタイトルはインクリメントしてリモートワークの回数は数えないことにしたw

KPT

Keep

  • とても集中できた。
  • 妻と娘の姿を見ながら仕事できるので、癒やし効果が高い。

Problem

  • 娘もパパが昼に居ることに慣れてきたのか、妻がトイレに立ったときとかにちょいちょい「構って〜!」って感じで作業に割り込むようになってきた。
    • まぁ、タバコ休憩みたいなもんだと思えば、許容できる割り込みかな。
  • タスクの共有が漏れがち。
    • 何か作業を始めるときに、直ぐにゾーンに入っちゃってカンバンでタスクを作業中に移動させるのを忘れがち。
    • リモートの場合、「今何やってるのか?」をちゃんと共有しないとダメだと理解してはいるのだが…。

Try

  • タスク共有について何か考えなければなのだが…。
    • Toggl の状態変更とかのタイミングが一番望ましいとは思っているが…。
    • PullRequest を先に作るスタイルを確立できれば、解決できるかも?

iPhone X Tester for Unity を公開しました!

はじめに

  • 私が TechLead を務める 株式会社キッズスター のアプリ「 なりきり!!ごっこランド (iOS / Android) 」を iPhone X 対応する際に、都度ビルドするのも大変なので「Editor 上で iPhone X での見え方を確認できるようなアセット」を作りました。
    • 一応 Unity 公式でセーフエリアに対する対応が行われるそうですが、待っていられなかったので作りました。
  • 元々は社内で使うだけのつもりだったので、Private リポジトリで開発していましたが、需要がありそうだったので Public に切り替えて公開することにしました。

概要

  • iPhone X のベゼルとかセンサーハウジングとかホームインジケータを再現したフレーム画像を GameView 上で重ねます。
  • f:id:monry84:20171110102546p:plain
    • 開発中の画面なので、中身にはモザイクを掛けております。
    • (公開時点ではモザイク掛けてなかったので、 Twitter の OGP 画像が古いままなんだよなぁ…。1週間くらいしたらクリアされるらしいので、それまで待つしかなさそうだ…。)

導入

  • こちらのリポジトリ にて公開しています。
  • README に書かれている方法でプロジェクトにインストールすれば、即使えるようになるはずです。
    • npm コマンドを用いるため、Node.js のインストールが必要になります。

使い方

  • README に記載していますが、 シーンを再生していない状態で メニューの Assets > Install iPhone X Tester を選択してください。
    f:id:monry84:20171110101423p:plain
  • GameView のサイズを 2,436 × 1,125 などにすると実際の iPhone X の画角で確認できます。
    f:id:monry84:20171110101500p:plain
    • 正確に上記のサイズでなくとも、似たような比率であれば良いかと。

詳細

  • 既存のシーンには影響を与えないように、マルチシーンとして追加されます。
  • 現在のところ、Landscape (横向き) のみに対応しています。
  • センサーハウジング(端末上部の切り欠き)やホームインジケータ(画面下部のホームボタン代わりの横棒)の領域に当たり判定は設置していません。
    • あくまで見え方を確認するためのモノなので。
    • 当たり判定置きたい場合は、BoxCollider2D なり PolygonCollider2D なりを置くと良いでしょう。
  • シーンが再生されると iPhoneX_Tester シーン内の GameObject は DontDestroyOnLoad フラグが立てられて iPhoneX_Tester シーンそのものは UnloadScene されます。
    • DontDestroyOnLoad フラグが立つ GameObject の中には Camera も含まれるため、開発中のシーンでも Camera 付きの GameObject を DontDestroyOnLoad すると思わぬ挙動を示す可能性があります。(未検証)
  • iPhoneX_Tester シーンの Camera の depth は 10 に設定してあります。
    • フレームが奥に隠れてしまう場合はこの値を大きくすれば良いでしょう。
  • なお、インストールの際に npm を用いるのは、私が開発している umm: Unity Module Manager という仕組みで提供されるアセットとして作ったためです。
    • umm の詳細は近々記事にします。

おわりに

  • 「あー、対応しなきゃー」って時に、サッとフレーム画像を作ってくれた弊社のスーパーデザイナーさんに感謝です!
    • 「ブログで紹介しても良いっすか?」って聞いたら、「今、すごく需要ありそうだし、全然 OK!」的なリアクションで返してくれたのも嬉しかったです。
  • 公開のきっかけを与えてくださった @lycoris102 さんにも感謝です!

娘の心理的成長

今日は、近くのデパートに昼食と買い物を兼ねて家族3人でお出掛けしました。

昼食後にお昼寝するかなぁ?と思ったら寝なかったので、無料のキッズスペースに娘(2歳3ヶ月)を連れて行き、しばし遊ばせました。

その時に、娘の心理的成長を感じる出来事があったので記録する次第です。

今日はちょっと年上の男の子が多く居て、バタバタと走り回っている感じでした。

普段なら物怖じして端っこで私と遊ぶ展開になるのですが、今日は男の子達の後ろを追い回したり、他の子が遊んでいるクッションを借りようとしたり、と普段と異なる行動パターンをとっていたので、私としてはかなり衝撃的な展開でした。

妻に何かキッカケとなるような出来事があったのか?と聞いても、特にそれらしい出来事はなかったらしく、最近になって子育て支援センターとかでそういう感じになったんだとか。

単純に月齢が進んだことにより心理的な発達がみられたというコトかな…?

まぁ、何にしても程よく友達を作って、娘なりの交友関係を築いていって欲しいなぁとか思った土曜の昼下がりでした。

特にオチもない記事になってしまったが、寝かしつけもつつがなく済ませてビールを飲みながらダラダラ書くのもまた一興ということで。