【Unity】できれば「使わない方がいい」Unityの機能ワースト3

Unityを使っていると、ある機能についてよく調べたときに公式が「その機能は使うな」みたいなことを平気で言っていることがあります。個人的には機能を提供しておいてそれはねーだろ…と思うわけですが、Unityでは「あまり良くない機能だが、分かりやすいので初心者向けに一応残してある」というようなものが結構あるみたいです。

それで皆さんに馴染みのある機能の中にもそういう「できれば使わない方がいい」機能がいくつかあるので、ここでは特に使ってしまいがちな機能を3つ紹介して

なんで使わない方がいいのか
代わりにどうすればいいのか

といったことを書いていきますね。

※注意：
念のため書いておきますが、ここで取り上げる機能は「絶対に使うな」というわけではないので勘違いしないようにしてください。

Unityでなるべく使わない方がいい機能ワースト3
おわりに

Unityでなるべく使わない方がいい機能ワースト3

では早速ですが、Unityでなるべく使わない方がいい機能ワースト3を挙げると次の通りです。

PlayerPrefs
Resourcesフォルダ
DontDestroyOnLoad

それぞれ詳しく見ていきましょう。

第1位：PlayerPrefs

まず堂々の第1位は「PlayerPrefs」です。Unity初心者の方にとってはセーブといったらこの機能だと思いますが、正直これはダントツで使わない方がいいです。

PlayerPrefsを使わない方が良い理由

PlayerPrefsを使わない方が良い理由は次の4つが挙げられます。

Windows用ビルドの場合、保存先がレジストリだから（←最悪）
保存できるデータの型が限られているから
セーブデータの読み書きが遅いから
複数データを一括で処理できないから

まあ色々問題がありますが、何よりも1番目の仕様が気になります。なんでゲームデータをレジストリに保存するのさ…正直意味が分かりません。これがPlayerPrefsがクソ機能たるゆえんです。

PlayerPrefsを使わずに済むセーブ方法

代替案としては、セーブデータを外部ファイル（主にJSON形式）に書き出して保存する方法が有名です。

これについては以下の記事で詳しく説明していますので興味があればご覧ください。

【Unity】JSONを使ったセーブ・ロード処理の作り方

Unityでゲームを作っていると「セーブ・ロード処理」で悩んでしまうことがあります。なぜかというと、 Unity標準のセーブ・ロード機能である「PlayerPrefs」は問題だらけ（※後述）アセットを使うにもまともなアセットは高額一応ネ...

第2位：Resourcesフォルダ

さて、次に第2位は「Resourcesフォルダ」です。よくスクリプトからアセットにアクセスする場合に使われますが、これもできれば使わない方が賢明でしょう。

Resourcesフォルダを使わない方が良い理由

Resourcesフォルダを使わない方が良い理由については、公式リファレンスに次のような記載があります：

Resources フォルダーは、しばしば Unity プロジェクトで発生する各種問題の原因となる場所です。 Resources フォルダーの不適切な使用が原因で、プロジェクトのビルドサイズの膨張やメモリの極端な過剰使用が引き起こされ、アプリケーションの起動時間が著しく増加してしまうことがあります。

まあ要するに「Resourcesフォルダは簡単に使えるけど、下手に使うと危険」というわけですね。

Resourcesフォルダを使わない代替案

Resourcesフォルダの代替案はいくつかあると思いますが、一番簡単なのは

なるべくスクリプトからアセットをロードしようとせず、代わりに予めインスペクターから参照を登録しておく

ことに尽きると思います。

また、他には「Addressables」というUnityのリソース管理システムを使う方法もあります（こちらは完全にResourcesフォルダの代替案となる仕組みです）。Addressablesについては下記の記事で詳しく説明していますので、ご興味があればそちらも併せてご覧いただければと思います。