プチコン初心者です。壁に判定を付けるために壁(■)と座標が同じになったら戻るという感じにしたんですが、途中ですり抜けてしまいました…どうすればいいですか？教えてください…

とりあえず1点だけ…。というか前にコメントした内容の修正になるんだけど、BX=BX-1とかはBX=-1とかにしてください。（その他の同様の箇所も）というのはX=X+BXで最終的にXに足す値としての利用なのでそうじゃないとおかしい事になっちゃいます。 質問の答えと直接は関係なくてすいません。

でんぺんさんありがとうございます！

　あとボタン操作も、不必要に複雑な記述になっています。 慣れてくるまでは簡単で読みやすい、例えば IF BUTTON()==1 THEN BY=BY-1 IF BUTTON()==2 THEN BY=BY+1 IF BUTTON()==4 THEN BX=BX-1 IF BUTTON()==8 THEN BX=BX+1 IF BUTTON()==0 THEN RETURN 　という書き方でいいと思います。

＞こうやまさん うーん…。正常に動いているところまでわざわざ変更させなくてもいいような気もしますよ〜…。それよりは、やっぱりプログラムに不慣れで間違いが多いところが気になるので、出来ればそれを指摘してあげて欲しいです。 てか僕が指摘しなくてすいません。あまり同じ人がずっと説明するよりも色んな人から多角的な意見を聞いた方が理解の助けになるかなと思ってるところもあったりしてます。またあまりまとめてドバーッと言っても逆に辛くないかなと思っちゃうところもあるんで…。 気長に頑張ってください！

ちょっと補足。 ただこうやまさんのようにすると斜め（2つ同時）に押すことが出来ないので、そのぶん当たり判定が楽になる可能性はあります。 なので色んな記述を知って、その違いを理解するのも良いことだと思います。なんでそうなってるのかがわかってくると色々とやりやすくなってくると思いますし頑張ってください！

でんぺんさんのアドバイスで、壁をすり抜ける問題の半分は解決してますね(^ω-) ちなみにとりゅふさんは、壁をすり抜けている原因は分かりますか？ 「どうやってきちんと当たり判定を取っているか？」って言い換えてもいいですけど。 ちなみに >こうやまさん そうやると、読みやすさじゃなくて挙動が変わっちゃいますぜ？

でんぺんさんのご指摘のように変更することですり抜けは 防ぐことができます。 何故すり抜けてしまうのか説明しますと、 このプログラムでは変数BX,BYはプレイヤーキャラの 移動量となっています。この数字が2になると1個おきに 移動するようになってしまうので壁のキャラが検知できずに すり抜けたように見えます。 【すり抜けが起きる場合】BX=2,BY=0とする。 ◎□□□□■□ □□◎□□■□ □□□□◎■□ □□□□□■◎ ◎プレイヤー　□空白　■壁

けいさん»座標を決めて当たり判定を取っているからですか？

ottaさん»つまり毎ループごとにBX=0を入れればいいんですか？

↑つまりと打ち間違えた文字を入れてしまいました…

>とりゅふさん 「座標を決めて」………だと多分ちょっと違いますね。 すり抜けの原因は、otta777さんがコメントで詳しく解説してくださってます。 当たり判定の前の所になりますが、とりゅふさんは、このゲームのキャラがどうやって動いているかは分かりますか？

>とりゅふさん でんぺんさんが指摘されているように十字ボタンを 検知したときのBX,BYに加算、減算をしている部分を 1または-1を代入するようにすれば解決できます。 つまり移動量は1または-1となるようにすれば壁を 検知できずにすり抜けることは無くなります。 毎ループごとにBX=0:BY=0実行するとボタンを離したときに プレイヤーキャラが停止するようになり今までと動きが 変わります。

上手くいきました！

ありがとうございます！

そういえば本題の事なんですが、当たり判定はCHKCHRを使って付けるんですか？IF文での当たり判定の付け方はだいたい分かるんですがCHKCHRはよく分かりません…教えてください…

ぶっちゃけ言います 移動用の増分と実座標を分けて考えて下さい 移動前に移動後の状態を想定し、その判定をして下さい 現状コードでは 移動用の増分を加減算している 移動したあとに、更に移動後の状態を判定をしている です 代入すべきを計算していることがそもそもの間違いです とは言え、こうやまさん以外の方々は指摘してますね 計算を代入に変えたとしても、処理順序に問題があります 「なんで移動後に、その後の移動先を判定している？」 けいさんあとは任せた←さっきのしかえしw

　とりゅふさんの作られているヘビゲームですが、似た作品をいくつか確保しているので、勉強用に教えちゃいます。 ・食べ歩きゲーム（公開キー 2DKEV28E） 　3号へは私が移植。移植前のリストや動画はこちら。 http://smileboom.com/special/petitcom/pochette-tabearuki.html ・あるけあるけ（公開キー JRKEEEAV） 　これも3号へは私が移植。 ・スネークゲーム 　こちらは初代プチコン版だけ紹介します。 http://smileboom.com/special/petitcom/pochette-snakegame.html 　3号への移植もあるが、リストが複雑になったので、3号版は省略。 　これらのリストを見くらべるなどして、勉強に使って下さい。

chkchrと言う関数は、指定座標のキャラクタコードを取る関数です なので、移動、表示したあとに、そこのキャラクタコードを取っても、自分のキャラクタコードしか入りません 移動する前に、移動後の場所を想定(chkchr(x+bx,y+by))してキャラクタコードを取ることで、当たり判定の目安となります （ついでに言えば、当たってない判定をされた後でないと、移動してはいけない。当たってない判定をせずに移動すると当然壁にめり込む） chkchr自体は当たり判定の「目安」となるものであって、当たり判定自体は自分で書くものです

>sayさん はーい、バトンキャッチー(´ω`)／ って、バトン渡したあともかなり丁寧に説明してますやんｗ でも、とりゅふさんに向けての説明としては、用語や前提にしてる概念がちょっと難しすぎるのでは？ つまづいてるのも、もうちょっと前の所じゃないかと思います。

>とりゅふさん CHKCHRは関係なく当たり判定そのものの仕組みと、CHKCHRの命令の意味は正確に分かりますか？ CHKCHR命令は、指定した場所に何があるかを調べる命令です。 とりゅふさんのプログラムですと指定した場所にCHKCHRを使って、そこが壁かどうかをIF文で判定してますね。で、もし壁だったら進む方向を反対にしてますね。 コメントからの印象ですが「キャラがどうやって動いているか」と「どういう仕組みで壁に跳ね返らせているか」の理解があいまいな所があって、それでつまづいてるんじゃないかと思いました。

色々な方がアドバイスしてくれてますね！ 僕もけいさんと同様の印象をもっています。おそらくなのですがMiiverseでのサンプルや回答をもとにプログラムを作っているが、それに対しての理解があまり曖昧で自分でもなにをやっているかわからないまま作ってしまっている部分があるんじゃないのかな？　って思ったりします。 なのでソースを見てもどこまで理解しているかがわかりにくいというか、どう答えるのがベストなのかがわかりにくいんですよねー…。 おそらくソースのコピヘや言われたままの修正などもしていると思うのですが、そうじゃなくてとりあえずでもいいので自分の考えでゼロからプログラムを組んで（逆に言うと組める範囲の内容まで縮小して）みたらいいんじゃないかなって思っています。

ついでにコメントすると、上記ソースの43行目は不要だと思います。というか無意味です。 もし上下左右ボタンを押してないならという判定をしたいのだったら、 IF (BUTTON() AND 15)==0 THEN GOSUB @NOMOVE になります。なんでこうなるのかはビット演算のついて説明しなくてはならず現段階では難しいと思うので省略します。 また正常に動作してもGOSUBの先が何もなくRETURNで返ってきているだけなので、今のままではどちらにしても不要だと思いますし、とくに予定がないなら削除してしまった方がいいような気がします。今はなるべくシンプルにまとめることを考えた方がいいと思うので〜。

度々すいません。 ちなみに足し算ゲーム（ってほどの内容じゃ無いけど）ってゼロから作れますか？　とりあえず仕様は以下の通りとします。 １　足すための２つの数字をユーザーに入力させます。 ２　１の２つの数字を足した数字（答え）をユーザーに入力させます。 ３　１の入力と２の答えが合っていたら正解と表示して終了。間違えていたら間違えと表示して再度答えを入力させます。（２に戻ります） これだけです。もしバカにされていると感じてしまったらすいません。そんな意図はなくて、これだけでもプログラムの流れの基本である、入力・変数・計算・条件判断・ループが含まれるのでプログラム事態の把握度がわかりやすいんです。 もしこれが出来ない、または難しく感じたらもう少し基本の部分のおさらいを増やした方がいいし簡単すぎてばかばかしかったら、それで次のステップを考えられるんじゃないかと思いました。

返信遅くなってすみません…丁寧に説明して下さりありがとうございます！

でんぺんさん»こんな感じですか？

ほぼ当たりと言えますね〜。ただ要件（仕様）では間違ったときには間違えを表示する、と書いてあるので一応表示して欲しかったですね〜。 あと8行目と9行目はちょっと考えるとIFは1つだけで実現出来ると思うので、その辺も考えてみてください〜。

でんぺんさん»8,9行をまとめる方法が分かりません…ELSEを使うんですか？

まとめるというかIFを１つにするだけなので行としては複数行になっていいですよ。（というか複数行のつもりでした） ELSEは使わないで大丈夫です。 これでわかるかな？　わからなかったらまた聞いてください〜。

でんぺんさん»5行目のC=A+Bを省く所しか分かりません…

あー、C=A+Bが不要なのも見落としてましたね…。確かにそれは意味がないので無くすか別の変数にしてIFで使うべきですね。 IFを一つにするには考えを少し変える必要があります。ということでプログラムの流れを意識して上記３を考えてみます。 上記3では、「１の入力と２の答えが合っていたら正解と表示して終了。間違えていたら間違えと表示して再度答えを入力させます。（２に戻ります）」と書いてありますが別にこの順番でプログラムを書く必要はありません。なので逆に考えると流れがスムーズになります。つまり、 １の入力と２の答えが間違えていたら間違えと表示して再度答えを入力させます。（２に戻ります） それ以外は正解なので正解と表示して終わります。 こう考えるとIFは1つで済みます。それ以外はELSEですが、この場合はELSEを使わなくても間違えていたら２に戻るので、それ以外は正解です。

でんぺんさん»そんな考え方があったんですね…全く気付きませんでした…

そうです〜。プログラムの流れを意識するとより最適なプログラムにたどり着けますし、その方がシンプルになるので自分でも理解しやすくバグも少なくなるのです〜。 まあ要件的には間違えた時もメッセージを出したいので、 IF A+B != C THEN ?"まちがえ":GOTO @KOTAE みたいな感じがいいですけど、今回の趣旨は流れと変数の使い方なので正解です。 まあ変数の使い方という意味では、 ANS=A+B として答えを変数に求めておいてから、 IF C != ANS THEN〜 の方が変数を使ってるんで学習用としてはいいかなと思いますが、一応そんな感じでした〜。 こういう風に単純なプログラムでも書き方は色々あって、書き方によってプログラムはシンプルにでも複雑にでもなったりするので、よりベストな書き方はないかなと考えたり意識してみると今後役に立ってくると思います〜

と言うことでお疲れ様でした！ ちなみに少し思うのですが、テキストによるキャラクター操作は移動するときに消さないといけなかったりもするし、実はスプライトを使った方が簡単だったりするところもあるかなぁ、と思ったりします。ある意味、テキストってローテクですしね〜…。 スプライトはスプライトでその概念を理解する必要はありますが、移動する際に消さなくてもよかったりスプライト同士の当たり判定命令が用意されていたりと便利な部分もあるんで、ただ動かすだけならスプライトの方が楽だったりするかもしれません。

でんぺんさん»ありがとうございます！

けいさん、sayさん»よくは分からないんですが、当たり判定はキャラの移動後の場所に付けれはいいんですか？

>とりゅふさん いえ、sayさんも言ってますが、キャラの移動の「前」が良いです。 流れとして ・予定の方向に進めるか確認 ・進めるならそのまま、進めないなら方向を逆にする ・実際に移動させる という順番が自然なのですが、意味は分かりますでしょうか？

けいさん»移動後の判定にすると ○○○■ ○○○■ ○○○◎ ○○○■ と壁に移動したキャラが重なってCHKCHRに自分のキャラのコードしか入らないからですか？

>とりゅふさん ええ。それもありますね。 あと、自分のキャラのコードが入らないようにするのは工夫したら解決できますが、壁に入った「後」に壁に入った事が分かっても手遅れで、処理がめんどくさい、というのが一番です。 このゲームで当たり判定って「もし壁にぶつかったら反対方向に進む」だと思いますが、そうすると、キャラが壁の中に入ることがあってはいけません。 だから、進んだ後で判定して「壁の中にいる」事が分かっても遅いのです。 それよりも、実際に進む「前」に判定して、もしこのまま進んだら壁に当たる場合に、向きを反対にすれば簡単です。

ありがとうございます！

教えて下さったCHKCHRを使ってイライラ迷路ゲームを作りました！これも教えて下さった色んな方のおかげです…