モバイル UI デザインに関するベストプラクティス – 第 2 部

モバイル UI のパフォーマンスをテストし最適化することは、設計/開発プロセスの重要な部分であり、あらゆるゲームの成功にとって不可欠なことです。

本インタビューの第 2 部では、Outfit7 のシニアソフトウェアエンジニアである Aleksander Gregorka 氏、Samsung のデベロッパー窓口担当エンジニアである Søren Klit Lambaek 氏、そして Unity のシニアテクニカルプロダクトマネージャーである Benoit Dupuis とのディスカッションに戻って、高パフォーマンスなゲームと楽しいプレイヤー体験を提供するためのベストプラクティスについて聞いていきます。

Q&A の第 2 部では、UI の実装、テスト、パフォーマンス最適化、およびアナリティクス統合について 3 人が詳しく語っています。

前回の続きから始めましょう。コーディングなしでユーザーインターフェースを実装するためのベストプラクティスとしては、どのようなことがあるでしょうか？

Benoit Dupuis：Unity UI を使用する場合は、インターフェースの要素を有効化したり無効化したりするのに Unity イベントを使用することで、機能的なワイヤーフレームのプロトタイプ作成を簡素化することができます。これらは、ボタンやトグルなど、特定のインタラクティブ UI 要素を使って Inspector に公開されます。例えば、ゲームオブジェクトを Unity イベントに追加すれば、ボタンがクリックされたときにトリガーするアクションを選択することができます。

この例は、ゲームオブジェクトを有効にするナビゲーションフローをシミュレートしたものです。OnClick イベントは、SetActive(true) を呼び出すことで NewPopUp というゲームオブジェクトを有効にし、その後、PopUp ゲームオブジェクトを無効にします。

以下にその他のヒントをいくつか挙げます。

• Unity イベントまたは UI ツールキットを使用して Unity UI からトリガーできるゲームプレイ機能は、ビジュアルスクリプティングによってコードを書かずに作成することもできます。
• UI Builder は、UI Toolkit を使用して UI を実装するために使用できます。通常、UI Toolkit の UI 要素をコードに接続する作業は開発者が担当します。UI Builder は、インターフェース全体を視覚的に作成できるビジュアルオーサリングツールです。このワークフローの強みは、デザイナーとプログラマーが別々に作業するという点にあります。両者の連携は、双方が共通の命名規則に従って（例えば、メインプレイボタンなどの）名前を付けることで可能になります。

上記は UI Builder の画面で、その下がコードです。要素の階層構造である Visual Element Tree はコードでスキャンされ、その後、インタラクションを必要とする要素が登録されます。たとえば、プレイボタンは変数に保存されます。ボタンが押されたときには、コールバックを待機させることができます。デザイナーとプログラマーが必要とする情報は、ボタンがどのように呼び出されたかということだけです。

• ビジュアル要素やスタイルシートの命名規則には、Block Element Modifier（BEM）を使用することをお勧めします。要素の名前に BEM スタイルを使えば、要素の役割、出現場所、および周りの他の要素との関係性が一目でわかります。

  BEM による命名の例：

  menu__home-button
  menu__shop-button
  menu__shop-button--small
  button-label
  Button-label--selected

さまざまな UI 変更を統合し、テストするには、コードベースをどのように構築するのが良いのでしょうか？

Aleksander：ビューコンポーネントからロジックを分離することが重要です。UI 変更について事前に計画を立てるのは困難です。ただし重要なのは、UI ビューではロジックの変更を行わないようにするということです。ビューでは、値を直接受け取るか、値を観察してイベントを受け取りながら、何が送られているのかを表示するだけに留めるべきです。その場合、必要に応じて単にレンダリングロジックを置き換えれば対応できます。たとえ UI システム全体が変更された場合でもです。

UI のテストフェーズには、通常誰が参加していますか？

Aleksander：UI のテストには、複数のアプローチを採用しています。そのうちの 1 つは、ターゲットユーザーにゲームをプレイしてもらう、「ユーザーテスト」です。私たちは彼らの行動を観察してメモを取り、必要に応じて UI を調整しています。

私たちが採用しているもう 1 つのアプローチは「内部テスト」です。これは、弊社の従業員がゲームをテストし、遭遇した問題を報告するというものです。従業員は UI に対する期待値がきわめて高いですし、関連する経験も豊富なので、多くの場合、非常に有用なフィードバックを得ることができます。

折りたたみ可能なデバイスを所有していない人は、どのように UI をテストしているのですか？

Søren：Samsung では、Remote Test Lab を提供しています。そこで多数の物理デバイスをセットアップしているので、Samsung アカウントを持っている人なら、デバイスを選択し、タイムスロットを予約することができます。このシステムでは、APK ファイルをアップロードして、さまざまな物理デバイスでテストを行うことができます。

モバイル UI にとって、最大のパフォーマンス低下要因は何ですか？

Aleksander：モバイル UI において特にパフォーマンスを低下させる要因は、オーバードロー、動的な要素がある場合の頻繁なキャンバス再構築、多数の要素がある場合のキャンバスの再構築時間、そしてテキストメッシュの生成です。私たちのゲームプロジェクトでは幅広いデバイスをサポートする必要があるので、これらの要因について注意を払っています。

Søren：非常に大きなラスターグラフィックスを使用すると、UI が遅くなる場合があります。ですので、使用するグラフィックスがデバイスの許容メモリ容量に適合していることを確認するのが重要です。また、3D グラフィックスを UI にリアルタイムでレンダリングすると、パフォーマンスが著しく低下する場合があります。ミニマップやキャラクターインベントリシステムなどがこれに該当します。

UI を最適化するうえで特に役立つヒントは何かありますか？

Aleksander：UI 要素を複数のキャンバス（または子キャンバス）にグループ化して、キャンバスの再構築が増えすぎないないようにすることです。要素が変更されると、そのたびにキャンバス全体の構成が変わって再構築が必要になります。これは非常に高コストになる可能性があるので、動的要素を専用のキャンバスに置いたり、専用キャンバスを増やしたりした方が合理的です。

レイアウトグループは可能な限り避けましょう。特に、ネストされているとキャンバスが散らかります。静的な項目がある場合は、事前に計算された位置とサイズを指定するのが良いでしょう。

非インタラクタブルの UI 要素では、Graphic Raycaster とレイキャストターゲットを無効にしましょう。Graphic Raycaster では、タッチが UI コンポーネント内かどうかの判断が試行されますが、これが高コストになる可能性があります。

同様に、全画面の UI（ダイアログなど）を表示しているときには、バックグラウンドカメラを無効にしましょう。これにより、隠れているカメラの余分なレンダリングコストを回避できます。

テクスチャアトラスは有効ですが、異なるアトラス間でのスプライトの分散方法を考慮し、必要に応じて適切なアトラスをロードして、メモリ消費量を減らすようにしましょう。

最後に、最も重要なヒントは、実際にデバイスでゲームをプロファイリングして、何を修正する必要があるかを決定するということです。リストに挙げられた最適化項目をやみくもに実行していくのは良くありません。

Benoit：Unity UI では、各要素が静的なのか、それとも更新が必要なのかに基づいて、要素を複数のキャンバスに分けることが一般的に推奨されています。各キャンバスでは、更新時にすべての子要素がリフレッシュされるので、実際にリフレッシュが必要な要素のみにこれを行うのが良いかもしれません。

また、透明なピクセルが重ならないようにし、UI 要素の外観をできるだけ平坦化することでメリットが得られる場合もあります。実行時に生成される UI 要素については、スプライト画像を作成することで要素の数を減らすことができるかもしれません。例えば、画面上の 1 桁の数字のビジュアルインジケーターや、事前定義された絵文字のセットなど、平らな画像になる可能性のあるものがその対象です。詳細については、UI パフォーマンスに関する章がある、こちらの e ブックを参照してください。

UI は、Samsung デバイスでのモバイルゲームのパフォーマンスにどのような影響を与えていますか？

Søren：現時点では、UI に起因するパフォーマンスへの大きな影響は発生していません。ただし、絶対に起こらないとは言えません。特にデザインが複雑になった場合や、ミニマップなどの UI コンポーネントが注意深く実装されなかった場合には、影響が出る可能性も考えられます。

UI デザインに関して、Adaptive Performance がもたらすメリットはありますか？

Søren：UI デザインに Adaptive Performance を利用することは可能ですが、2D ラスターグラフィックスについては、使いすぎると表示がぼやけたり、望ましくない結果になることが多いので注意が必要です。Adaptive Performance は、3D ジオメトリを即断で UI レイヤーにレンダリングするような場合の方が、より適しているかもしれません。

リソース管理とランタイム最適化の観点から見た場合、各パネルに対して大きな固有のアートアセットを作成するのと、小さなパーツのライブラリを作成し、それらを組み立ててレイヤー化できるようにするのとでは、どちらが良いのでしょうか？

Aleksander：ユースケースによります。パフォーマンス的には、大きなアートアセットを使用する方がメリットがあるかもしれませんが、一般的には、小さな UI パーツのライブラリを使用する方が安全です。モバイルアプリでは、アプリサイズに制限があるので、可能な限り 9 スライススケーリングを使用するようにしています。

プロジェクトを開始する際には、UI 要素のプレハブライブラリを作成すると非常に有益です。最初は少し時間がかかりますが、一度作成すれば、コンポーネントをすばやく再利用して、UI をスピーディに構築できます。重要なのは、ゲーム全体でアートスタイルに一貫性を持たせることです。

Benoit：Unity UI を使用しているゲームが高度に定型化されている場合は、ヒーローポップアップメニュー用の画像を用意することで、実行時のパフォーマンスを改善できるかもしれません。ただし、テクスチャのサイズに関しては、Sprite エディターのスライス機能を使用したり、可能な限り子 UI オブジェクトの数を減らすことをお勧めします。

テキストの自動サイズ調整の管理については、ローカライゼーションを考慮したうえで、どのように進めていますか？

Aleksander：自動サイズ調整を管理する最善の方法は、できるだけ使わないで済むようにすることです。画面内の領域に余裕があれば、必要なすべてのローカライズに対応できるようにテキストエリアを拡張するのも良いでしょうし、テキストが動的でないのであれば、異なる言語用のプリセットを準備するのも良いでしょう。自動サイズ調整を使用する場合、必要ないのであれば、テキストをフレームごとに更新しないようにしましょう。いずれにしても、追加されたすべてのテキストについて、それらが画面にフィットするかどうかをテストするようにしましょう。 

デザインの効果を検証するために、UI ワークフローにアナリティクス機能を統合していますか？

Aleksander：弊社では、UI を含め、ゲームのあらゆる側面をカバーする独自のアナリティクスワークフローを使用しています。どの UI 要素がクリックされたか、あるいは無視されたかを測定し、そのデータに基づいて決定を下すようにしています。

主に焦点を当てているのは、動画リワード広告の位置や、アプリ内課金（IAP）のオファーなど、主要なパフォーマンス指標（KPI）に密接に関連する UI 要素です。また、プレイヤーの行動についてさらなる知見を得るために、画面上のヒートマップの可視化も試みています。

モバイルデザイナーやモバイル開発者にとって重要なポイントは、UI のテスト、パフォーマンス最適化、およびデータアナリティクスにおいて、万能の戦略は存在しないということです。状況はケースごとに異なるので、ゲームを最善のパフォーマンスでリリースするには、これらのベストプラクティスを心に留めておくことが重要です。

もっと知りたい方にはUnity でのユーザーインターフェースのデザインと実装に関する Unity の新しい e ブックをご覧ください。また、Made with Unity フォーラムにて成功を収めるためのヒントを他のユーザーと共有してください。