Unityでゲームを作っていると、必ずといっていいほど「セーブ機能」の壁にぶつかりますよね。PlayerPrefs、JSON、ScriptableObject、Easy Save…調べれば調べるほど方法が出てきて、結局どれを選べばいいのか迷ってしまう方も多いのではないでしょうか。
とりあえず手軽そうな方法で実装してみたものの、あとから「思っていたデータが保存できない」「作り直しが必要になった」と困った経験がある方もいるかもしれません。
この記事では、Unityで使われる代表的なセーブ方法を、保存したいデータの種類ごとにどう使い分ければいいのか整理して解説していきます。読み終わる頃には、今つくっているゲームにどの方法が合っているか、自分で判断できるようになっているはずです。
Unityのセーブ、何を使うべき？
結論からお伝えすると、「これさえ使えば安心」という万能なセーブ方法は存在しません。大切なのは、保存したいデータの種類に合わせて方法を選ぶという考え方です。
たとえば音量設定のような軽いデータと、プレイヤーの所持アイテム一覧のような複雑なデータでは、そもそも向いている保存方法が違います。同じ感覚でひとつの方法にすべて詰め込もうとすると、あとから管理が難しくなってしまうことも少なくありません。
まずは、どんなデータにどの方法が向いているのか、大まかな目安を見てみましょう。
| 保存したいデータの例 | 向いている方法 |
|---|---|
| 音量・画質・ハイスコアなどのシステム設定 | PlayerPrefs |
| レベル・所持金・クエスト進行などのプレイ状況 | JSON |
| 武器の攻撃力・アイテムの性能などのマスターデータ | ScriptableObject（※セーブそのものには不向き） |
| 大量データや複雑な構造を、実装工数をかけずに保存したい場合 | Easy Save |
ここで「あれ、ScriptableObjectはセーブに使えないの?」と気になった方もいるかもしれませんね。この点は誤解しやすいポイントなので、後ほどの見出しでしっかり解説します。
まずは自分のゲームでどんなデータを保存したいのか思い浮かべながら、次の見出しからそれぞれの方法を詳しく見ていきましょう。
PlayerPrefsが向いているデータとは
PlayerPrefsは、Unityにあらかじめ用意されている一番手軽なデータ保存の仕組みです。「キー」と「値」のペアを指定するだけで、数行のコードで保存・読み込みができます。難しい設定がいらないぶん、まずはここから覚える方が多い方法です。
PlayerPrefsに向くデータの具体例
PlayerPrefsが力を発揮するのは、変化がシンプルで数が少ないデータです。具体的には、次のようなものが向いています。
- BGMや効果音の音量設定
- 画面解像度・フルスクリーンのオンオフ
- そのままの数値で管理できるハイスコア
- チュートリアルを表示済みかどうかのフラグ
どれも「ゲームを再起動しても覚えておいてほしいけれど、構造は単純」という共通点がありますね。逆に言えば、この条件から外れるデータは別の方法を検討したほうがよいサインです。
ワンポイント
PlayerPrefsの保存先はプラットフォームによって少し違います。Windowsではレジストリ、Android・iOSでは端末内のアプリ専用領域、WebGLではブラウザのローカルストレージに保存される仕組みです。仕組みを意識しなくても使えますが、頭の片隅に入れておくと安心です。
実際にPlayerPrefsを使ってハイスコアを保存・リセットする具体的な手順は、以下の記事でくわしく解説しています。あわせて参考にしてみてください。
PlayerPrefsを使ってはいけないデータ
「PlayerPrefsは何でも保存できる」と思われがちですが、実はそうではありません。保存できる型は整数(int)・小数(float)・文字列(string)の3種類だけと決まっています。
そのため、次のようなデータはPlayerPrefsだけでは扱いきれません。
- アイテムのリストやインベントリのような配列・リスト構造
- 複数の項目をまとめたクラスや構造体
- キーと値の組み合わせが大量にある辞書(Dictionary)型のデータ
こうしたデータを無理にPlayerPrefsへ詰め込もうとすると、キーの数だけがどんどん増えてしまい、あとで管理しきれなくなります。構造を持つデータは、次の見出しで紹介するJSONのほうが向いています。
PlayerPrefsに保存したデータは暗号化されず、そのままの状態で端末に残ります。オンラインランキングや課金フラグなど、書き換えられると困る情報を保存するのは避けましょう。
JSONが向いているデータとは
PlayerPrefsでは対応できない、構造を持ったデータを保存したいときに活躍するのがJSONです。オブジェクトや配列をまとめてテキストに変換できるので、プレイヤーの進行状況のように項目が多いデータをひとつにまとめて扱えます。
JSONに向くデータの具体例
JSONが得意なのは、いくつもの情報をひとかたまりとして保存したい場面です。たとえば、次のようなデータが当てはまります。
- プレイヤーのレベルや経験値
- 所持金やクリア済みステージの一覧
- インベントリに入っているアイテムのリスト
これらはひとつの「プレイヤーデータ」としてまとめて考えられるものばかりですよね。UnityではC#のクラスに[System.Serializable]という属性をつけることで、こうしたデータをそのままJSON形式の文字列に変換できます。項目が増えても、クラスに変数を追加するだけで対応できるのも扱いやすいポイントです。
JSON利用時の注意点
「JSONで保存すれば安心」と思われることもありますが、実はセキュリティ面では弱点があります。JSONはただのテキストファイルなので、パソコンのメモ帳のようなソフトで開けば、誰でも中身を読んだり書き換えたりできてしまうのです。
ハイスコアやアイテムの所持数など、書き換えられると困るデータを扱う場合は、暗号化などの改ざん対策を別途用意する必要があります。オフラインで完結する個人開発のゲームであれば、対策を省略しても大きな問題にならないケースもありますが、対戦要素やランキングがあるゲームでは注意が必要です。
もうひとつ意識しておきたいのが、ゲームをアップデートしたときの対応です。開発の途中でセーブするデータの項目を増やすと、以前のバージョンで作られた古いセーブデータを読み込めなくなることがあります。この点をあらかじめ設計に組み込んでおく方法は、以下の記事で詳しく解説しているので参考にしてみてください。
Unity標準のJsonUtilityは、辞書(Dictionary)型やprivateな変数をそのままJSONに変換できません。こうしたデータを扱いたい場合は、保存できる形に変換してから使う必要があります。
ScriptableObjectをセーブに使ってはいけない理由
「エディタ上でScriptableObjectの値を書き換えたら、そのまま保存されているように見えた」という経験がある方もいるのではないでしょうか。実はこれ、初心者がとても引っかかりやすい落とし穴なんです。結論からいうと、ScriptableObjectはプレイヤーのセーブデータとして使ってはいけません。
エディタとビルドで挙動が変わる仕組み
ScriptableObjectは、Unityエディタ内でデータを定義してアセットとして保存できる、Unity独自の仕組みです。エディタを再生した状態(Playモード)で値を変更すると、たしかにその変更が保持されているように見えます。
しかし、これはエディタだけで起こる特別な挙動です。ゲームを実際にビルドして製品版として動かすと、ScriptableObjectは書き換えのできない読み取り専用のデータとして扱われます。ゲーム中にプレイヤーが経験値を稼いでも、アプリを再起動すれば元の数値に戻ってしまうということですね。
この仕組みを知らずに「セーブ機能が動いた」と勘違いしたままリリースしてしまうと、プレイヤーの進行状況がまったく保存されないという大きな不具合につながります。
ScriptableObjectの正しい使い道
では、ScriptableObjectはどう使えばいいのでしょうか。向いているのは、プレイヤーの操作では変化しない「設計図」のようなデータです。
- 武器やアイテムの攻撃力・価格などの初期設定
- 敵キャラクターのステータス
- ゲームバランスを調整するためのパラメータ
こうした静的なデータをScriptableObjectで管理し、プレイヤーの進行状況はJSONなど別の方法で保存する、という役割分担が基本になります。ScriptableObjectを使ったデータ管理の考え方は、以下の記事でより詳しく解説しています。
Easy Save導入を検討すべき基準
ここまでPlayerPrefsとJSONを紹介してきましたが、どちらも無料で使えるぶん、複雑なデータを扱おうとすると自分でコードを書く手間が増えていきます。その手間を大きく減らしてくれるのが、Asset Storeで販売されている有料アセット「Easy Save」です。購入すべきかどうか、判断の目安を見ていきましょう。
Easy Saveが向いているケース
Easy Saveは、Dictionary型やGameObject、Textureといった複雑なデータでも、わずか数行のコードで保存・読み込みができるのが強みです。次のような状況に当てはまる場合は、導入を検討する価値があります。
- アイテムの種類が多いRPGなど、保存するデータ構造が複雑になりそうな場合
- セーブデータの暗号化を、自分で実装せずに済ませたい場合
- 複数のセーブスロット(冒険の書のような機能)を作りたい場合
- リリースまでのスケジュールが厳しく、セーブ処理にかける時間を最小限にしたい場合
特に暗号化については、Easy SaveならAES暗号化の設定をエディタ上のメニューから選ぶだけで完了します。自分で暗号化のコードを書く必要がないのは、初心者にとって大きな安心材料になりますね。
無料手法だけで十分なケース
ここで気をつけたいのが、「Easy Saveを買えば設計を考えなくてよくなる」という誤解です。Easy Saveはあくまで保存・読み込みの手間を減らしてくれる道具であり、どのデータを動的なプレイヤーデータとして扱い、どのデータを静的なマスターデータとして扱うか、という設計の考え方自体は変わりません。
そのため、保存したいデータがシンプルで、複数スロットや暗号化といった機能も特に必要ないという場合は、無理にEasy Saveを導入しなくてもPlayerPrefsとJSONの組み合わせだけで十分対応できます。
個人開発の小規模なゲームであれば、まずは無料の方法から試してみて、必要になったタイミングで導入を検討するという流れでも遅くありません。
ゲーム規模別のおすすめ組み合わせ
ここまで4つの方法の特徴を見てきましたが、実際のゲーム開発ではひとつの方法だけで完結することはほとんどありません。多くの場合、複数の方法を組み合わせて使うことになります。ここでは、開発するゲームの規模に合わせた組み合わせの目安を紹介します。
小規模ゲームの組み合わせ
個人開発やカジュアルゲームのような小規模なプロジェクトであれば、Unity標準の機能だけで十分まかなえます。具体的には、次のような役割分担です。
- 音量設定やハイスコアなどの軽いデータ → PlayerPrefs
- プレイヤーの進行状況をまとめたデータ → JSON
- ステージ構成や敵の配置など変化しない設定 → ScriptableObject
すべて無料の標準機能だけで構築できるので、追加のコストがかからないのが魅力です。セーブ機能の基礎を学びながら実装したいという方にも、まずはこの組み合わせから試してみることをおすすめします。
中〜大規模ゲームの組み合わせ
RPGやシミュレーションのように、保存するデータの量や種類が増えてくるプロジェクトでは、「プレイヤーデータ」と「マスターデータ」を分けて考えることが設計の軸になります。
プレイヤーのレベルや所持金、クエストの進行状況といった動的なデータはJSON、あるいは複雑な構造を扱いやすいEasy Saveで保存します。一方、武器の攻撃力やアイテムの名称といった静的なデータはScriptableObjectで管理する、という分担です。
この分担ができていると、「武器の攻撃力を調整したい」といった変更があっても、マスターデータのアセットを直すだけで済み、プレイヤーのセーブファイルには一切手を加えずに対応できます。あとから複数のセーブスロットを用意したいという場合は、以下の記事で実装の流れを解説しているので参考にしてみてください。
まとめ
Unityのセーブ方法選びで大切なのは、「どれが一番優れているか」を探すことではなく、保存したいデータの役割に合わせて方法を使い分けることです。システム設定はPlayerPrefs、進行状況はJSON、変化しない設定はScriptableObject、複雑なデータや工数の削減はEasy Saveというように、それぞれの得意分野を思い出しながら選んでみてください。
まずは今つくっているゲームで、どんなデータをどのタイミングで保存したいのか書き出してみましょう。それだけで、自分に合った組み合わせが自然と見えてくるはずです。
よくある質問
-
QPlayerPrefsとJSONは併用してもいいですか?
-
Aはい、併用が一般的です。音量設定などの軽いデータはPlayerPrefs、プレイヤーの進行状況などの構造をもつデータはJSONというように、データの性質ごとに使い分けて問題ありません。1つの方法にすべてを詰め込む必要はなく、役割ごとに分けて考えるのが基本の考え方です。
-
Qセーブデータの暗号化はEasy Saveなしでもできますか?
-
AC#の標準機能を使って自分で暗号化のコードを書けば、Easy Saveがなくても対応は可能です。ただし、暗号化の実装やエラー対応には手間がかかるため、開発にかけられる時間が限られている場合は、設定だけで暗号化できるEasy Saveのようなアセットを検討したほうが効率的なこともあります。
-
Q保存方法はあとから変更・移行できますか?
-
A方法自体を変更することは可能ですが、すでに配布したセーブデータがある場合は、古いデータを新しい形式に変換する処理を別途用意する必要があります。開発の初期段階でデータの役割分担を決めておくと、あとからの変更による手戻りを減らしやすくなります。
※当サイトはアフィリエイト広告を利用しています。リンクを経由して商品を購入された場合、当サイトに報酬が発生することがあります。
※本記事に記載しているAmazon商品情報（価格、在庫状況、割引、配送条件など）は、執筆時点のAmazon.co.jp上の情報に基づいています。
最新の価格・在庫・配送条件などの詳細は、Amazonの商品ページをご確認ください。