Games Focus：皆さんのフィードバックがどのように製品開発を推進させているか

今回のブログは、2023 年以降の製品開発の主要な取り組みについて紹介する Games Focus シリーズの第 6 回です。このブログでは、Unity のエンジニアが皆さんのフィードバックをどのように優先順位づけして、どのように製品の開発に取り入れているかをお伝えします。

こんにちは、Andrew です。Unity のエディター・エンジンチームの製品マネジメントのリードをしています。私はこれまでのキャリアのほとんどを、プロジェクトの規模に関わらず、ゲーム開発者がプロジェクトに楽に取り組めるようになるツールやテクノロジーの開発に捧げてきました。私の仕事で好きなところは、私たちが受け取ったフィードバックと私たちが皆さんのために最終的に開発するものを合致させる部分です。

Unity では常に皆さんができるだけ良いゲームを作るための力となれるようなテクノロジーを懸命に開発しています。それが新機能の開発であっても、パフォーマンスや生産性の向上であっても、製品の修正であっても、皆さんのフィードバックは Unity のエンジニア、製品マネージャー、デザイナー、QA スタッフの仕事の方向付けに非常に重要な役割を果たします。 

ここでは、私たちがこれにどのように取り組んでいるかについてご紹介します。

ユーザーからのフィードバックは、私たちが製品について正しい判断を下すために欠かせないものです。私たちは、皆さんからのフィードバックをもとに行っている私たちの活動についてお伝えし、願わくば、皆さんからさらにニーズ、知見、経験を共有していただきたいと考えています。

私たちがフィードバックを収集し、管理する目的はシンプルです。皆さんから寄せられた知見により、私たちはさらに大きな価値を皆さんにお届けすることができます。そのため、皆さんにとって最も重要で、最も効果のある改善ポイントを優先し、そこに時間を費やすことができます。

最近 12 か月で、私たちのロードマップのエントリに対して、コミュニティから 9,000 件に迫るコメントや見解が寄せられています。数多く寄せられた問い合わせすべてに対して、バグレポートの作成を要求してはいません。重複するものも多く、そうしたものは 1 つのレポートに集約されることもあります。

こうして集約されたレポートについては、私たちは優先順位を上げて作業します。各チームが担当している製品領域に関連するフィードバックや問い合わせを取り上げ、何度か検討して、そのうちどれについて、どのような順序で実装を行うべきかを決めます。検討の際に行う主な問いかけは以下のようなものです。

• この機能や改良はどのくらいのユーザーにリーチするか。
• この項目がユーザーに与える影響はどのようなものか。
• 私たちはどのくらい自信を持って結果を理解していると言えるか。
• エンジンの異なる部分に対して後続の作業を始めなければならなくなった場合、私たちは何をするのか。
• 新機能が出荷される見込みになったとき、他にどのような変更を予測するべきか。

最近リリースされた TECH ストリームリリースである Unity 2022.1 については、私たちはすでに皆さんからいただいた情報の大部分をまとめて得られた統計のうち、注目すべきものをいくつか見出しています。この情報に基づいて行われた改良が Unity 2022 LTS に取り入れられ、2023 年の春には皆さんのお手元に届きます。

毎年リリースされる LTS は、最も安定していて、最も頼りになり、最もサポートが手厚いバージョンの Unity として設計されます。Unity LTS は新機能の導入や API の変更がなく、2 年間にわたって隔週で修正プログラムが提供されるため、自信をもってそのバージョンに固定して制作を進めることができます。しかし、これはフィードバックが実際にある LTS リリースに反映されるまで、最大で 2 年かかるということも意味します。

Unity 2021 LTS のリリース以来、私たちは 12 回のアップデートをリリースしてきました。その内容はすべて新着情報のページに詳細なリリースノートとあわせて公開されています。

顧客からのリクエストやフィードバックをもとに実装された新機能または改善の具体的な例をいくつか選びました。これらの一部は Unity 2022.1 TECH ストリームリリース時のブログ記事でも大きく取り上げられています。

フィードバックから生まれたもの：マテリアルバリアント

レンダリングとビジュアルエフェクトロードマップの中で最も皆さんからの要望が高かった機能カードの 1 つが、マテリアルバリアントでした。

マテリアルバリアントは、アーティストが大量のアセットを管理するチームにおいて、マテリアルを再利用する際の反復作業やオーサリングミスを減らすための、統合された強力なワークフローを提供します。

HD レンダーパイプライン（HDRP）とユニバーサルレンダーパイプライン（URP）の両方でマテリアルバリアントが利用可能となったことで、マテリアルの階層を作成し、子マテリアルは親マテリアルと共通のプロパティを共有し、異なるプロパティのみをオーバーライドすることができるようになりました。テンプレートのマテリアルの共通プロパティやオーバーライドされないプロパティの変更は、自動的にバリアントのマテリアルに反映されます。これで時間を節約し、マテリアルの変更をはるかに簡単に行えるようになります。

フィードバックから生まれたもの：新しいパフォーマンス最適化ツール

たくさんの開発者とのやりとりを通じて、私は Unity の「中」で何が起きているのかを理解するためのツールがまだまだ求められていることを知りました。開発者はゲームのパフォーマンスの向上に役立ち、幅広いプラットフォームやデバイスにわたってプレイヤーによりスムーズな体験を届けるために役立つ、行動につながるインサイトを得たいのです。

よく受け取るリクエストの 1 つに、Arm チップセットを搭載したデバイスをターゲットにしている Android 向けのゲームについて、低レベルのパフォーマンスデータにアクセスしたいというものがあります。これに応えるために、私たちは Arm と協力して System Metrics Mali パッケージを提供し、開発者の行った変更がハードウェアにどのような影響を与えるかということに関するインサイトを得られるメトリクスを公開しました。

物理演算と UI はゲームのパフォーマンス最適化に関わる 2 大分野です。Physics Debugger は、物理エンジンの内部動作やプロジェクトで観察される特定の動作の理解に役立つツールです。そのため、リッチで説得力のある物理挙動を持つコンテンツのオーサリングに不可欠なツールとなっています。私たちは Physics Debugger の UI を完全に書き直し、プロパティをグループ別にタブにまとめ、新しく追加されたプロパティもあわせ、必要に応じてタブを展開できるようにしました。Physics Debugger の改良の詳細を知りたい方は、こちらの記事をお読みください。

フィードバックから生まれたもの：UI Toolkit のデモ

新機能を効率よく使い始められるように、ベストプラクティスやサンプルプロジェクトをもっと示してほしいという声も聞かれました。私たちは新しい UI Toolkit のサンプルとして『Dragon Crashers』をリリースしました。このサンプルは、皆さん自身のアプリケーションで UI Toolkit を活用する方法を示してくれます。このデモでは、ミニ 2D RPG である『Dragon Crashers』のスライスに、実行時に Unity 2021 LTS の UI Toolkit ワークフローを使用してフル機能のインターフェイスを提供しています。

このデモは年内にリリース予定の新しい e ブックでも取り上げる予定です。今すぐ事前登録し、公開されたらすぐに通知を受け取れるようにしておきましょう。

最後に、顧客から直接受け取るフィードバックがどのようなものか、そしてそれが私たちの仕事の優先順位にどのような影響を与えるのか、その一例をご紹介したいと思います。Accelerate Solutions のゲームコンサルティングサービスなど、Unity のコンサルティングおよびエンジニアリングサポートチームは、定期的に皆さんの声を開発チームに伝えています。また、自らソリューションを提供することもあります。これらのソリューションは、他のユーザーにも広く使っていただけるものにつながることも多いです。

その一例として、『Subway Surfers』の制作者である SYBO 社との長年の協力関係から生まれたものがあります。レンダリングに繰り返し発生する問題を発見した開発者は、そのクラッシュログを Unity に渡しました。エンジンのバグを認識した Unity は、すぐにパッチを開発し配布したのです。

皆さんからいただいたご意見や、サポートエンジニアとの対面のやりとりでお伝えくださったご意見は、現在開発中の多くの機能の開発を始めるきっかけとなっています。興味深い事例をいくつかピックアップしてみました。

皆さんから、スクリプタブルレンダーパイプライン（SRP）に対応したサーフェスシェーダーや、Unity のシェーダーシステムに組み込むより良い方法が必要との声をいただいていました。私たちは、実験的なブロックシェーダーワークフローで有意義な解決策を提供するために懸命に取り組んでいます。

ブロックシェーダーは、テキストベースのシェーダーのオーサリングワークフローを合理化し、モジュール化したものです。これにより、オリジナルのシェーダーのソースを修正するような複雑な作業をすることなく、既存のシェーダーの機能をオーバーライドして拡張することができます。これは、ビルトインレンダーパイプラインのサーフェスシェーダーの場合と同様のワークフローです。また、ブロックシェーダーは、複数のレンダーパイプラインにおいてシェーダーのオーサリングを統一することを目的としています。

この機能についての詳細を確認したい方、あるいはご意見をお寄せいただける方は、フォーラムのスレッドをご覧ください。

サポートチケットの集計も緻密に管理しています。私たちは傾向をとらえ、ホットスポットの根本的な原因を探ろうとしています。

Accelerate チームとの対話から、ホットスポットの 1 つは Unity がランタイム用にコンテンツをどのようにパックするのかを把握することとなっていました。この問題に対処するため、私たちは新しい Addressables Build Report Visualizer ツールを開発しています。 ユーザーはコンテンツのビルドをレビューし、最適化の可能性がある重要な領域を迅速に特定することができるようになります。

また、ユーザーフレンドリなインターフェースや、プロジェクトの種類や規模に関わらず、Addressable のビルドに役立つ貴重なインサイトを提供します。例えば、Addressables グループと AssetBundle の相関関係や、さまざまな AssetBundle 間の依存関係を確認することができます。

上記の Visualizer ツールと同様に、UnityDataTool は、UnityFileSystemApi ネイティブ動的ライブラリで何ができるかを紹介するコマンドラインツールのセットです。これは、Ludia 社のサポートエンジニアの 1 人が、ゲームサイズを小さくするためのソリューションを求めて開発した実験的なツールです。

同社のサポートエンジニアが最初に開発したアセットバンドルアナライザーは、同じアセットの重複したコピー、テクスチャサイズやフォーマットの誤り、圧縮されていないオーディオクリップなどの問題を発見するために役立つものでした。Ludia 社は、最終的にこれをビルドシステムに統合し、ゲームデータが日々どのように変化していくかを追跡できるようにしました。

最近開始した Dev Blitz Days は、皆さんからご意見を寄せていただく新しい手段です。このオンラインイベントでは、ロードマップや計画、機能に関する要望など、率直な質問をお寄せください。すでに、UI とレンダリングをテーマとした Blitz Day を開催しており、今後も順次開催予定です。

以下に示すものは最もよく利用されているフィードバックチャネルです。皆さんご自身の Unity 経験のレベルを問わず、積極的にご利用ください。

• 製品ロードマップ：フィードバックを寄せるには、製品ロードマップを使うのが最適な方法の 1 つです。 
• エディター内：皆さんが遭遇した特定の問題に対して、何種類かのエンジン計測、クラッシュレポート、およびバグ報告を通じてフィードバックを収集します。
• ベータ版プログラム：新機能にいち早くアクセスでき、今後リリースされる Unity に備えるために最適な方法です。
• Insiders プログラム：Insiders プログラムに登録すると、Unity の機能エンジニアリングチームの人員が参加する、招待制のフィードバックセッションに参加することができます。
• オンライン：ソーシャルメディア、フォーラム、Reddit、Discord
• 対面：Unite のようなイベントから、アクティブなプロジェクトでエンジニアリングサポートを提供するための体系的なミーティングまで、Unity のチームと対面で話すことで、直接コミュニケーションを取ることができます。

ユーザーとの率直な対話は、Unity に入社してよかったと思うことの 1 つです。より良い会社、より良い Unity を作るために、時間を割いてフィードバックを送ってくださる皆さんに感謝します。そして、これからもよろしくお願いします。

次回の Games Focus シリーズは近日公開予定ですので、ご期待ください。 また、11 月 1 日（火）に開催される Unite 2022 に参加し、次に何が Unity にやってくるか、詳しく知りましょう。

編集者注（2022 年 11 月 2 日）： 本ブログの以前のバージョンでは、Unity 2021 LTS の発売以来 8 回のアップデートをリリースしたと記載しておりましたが、実際には公開時点でのアップデートの総数は 12 回でした。ここに訂正させていただきます。