スマホゲームUIの正しい作り方【実装編】

ゲームアプリUIの基本的なデザインルールを前回ご紹介しましたが　「スマホゲームUIの正しい作り方【デザイン編】」
今回は実装においてデザイナーがやるべき賢い構造化の方法をご紹介します。
デザイン時に実装のことを踏まえた設計やデータ構造を作っておかなければ運用時に苦労することになります。
ゲームアプリのUI周りを実装するうえで、のちの運用のために予め決めておくと良いことをまとめます。

もくじ

• ディレクトリ構造は先に決めておく
• 画像圧縮の方法を決めておく
• どこを組み込むか、どこを外部参照にするか決めておく
• spriteにするかsliceにするか決めておく

ディレクトリ構造は先に決めておく

自分たちのデザインした画像データがどこにあるのか？デザインを調整するためにはどこをどう編集すればいいのか？
エンジニアさんはデザイナーのことを考えてシステム設計するわけではないので、デザイナー側から介入しなければ、エンジニア以外触れない難解なつくりになってしまいます。
特に長期運用を見越したSGの場合は運用が長引くほど構造が複雑化し、リソースも肥大化していくので、開発段階でエンジニアと連携しながらどんな構造にしていくかをきちんと話し合っておくことが大変重要です。

最低限決めておきたい項目

• ●UI周りの画像ファイルの管理場所～Atlesの管理場所
• ●画面データ(secene)やコンポーネント(prefab)の管理場所
• ●追加DL系(運用追加分)ファイルのアップ場所(AssetBundle)
• ●アプリに組み込まない外部参照ファイルの管理場所(アニメファイルや背景、3D、サウンド等)

---

UI周りの画像ファイルの管理場所(sprites,Atlas)

まずUIデザイナーが一番に考えなければいけないのが、UI画像ファイルの保管場所です。
ここをエンジニアに丸投げしてしまうと、画面を実装する時にどこから画像を呼び出しているのか解らなくなってしまうので非常に面倒です。最低限決めておきたい重要事項です。

unityの場合まずは
sprite群をどこに格納するか？
そしてそれらのspriteから生成するAtlasがどこに格納されるのか？
この二つはきちんと把握しておきましょう。

プロジェクトによってはAtlas化をビルドの段階で自動生成してしまうプロジェクトもあるかと思いますが、Atlasの中身はデザイナーが把握しておいた方が何かと都合がいいです。

理由は
■Atlasを自動生成させてしまうと、どこの画面で何のspriteを使用しているかわからなくなる。 同じspriteを違う画面で使ったり、共通パーツを使いまわしたりするとAtalas内に同じ画像が複数登録されるので、画像サイズが肥大化します。

■Atlasが何枚あってファイルサイズをいくら圧迫しているかわかるので、アプリサイズの見える化が出来る。 →アプリサイズが肥大化してきたとき、どのAtlasを節約すればいいか任意に調整できます。

可能ならAtlasも管理できる体制を作っておくことをお勧めします。
Atlas化した状態で組み込んでしまえば、極端な話spriteが不要になります。プロジェクトから大量の画像データを削減できます。

---

画面データ(secene)やコンポーネント(prefab)の管理場所

画面データ(scene)やコンポーネント化したパーツ類(prefab)はデザイナーも編集することが多いので、管理場所をエンジニアと相談してきちんと把握しておくことが重要です。

どこの画面でなんのprefabを読み込んでいるのか、prefabがどこのsceneで使用されているのか、どうやって動いているのかさえ分からなくなると修正や改造がそもそも不可能になります。
また、こういった管理は属人化するケースが多いので、担当者が異動や退職でいなくなってしまうと誰も触れなくなってしまいます。

システムの構造設計はエンジニアマターですが、デザイナーでも理解できる構造にしておくことで、後の作業がスムーズに行えるようになるので、リスト化するなどしてきちんと管理しましょう。

---

追加DL系(運用追加分)ファイルのアップ場所(AssetBundle)

運用が長引くと画像や追加データがどんどん肥大化していきます。
これらの追加データは通常アプリ内に組み込まれるものではなく、追加DL等で随時取得されるのが一般的なので、それらのファイル群をどこに格納し、どうやって運用していくのか？という構造設計が非常に重要になってきます。 Asset内のデータをイベントごとに区切っているバカなプロジェクトに遭遇したことがあります。
追加されたキャラやアイテムのデータがイベントフォルダに分散しているので、目的のキャラデータがどこにあるのか誰も把握できませんでした。ありえない運用方法ですね。

---

アプリに組み込まない外部参照ファイルの管理場所(アニメファイルや背景、3D、サウンド等)

ゲーム開始時に最低限必要なデータでも、運用データと同じように外部参照させておくファイルなどもあります。
UIやゲームの基本機能に紐づくデータ群はあらかじめアプリデータに組み込むものですが、キャラクターのモデルやサウンド、背景等のマップデータはアプリ内に組み込まず、追加DLで後から読み込ませるのが一般的です。
ゲーム開始時に使用するキャラだからとアプリのデータ内に組み入れてしまうと、後に追加したキャラやデータと管理する場所が変わってしまうので、管理場所が2重になって複雑になります。
アプリデータには必要最低限のものだけで十分です
3Dモデルや背景、キャラのデータ等はバナーなどキャンペーン関連のデザイン素材の作成にもよく使用するので、管理場所は分けておくと便利な場合が多いです。

データ構造やリソースの管理は基本エンジニアマターですが、丸投げしてしまうとブラックボックス化してしまい、デザイナーが触れない状況に陥ることが結構多いので、デザイナー側から積極的に働きかけてデザイナーでも触れる構造づくりをきちんとしておきましょう。

画像圧縮の方法を決めておく

高解像度の端末が増えた現在、グラフィックのクオリティがゲームのクオリティを左右するといっても過言ではありません。
画像をいかにキレイに出力するかというのがデザイナーにとって一番気にかかる部分になってくると思いますが、システム的に「動いていればそれでいい」というエンジニアも多いので、
画像の圧縮技術に関してはグラフィックに関心を持つエンジニアさんでもいない限りはデザイナーが主導してグラフィッククオリティを担保するのがマストになってきます。

unityで画像を綺麗に出力する方法は以下の記事でご紹介↓ 「unityで画像を綺麗に表示させたい」

どこを組み込むか、どこを外部参照にするか決めておく

前項で触れた「追加DL系(運用追加分)ファイルのアップ場所」に関係する内容です。
UIの中には固定化されるパーツと、状況に応じて表示が変わるシステム的に読み込まれるパーツの2種類があります。
そしてこの二つは管理場所を明確に分ける必要があります。
システム的に読み込むような画像はAtlasに組み込んでしまうと、毎回余計な画像まで一緒に読み込むことになるので、端末に負担をかけます。
使いどころは見極めましょう。

運用中に絶対に変わらないUIパーツ【ボタンやヘッダ・フッタなどの固定オブジェクト等】はAtlas化、運用中に変更、追加、削除が見込まれるもの【アイテムやキャラのアイコン、状況に応じて可変する表示物等】はAssetBundle化などが考えられます。

属性アイコンなどはシステム的に読み込むデータですが、運用中に変わることのない固定化されたデータでもあります。
AssetBundle化するか共通Atlasに組み込むか、もしくは通常のAtlasとは別管理にするなど、のちの運用を考えてどうやって管理するのが扱いやすいか考えておきましょう。
個人的にはCommonAtlasに入れちゃっていいともいます。(サイズがそれほど大きくなく、数も少なければですが)
CommonパーツならすでにUI上で読み込んでいるはずなので、Atlas内にアイコンをマージしてしまっても問題ないということです。

デザインの段階でAtlasに組み込むものと、AssetBundle化するものとを差別化してデザインを作りましょう。

spriteにするかsliceにするか決めておく

なんでもかんでもAtlasに組み込んでしまうとAtlasの肥大化を招きます。
ゲームアプリ開発でのデザインのポイントは”いかに画像を使わずにデザインするか”です。
unityには画像の一部分を繰り返したり引き延ばしたりする”slice”という機能があります。
画像をそのまま組み込むのではなく、sliceなどを駆使して、出来るだけAtlasサイズを抑えるのがとても重要です。

画像のデータは量が多いほどアプリサイズを圧迫し、読み込み点数やサイズが大きいとメモリを圧迫します。
端末に負担をかけずにリッチな画面を構築する工夫をしましょう。 「Atlasを小さくするテクニック」

---

さいごに

ゲームアプリを作るうえでUIUXデザイナー(TA・フロントエンド)は運用を見越したデータ構造を作りこんでおくのが必須になります。
プロジェクトの構造設計はエンジニアマターの作業ですが、彼らはデザイナーが管理しやすい構造など考えてはくれないので、
デザイナーから積極的に働きかけてデザイナーでも触れる構造設計をエンジニアと連携しながら作り上げましょう。
「解らないから」といって丸投げしてしまうのは絶対にＮＧです。