うーむ

物凄く非効率な気がしている。(たった)１日悩むも 効率案が出てこないな。 プレイタイムが狂うと思えば 今 セーブ側の加算が問題くさい事に気づいた。（表示側ばかり見ていた）

１０マップと仮定したセーブでも容量食い過ぎだな。 この辺も考えなくては。

容量削減を入れた所 セーブ時に最大桁数まで数値纏めて ロード後に分解という 何とも間抜けな作りになってしまった。 何の為にDATでやってたのか これもう判んねぇな。 作り的にはTXT向きっぽいイメージだし TXTなら容量もごっそり削れるだろうし 作り変えてみるテスト。（TXT保存は手を付けた事がない）

整数型はどうだろう

整数型をどうするのだろう・・。 とりあえずテストでは問題なく保存～読込後変換出来そうだったけど 変数の数を考えると面倒さは上がってしまった感。 非効率に感じる＝セーブロードで左辺右辺を入れ替えただけの物を使ってるので 変数で入れ替え用とするも配列代入が手強すぎたのでした

整数型DATなら同じ要素数でサイズ半分じゃね、ってことだけど…

おお・・ホントだ。良い知識を得た。ありがと～

問題点がいまひとつ分からないのですが、セーブデータのサイズを小さくしたいということですか？それともセーブデータの結合、分解処理を短くしたいということですか？ セーブデータにおいてはプチコン3号ではDAT（バイナリデータ）とTXT（テキストデータ）が使えますが、それぞれにメリット、デメリットがあります。

DATは実数型だと1要素あたり8バイト、整数型だと4バイト、TXTは1文字あたり1～2バイトのサイズになります。しかし、実数型の配列に1桁の数値を入れてしまうとそれだけで8バイト消費されます。 1要素あたり実数型ならば64bit、整数型ならば32bitのデータが入るためうまくセーブデータを作れば1要素あたり（1文字あたり）のサイズは異なってもどの型も同じサイズまでセーブデータを小さくすることが可能です。 したがって、セーブデータの作りやすさとの兼ね合いで型を選択すると良いと思います。 セーブデータが文字メインなのにDATで保存したり、セーブデータが数値メインなのにTXTで保存するとセーブデータを作るのが難しくなります。 また実数値を保存するのに整数型配列のDATで保存する場合もセーブデータを作るのが難しくなります。

セーブに関しては 容量を小さくしたいという事ですね～。 何故 整数型で半分になったのか一瞬だけ考えた所 単純に小数点以下まで保存すれば長くなって容量増えて当然か となりました。 非効率と感じる部分は セーブ時はＡ＝Ｂ　ロード時はＢ＝Ａとしているだけなので効率化図れないものかと悩んでた感じですね。 とある日本語物の場合 多次元配列を変数化出来るので Ａ＝Ｂを１つ作って代入先を変えるだけなんですけど 書いていて もしかして自作出来るのではと思い始めました。

(bit数の違いだったり) 実数型は64bit使うのに対し、整数型32bit 要素数を掛け（てヘッダのサイズを足す）とファイルサイズになります

容量増えて当然かとなりました は自虐みたいなもので言葉足らずでした。 bitの違いで半分だったのね。 半分で36000の状態から 8000まで削れました。突き詰めればもっと削れそうだけど 大満足であります。

1要素あたり1bitしか入ってなければ整数型の配列に入るだけ詰め込めば32分の1にセーブデータを圧縮できます。 セーブデータの読み出し、書き込みのプログラムの共通化はVAR関数を使えば可能になります。 VAR関数についてはこちらのトピックスを見るかさらに詳しく知りたければプチコン3号入門講座を読んでください。 https://miiverse.nintendo.net/posts/AYIHAAAEAACHVRTs1c4kFA ただし、セーブデータは数10KB、数100KBという大幅な短縮が可能ですが、セーブの読み出し、書き込みを共通化してもせいぜい数100バイト程度の短縮しかできないと思うのでそこまで気にする必要性は無いと思います。

こんな手があったとは。 一段落したら 実験程度にウ＠ィタ仕様を作ってみようとしたけど コレのが短くて良さそうですね。 共通化は容量削減目的じゃなくて 何て言うんだろ。良い言葉が出てこないけど 自己満足的な感じですねぇ。プログラム的にスッキリしそうというか何というか。