坂道の当たり判定を作っています。

[ISLe]

オフトピック

CPlayer::GroundFlagがオンのときCPlayerは地上にいるように振る舞う。
CPlayerはCPlayer::GroundFlagによってのみ振る舞いを変える。
これは前提。

現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。

当たり判定の範囲と、めり込んでいるとする範囲をずらすという方法がある。
選択肢の一つであり何が正解というわけでないが、シンプルだし、現状においては変更点も少なく済む。

キャラの足元、1ピクセル重なってブロックがある場合
当たっている。が、めり込んでいない
キャラの足元、2ピクセル重なってブロックがある場合
当たっている。1ピクセルめり込んでいるとみなして押し戻す
というふうにする。

接しているかどうか判定するのは難しいけれど、重なっているかどうかなら簡単。

[keito94]

正に舌の根の乾かぬうちにってやつですね。

そうです…。

CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。

もしかしてこうではないのでしょうか？

現状、座標補正によって、当たり判定の範囲外に移動するため、フレームごとにCPlayer::GroundFlagのオン/オフが繰り返される状況。
キャラの足元にブロックがあるあいだ、CPlayer::GroundFlagがオンのまま維持されて欲しい。

たしかにそれは言えている…。

たしかにそうなんですよね…。

[ISLe]

(※下線加筆)

No.67に書きました。
CPlayer::Moveから除けたいのは、あたり判定(を直接呼び出している)部分。

カオス過ぎていますぐそれはできないので、少しずつ改善しようとしているところ、ことごとく先回りして改善の芽を潰す。
ある意味keito94さんの才能かもしれませんね。

これ、いますぐやっちゃダメって読めないですかね。
わたしの文章がおかしいのかな。


あと、不思議な文言があるのに気づきました。
#前後のインパクトのほうが大きかったもので

No.81の当たり判定のアルゴリズムの左右の当たり判定の部分は完成したのですが、
上下の当たり判定で、めり込んで左の壁まで行ってしまいます。

「左右の当たり判定の部分は完成した」？


コードは完成していて、動作は理想と違う
というのがkeito94さんの最終形なのでしょう。
少なくともkeito94さんの態度が改まらない限りそこから変化しないと思います。


keito94さんとわたしでは世界線が違う。
keito94さんとわたしがやり取りを続けても収束しません。
わたしがここ数回オフトピで投稿しているのはわたしの世界線を収束させるためのものです。

[ISLe]

オフトピック

坂道に沿って上り下りするというのは、キャラを基準に移動するだけでなくプラスアルファが必要。
特に坂道を下るのは、補正に頼るとキャラが浮いてしまったりしてうまくない。
#逆にそれが活きるデザインもあるが。

なので、坂道の上り下りの際は、キャラを主体ではなく客体とする。
どういうことかと言うと…
・坂に入ったら、キャラは見えない動く床に乗った状態になる
・ユーザーの操作で動くのは見えない床で、キャラはその床に対して位置を保ちつつ、その場で足踏み
・坂道の端を超えて移動するあるいは途中でジャンプするなど坂道を離れたら、見えない動く床は消滅し、キャラは通常運転に戻る
という具合。

もちろんこれも方法の一つに過ぎず正解というものではない。

この方法のメリットは…
・動く床やエレベーター、エスカレーターなど応用できる(というかこちらから発想を得ている)
・コース設定次第で波やループなどどんな形状にも対応できる
・応用の幅を広げてもキャラの実装が重くならない

[keito94]

すいませんでした…。
正確には当たり判定のコード自体は完成していたのですが、
なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き（地上にいるときだけGroundFlagがtrueになったまま）になるのでしょうか？

[ISLe]

正確には当たり判定のコード自体は完成していたのですが、

例えば、CCollision::GetXPosition関数の中にあるコード…
(Collision.cpp:267行目～)

コード:

		if (block.x < *myx) {
			*myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f);
		}

block.xは、左端のブロックを0番目として右へ何個目かという数値が入ってます。
*myxは、キャラの中心のX座標がピクセル単位で入ってます。
まったく意味の違う数値を比較しているこのコード、正しいですか？

なかなか理想通りの動きになりません…。
どうしたら、理想通りの動き（地上にいるときだけGroundFlagがtrueになったまま）になるのでしょうか？

どうすればいいか(あるいはそのためのヒント)は既にNo.98,No.101に(さらにそれ以降も)書きました。
ですが、どうしたらkeito94さんが理解できるかはわたしには分かりません。

[keito94]

ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。
でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。

[ISLe]

ISLeさんのご指摘を受けて、ブロックの単位ではなく、座標で判定して見るようにしてみました。

CCollision::GetXPosition関数内
Collision.cpp:267行目～

コード:

		int bpos = block.x * 16;
		int brpos = bpos + 32;
		int blpos = bpos - 32;
		bool Debug = true;
		if (brpos < *myx) {
			*myx = (float)((block.x - 1) * 16 + 8 + OffsetR - 0.1f);
		}
		if (blpos > *myx) {
			*myx = (float)((block.x + 1) * 16 + 8 + OffsetL + 0.1f);
		}

CCollision::GetYPosition関数内
Collision.cpp:297行目～

コード:

		int bpos = block.y * 16;
		int bbpos = bpos - 8;
		int btpos = bpos + 8;
		bool Debug = true;
		if (bbpos < *myy) {
			*myy = (float)((block.y - 1) * 16 + 8 + OffsetD - 0.1f);
			*jcount = 0;
			*gflag = true;
		}
		if (btpos > *myy) {	
			*myy = (float)((block.y + 1) * 16 + 8 + OffsetU + 0.1f);
		}

CCollision::GetXPositionでは32を足したり引いたり、CCollision::GetYPositionでは8を足したり引いたり…
どんな意味があるんです？

でも、また新たなバグが発生してしまいました…。
実行すると、着地せずに画面外に落下します。

デバッグすれば、CCollision::GetXPositionでもCCollision::GetYPositionでも、ifの条件が両方同時に成立していることが確認できるはずですが。
このコードでは、画面外に消えるのが正常。


keito94さんは、トピにしてもコードにしても見直すのがめんどうくさいのでしょうか。
デバッグするのもめんどうくさいですか？
もしそうなら、プログラミングが好きではないのでしょう。

好きでもないのにプログラミングするのはつらいだけなのでやめたほうがいい。
仕事でないならプログラミングできなくて困るわけでもないでしょう。


あと、ゲームを好きでもないのにゲームを作ろうとするのもやめたほうがいい。
キャラをどう動かしていいか分からない、のでなくて、そもそもキャラがどう動くか知らないでしょう。
プログラミングできなくても既存ゲームをプレイして研究するとかはできますよね。
ゲームをプレイするのはめんどうくさいですか？

自分の作ってるゲームがどう動いているかにも興味ないですものね。

[keito94]

ブロックの座標で当たり判定を実装しようとしています。
現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
（キャラの座標が中央基準なので…。）
ですが、地上に着地せずにめり込んで左に移動してしまいます。
左右の判定は一応完成しました。

[ISLe]

現在考えているのは、衝突したら一ブロックずらした座標で判定するということです。
（キャラの座標が中央基準なので…。）
ですが、地上に着地せずにめり込んで左に移動してしまいます。

ブロックが等間隔に並んでいることが前提条件になりますよね。
わざわざブロックが等間隔に並んでいないといけなくするメリットって何でしょう。

オフトピック

むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。

そもそも、衝突したブロックの左にあるブロックがキャラより左にあって、衝突したブロックの右にあるブロックがキャラより右にある、というのは当たり前。
こちらも同時に成立する条件。
あいだにelseを入れたので、前回は常に右へ下へだったのが、今回は常に左へ上へとなった。
それだけ。
本質的に何も変わってない。

左右の判定は一応完成しました。

そうですか。
おつかれさまでした。

[ISLe]

ですが、地上に着地せずにめり込んで左に移動してしまいます。

添付されているソースファイルは、そうならないようにCPlayer::GroundFlag書き換えている箇所を移動してますね。
どうしてでしょうね。

[keito94]

むしろ、坂道を実装するには邪魔になりそうな前提条件は排除していきたいが。

どうやって排除するのですか？

[ISLe]

keito94さんは、“坂道を実装するには邪魔になりそうな前提条件”が何なのか分かっているのでしょうか。
分かっていないなら、差し当たって、目の前のコードを理解するところから始めましょう。
分かっているなら、どこがどうして問題なのか、説明して見せてください。

どうやって排除するか、を考えるのはそのあとです。

[keito94]

分かっているなら、どこがどうして問題なのか、説明して見せてください。

その問題というのは、CheckMapや、マップチップを確認する部分にあります。
ブロックを左から何個目にあるかを判定する都合上、動いているブロックやキャラのX座標の位置がずれることが前提の上下の当たり判定で、
（今のコードでは）左へ上へ行ってしまうバグが起きてしまうことです。

[ISLe]

分かっている、を選択しておいて、分かっていませんね。

キャラはピクセル単位で動くのだから、ピクセル単位で座標がずれるのは最初から想定内ですよ。

（今のコードでは）左へ上へ行ってしまうバグが起きてしまうことです。

そうなるようにコードを書き換えたのはkeito94さんですよ。

その問題というのは、CheckMapや、マップチップを確認する部分にあります。

「どこが」はまあ合ってますけど、たまたまですかね。

“坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。

[ISLe]

オフトピック

そういえば、No.47でリンクしたトピで、ブロックに当たったら当たる前の座標に戻す、という方針を採用する方向だったはずだけど、いまのコードには欠片も見当たらない。

当たる前の座標に戻せば、当たっていない状態に戻る、というのが悪魔の証明なので、それ以降スルーしてたのに。
前提条件がなければ、当たっていないとすることを保証できないのだから。

前提条件を積み重ねたコードはトピが解決してもずっと爆弾抱えたまま。

[keito94]

“坂道を実装するには邪魔になりそうな前提条件”は、たぶんkeito94さんが完璧だと思っているところ、にありますよ。

もしかしてめり込み防止の部分ですか？

[ISLe]

もしかしてめり込み防止の部分ですか？

「もしかして」？
あてずっぽうですか？
あてずっぽうであたったとして何の意味があるんでしょう。

場所はCCollision::CheckMapで合ってると書いたのに。
#そこだけとは言ってないけど

ひとつは、ブロックとキャラが当たってるかどうか調べるのに、縁を何点かだけ調べているところですよ。
これは、ブロックが固定で等間隔に並んでいて、尚且つキャラとブロックが同一サイズというのが前提になる。
#keito94さんサイズ変えたらうまくいかないっていう質問を前にしてましたよね。

この前提では、ブロックがあるところは、全面ブロックである。
だから、ピクセル座標とブロック単位の座標が混在してもテキトーに誤魔化せてしまう。

いま実装しようとしてる坂道は、45度傾いていて、当たり判定のあるところとないところが半々に交じってる。
前提から外れたことを同じやり方でやろうとしたらどうなりますかね。

[keito94]

場所はCCollision::CheckMapで合ってると書いたのに。

ごめんなさい…やっぱりあってたんですね…

前提から外れたことを同じやり方でやろうとしたらどうなりますかね。

そりゃ、バグが発生するわけですね…。

[keito94]

オフトピック

今思うと問題点だらけだったんだな…。

[keito94]

>>ISLeさん
…つまり、何が言いたいんですか？

[ISLe]

ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。

keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。

坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。

[keito94]

ブロックとキャラの当たり判定を書き直す必要がある、ということですよ。

keito94さんは、そこで使うべき方法を既に知っています。
RECT型の当たり判定について
こんどは返信がもらえるように頑張りましょう。

坂道の実装までまだまだ遠いので、新たにトピたてて仕切り直したほうが良いかもしれません。

了解しました！
一応この記事は今度こそ解決とさせてください！！