-^%"^?)*$---Z*$<"d)))d"|)3m2d>f83Dz><$3d0m:d4zd!),m0,$3=@/-d0$%";p4d)3#+D"*(<"m2dZ4";f8d)@$3+Z*$+D"*&4-d"m:Z4"d!)@$3+Z.#|)/=!D0>3-^?zd0=04?!)*$3=3=0=0.#;e2D)*m0+=D"*&4-;$#4";a?)3%#><#+Z;p4d)@m??zD"*(<"$,3m04"d!)>m0=$Z/-dZ$%|)3-f8-f80P6Dz><))0{4z^:)3%#*$3
怪しげな文字列 (セーブデータ)
マップデータの送受信に絡んだ問題
一方こちらの持つセーブデータは 610 byte でこれ以上増えないから、圧縮してデータ量をこの半分以下…???四分の一以下???…にしたい…これはやる前から…無理ゲー決定だ。しかし一応やってみることに。
まず汎用的な Zip で最高圧縮率を試みたが結果やはりファイルサイズは思ったほど小さくならない。
仕方ないので自家製の圧縮アルゴリズムを作って試したらサイズは Zip よりも大幅に縮んだ…が、後少し頑張っても 200 バイトの壁は破れないだろうという結果で第一ラウンド終了。自家製の圧縮アルゴリズムは特定データ形式に対して最適化されているため、汎用的な圧縮に用いられる Zip アルゴリズムよりも情報圧縮率が大幅に高いのにはちょっと感心した。
自家製圧縮アルゴリズムは別パターンも試してみたが結局 250 byte 以下に大きな壁があってこれより下を掘れない。三分の一にまで圧縮することはおそらくできる場合もあるのだろうけれども、140 byte 以下はムリだ。最初から Twitter の制限である 140 文字で表現できる範囲でセーブデータを考えるとか別の工夫やアプローチが必要みたい。
その後
圧縮率が高くなるようにセーブデータを予め整形する方法を思いついたので実行。圧縮が効きやすいように整理してからもう一度自家製圧縮をかけたところ縮む縮む、おもしろい。そして最終的に 200 byte の壁を破り念願の 140 byte 以下を達成!もしかしたらコンスタントに 140 byte 以下にデータを圧縮できれば Twitter でマップデータを交換できるかもしれないという結論に。
しかし今度は圧縮を解凍するためのロジックを CF25 使って組むのがめんどくさいことが判明。CF2.5 の標準機能で文字列を扱う機能は貧弱なので、無理やりできなくはないが恐ろしく効率が悪い。だとしたらエクステンションを自作するのが速そう。
ZmY)T)W:sYZ)wd[;m2dVf@xZ)>du[XmwSY&t]0m2*+)XzYZTXd!0D]>*YvzY&vdxSVDWZm)u$[YUS?W&!2DVm0zS%Yu#)yZvzvdtwm(@XZwmVdYT$Y00&;<0<-0Dx&T1dy
690 バイト ( 690 バイト) 未圧縮状態のベタテキストファイル
352 バイト ( 352 バイト) Zip (最高圧縮率)
265 バイト ( 265 バイト) 自家製圧縮
511 バイト ( 511 バイト) 自家製圧縮後に再度 Zip 圧縮したらサイズが増えた例
130 バイト ( 130 バイト) 新自家製圧縮