間が空いてしまいましたが、Unite Tokyo 2018 3日目 のまとめです。
さては非同期だなオメー！async/await完全に理解しよう
Unity の対応する C# のバージョンが 4.0 から 6.0 へ、.Net のバージョンが 3.6 から 4.x へ、それぞれ引き上げられ、コード内で扱える機能の幅が広がりました。
この中で、async と await 、そして Task を使用した非同期処理について、講演の前半で解説されています。
そして講演の後半では、従来から Unity での非同期処理機能として使用されているコルーチンや、Unity 2018 で追加された並列処理の機能 C# Job System について、軽く紹介されています。
コルーチンは講演内でも触れられている通り、戻り値の扱いなどがやや不便で、C# Job System は並列処理用の機能ということで、非同期処理として軽く実行したい場面とは、また目的の異なる機能かと思います。
（C# Job System については、自分がまだしっかりと理解していないので、語弊のある言い方になっていたらすみません）
今後の Unity における非同期処理は、async / await の利用がスタンダードになっていくのかも知れませんね。
↓2017年 のこちらの講演スライドでも、Unity が C#6.0 と .Net 4.6 に対応することにより新しく扱える機能や移行の注意点についての紹介がされていました。参考になります。
スクリプトによるTimelineがっつり拡張入門
スライドは Slide Share に記されているリンク先からダウンロード可能です。
内容はほぼタイトル通り、Unity 2017 から実装された Timeline 機能の、スクリプトによる拡張について。
講演の最初は、Timeline 機能を拡張して、どのようなことができるかの紹介から。
Timeline で演出している舞台をそのまま用いて、ゲーム的な操作へ移る挙動（『インタラクティブカット』と称されています）や、プロジェクトの Quality Settings を Timeline 内で変更できるように拡張することで、影の表現を Timeline 内で動的に変化させる演出（「曇り空では影をボケさせ、稲妻が光るとシャープにする」みたいな）などが紹介されています。
次に、Timeline 機能をどのような方針で拡張すべきか、について。
自分は Timeline 機能を実際にいじって何かを作っているわけではないので、細かい部分は理解しきっていないのですが、「GameObject を生成してそこのパラメータをコントロールできるようにする」「Timeline 上のトラックを機能拡張する」など挙げられた方法から、エディタ使用者にとっての使い勝手を考慮して拡張方法を選択するのが大切かと思われます。
最後には、スクリプトからの Timeline の Create 方法や After Effect との連携まで紹介されており、単なる Timeline 機能拡張だけでなく、一連の作業用ツールとしての拡張についても、軽く触れられています。
Timeline 機能、まだ使用する機会には恵まれていないのですが、Unity 内での調整がやりやすく、拡張も容易にできるのであれば、今後は業界的にもカットシーンの標準の機能になっていくのではないかな、と少し思っています。
60fpsのその先へ！スマホの物量限界に挑んだSTG「アカとブルー」の開発設計
Unity の公式サイト Made with Unity でも、Unity を用いた開発に関するインタビューが取り上げられていた、『アカとブルー』に関する講演です。
Made with Unity のこちらの記事も、「他の Unity を利用した開発プロジェクトが、どのような環境なのか」を知る機会として、とても面白いのでオススメです。自分も、ScriptableObject の使い方なんかは参考にさせていただいています。
今回の講演の内容も、この記事の延長上という感じで、Unity を用いて 2D 弾幕シューティングを開発する上で、最適化（主にメモリまわり）のための工夫がメインに取り上げられています。
ただし上の記事や今回の講演ともに、ある程度 Unity の特徴的な機能（Monobehaviour, uGUI, Collision, など…）を捨てる選択や、C# スクリプトの1行1行の書き方について細かな工夫を加えることで、パフォーマンスを得るような方法が紹介されてます。
これは Unity で自然に動作する 2D 弾幕シューティングを開発するという試みを、開発のしやすさを捨てて達成している、とも言えるため、この講演内容を各々のプロジェクト開発環境でどれほど取り入れていくかは、当然ながら『パフォーマンス』と『開発のしやすさ』のトレードオフを考えて検討していく必要があるかと思います。
例えば、オブジェクトの数がそう多くなく、メモリ的にもそこまで繊細に気にする必要もない、処理落ちもあまり発生しないようなタイプのゲームであれば、せっかくの Unity の便利機能である uGUI などを縛るような開発は行う必要は無いかと思います。
一方、例えば 2D アクションゲームの開発環境であれば、Unity 自前の Collision を利用せずに自作することは、アクションゲームとしての手触りに確かに影響しますし、重要なアプローチかと思います。
処理落ちやスパイクを防止するためのコーディングの工夫なども、ゲーム性に影響があるようであれば同様です…が、この辺りは Unity のアップデートによって、メモリアロケートや処理速度について改善された結果、こちらの工夫が意味を成さなくなることもあるので、ノウハウの蓄積としては微妙になる場合もあり得ますが…。
（例えば Unity 5.3 辺りの頃は、foreach は使うべからず、みたいに言われていたこともありましたが、今は普通に問題無く使って良い…はず…。）
余談：講演の中で「string の初期化時は = “” ではなく = string.empty を利用しましょう」という内容があり（スライド 62 ページ目）、その有用性と信憑性について Twitter で少し話題になっていました。
これについて、講演者である『藤岡 裕吾』氏ご本人の Twitter から「どちらでも変わらない」と訂正があったようでした。
https://twitter.com/fujiokoact/status/995985900071927808
© Unity Technologies Japan/UCL
