1年前16×16で区切る碁盤上のマップに配置した16×16の障害物に対してプレイヤーの幅、障害物の幅とが、キッチリと判定してくれません。障害物が並んでいる場合だと判定がおかしくなります。移動先の調べ方に抜けがあるのか、半ずらしでは障害物の間に入り込めたりできる場合があります。考え方としてなにが足りないのか、どこがおかしいのか、、。(ソースが長いので今回「PLAYERが下方向に進んでいる時の先の障害物調べる」処理だけ抜粋させて頂きました。movespeedでプレイヤーの移動方向を認識し、その方向に障害物があるかを調べる処理です。マップは二次元配列で、PLAYERの移動先のX、Yを求め、マップ[Y][X]が障害物ブロックか、調べるという感じです。}自分はなにか間違っているとは思うのですがご指摘頂けるとありがたいです。16×16の障害物が単体で配置してある場合は、処理が簡単なんですが障害物が連続して繋がって並んでいると、なにか変な動きになります。障害物と障害物の間に一瞬入り込んだり、とかです。当たり判定の確認をするときは、視覚的に確認できるようにするのも手ですよ。シューティングを作るとき、レーザーと自機が正しく当たり判定計算できているか確認するときhttps://dixq.net/rp/34.htmlこんな風に実際のレーザーの上に当たり判定を描画して確認しました。分かりやすいと思いますよ。意外と±やベクトルの方向が逆に画面右半分全部抜けてるなんてこともあります。1年前URL見ましたが、弾と自機の衝突判定の仕方は理解してます。普段は矩形判定でやってます。配列上のブロックに対するオブジェクトの当たり判定する場合の組み立て方を知りたいんです。右上や左上の壁にplayerが気づかず、それらと半分重なっていようとも、playerは進めてしまいます。私は、playerが上に進む場合は、まず自分の真上の配列を出して壁かを調べ、そのあと、左上、右上の配列を調べてから上に進めるか、の様な処理を書いてます。1年前>・問題が生じている箇所を絞り込む>・アルゴリズムの実装が,自分が意図した通りにできているのかどうかを確認する>といった調査をしましょうなんか、そのアドバイスって別に今回の私の問題じゃなくても、プログラムで悩む誰にでも当てはまるアドバイスですよね。考え方を手ほどきして欲しかったというか。全部自分で考えろということですよねありがとうございました。1年前ちなみに、当たり判定を描画して、なんてやってますから。やってて、解決しないから相談してるわけで。私がやりたいことを説明させて頂いた上で、じゃあ私の記載したソース(考えかた)じゃなにが足りないか、どこが間違ってるか、をご指摘してもらいたい。上級者なら間違ってる部分は見てわかるはずですし。相談したら、おかしい部分を自分で探せ、で済むなら相談ませんし、そんなアドバイス、初心者でも言えますから。URL貼ってここを見ろ、も誰でもできるアドバイスで、丸投げに感じました。1年前>ちなみに、当たり判定を描画して、なんて>やってますから。>やってて、解決しないから相談してるわけで。少ない情報からない頭で考えてみるに、複数の壁があるときにおかしくなるということを考えると、そもそも当たり判定の判定先が一つなのが奇妙に感じます。今二つの壁に向かって円いプレイヤーが進んでいたとして、その先に進めるかどうかは少なくとも二つのブロックを調べる必要があるはずです。比較対象が一つしかないと思っているからおかしいのではないでしょうか。仕様もよくわからない状態でそのようなコードを見せられても私には明確な回答ができません。初代ドラクエのような動きをするのか、ボンバーマンのような動きをするのかにもよるでしょう。ボンバーマンのような動きをさせたいのなら少々難しいコーディングをする必要があります。それに、デバッグの方法、何か問題があった時にそれを解決する方法を養わないと今後無限に遭遇するバグがあるたびにトピックを立てなければならなくなります。それを踏まえた上でアドバイスを受けてデバッグしてみるのは間違っているのでしょうか。「単純化してみる」「可視化してみる」という対応が王道です。今回の問題が可視化で解決しないのであれば、条件式を最小限にして自分の想定通りの動きになっていることを確認しながら少しずつ処理を追加していくといいです。・ブロックを1つにしてみる・ブロックを2つにしてみる・ブロックをfor文で計算してみる・ブロックを1次元にしてみる・二次元配列にしてみるすでに可視化していると言っていますが、おそらくデバッグ可能な正しい可視化ができていないのでしょう。今回の問題となっている添え字のx,yがどの領域になるかをリアルタイムで可視化していますか?必要な可視化ができていればデバッグのしようがあると思います。今回の問題が一つのブロックしか調査してないことが原因だとしたら、可視化していれば分かるはずと思います。読んだ限りでは□□P□□という時にバグっているとおっしゃっているようですが(配列[0]と[1]の間にプレイヤーがいるとき)管理人さんの言われるように、この時判定がおかしいのではないでしょうか。少ない情報からない頭で考えてみるに、複数の壁があるときにおかしくなるということを考えると、そもそも当たり判定の判定先が一つなのが奇妙に感じます。1年前あ、確かによく読んだらその通りでしたね。数日開きましたが、確認させていただきました。#9以降のusaoさんや管理人の回答には有益に感じられる内容がいくつかありました。最初からソースに対するそれくらいの議論、ないしは建設的な回答が頂ければな、とも思いましたが、ちゃんと相手して頂いたことにはお礼申し上げます。いくつか思うところがありますので言わせて頂きたいと思います。>碁盤のマスの個数がたかだか16x16しかないのであれば誤解しています。個数では無く、1マスのサイズを16×16で設定してあり、それが数百×数千と碁盤上に並んだ(二次元配列で作られた)マップです。「たかだか」のゲームを作っているわけではありません。(もちろん、今回のプログラミングミスを検証するなら小さなマップでも作ってからやるのがいいのでしょうけども)>プレイヤーがインベーダーのような動きをするのか、>初代ドラクエのような動きをするのか、>ボンバーマンのような動きをするのか初代ドラクエって斜め移動できたかは知りませんがまあ、よくある斜め移動込みのRPG移動です。斜めもあるんで、判定も少しは面倒だと思うんですけど。PLAYERposXってのは真ん中?左端?その他?pixelです。基本posは左上のつもりですコリジョン判定する時には当り判定を座標を割り出してます。>forの奇怪な繰り返し条件により,>判定箇所(x)を算出するループが最低2回は回ることが保証されているので,ここ、一番気になりました。私のソースを理解してくださっていることはありがたいのですが、「奇怪」呼ばわりは解せません。がんばって考え抜いた処理とは言え、未熟者なのは認めますがなぜこの繰り返しは奇怪なんでしょうか。理論的には正解のひとつではないですか?要は、自分の進行方向にあるインデックスをすべて見ているわけです。見ないとすり抜けるだろうと踏んでいるので。それに対するusaoさんの提示される処理は>列挙されるべき配列indexの値は連続的であるハズなのだから>最初と最後のindexさえわかれば中間のindex群を馬鹿正直に計算する必要はない>forの主体がpixelであった上記(2)の状態から,forの主体が配列indexである状態へ,自然な形に変換できるというものですが、アバウトすぎてわかりませんでした。配列のインデックスは連続的でしょうけど、そのマスが壁か、そしてその壁が連続かはわからないことです。どこまで壁かもわかりません。いちいち視野に入るインデックスを調べる処理になってしまいました。1マス16×16が連続してることをさしているのでしたら。管理人さんの貼った画像みたく、PLAYERが中途半端な場所にいる場合はどうされるのでしょうか?16で割ってインデックスを出しても、片側だけのマスしか出せないはずです。するとそこだけ見て移動しては、PLAYERの画像はすり抜けが起こるはずです。↑1年前//配列indexがxの箇所について判定をusamiさんはぼやかしていらっしゃるんで、わからないです。