BGGETで横の判定がつかないのですが何故でしょうか？ 片側だけのBGGETしかやっていないのはわざとです。

24行目のIFが判定用のB3でなくBG3という変数名になってますよ〜。 ちなみにこのようなミスがわかりやすくなるようにするには、１行目にOPTION STRICTとつけて以降の変数は必ず初めて使うときは宣言(VARやDIM）をするようにするといいです。 これはある意味、中級者以上だとある程度の長さならほとんどの人がつけてるオプションじゃないかなぁ？って思いますー。 OPTIONをつけると宣言が必須になるぶん、多少面倒に感じますが、経験者ほどこういうスペルミスが痛い（意外と見落としやすくて、見落とすと厄介なバグになる）とわかってるから、使用しているオプションになるんじゃないかなって思いますね。

ありがとうございます。全く気付きませんでした。やってみて一応判定はついたのですが少しずれているのですが何故でしょうか？色々数字を変えてみたのですがうまくいきません。

BGGETで調べてる座標がX+10,Yの位置になってますが、使っているキャラ（スライム）の原点位置は左上みたいですね。 スライムのサイズは１６×１６なので原点のX座標の１０を足した位置を調べても、その位置はスライムの中の位置なので、最低でもスライムの横サイズ（１６）を足さないとめり込むと思います。 またY座標も上なので調べてる位置としてはちょっと高い気もしますが、このどの座標を調べるかというのは当たり判定によって違うので、自分で考えたり調整して決める必要がありますね。

ちなみに実際には移動先の座標を調べないといけないので、スライムのサイズが１６で、３ドット移動する予定（上記のプログラムがそうなってる）だとしたら、少なくともXには１６＋３で１９を足した位置を調べた方がいいと思いますよ。

これって何処かおかしい所ありますか？凄いおかしい事が起きているんです。

こんな感じで途中で止まってしまいます。

ちょっと勘違いしていたところがありました。 処理的に移動出来るなら移動ではなくて移動後に当たっていたら戻す、みたいな感じでしたか？　だとしたら僕の説明した座標の加算値は正しくありません。 その辺も含めて調整すれば直るとは思いますが、どうしてもわからなかったら公開キーを出してくれたらちゃんとチェックしてみます。

すいません色々調節してみたのですが上手くいきませんでした。公開キーは「VADN23DJ」です。

そうですかー。公開キー見てみようと思いましたが見つからないと出てしまいますね。間違えてませんか？？？

すいません公開キー間違っていました。 公開キーは「V4DN23DJ」でした。

とりあえず上記のソースで２５と２９で同じ引き算しているのはおかしいですねー。 あとは座標のチェックなのですが、始めに座標のチェック（変数にいれる）をしてから後でまとめてIFで座標調整した方がいいですね。そうしないと補正した値を元にBGをチェックする事になっちゃってるんで、おかしな事になってる感じだと思います。 とりあえずは上記の点に気をつけて修正してみてくださいー。

下側の当たり判定がつかないのとジャンプして着地したときの位置がずれてしまうのですが何故か分かりますか？

なんとなくはわかってますが、細かいところでどう答えたら良いかわかりにくい感じですねー…。 プログラムの流れや座標計算に関して、もうちょっと考えてみてコードを書くのがいいかなと思いますね。 例えば８行目でYに７を足してから位置を設定していますが、このままだとこの時点の位置の表示になるので以下の補正結果からかならず７ずれた位置に表示される事になるんで位置のイメージがしにくいです。なので通常は座標補正後のX,Y座標をSPOFSで設定した方がいい（つまり下の方に来る）感じだと思います。 あとこのジャンプはジャンプとしては急なジャンプになっちゃいますが、それはまあこの際置いておく感じとして、まずこの仕組みできちんと座標計算がうまくいって表示出来るようになるといい感じですね。

移動判定と衝突判定をサブルーチンとか関数にまとめると、可読性も上がりバグ取りしやすいと思いますね。あとSPHOME使えば面倒な座標計算が簡単になるのでは。