【Unity】開発前に確認・理解しておきたい10項目
先月、Android向けスマホアプリとして「突撃！ヨーコ道場」をリリースしました（ぜひ遊んでもらえると嬉しいです！）。
それにあたって事前に知っておきたかったこと、開発途中でわかって苦労したことなど含め、Unityで開発前に確認・理解しておきたい10項目を整理してみました。
ぜひご自身の開発と照らし合わせて確認してみてください。
なお、記事内でよそ様の記事・ツイートをいくつか紹介しています。この場を借りて御礼申し上げます。
非常に助かりました、ありがとうございました！
FPSはいくつにするか決めてる？
そもそもFPSって何？
FPS（Frame Per Seconds）とは1秒に対してゲーム側がどのぐらいの処理を実行するか、という項目。
30fpsは1秒間に30回、60fpsなら1秒間に60回処理が行われます。この設定値によってUnityの画像描写やUpdate関数（毎フレーム毎に実行）の実行頻度も変わる訳です。
FPSが高いとどんなメリット・デメリットがある？
処理頻度が高ければ高いほど、細かくオブジェクトやアニメーションを動かすことができるので、全体の動きが非常に滑らかに感じられます。
一方で、処理負荷が高まるため、電池の消耗速度や発熱量が増加するなどの影響があります。
Unityのデフォルト設定値は？
UnityのデフォルトFPSは画面と同期、すなわちディスプレイのリフレッシュレートに応じて変動するものとなっています。ようはディスプレイが60fpsなら60fps、90fpsなら90fpsで動くという訳です。
高リフレッシュレート対応のディスプレイを使うとより滑らかに動くというのは、格闘ゲームのようにシビアな判断が求められるゲームでは非常に便利そうですね。
ただ人によってゲーム体験に大きな違いを出したくない場合、ゲームの処理負荷や通信量を抑えたい場合は固定FPSにするという選択もありです。
スマホ対応時は要注意！
「プロジェクト設定（Project Settings）」⇒「品質（Quality）」⇒「VSync数（VSyncCount）」の設定を確認してみると、初期値は「すべてのVブランク（Every V Sync）」、すなわち「画面と同期する」になっているかと思います。
ただし、AndroidやiOSビルドの場合はこんな注意書きもセットに出ているはず。
そう、Android・iOS・tvOSではこの設定は無視されます。
ではどんな値が設定されるかというと、実はモバイルの場合は30FPSが初期値として設定されます。
これは公式リファレンスにもきちんと記述されています。
このことを知らずにデフォルト設定のまま開発を進めてしまうと、PC（画面同期）ではぬるぬる動いていたのに実機テスト（30FPS）してみたらめっちゃカクカク！ なんてことになってしまうのでご注意下さい。
対処方法は？
公式リファレンスにもある通り、スクリプト側でApplication.targetFrameRateに値を設定することで、FPSを変更することができます。
ただし、下記記事によると、
30FPSでは10分で1
2%減る程度だったのに対し、60FPSでは10分で78%程度バッテリーを消費しました。
とのこと。
機種や利用年数にもよるとは思いますが、安易に高FPSにしてしまうとバッテリー消費量がぐっとあがるということはご理解いただけたかと思います。
上記記事内にもある通り、ぬるぬる動かしたいところは60FPSにしてそれ以外は30FPSにするなど、どうしても高FPSにしたい場合は影響を最小限に抑える工夫ができるといいですね。
UI最適化の方法を把握してる？
新しく作るよりも、一度作ったものを後から変更する方が圧倒的に大変でコストがかかります。
最低限、UIをどういう風に構築していくと処理負荷を抑えられたり、なるべくシンプルな構造にしたりできるだろうか、という点は事前に情報収集しておくとよいでしょう。
という訳で、こちらが参考資料です。
特に、
- Canvasは分けて管理しよう
- Canvasの表示・非表示はCanvasコンポーネント側で操作しよう
- UIオブジェクトのプール方法に注意しよう
は根本的な設計に関わる部分なので、事前に理解しておくことをオススメします。
PixcelsPerUnit（ユニット毎の参照ピクセル数）決めてる？
PixcelsPerUnit（略してPPU）は「ワールド空間座標の 1 単位分に相当する、スプライトのピクセル数」のことなのですが、言葉にすると何のこっちゃですね。
解説は下記がわかりやすかったので下記をご参照下さい。
これも最初にベースとなる値を決めておかないと、後から変更しようとしたら画面レイアウトがぐちゃぐちゃになって結局作り直すレベルになってしまう恐れがあります。
いくつかのメイン画像（キャラクターや背景など）を使って、事前に検証しておくとよいでしょう。
その他、参考記事。
セーフエリア対応やってる？
そもそもセーフエリアって何？
スマホは機種によってノッチ（だいたい画面上部にある出っ張りみたいなの）やパンチホールがあります。なので、画面いっぱいに情報を表示してしまうと、見切れてしまう文字や押し辛いボタンなどが出てきてしまう恐れがあるんですね。
そこで、ノッチやパンチホールなどに邪魔されない最大範囲をセーフエリアと呼び、画面サイズとは別に定義することにしました。
セーフエリア対応とは？
セーフエリア内であれば、どんな文字やボタンを表示しようと、機種側のデザインの問題で見切れたり押し辛いなどの問題が発生することはありません。
そこで、UIなどの視覚情報をセーフエリア内に収まるよう調整する対応のことを「セーフエリア対応」といいます。
具体的な対応方法は？
セーフエリアは機種毎に違うため、その機種に応じてスクリプトで制御する必要があります。
詳細は下記記事参照。
また、ヒエラルキー構造も要注意。
エリア外をクリックした時の挙動決めてる？
スマホゲームあるあるですが、メニューなどを開いた際にメニュー外のエリアをクリックした時はメニューが閉じるようになっていることが多いかと思います。
そういうある種のお約束をデザインとして踏襲するかどうかは事前に決めておくとよいでしょう。
後からそういう仕掛けを持ち込もうとすると結構苦労します（体験者談）。
プレハブ＆プレハブバリアント活用してる？
特定のオブジェクトを使い回したり、一部分だけ変更したりすることができるプレハブ。
Unityにおける大きなサポート機能ですね。
このプレハブは活用してるよ！ という人も多いかと思いますが、プレハブバリアントの方はどうでしょうか？
プレハブバリアントは、元となるプレハブを継承した新しいプレハブを作る機能です。
何だか複雑になりそうで面倒臭そうと思われるかもしれません。ですが、この機能を使うと特にUIで変更に強い構造にすることができます。
例えば、フォントサイズは同じだが文字色が異なるテキストオブジェクトを作成する場合。
＜プレハブのみ使用＞
プレハブ①：フォントサイズA-文字色白 プレハブ②：フォントサイズA-文字色黒
＜プレハブバリアントも活用した場合＞
プレハブ①：フォントサイズA プレハブバリアント①（プレハブ①継承）：文字色白 プレハブバリアント①（プレハブ①継承）：文字色黒
もしベースとなるフォントサイズを変更したいとなったら、プレハブのみ使用パターンでは2つのプレハブのフォントサイズを変更する必要があります。ですが、プレハブバリアントではベースとなるプレハブ①のフォントサイズを変更するだけで済むのです（プレハブバリアントはその値を継承しているため）。
＜プレハブのみ使用＞
プレハブ①：フォントサイズA-文字色白 ⇒ フォントサイズBに変更 プレハブ②：フォントサイズA-文字色黒 ⇒ フォントサイズBに変更
＜プレハブバリアントも活用した場合＞
プレハブ①：フォントサイズA ⇒ フォントサイズBに変更（一箇所修正でOK！） プレハブバリアント①（プレハブ①継承）：文字色白 プレハブバリアント①（プレハブ①継承）：文字色黒
プレハブバリアントを活用すると、変更を最小限に抑える開発を行うことができるようになります。積極的に活用していきましょう！
重い処理把握してる？
便利だからという理由で使っているコードが、実は公式・非公式問わず非推奨で有名だった、なんてことがままあります。
有名どころではGetComponent、Find、Destroyは処理が重いことで有名ですが、他にもちょっとした工夫で処理負荷を減らすことができるので、事前に色々調べておくとよいでしょう。
プライバシーポリシーをきちんと表明してる？
昨今、プレイヤーの情報を全く収集・活用しないゲームというのはほとんど存在しません。
例えばオンラインを活用した機能、TwitterやLineなどの外部アプリを利用したシェア機能、ユーザの活動内容を収集するアナリティクスなどなど。
これらの情報を収集する場合、必ず下記の対応が必要となります。
- プライバシーポリシーを明記したページの作成
- ゲーム内にプライバシーポリシーへのリンク設置
これをしておかないとせっかく登録したアプリが削除されてしまうことがあるようです。ご注意をば！
JSON Utilityの対応型を把握してる？
.NETに古くからあるJSON操作ライブラリに比べて、非常に軽量で有名なUnity独自のライブラリJSON Utility。
皆さんもUnityでセーブデータなどを取り扱う際はこのJSON Utilityを使っていることが多いのではないかと思います。
が、ただただ軽量で完全に上位互換という訳でもないのです。
特に注意してもらいたいのは下記の点。
- Dictionary型は対象外
- DateTime型は対象外
- List型をルートに使用するのは不可（何かのクラスのメンバー変数とかならOK）
他にも色々差異があるので、その他選択肢の候補も含めて、下記記事を一度確認しておくことをオススメします。
ビルド方法確認してる？
これは開発前というより主に開発後期以降に役立つ話になりますが、Unityのデフォルトのビルド設定（Mono）はビルド速度優先で、処理速度優先ではないです。
そのため、実機起動時に長いロード時間が発生することがあります。
ビルド方法を「IL2CPP」に変更することで劇的に改善されるので、「自分の処理の組み方がだめなのかな……」などと悩んでしまうことがないようにしておきましょう（iOSはデフォルトで「IL2CPP」）。
その上でそれでも処理が遅いのであれば、改善を検討してみてください。
手順は下記参照。
また、Google Playは2019年8月以降、64bit版のみ対象としています。64bit版は現状「IL2CPP」でしかできないので、Androidアプリとしてリリースする場合は最終的に必ず「IL2CPP」でビルドすることになります。
詳細は下記参照。
おまけ.バックキー対応してる？（Android限定）
Androidにはバックキーと呼ばれる、常に押すことができる共通・強制の「戻るボタン」があります。
違和感のないユーザ体験を提供するのであれば、「戻るボタン」を押しているのに何もゲーム内アクションが発生しないのは問題なので、このボタンを押下した際の挙動も事前に決めておくとよいでしょう。