助言募集:セーブデータの軽量化

munokura

ユーザー
▼やりたい事
ゲームアツマールに投稿するのに、セーブデータが大きくなってしまっている。
これを軽くしたいと考えています。

▼状況
アクターの数が多く、これがデータを大きくしている原因と見ています。
アクターの半分は、データ表示用にしか使用していないため、これをセーブデータから外すことが出来ると、かなりの軽量化が見込めると考えています。
データ表示の他の良い方法があれば、それでアクターも減らせるとは思っています。
しかし、自分のスキルで実現できるもので、使い勝手が良いものを作るのはかなり難しいと感じています。

実例
各職業がレベルアップしたら、どのようなスキルを習得するのか見せる場面を作っています。

コード:
◆スクリプト://パーティメンバーの記憶
:     :$gameParty._lastActors = $gameParty._actors.clone();
◆スクリプト://パーティメンバーを全員外す
:     :$gameParty._actors = [];
:     :$gamePlayer.refresh();
:     :$gameMap.requestRefresh();
◆スクリプト:for (let i = 15; i < 29; i++) {
:     :  $gameParty.addActor(i);
:     :}
◆ステートの変更:パーティ全体, + 未来視
◆スクリプト:// アクターのスキル画面を開く
:     :const actor = $gameActors.actor(15);
:     :$gameParty.setMenuActor(actor);
:     :SceneManager.push(Scene_Skill);
◆スクリプト://パーティの復元
:     :$gameParty._actors = $gameParty._lastActors;
:     :$gamePlayer.refresh();
:     :$gameMap.requestRefresh();
付与しているステートは、アイコンなしの麻痺という感じで、スキルを順に選択してヘルプが見られるようにしています。
アクターID15から28はこのためだけに存在しています。

最初はアクター1人だけを選択して表示していたのですが、数が多いためこのように左右ボタンでめくっていけるほうが使用しやすいということで、この状態になっています。


▼MV時の対策
下記の2つのプラグインを使用して、かなり軽量化されました。
特にLightSaveDataの効果が大きかったです。

▼セーブデータ軽量化(トリアコンタン様作) - LightSaveData.js

▼セーブファイルの軽量化(terunon様作) - TN_LightSaveData_Map.js


▼困っていること
セーブデータの構造がMVからMZで変わっているらしく
LightSaveData
そのままでは、保存すべきアクターの情報も消えてしまいました。
設定ミスで消えただけだったようです。
逆に削除した形跡(デフォルトで入っているlogで確認)がありませんでした。

カスタムシーンプラグインでのシーンも考えたのですが、難易度が高く断念しました。

何か解決策がございましたら、ご提案いただきたく、お願いいたします。

※トリアコンタン氏にLightSaveDataをMZへ移植を打診しましたが、他のプラグインの移植もあるのとセーブデータは慎重に扱う必要があるので…ということで希望は低そうです。


▼追記
セーブデータが大きくなったと言われたリメイク中のゲームではアクター数が減っているため、これが根本的な原因だとは考えにくいようです。
(もちろん、軽量化できるにこしたことはありません)
 
最後に編集:

温州みかん

ユーザー
セーブ容量の削減はアツマールへ投稿する際、とても重要になります。
プレイヤーの半分は(もしかしたら、それ以上かもしれない)通常アカウントなので、サーバー上に保持できるセーブ容量――ブロック数に制限があります。
複数のゲームをプレイしていると、あっという間に上限値になってしまいます。
そして、思い入れがあるとなかなか整理できません。
私も、プレイヤー様からセーブ容量が大きいことについて指摘され、TN_LightSaveData_Map を導入した経緯があり、これにはかなり助けられました。
2ブロック減.jpg
ファイル1が導入前、ファイル2は導入後、2ブロック削減できました

MZでは、マップ上になるべくイベントを作らないようにしています。(最大でも16)
スイッチや変数を組み合わせて、統合できるイベントは統合するよう心掛けています。
そのため、ダンジョンマップ、町マップも細かく区切ったデザインにしています。
イベントを1増やすより、変数を1増やす方が容量が少ない、という点も着目できます。
オートセーブ機能も、見かけ上のセーブ容量を増やしてしまうので、どうしても、という場合は、オートセーブを一切禁止にするのも有効な手段です。

姑息な手段ですが、セーブできる場面を制限して、イベント情報を極限したセーブ部屋に場所移動させるというのも可能です。
セーブしたら自動イベントで元の場所(セーブ直前に取得した マップID、x、y座標)に移動させるというのもアリだと思います。
セーブコマンドにこの処理をプラグインで書き込めば、疑似的に TN_LightSaveData_Map を再現できます。

さて、本題の「仲間が多すぎてセーブ容量に食い込む問題」です。
しかし、こればかりは、どうしようもない、と思います、
未加入者のデータを除外しても、仲間になる終盤では、それなりの容量に膨れあがり、セーブ容量の仕様を知らないプレイヤーをかえって困惑させてしまうことになります。
しいて言えば、1軍、(2軍)パーティーメンバー分だけのアクターID数にしぼり、パーティー外とのメンバーの入れ替えは、イベントやスクリプトで疑似的に実行する、内部的には名前とレベルその他もろもろ変わる転職、という方法でしか解決できないと考えています。
各パラメータに変数を使うと、結局同じになってしまうので、職業だよりのものになってしまいます。パラメータを成長させる、いわゆる種アイテムは導入できません。所持経験値もそのレベルの初期値からスタートです。
そしてもちろん、男女平等 裸 で待機。
でも、パーティー加入時に「最強装備」をさせることで、それっぽく補うことはできるかもしれません。

私が思いつく限りの考察です。
 
もっと姑息な手もあります。
・最大セーブスロット数を少なくする。
→プラグイン で最大セーブスロット数を最小限にする事で複数セーブの容量喰い予防が出来ます。
 

munokura

ユーザー
TN_LightSaveData_Map をMZで使用したところ、少し効果がありました。
自分のゲームはセーブできるマップが一箇所しか無く、イベントが移動しないので入れておくことにしました。

セーブデータを分析したところ、どうやら
データベースの登録状態から変化したアクターが保存される
ようです。

上記の自分のようなスキル参照だけだと保存されないようです。
よって、自分のケースでは LightSaveData がMZに移植されても、効果がないことが納得できました。

オートセーブはMZ付属のものではなく、TorigoyaMZ_SaveCommand2 を使用することで実現しています。
プレイヤーの選択肢を減らさないためにスロット数は変化させていません。
(これが、イベントの組み方を間違えると EventReSpawn と競合するのか?よく分からないエラーを体験しました)

セーブ専用の何もないマップに移動させてセーブさせるという動作も考えたのですが、1kbくらいしか変わらないので、変なバグを生むよりは分かりやすい構造にしておくことにしました。

下記辺りを参考に、個別コモンイベントとマップイベントの自動実行の制御とどちらが軽いかを比較しようとしたのですが…謎のエラー(TorigoyaMZ_SaveCommand2 と EventReSpawn の競合?)が起こるので、諦めました。
TorigoyaMZ_SaveCommand2の代わりにイベントコマンドで「セーブ画面を出す」にしてマップイベントでセーブした場合、1kbは減ったのですが、構造が複雑になってきたので、諦めました。
 
実際のゲームを見ていないので、参考になるかどうかは分かりませんが
ひとつ記事を紹介させて下さい。(外部リンク)

神ゲーが台無しに!?アツマールにおけるセーブ容量の驚異とそれを減らす方法 : 口だけブログ (livedoor.blog)

こちらの記事では、データ肥大化の主因として下記のようなものが挙げられていますね。
・セーブが行われたマップのデータの大きさ(多分こっちは問題ないと思いますが)
・プラグインによってアイテムやエネミーのデータがまるまるセーブデータに保管された可能性
  →図鑑プラグインなどを活用されている場合は、念の為気をつけた方が良いかも知れません。
 

munokura

ユーザー
アルツール氏にご紹介いただいた記事は読んだことがあったのですが、プラグインの使い方が煩雑だったのとMZに対応しているのかよく分からなかったので、某チートツールを使ってセーブデータをJSONに変換して確認しました。
予想通り、新しく追加した
NUUN_ItemBook.js
NUUN_EnemyBook.js
のデータが少し大きいですが、内容的にこれ(インデックスのみを保存?)を減らすのは困難だと思う内容ですね。

ですので、自分のゲームとしては、アクターの数を減らすのが最も有効だろう、とは考えています。


パーティに4人しか入れないゲームとしているので、最初からキャラメイク的にすれば、4アクターのデータで済みます。
心配しているのはプレイヤーがゲームを始めるまでにキャラメイクを経る必要が出るので、面倒が増えるということですね。

このあたりはトレードオフなので、体験版へのコメントによっては変更を検討します。
 

munokura

ユーザー
TN_LightSaveData_Map をMZで使用して、色々テストしたところ、状況によって問題が発生しました。
厳密に内容を確認して移植する必要がありそうです。
 
トップ