ファミコンの頃から存在している手法だったりします。マップをよく見ると、2バイトで一つのオブジェクトを形成しているような形状が多い事が分かります。圧縮プログラムを書いてテストしてみました。1.4KB縮みはしましたが、正直微妙な結果に...。いう圧縮を知りました。展開ルーチンが付いていて高圧縮そこそこ高速。1.2KBさらに微妙な結果に...。最終的には全10面を入れたいので、単純計算で12KB必要となります。この時の残りメモリは、8KBを切っていました...。サウンドデータが入ってないし、あれもこれも作ってない。そもそも圧縮率42.8%って凄い事なんです。凄い事やって足りないのなら、そのデータ構造ダメやんね...。!データ構造そのものが抜本的に拙いのだ!!そこで私は仕様の見直しを始めました。画面全体をそのまま保持する考え方そのものを止める事にしました。考えたら、そんな贅沢なデータの持ち方ってないよなあと。仮配置されたマップをよく見ると、マップ内にはオブジェクト毎にパーツ化できる塊がありました。この塊をエディタで事前に作成して、そのパーツをどこに配置するかだけをデータ化すれば軽いんじゃないのか?また、複数ステージで流用するパーツも当然あるはずです。PCGはステージ毎に要る要らないがあるので、まとめて全種類を定義しておくのは勿体ない事にも気がつきました。PCGデータは要らないですよね。樹木パターンはどのステージにも使うわけだから、使う分だけトータルで管理すればデータ量は減るはずです。圧縮と言えば、お出掛け荷物の圧縮も手軽にしたいですよね。新マップデータ構造の構築PCGは全てのステージで使用済みだけを分解して保持する事にしました。PCG管理専用のダイアログを準備する事にしました。オブジェクトの塊を事前に編集するダイアログを別途用意して、データを吐き出す際は使用済みだけとする事にしました。上記で編集済みのPCGとオブジェクトをステージ毎に、配置座標データを作成する事にしました。このような数段階の分離形式にはなりましたが、思惑通りのデータ形式で実際に落とし込む事が出来ました。マップの作成中にふと気がついた事が。マップの配置データの半分を次のステージの配置データに活用すれば、少なくとも配置データは半減するし、マップの連続性もよくなるし、データ作成もラクだし!このアイディアは使えないかと!具体的には、このマップデータから...次のステージに繋がる左半分だけを取り出して、右側に単純移動させます。この前回のマップを下地として、次のマップに必要なオブジェクトを継ぎ足していきます。これならかなりの省メモリに貢献するのでは無いかと期待が膨らみます。マップに連続性が出来た事から、思わぬ副産物が。意図せず10面全てのマップに、ゼビウスのマップのようなストーリー性が生まれたのです!右側から左側に進んでいく事で、最初に山間部に現れた怪獣が、最終的には都市部の地球防衛隊本部まで到達するという流れが、勝手に出来てしまったのです。いやー、これは本当に棚ぼたでした。このゲームにストーリー性が加わって、ますます完成度が上がった気がした瞬間でした。再度データ圧縮を行う全10面ではありますが、マップはそのとき使用するステージだけを展開して、それ以外はメモリ上に圧縮して待避させておくのがベストです。展開バッファが必要になりますが、PCG定義データ、オブジェクトパーツ、配置データという3種類をメモリに展開しなくてはいけません。そのため、ゲーム中に使用しているバックバッファをその裏方データの展開に使用しました。その展開したデータを元にマップを再構築するのは、VRAMそのものです。このゲームでステージ切り替え時に、ペンゴのマップ生成のように、マップが作られていく過程が見えるのは、そのような理由からです。展開が見えるおかげで、1秒ちょっとの待ち時間が全く苦にならなくなりました。速いと感じられるぐらいです。作られていく過程が見えるのは楽しいですからね。モニタがやっぱり画面復帰時に荒ぶってくれたので、この方法は採用できませんでした。荒ぶらなければ、このゲームはもう少し違ったテイストになっていたかもしれないですね...。おいて他の選択肢は考えられません。0.3KBうわははは!やった、やったぞ!めっちゃくちゃ小さくなったぞ!!ライセンス問題発生Newシティヒーロー完成後暫くして、BEEPさんからパッケージ販売のオファーがありました。そこで、使用しているソフトなどの権利に問題が出ていないか確認をしていたのですが、ひとつかなり致命的な問題が発覚しました。