Vais-je regretter d'utiliser un système de détection de collision basé sur la couleur?

Je commence tout juste à créer mon premier jeu avec XNA (j'ai de l'expérience avec C # mais pas avec les jeux).

Je construis un jeu de tir 2d assez simple de haut en bas. J'ai lu ce tutoriel sur l'utilisation d'un système de collision basé sur les couleurs et cela me semblait vraiment cool. http://www.xnadevelopment.com/tutorials/theroadnottaken/theroadnottaken.shtml

Cela signifie que je peux rapidement faire des niveaux en utilisant n'importe quel programme graphique et ne pas avoir à définir mon paysage (murs, arbres, etc.) en termes de boîtes de collision, etc.

Cependant, je peux voir que descendre ce chemin signifie que peut-être le calcul pour déterminer si des objets se déplaçant rapidement comme des balles intersectent des murs, etc. devient potentiellement plus difficile, car vous ne pouvez pas faire de calculs de type d'intersection de géométrie de base.

Est-ce correct? Vais-je regretter d'aller dans cette direction si mon jeu se complexifie avec le temps? Vaut-il juste investir dans la création d'un éditeur de niveau pour définir mon décor en termes de géométrie?

Tout conseil pour un noob très apprécié!

xna collision-detection geometry

— TerryB
source

Vous êtes au courant de vos observations concernant les capacités d'une approche de collision basée sur le bitmap.

Cette méthode fournit un moyen très simple d'éditer vos niveaux avec n'importe quel programme pouvant produire une image bitmap (n'importe quel programme d'édition d'image). Ce système est également très flexible lorsque vous souhaitez définir différents types de terrain. Dites greenpour la boue et redpour un sous-sol solide. Vous interrogez ensuite facilement le pixel actuel et déterminez le type de métro sur lequel le joueur se tient. Même les rampes (gradients du type de sol A à B) sont possibles sans trop de problèmes.

Des problèmes surviennent avec la détection de collision. Il est facile de détecter une intersection avec un autre objet (il suffit de faire un test de pixels), mais il est difficile (cher en calcul) de déterminer l'orientation de l'objet avec lequel vous êtes entré en collision. Ceci est particulièrement important lorsque vous avez besoin d'une surface normale pour dévier correctement les objets .

Des objets se déplaçant très rapidement peuvent également être un problème, surtout si vous avez des objets fins (par exemple 1 pixel de large) avec lesquels entrer en collision. Il y a déjà cette question qui couvre ce sujet.

En fin de compte, tout dépend du type de jeu que vous souhaitez créer et de la résolution (en termes de détection / résolution de collision) dont vous avez besoin. L'approche basée sur le bitmap fonctionne mieux, lorsqu'une grande partie de votre monde est statique. Mais cela vous permet également d'implémenter assez facilement des éléments comme les niveaux destructibles .

Comme vous n'avez pas mentionné le type de jeu que vous souhaitez créer, c'est à vous de décider maintenant si une approche de collision basée sur le bitmap serait bénéfique pour votre jeu. Bonne chance.

— bummzack
source

D'après mon expérience, le problème de surface normale est assez trivial par rapport à la détermination réelle de l'impulsion angulaire après un impact, dans un système de détection de collision au pixel près. En règle générale, le PPCD n'est pas utilisé pour les jeux qui nécessitent ce genre de niveau de détail, probablement parce qu'il rend les choses beaucoup plus difficiles que la physique vectorielle, à cet égard. L'autre problème que j'ai rencontré avec cette approche était la possibilité de se "bloquer" lorsque vous faites pivoter votre personnage à certaines positions de votre niveau. Box2D et similaires gèrent cela en écartant les centroïdes lorsqu'ils sont trop proches.

— Ingénieur

Merci beaucoup! Je n'ai pas l'intention de faire de déviations, donc je pense que ça va. Je ne savais pas quoi faire avec des balles se déplaçant rapidement qui pourraient sauter par-dessus les murs dans un seul cadre. Déterminer s'ils ont traversé un mur semble correct, il suffit de prendre un échantillon de l'image de la carte dans un long rectangle mince qui est le chemin des balles et de rechercher des pixels colorés par le mur. Mais déterminer le premier pixel du mur qu'il aurait touché semble un peu plus difficile. Je pense que lorsque la balle se déclenche pour la première fois, je diffuserais des rayons et prendrais un certain nombre d'échantillons de pixels à de courts intervalles le long du rayon à la recherche du premier pixel du mur et le marquer comme point d'impact?

— TerryB

@TerryB: Je pense que l' algorithme de la ligne Bresenham fonctionnera très bien ici. Tracez la ligne jusqu'à ce que vous atteigniez un pixel du mur et ce sera votre point de collision.

— bummzack