2進数を用いたセーブデータ軽量化計画
108人のキャラクターに関する情報(真偽)を保存したいとする。
普通に配列としてデータを保存すると、以下のような膨大な量になってしまう。
そこで、まず108本のフラグを108桁の二進数とみなして
ヒロイン既出[1]
ヒロイン既出[3]
ヒロイン既出[4]
…
続いてそれを10進数に変換することにより、セーブデータを軽減を図ることにした。
つまり、1、3、4のフラグが立っている(真)であるなら、
二進数であらわされる数字は
それを10進数に変換すると
1011 (左が小さい位。5桁目以降はずっと0なので省略)
この13という数だけを記録しておけば、それは
1 * (2 ^ 0) + 0 * (2 ^ 1) + 1 * (2 ^ 2) + 1 * (2 ^ 3) = 13
1、3、4の3本フラグが立っていることを記録しているのと同様である。
逆に、10進数からあるフラグが立っているかを求める場合は以下の手順に従う。
10進数を2で割った余りを求める。
余りが1なら、フラグその1は真。
数字から余りを引いて、2で割った数に対して同様の判定を行う。
13 Mod 2 = 1 即ち、ヒロイン既出[1]は"1"
以下同様に
13 - 1 = 12
12 / 2 = 6
6 Mod 2 = 0 即ち、ヒロイン既出[2]は"0"
完全にもとの情報(1011)が得られる。
3 Mod 2 = 1 即ち、ヒロイン既出[3]は"1"
1 Mod 2 = 1 即ち、ヒロイン既出[4]は"1"
そこまでしなくても、求めたいフラグのナンバーの回数だけこの剰余の確認をすれば
その値が出てくることは容易に推測できよう。
情報系では基礎の基礎であるこの変換が、
自分のシナリオではかなり使えると気づき、意気揚々と実装。
いろいろミスをしながらもついに正常な動作を確認。
計画は成功したかのように見えた。だが───
フラグのナンバーが40を越えたあたりでエラーが出るように。
「なぜ？」
原因を究明すべく奮闘すること10数分。
実はこの方法にはある壁が存在することに気づいてしまう。
この方法、計算する値は2のべき乗で大きくなっていく。
フラグが1本なら0-1、2本なら0-3、3本なら0-7、10本なら0-1023…
これが40本になるとどうなるか。
SRCの数値計算がどういうやり方で行われているのかはわからないが
1024 * 1024 * 1024 * 1024 = 一兆以上
普通に型のサイズをオーバーしてしまっている模様。
とにかく、計算してくれない。
40本の時点で無理なら、108本なんて夢の彼方である。
さて、どうしたものか。
108本のフラグを27本の束4つに分けるなりして数字を抑えつつ
細かく処理するように変更するのが一番現実的なような気もするが、
もっと奇想天外、虚をつくような華麗な方法があったりしないだろうか…？
