ゲームで
— なぎせ ゆうき (@nagise) September 28, 2022
「壁をすり抜けるバグどうなってんだ！？」
みたいに言われがちですけども、プログラミングやると
「すり抜けない衝突判定、どうやってんだ！？」
ってなりますからね🤔
ゲームで
「壁をすり抜けるバグどうなってんだ！？」
みたいに言われがちですけども、プログラミングやると
「すり抜けない衝突判定、どうやってんだ！？」
ってなりますからね
デフォが素通し状態で、一生懸命に「ぶつかる」を作るんですよ。
— なぎせ ゆうき (@nagise) September 28, 2022
ぶつかるの難しい。
デフォが素通し状態で、一生懸命に「ぶつかる」を作るんですよ。
ぶつかるの難しい。
衝突判定は真面目にやると深いジャンル。
— なぎせ ゆうき (@nagise) April 6, 2020
それだけで一冊の本になるぐらい pic.twitter.com/jI25asSGhh
衝突した時、実は一瞬めり込んでる(小声)
— わあたろ (@x_Waataro_x) September 28, 2022
基本がすり抜けというか、元々の状態がすり抜けなので、プログラムしないと永遠にぶつからないんですよ
— 不知火@フォロバ100 ﾍｧｯ∧_ ∧ （ ・ω・)=つ≡つ （っ ≡つ=つ `/＿＿) (ノΠＵ (@siranui__) September 29, 2022
２Dだと「壁マップ作るの面倒だし、出力済の画像でまとめて衝突判定するか！」ってやった時によくすり抜けてました。 ダメダメでした。
— homemaku (@homemaku) September 28, 2022
衝突判定（しょうとつはんてい、Collision Detection）とは、「2つ以上のオブジェクトの交差を検出する」という計算機科学上の問題であり、具体的には「ある物体が別の物体に当たったか（衝突したか）どうか」を判定するプログラム処理のことを指す。
ロボット工学、計算物理学、コンピュータゲーム、コンピュータシミュレーション、計算幾何学など、さまざまなコンピューティング分野で応用されている。
衝突判定のアルゴリズムは、2Dオブジェクト同士の衝突判定と3Dオブジェクト同士の衝突判定に分けることができる。
この記事への反応
・それ自分で授業で作って痛感した
・DirectXの3Dゲームで当たり判定1から作ったときに壁ずりを作るのにクソ苦労した 大体隅が通り抜けるんよね
・壁1枚でも普通に難しくない？
・これはマジ。特に表現がリッチになればなる程、違和感のない衝突判定の構築は難しくなっていく。
・これゲーム作ったこと無い人にはまず理解してもらえない難しさなんだよなあ…😅
プレイヤーには「バグ」って一言で片付けられちゃうけど、壁に当たる処理だけでもそれなりに色々な事を考えて実装しないと別のバグ引くし、本当ゲーム開発ってめちゃめちゃ数学使うしめっちゃ大変なんですよね…😇
・これ、結局は処理能力やリソース生成コストの問題に帰着するんですよね。
判定方法自体はいくらでもやり様あるけれど「実用範囲な負荷」の見極めが難しく、真正直に数学的な交差判定だけでやると最適化をしても未だ厳しくて、FPS稼げない場合が非常に多い。
つまり「フィジクス糞重い」
・わかります
・僕の課題研究ではすり抜けると一歩戻るようにしました
正解は知らん
・衝突判定ガチムズい
・泣けてくるほどの、それな
簡単なゲームでいいから自分で作ってみると、市販のゲームの凄さを感じられるよな
これが今回のスプラの火消し？
すなわちスプラトゥーン開発者は素人w
すり抜け撃ちもセーフ
未だに髪の毛や装飾が体を突き抜けるのなんとかならんの？
だからゲーム開発者は制限すればするほど面白くなると錯覚してしまい結果的になんもかんもやり辛いクソゲーが世の中に出ることになるのだ
突き抜けずに自然に髪が動くようにすればかなりのパワーを使うから
格ゲーみたいに描画すべきキャラ少なければそういうのも防げるだろうけど
今時、コリジョン判定を一から作ってるところなんてあまりないだろう。
直そうと思ったら直せるけど、クッソ手間がかかる割に
その労力は別にゲームの売り上げにほとんど影響しないからあえてやんないんだ。
動く足場に乗るとキャラも一緒に動くと思ってるやつが多いが
それはそのようにわざわざ作ってるからだ
動く足場の持つベクトルと同じものをキャラにも適用してるから一緒に動くのであって
それやんなかったら足場だけ動いてしまい、キャラがストーンと落ちてしまう
できるけど死ぬほど重くなるぞ
プリレンダムービー用とかならわかるけど
スプラᔦꙬᔨ🔫🎨開発者さん頑張って下さい
息子も毎日楽しんでますゴキブリのネガキャンに負けないで下さい
なお、慣れた状態で普通に装備貫通するゲームやると違和感凄くなる模様
なお、慣れた状態で普通に装備貫通するゲームやると違和感凄くなる模様
そもそも衝突判定をどうするかだけの問題
アルゴリズムを解析してたけど、やっと解析完了した。
あれは3Dに見えるけど、処理上では、
「3Dを2D(UVマップ)に逆変換して”塗り絵”をするアプリ」だった。
それで最後に”塗り絵”を2値化＆定点解析して、範囲の多い方が勝ち。
プログラマーは知らんがシナリオライターはとんでもないクソ野郎だ
神っていう名前らしいぞ、HAHAHA
コリジョンなんかはエンジン側デフォルトでやってくれるのも多いけど、そこから処理軽くしようとするとエンジンが作ってくれた判定ちまちま削るって言う虚無な作業が必要になる事あるからなぁ
そりゃモブの視点からすりゃどんな神シナリオでもクソ野郎だろうなｗ
うるせー！
いろんなジャンルで使えるミドルウェア作ればゲーム会社喜ぶんじゃね
ライセンスも儲かるし
スプラトゥーン開発者はプログラミング覚えたて学生レベル
アレを何か別の物と勘違いしてる人が多い
ゲームエンジンがあって当たり前だと
・ゲームの中でも衝突や重力はあって当たり前。自然の摂理
・ペンキを発射したら当然色が塗られる。自然の摂理
・ゲームが終わったとき、色を塗り分けられたものを数えるのは難しい！！俺のような優秀な者にもわからない！！！
っていう自称エンジニアが現れる
まぁその労力を減らすためにミドルウェアを使うんだね
って馬鹿！
そのものを貼るんじゃない！
たとえばVietcongっていうゲームみたいに、前に武器を構えるスペースがないときは
前に構えずに銃を上向きにして回避、というような動きはできない
ゲームエンジン出来合いの動き以外をやりたいときは自分で判定処理を作るしかないが、それが面白いのだ
いかに単純化して軽量にするかの話。
その過程で貫通とかすりぬけの不具合が出る。
例の化学エンジンですか？？？
UE5だと、崖上るような動作にしてもそこらへんエンジン側が自動で設定してくれる機能あるらしいな
特にバグチェックと修正とかAIが重宝しそう
PS１時代から全く進化してないの何とかしろよ
よっぽどの無能でなければどうなってんだ？とはならない
落ちないぞ。その場にただのこるだけだ。
落ちるってのも、そういう下方向ベクトルの動きをプログラムしてるわけだから。
俺EDFで詳しいんだ
一般ユーザーでも使えるUEやUnityにもGUIで、AとBはぶつかるけどCはぶつからない、とかコリジョン指定すれば勝手にやってくれる
ああいう日本的な発想すこ
Havok Physics
あれは処理の順番の問題で、一番ダメなパターン
1Pの攻撃->ヒット処理->2Pの攻撃->ヒット処理 ってなってるから悪いんだ
1Pの攻撃 -> 2Pの攻撃 -> ヒット処理にしないと、1Pの後にヒット処理が来てるから必ず1P側が優先されてしまう
平和な世界ならモブ視点が一番楽なんだぜ？
実際プログラムに関しては多少優秀な専門学校生なら作れるだろってものすっげー多い
ゲーム作るうえで当たり判定付けるなんて初歩中の初歩だと思うが
そもそも当たり判定付けたつもりが付いてないってのがバグなんだから
その時点でプログラマーがどうしてすり抜けるんだ？って思うのは当然だと思うが
いやちょっと速い弾撃つと、ダメなんよね。ゆっくりだと壁にぶつかるんだけど。というのも６０fpsで動いてるから
例えば３４フレームで壁の前、３５フレームで壁の向こうって移動した場合、もうダメ。壁の中に移動したものは弾くけど・・ってやつだな。要するに現実と違って６０フレームでしか物理演算してないので、ふつーにそうなる・・。じゃあどうすんの・・っていうと・・。どうするんだろうね。壁みたいな動かないものの場合は、最初から交差するのがわかるからやりようはあるけど。
「同期」しながらやってんだが、そのやり方次第で変なことになるものもあるよ
ガンシューでやっちゃいけねえ
ハウスオブザデッド4はこれで、弾当たらなくなってたからな
だから今もう誰もやって無いんだな
反面教師？
そう言う話じゃ無くて草wwww
お前の仕事
素人が難しいって言うのとプロが出来ないってのは全く別次元の話だぞ
それでも突き抜けるときは突き抜ける
バグはバグだし
開発側の責任だ
お前の頭バグだバグだ
まあその通り
しっかり作ってちゃんとデバッグすればいいだけの話
ほんとコンマイさぁ
ってのはあんのよ
CPUでの処理が遅れてしまっていても関係なしに常に動いて処理してる部分
それを使わずにCPU側で衝突判定すると、CPUさんが忙しくなった時に衝突判定も遅れるため
まあ良くないことしか起きねえよな
ちゃんと作れwwww
バグが多くて遊べないクソゲーとかいう奴あるけれども、俺が真の遊べないクソゲーを見せてやりてえわ
は？
フロムのカメラ荒ぶるの半分くらいアレのせいだったと思うんよなぁ
いや、特許切れた今でもあらぶってるから関係ないか
早よ見せろ
内角、外角、法線ベクトル
めっちゃ使う
楽は楽なのだが、勉強にはなんねーぞ
ゲームエンジンというのは、「いろんな機種で同じものを売りたい」ときに楽をするためのもの
勉強で使っていいものではない
今もあるのかわからないが、
プログラムわからない人がゲームシステムの解析的な事を載せてるサイトの独自解釈や珍文が好きだったりする
俺が最強って事じゃん
なんで、衝突判定みたいな並列性重要な処理GPUにさせずにCPUにさせるのさ
2Dゲーならともかく３Dゲーやぞ
いつの話してるんだ。
だいぶ前にその話あったでしょ
PS2時代のゲーム開発じゃねーんだから
やらないとゲッダンみたいな形になりながらそのまま壁を貫通するだけ
いやそれは普通にCPUやろ。
グラフィックの描画がGPUの仕事だぞ。
これまでのポケモンはマスごとの移動だったのに、新作はドット単位で動けた
だからバグったんだよね
超点数が多い昨今のゲームじゃGPGPUで一気に処理するのが一般的だぞ
まあそれはそう。
業界で重宝されるのは、ゲームエンジンを作ったり内部にアクセスしてカスタマイズできる人材だからなあ。
ぶっちゃけゲーム動かすだけのプログラムだったらUE4のBPで何とかなるし。
本当に必要な技能はBPノードを拡張したり新しく作ったりする人よな。
感覚的には単純でもプログラムで実装するとものすごく大変な場合があるのは理解できる
まあそれはそう。
業界で重宝されるのは、ゲームエンジンを作ったり内部にアクセスしてカスタマイズできる人材だからなあ。
ぶっちゃけゲーム動かすだけのプログラムだったらUE4のBPで何とかなるし。
本当に必要な技能はBPノードを拡張したり新しく作ったりする人よな。
ゲームエンジンなど「汎用性の高さを重視すると」そういうのはあまり突き詰めない
本当に処理時間のケツが厳しい場合はやるだろうし、速いとは思うが
速度を犠牲にして良い
どっちか言って下さい
まんま学生時代のワイでくさ
親近感わいたわ
せめて三角関数と複素数と微分積分と線形代数はやってきてほしい
やるとしても軽量化したコリジュンモデル同士
だから髪とか布とかみたいなものがめり込むのは当然
いつの時代の話してるんだ
行列と四元数も頼むわ
大変だから見逃してくれは違うし出来ねーならF2Pにでもしてろよ
うるせー！こんなの気合だー！！
いわゆるtick rateと呼ばれる、処理の頻度(whileで回る処理のフレームレート)の関係上
その処理と処理の隙間にうまいこと噛み合うと、ある程度オブジェクト内部にメリ込んでから処理されるっていう
まぁほぼほぼAPIやラッパーしてる何かがあるので
実行した効果の動きを脳内で動かす事が出来る事が大事になるんですけどね
UnityPhysicsはDOTS100%が謳い文句なので、CPUだけでやってるよーに思う
任天堂あたりじゃいまだに通り越せていないみたいね
任天堂「壁をすり抜けないのスゲェ！いったいどうやってんだ？w」
その結果衝突判定が正常に発生しないですり抜けることはとても多い
パーティクルとかの賑やかしはそれでいいけど、ゲーム性に直結する当たり判定はCPUでやらんと不便だろう
GPUは確かに専門職だから速いが、専門分野以外だと
CPUさんのほうがなんだかんだで使いやすい
ましてや今回のバグは一階と二階の”床”抜け。
プログラマーならなぜ他の飛ばし系ではできているのに、これだけならないか？という風に考えるはずだが。
多少遅れたってどうってことない
しかし衝突処理が遅れるともう大参事やから無難にCPUさんで
知らなかったのか？
普通のヒットボックスで点数少ないならCPU側でやった方が転送時間考えると早い
普通に生成しているコリジョンの属性が違うからでしょ。
どう違うかは実データ解析しないと分からんし。
素人に言い訳させてる暇があるんなら、さっさと直せw
ちゃんとすれば問題ない。
あるあるバグやな
任天堂の内製は、UEとかの汎用ゲームエンジン使わないって話を聞いた。
イメージとしては、ミドルウェアを寄せ集めるような感じで、ゲームごとにめちゃくちゃ効率のいい専用システムを組んでる。
ゲームエンジンは色々できる分、ゲームに最適化はされてないからね。
だからいつもバグだらけなんすねぇ
ベゼルエンジンとか作ってなかった？
本当今更エンジン？って感じだったけど
つぎはぎのパッチワークでゲーム作ってるからバグの修正出来ない事になっちゃうよねそれだと
なーんも考えずに着弾地点から範囲攻撃判定出してるからでしょ。
そういう知識なくてもキャラクリあるゲームいくつかやると装備品や髪の毛が自身の体を突き抜けたりするモーション多発するから
衝突判定って作るの面倒なんだろうって推測できるんじゃないかな
目の前の箱使えば割と手軽に始められる趣味でもあるし
今の時代はゲーム作る一歩踏み出すのもお手軽だよ
正しく書いた方がいいよ
「任天堂の内製は、UEとかの汎用ゲームエンジン使わない」
「任天堂の内製は、UEとかの汎用ゲームエンジン使えない」(スペック的に)
頂点と同期させてしまうと落ちることはあるな
壁際に立ってから、マウスを超素早く動かして後ろ向くと奈落に落ちる、みたいな(1敗)
うちのデザイナーもBPいじれるようになって手間が減った
クソBP書かれてもこっちで手直しすりゃいいだけだし
ぶつかり判定とすり抜け判定は同じものだぞ
超簡単に書くと、ぶつかってるかぶつかって無いかを検知し、すり抜けるかすり抜けないかを処理するだけ
結局実装者がそれを想定して作って無かっただけの話だからな。
言い訳してんじゃねーよ
仕事で最先端の技法ってあんまり使わないもんだよ
こなれてないから無用な遅れとトラブルを招く
解決方法も一緒に勉強しないとロクなことにならない
土方(物理)は馬鹿ばかりだけど
当たり判定全振りだからなぁ
高さを監視して、閾値超えたら上空に移動かな
実践的でシンプルな解決策だと思う
座標の終着点決めないとそうなる。
終着点とか、リミットをプログラムせずに座標をずっとマイナス方向に-1していくと、最終的には座標変数がマイナス方向にオーバーフローしてプラスの最大値に変わる。そこからまたマイナスされていくから上から降ってくる
UE5とかそうなってないの？
MOD界隈で乳揺れMODを作る人がほとんどいないor作ったら称賛の嵐なので察してくれ。
大体のゲームエンジンにはついてるぞその機能
ゲームエンジンは標準搭載してるぞ
UnityもUEもだが
数値解析では正確さ命だからそんなことやってたわ
単純なのは34フレームの位置と35フレームの位置でカプセル作って壁と衝突させるんやで
Switch「…解せぬ」
知識なさすぎ
街中を散々家の壁登ったり、飛び回ったりしてるのに謎の空間に入り込んで再起動になる事は一回も無かった
バグチェック地獄だっただろうな
ゲームエンジンはそんな便利なもんじゃないぞ
アクションゲーム歴が長いからな、あのメーカー
ノウハウ持ったエンジニア達が頑張ってるんだろう
60キーはちょっと、、、、
素人に理解を求めてるうちはセミプロ
動画見たら笑ったわw
床下から攻撃して範囲攻撃貫通してるやんw
これ最低でも着弾点から複数のレイ飛ばして貫通判定しなきゃダメだよw
SwitchのクソCPUじゃ大変かもだけど、ちゃんと対策しないとゲームにならんやろw
これは流石に実装がクソすぎるだろw
着弾点からの直線距離で命中判定するのは別に構わんが、それに加えて簡易なレイキャストして着弾点→ヒット対象間に遮蔽物ないか調べないとダメだろw
言いたいことはわかるけど多分普通に判定が外れて落下したら一定数値で戻すって処理が書かれているかと
斜めとか微妙な角度でいい感じに当たると抜けてきてね…
実際には底なしになってることが多いのだが
地面となる判定部分から更に下にプレーン(見えない板)を配置しておくと
そこに当たったら規定の位置に戻るという処理ができるので、それで簡単に復帰はできる
何もなければこのプレーンに当たることはないが、万一地面をすり抜けたときの保険で俺は必ずやるね
純粋な数学的問題でありつつ、限られたマシンパワーで処理せにゃらんからね
場合によってはトリックも使うからマジで奥深い
ここら辺の分野研究…というか仕事でぶつかってるとグラだけじゃなくて
ギミックを色々作る上で本当スペックがどれだけ重要かってのを感じてくるわな
いかに手をぬいて処理を軽くするかに苦心するのだ
スペックがないのは首がないも同じだからな
エコ(棒)なハードで作れと命令されたら作るけど、まあ、色々妥協は必要になる
不可能すぎて草
日本語の本なんて見ないよ
日本で翻訳して有料の書籍で売ってる本ばっかりだし
表記は全部英語だけどそれぐらいPGなら読み解けって話だ
何回も調べてるうちになんとなくわかるようになるよ
絵を動かしているだけだから
素人集団任天堂
20年後があるような前提で語られても
八分木で大体片付く
あとゲーム性から逆算してコリジョン取るべきオブジェクトは絞れるかな
それ以上、壁の座標方向にスクロールしなくするだけでしょ
何も難しくない
こだわるとめっちゃ大変。
任天堂は拘ってないみたいだなw
自分にはプログラムの才能がないと諦め、その後ツクールユーザーになったとさ
昔はコリジョン用のメッシュを別途作って対応してるはず
重力設定は存在する前提でしょ。
そうでないとそもそも動く足場に乗れないんだから。
じゃないと崖の途中で立てちゃうから
俺だと球体辺り判定までしてくれるんだけど、俺以外だとBOX判定までしかやらないみたいな。
それ位のやり方でないと物理法則完全にシミュレーションできんと思うわ。
図ろうという意思を示したときだけ厳密にやるとかｗ
君の作ったゲーム動く壁に突っ込んだら+5くらいになって余裕で貫通しちゃった
しかも貫通したまま戻れないから詰んだ
返金しろ
それじゃあ2Dゲームだろ
ツッコミ待ちだろうから言ってやるけど
UE4とかUnityで作られたゲームどれだけSwitchにあると思ってるんや……。
UE5ならまだしも普通のゲームエンジンだったらいくらでも動くぞ。
違う。
バグの多さは、開発”規模”とQAコストのバランスが一番大きな要因。
要は任天堂がセカンドやサードパーティ向けに作ったサンプルや簡単にゲームを作れる実行環境でしょ？
PS1のときにソニーがそういうのも含めてセカンドパーティに配布したおかげで今までほぼ2Dか良くて疑似3Dゲームしか作ってこなかった日本のゲーム業界に一気に3D化が進んだと聞いてる
そのころのことは伝聞だけど、PS2はそこら辺のサポートがよく無くて苦労したとか、Wiiでは任天堂が配布したサンプルの素材を差し替えてそのまま販売したメーカーが居たとか
動きがもっさり→気持ちは分かる
ゲーム性だと動きの方が重要なんじゃね？
白と黒の石置くゲームでも盤がぐにゃんって感触だったら絶対なくなったと思うｗ
同じハードのスプラ2で同じ武器あるが問題ないしハード要因ではない
誰かがやらかして判定消したんだろうぜ
やらかしたやつ超怒られてるんだろうなぁ
ただ集めるだけならそうなるけど、まさか専用に最適化しないと思ってるの？
リアル志向のゲームほど大変だね
スクエニがFF7RでAI使ってQAしてなかったっけ？
皆がやる共通的な部分をライブラリにするわけで
歩く、走る、落ちる、ジャンプするみたいなのには対応できても超速でワープしたり、敵が掴んで引っ張ってきたり、見た目と違った部分に新たに当たり判定つけたりみたいなのには別個で対応せなあかんのよ
衝突判定からは逃げられない！！！
スプラのしょうもないバグ未だに修正できてない時点で答え出てんじゃん
まあ当然
逆でも何でも良いからすり抜けないように作れよ
アクションゲームプログラマとしては最初のステップだねw
フレーム概念がしっかりしてないと難しいよねw
3Dは面倒だよね
ジャンプとか無しでいい？って本気で聞きたくなっちゃうw
マップとか、オブジェとか、キャラモーションとか分業だと頭が痛い問題だねー。
ポリゴンとコリジョンの区別がつかない奴はデバッガ辞めろw
これ
階段（坂）も登れない
全然
で？それが対人メインのゲームで判定バグってていい理由になるの？
案の定支援車両が引っ掛かりまくって爆発音が響き渡り周囲は大パニック、
急襲終わった後に破壊された車両を見に行こうとしたら、さっさと形跡が処理されてて何とも物足りなく感じる
と言うのがユーザーの心情なんだけど、こういうのもプログラマーからしたらギリギリの駆け引きがあったりするんだろうな
ゲームエンジンのチュートリアルレベルだったら問題は起きない
けどゲームってのは例外を入れてナンボであり、面白い遊びを入れれば入れるほど破綻は起きる
物量重視のPvEと少数人数のPvPを同一視するとかw
階段はコリジョンをスロープにし、足だけIKで階段を踏む体裁にしてるのが多いよねぇ
まぁCPUに負荷が掛かるとどうやってもすり抜ける事はある
低スペックハードでは更に限界はあると思うし
PCだってノートPCとかで大作遊ばれたら壁抜けしまくる可能性は高い
プログラマー視点なんか知らんわ
パナムがグラード（対物ライフル）持ちながら手を腰に添えて休めのポーズしてんだ
どうなってるかというと、パナムの親指からグラードが生えて、それが体貫通してんだよ
一体どうやったらこうなるんだ？
オレのことだけど
衝突判定も厳しくて、行けないとこできないことが多くなる
逆に海外のその辺適当に作ってるゲームは自由度が高い代わりにすり抜けバグだらけとかあるある
結果的に大体あたってる・・筈！の位置で判定が発生してるからなんだろう
プログラマーを育成したければ格闘ゲームなんか作るもんじゃない！と昔の人はいい事を言ったと思う
BPでなんとかなるゲームなんて大型タイトルで存在しているのか？
C++書きまくるぞ。
プログラムは液体なんか？
大人の都合で衝突判定なくしてすり抜けるようになってるのを衝突判定作って揺れるようにするの
大変だけど面白い。
液体でもなんでもない。表示してる物はただの絵。絵同士に当たりなんてあるわけがない。
簡単なゲームだと逆効果だと思う。
リアルタイムじゃないターン型でローグライクのようなやつだと、移動処理前に当たり(移動可否)判定するだけなのでせいぜい凡ミスやらかしたんろうぐらいの認識にしかならない。
こんな話が1万とあるから、だからバグ取りは難しい