Opinions sur les objets de détection de collision avec une scène en mouvement

Question

Donc, ma question est simple, et je suppose que cela se résume à l'anal que vous voulez être sur la détection de collision. Pour garder les choses simples, supposons que nous parlons de sprites 2D définis par une boîte englobante. En outre, supposons que mon objet sprite a une fonction pour détecter les collisions comme ceci: S.collidesWith(other); Enfin la scène bouge et les "murs" de la scène peuvent bouger, un objet ne peut pas toucher un mur.

donc une implémentation simple pourrait ressembler à ceci (code psuedo):

moveWalls(); 
moveSprite(); 
foreach(wall as w) { 
    if(s.collidesWith(w)) { 
     gameover(); 
    } 
} 

Le problème est que si le mouvement de l'image-objet et le mur vers l'autre, en fonction des circonstances (par exemple instant diagonale) . Ils peuvent passer l'un à travers l'autre (improbable mais pourrait arriver).

Donc, je peux le faire à la place. Cela prend soin de la traversée de l'un l'autre problème, mais un autre problème rare se présente. Si elles sont adjacentes (littéralement le pixel suivant) et que le mur et l'image-objet se déplacent à gauche, j'obtiendrai une collision invalide puisque le mur bouge, vérifie la collision (hit) puis l'image-objet est déplacée. Ce qui semble injuste. De plus, à cela, la détection de collision redondante est très inefficace. Je pourrais donner la priorité au mouvement du joueur en soulageant le premier problème mais il est encore en train de vérifier deux fois.

moveSprite(); 
foreach(wall as w) { 
    if(s.collidesWith(w)) { 
     gameover(); 
    } 
} 
moveWalls(); 
foreach(wall as w) { 
    if(s.collidesWith(w)) { 
     gameover(); 
    } 
} 

Suis-je simplement sur la pensée de cette question, si cela vient d'être écrit à la craie jusqu'à « ça arrivera assez rare que personne ne se souciera »? Certainement en regardant de vieux jeux basés sur des sprites, je trouve souvent des situations où la détection de collision a des défauts subtils, mais je pense que maintenant nous pouvons faire mieux: -P. Quelles sont les pensées des gens?

Answer 1

Il est important de savoir si cela vaut la peine d'améliorer la précision, mais cela devrait devenir évident au cours du test.En ce qui concerne l'augmentation de la fiabilité de votre détection de collision, vous avez plusieurs choix:

1. Diminuez la taille du pas de simulation. Si stepsize * (vitesse maximale du joueur + vélocité maximum du mur) < (largeur du joueur + largeur du mur), vous ne manquerez aucune collision.
2. Vérifiez également que le lecteur est du même côté du mur avant et après l'étape de simulation. Plutôt que de vérifier uniquement les collisions à la fin de chaque étape de simulation, dérivez une formule qui calcule l'heure à laquelle le mur et le joueur entreraient en collision en fonction de leur vitesse actuelle et signale une collision si la simulation actuelle étape. Ceci est probablement excessif dans votre cas, mais peut être utile pour modéliser des choses telles que rebondir sur les murs.

Answer 2

Cela dépend beaucoup de la fréquence que vous utilisez pour vérifier la collision (et le périphérique d'entrée du lecteur). Lorsque vous vérifiez souvent, le cas où les deux bougent «en même temps» devient moins probable. Si c'était un jeu de stratégie basé sur des tours, ce serait une question différente. Cela dit, je ne sais pas, quel modèle vous utilisez en détail, mais si vous avez un thread, qui vérifie l'entrée du joueur, et celui qui fait le calcul du mouvement et la détection de collision, alors les deux devront être synchronisé (verrous en lecture/écriture) de toute façon. Dans ce cas, c'est clair, ce qui est arrivé en premier. Même chose, si vous n'utilisez qu'un seul thread. En fonction du modèle de physique, l'entrée pourrait orienter l'accélération, qui déterminerait la vitesse, ce qui à son tour détermine la position. Si la ligne du mouvement de l'objet de la position précédente à la position suivante (possible) traverse la position du mur à ce moment-là, vous avez une collision (en prenant en compte les contours entiers qui pourraient entrer en collision).

La chose qui est probablement plus difficile, est de calculer l'effet du rebond. J'ai trouvé cela vrai quand j'ai écrit un jeu basé sur OpenGL, où les murs ne peuvent pas bouger, mais le sol peut être incliné: Quand le rebond n'est pas assez fort pour contrer l'accélération contre le mur, vous serez toujours à l'intérieur du mur après la collision. Après avoir investi quelques efforts, je pense que ça marche plutôt bien (y compris rouler le long du mur, ce qui est encore un autre problème), mais avec des murs mobiles, c'est un peu plus difficile.