>>407
動作テスト頑張って下さい。

入札制の採用、もしかして私の提言からですか（笑）？　だとしたら、大変光栄です。ありがとうございます。
一発勝負の方が時間もかからず、いいと思いますね。

ワープ情報というのは、「ワープの行き先」ですかね？　この定義法については提言あり。
一度>>336で書きましたが、「あるワープマスで移動できる先は、必ずただ１つのマスに固定されている」ので、
現在、店である時にしか使用しない事になっているであろう、
「元本」・「エリアNo.」の部分を上手く使うと、専用配列を増やす必要がありません。
ワープ先の取得は店のデータを読むのとほぼ同じ処理になるので、新規配列を作るよりも楽。

例：座標(5,8)にワープするワープマス（このマスの座標は8,7）がある場合

「元本」の座標（8,7）のデータ部分に5、「エリアNo.」の座標（8,7）に8を入れます。
実際にこのマスに止まったら（止まったマスがワープマスなら）、
新x座標をそのマスの「元本」から読んだ値、新y座標をそのマスの「エリアNo.」から読んだ値にします。

こういう定義法を提言するのは、ワープマスの数によってマップデータの長さが変わってしまう事を防ぐ為です。
ワープ先だけ別定義で用意すると、その分だけマップデータを追加しなければなりません。
既存マップデータの未使用部分を使用する方法だと、データの数値が変わるだけなので、マップデータの容量は変わりません。

この方法の欠点は特定のマスにワープするチャンスカードに対応できない事。
実はいたストSPでは、銀行行きを除いて、この種類のカードがなくなっていたりします。

なお、データの長さが変わらないようにすると、ゲーム前に正しいマップデータかチェックする事ができるようになります。
つまり、最初の８バイト（＝マップの縦横幅）を読んだ結果から算出されるマップデータの長さと、実際の長さが合わなければ、
このバイナリデータは正しいマップデータではない、とできます（次回のコンバーターVer.アップ時に試験的に実装予定）。

>>405
ワープできないと、良くも悪くも、離れ小島マップが作れないですよ？