プラグインによるセーブデータの容量増加について

ヱビ@名前が2文字

ヱビ@名前が2文字

ユーザー
こんにちは。

プラグイン制作で、わからないことがありました。

先日、モンスター図鑑が見られるプラグインAB_EnemyBook.jsについて、
こんなリクエストをいただきました。

敵を倒して図鑑に登録されても弱点と耐性は隠れていて
各属性で攻撃することで初めて表示
もっと読む

参考３.png
参考４.png


今までは敵キャラが登録されているかどうかをセーブしていましたが、
この機能を実現するには敵キャラの数×属性の数だけセーブデータが増えてしまいます。

この機能は私も欲しい機能なのですが、
このプラグインを使ったゲームがセーブデータが大きすぎてセーブできなくなったり、
RPGアツマールで容量を食ってしまうのは心苦しいです。

RPGツクールのセーブデータはどこまで保存できるのでしょうか？
今回の機能を実装しても問題ないでしょうか？

また、ステートにも同じ機能を作ることが考えられますが、それも実装しても問題ないでしょうか？

コードは次のようなものを考えています。

コード: 
// エネミーに弱点属性または耐性属性で攻撃した時
Game_System.prototype.addEnemyElement = function(enemyId, elementId) {
    if (!this._enemyBookElementFlags[enemyId]) {
        this._enemyBookElementFlags[enemyId] = [];
    }
    this._enemyBookElementFlags[enemyId].push(elementId);
};

このコードだと、初めのうちは問題ないと思うのですが、敵キャラを増やしたり、
ゲームを進めたりすると容量が増えていきセーブできなくなってしまうのではないかと心配です。


プラグインを配布しているサイト：
http://www.zf.em-net.ne.jp/~ebi-games/AB_EnemyBook.html
ツクマテのリクエストのあったページ：
https://tm.lucky-duet.com/viewtopic.php?f=5&t=533&sid=859583139cecd119c60f85781eff1ed3&start=50
 
＞猫二郎様

ご意見ありがとうございます。
なるほど、そうですね……。
一応、プラグインパラメータでON、OFFにできるようにしようと考えています。
 
ヱビ@名前が2文字の発言:
＞猫二郎様

ご意見ありがとうございます。
なるほど、そうですね……。
一応、プラグインパラメータでON、OFFにできるようにしようと考えています。
もっと読む
ON、OFF前提だとしても、ONの状態でモンスターの数で容量が増えるというデメリットはアツマールでは、結構、痛手・・。アツマールはスマホ動作も考慮されているから、その辺を注意しないとエラー停止しそう。

自分もサイドビュー戦闘同士でギリギリ動作環境範囲に入ったり、入らなかったりしたから・・。音関連は未だ解決してないけど。
 
デバッグコンソールにsave data too big! って出ることがありますね
想定外のサイズ、の目安になるかも？

２次元配列にした変数をセーブして試してみたんですが
256x128とか保存するとtoo big ! って言われますね
実ファイルサイズは128KB程度でしたが

256x64なら警告出ませんでした

enemy 256体 x 64属性がなんとかなるなら大体OKなんじゃ･･･という気もしますが
他の要素もあるのでこれだけじゃなんともいえませんね
 
これ、同様の機能のリクエストを受けましたがセーブデータが大きくなるので私は諦めました。
一定回数以上倒した場合にすべての弱点を表示するようにしてデータを小さくするしかないと思います。
ただ、この場合もすべての弱点を表示する閾値ギリギリでデータを追加されるとアウトです。
正直なところ、手間をかけてまで不安定要素の残る機能を実装するのはリスクが大きいと思います。
 
皆さん、コメントありがとうございます……！

ON、OFFありだとしてもアツマールでは結構痛手なのですね。
256×128で大きすぎるなら、ツクールは最大2000体まで敵キャラを作れることを考えると、
やめたほうがいい気がしてきました。
今回のリクエストは諦めます。ありがとうございました。
 
変数にビット立てでフラグ管理を仕込んで圧縮することでセーブデータに必要な容量を削減することってできませんか？

例えばA敵からD敵までの敵の属性解錠を管理したかったとして
A敵の属性解錠が成立したら変数に1を立てます。
B敵の成立時は2を立ててC敵の成立時は4を立ててD敵は8を立てるとやって被らないように独立して分離させます。
この条件で例えばACDが成立しているときその変数は13になります(2進数で言うと 1101 になりこれがフラグ可否の考えの基礎になります)
また、変数13の中にはこの管理手法だと2は立っていないことになるのでB敵は未解錠ということが管理されます。
値を判定に取り出すときが少し大変ですが大きな方から剰余なり除算なりで分解すればたった1つの変数値管理で成否の管理が可能だと思います。

昔のゲームはメモリ上にこのような考えでビット単位でフラグ管理していて物凄い密度で敷き詰めて詰め込んでフラグ管理しています。
1フラグにつき1領域用意なんてことをやっていると肥大化してしまいますから、そういう贅沢ができないときのフラグ管理圧縮手法としてこのようにビット立てで作る方法を考えてみるのも一興だと思います。

まあ実はここまで書いておいて実際にツクールで実現できるかどうか試していないので実現性があるかどうか不明で申し訳ないのですが。
それでも何かの参考やら発展事項やらになってくれないかと期待を込めて書きこみしちゃいます。ポチ！
 
ロクに知識はないのですが興味本位で、、

最大密度でフラグ管理した場合、敵2000体 x 100属性 x 1bitフラグ で20万bit ≒ 24.4KByte
セーブデータのマッピング上、一切の無駄なく最適配置できるとすればこんなものになるような気がします
ところで、こんな天文学的数値、現実的に扱えるものでしょうか？
１つの値にしようと思ったら、pow(2, 200000) ですよね？
考え方おかしいですか？
 
＞たかッシュ様
＞WTR様

すみません、今返信に気が付きました。
今回のリクエストは断ってしまいましたが、
ビット立てでフラグ管理を仕込む、という方法は知らなかったので、
勉強になりました。
 
You must log in or register to reply here.
Back
トップ