どういう事をやりたいのか具体的に書くとアドバイスがもらえるかもしれませんね。

OPTIONはプログラムの先頭につけておくといいです。そうすると多分、エラーが出るようになると思いますが、それは宣言をつけたり逆に外したり（二重定義の場合）して直します。 ACLSはグラフィック定義や画面などを初期化してくれますが変数は初期化しないので、変数は自分で別途初期化する必要があります。 サブルーチン化するかどうかはケースバイケースですー

エラーメッセージは5行目でタイプミスマッチなのでBGSAVEがおかしいって感じです。 BGSAVEでの配列は文字列ではだめで数値配列でないといけないのでそういうエラーですが、ただ意図している用途では使えない命令だと思うので、このやり方でBG再現するのは無理じゃないかなーって思いますよ。

OPTION STRICTって使ってますか？ もし使ってないなら使うようにして変数は必ず宣言するようにした方がいいかもしれません。始めはちょっと面倒に感じると思いますが最終的にはデバッグの労力が減るのでいいと思いますよ。 で、変数のリセットですが、通常は始めに使う変数は初期化するようにします。なのでプログラムの頭で初期化するか、もしくは初期化するためのサブルーチンを作ってリセットしたいタイミングで呼び出すとかするのがいいんじゃないかなって思います。

配列からBGを作るならBGLOADですが、そもそもとしてデータの形式があってないので、そのやり方でやるならBGPUTなどを使って自分で配置していく必要がありそうですね。

正確な事は分からないですがプログラムが提示されない以上はどんなに考えても推測の域から出ませんし、公開できる状態になってから考えた方がいいかもですね〜。 個人的にはシステムの不具合である可能性はかなり低いと考えますが、その推測もなんとも言えない部分もありますし、見てみない事には分からないのが本音ですね〜

バグだと思ったものが自分のミスだったと言うことは凄く多いですね〜。なのでシステムのバグだと疑う場合は、その部分をどんどんシンプルにしていき、バグしか出ない状態にまでシェイプアップする必要がありますね。 難しい部分がなくても初心者になればなるほど見落としや勘違いは増えるので、簡単なバグってことはないと思いますよ。得てして簡単なミスの方が上級者のプログラマーも犯しやすいところがあります。そういうミスは判明したときにガッカリしますが、それも経験だと思うし、そういう経験が積みかさなかってミスが減っていくところもありますしね。

ちょっとだけ補足です。 区切り0のハコはありえますね。正確にはDIMで指定した数の -1の数が区切りの数になりますね。つまり8ならハコの図としての区切りは7つで使える添字は0〜7までです。 ただ配列の添字は区切りの数ではなくてハコに入れる事ができる要素数なので、0だと何も入らないハコというありえないハコになってしまうのは同様です。なので配列に値を入れるなら最低1以上の添字が必要です。ただ0で宣言（定義）しても後からPUSHなどで増やせるので、そういうやり方をするパターンも多いです。（他にもLOAD命令など足りなければ自動的に拡張してくれるケースもあります） とまあそんな感じですが、比喩だけに逆にわかりづらいぶぶんもあったと思いますし、わからないことや不明点があったら気軽に質問してくださいね〜

なんとなくでもわかってきたなら良かったですよ〜。 ちなみに普通の変数（四角いハコ）はすぐに用意できるので宣言しなくても利用出来る（ただしOPTION STRICTした時は宣言がいりますが）が配列（長方形のハコ）は予めハコをいくつに区切るか決めておかないといけないのでDIM EX[8]のような宣言が必要だと考えれば理解しやすいかも？ まあPUSHのように後から区切りを追加する方法もあったりDIM EX[0]みたいな区切り０というハコで考えるとありえない事も出来たりしますが、ひとつの考え方的な感じです。 ちなみに区切った場合の添字の数字の意味としては図のイメージのようにハコの左から何番目かを指定している（ただし０スタートなので８に区切った場合は０〜７まで）と思うといいと思います。

普通の変数はわかるのかな？ 普通の変数を知っているなら、ちょっと考え方を変えれば理解出来ると思いますが、変数が曖昧ならまずはそこからスタートですね！

個人的には現状だとあまりスロットを分けるメリットを感じていませんねー。 ただ、スロットの方にシナリオを読み込んでメインはエンジンだけにするマルチシナリオシステムとかには興味があります。

おすすめありがとうございます！ 確かに狭いマップやパズル的なマップはデータで作った方が手っ取り早くもありますね〜。 逆にRPGの本格マップとか、広大なマップならマップエディタが役に立つかもしれません。

僕の活動の最新でもマップの話題があるので良かったら参考にしてみてください〜

修正できたみたいですね！　良かったです。 これからも頑張ってください〜。

なるほど〜。当たり判定はちゃんと動いてますね。 ただ僕のサンプルはスプライトの原点を中心に２ヶ所ぐらいしかチェックしていません。なのできちんとするならちゃんと当たり判定を増やす必要があります。 また原点も中心のキャラを前提にしています。なので実際は多少はめり込むことを許容しているサンプルになります。 それに対して今使っているキャラの原点が左上なので余計にめり込んだ風に感じるんだと思います。 当たり判定は厳密にやろうとするとスプライトに対するチェックヶ所が増えるので、その辺を意識して改良するといいと思いますよ。

基本的には１の部分は通れないはずですが、プログラム次第なのでなんとも言えないですね〜…。 どうしてもわからなければ現在の公開キーを出してもらえれば、どうなってるのかをチェックすることは出来ます。ただ確認するだけなので改良までは出来ないので、その辺は自分で修正してもらえたらって感じです。

スクロールや当たり判定はプログラムによるのでなんとも言えませんが、サンプルを利用しているのだとしたらサンプルはアトリビュートの機能を使って当たり判定をしているものが多いです。 アトリビュートとは、BGキャラに対して設定できる値です。なので同じ絵には同じ値になりますが、数値で設定できます。 LまたはRボタンを押しながらXボタンを押すと通常（EDIT）モードとアトリビュート（ATTR）モードを切り替えることが出来ます。このモードで１に設定してあるものを移動出来ないとして処理している（この値をどう利用するかはプログラマー次第です）ので、それを確認してみるといいかもしれません。

コピーの範囲が間違っていたり変数名が重複している可能性もあるので注意して確認してみてください〜

スクロールや当たり判定は自分できちんとしないといけませんよ〜。サンプルはあくまでBGデータを読み込んで再現するだけなので、それをどう利用するかはプログラム側の問題になります。 ちなみにそれらを実装しているのが他のサンプルなので、必要ならそれを参考にしつつ独自に実装する感じになるとは思います。