Unityのデータ保存周り
はじめに
Unity以前に基本的に運営していく上で、
ストレージ, DB, CDNを抑えておけばデータ保存は概ね問題ないことを前提に話を進めます。
ScriptableObject, Addressable等も理解していること前提で話しています。
もくじ
- ストレージ管理
- DB管理
- CDN管理
1. ストレージ管理
ローカル保存の場合(PlayerPrefs, Application.dataPah等へ保存)
基本的にはゲーム中の設定情報、ゲームジャム的な取り敢えずアプリ消されるまででいい的なタイムスケジュール感で消えても困らない情報、見られても良いようなセキュリティレベルの低い情報を保存する。
他暗号化,OS機能, キャッシュ用パス等で多少要望を満たせる可能性はあるが、セキュリティ性をあげるのであればサーバーに上げるのが早い。
サーバー保存の場合(AWS,Azure,GCP,他Firebase,UnityGamingServicesストレージへ保存)
１，生データ等に変換する
２，UnityWebRequest(HTTP)送信をしてサーバへPOSTする
３，サーバー側で受け取った情報をストレージへ保存する
→ UnitySDKが提供されていればそちらを使用する方が良い可能性が高い
2. DB管理
◆サーバー側で値を更新しないDBの場合
Unityの場合はScriptableObjectという専用DBインスタンスが存在するので、こちらを使うことで楽にDBを作成できます。ただしScriptableObjectは当然Unity専用クラスのためサーバー側で変更をすることができません。
なので、基本的にはUnity独自のPrefab、モデル、音、画像、全シーンで共通で管理したい値等がメインの管理対象かと思います。
→ こちらはDBというよりはCDNに近いかもしれません。
◆サーバー側で値を変更するDBの場合
基本的にはサーバーにDBを作成して、PHP等を用意してHTTPから呼び出す形がメインとなるかと思います。
他Json等で保存しDBへアップロードする等の方法もあります。
3. CDN管理
Unity側からはHTTPリクエストで取得するだけなので、テスト中はS3ストレージ配置でも問題ありません。
ローカル保存の場合(AddressableSystems(UseAssetDataBase)読み込み)
特に理由がなければAddressableを使用することでローカル運用も問題ありません。
サーバー保存の場合(AddressableSystems(UseExitstingBuilding)読み込み)
ビルドしたAssetBundle, Catalog, Hashファイルをサーバーへアップロードして読み込みます。
Discussion