Comment puis-je détecter le joueur écrasé dans un jeu de plateforme 2D?

19

Je vérifie la collision pour un personnage de plateforme comme indiqué dans # 1. Les points rouges sont les pixels qui sont vérifiés et les lignes grises indiquent les axes auxquels ils se rapportent. J'aime les résultats que j'obtiens en vérifiant la collision de cette façon (contre, disons, la boîte englobante). Tout fonctionne exactement comme je le voudrais, sauf un problème: la détection d'écrasement.

Dans les images suivantes, la boîte bleu clair représente le sol, la boîte orange est un objet et les flèches indiquent la direction du mouvement.

La solution simple pour détecter le moment où le joueur est écrasé est de voir si les points de collision des côtés opposés se déclenchent tous les deux. S'ils le sont, le joueur est écrasé. Dans # 2, vous pouvez voir un scénario d'écrasement normal. Le joueur est mis à la terre et les points de collision supérieurs se croisent avec l'objet qui tombe. Cela déclenche un écrasement.

Les numéros 3, 4 et 5 présentent des scénarios problématiques. Dans # 3, le joueur se déplace vers l'objet, qui se déplace vers le haut. Un point de collision du côté droit frappe l'objet, provoquant une collision et arrêtant le joueur.

Maintenant, si l'objet continue de monter et que le joueur continue de se déplacer vers la droite (comme illustré dans le # 4), l'objet efface le point de collision du côté droit du joueur et le joueur se déplace vers la droite. Mais maintenant, après l'avoir fait, l'objet coupe un point de collision supérieur provoquant un écrasement vertical indésirable.

Un scénario similaire est illustré au # 5. Deux objets sont suffisamment éloignés l'un de l'autre pour que les points de collision inférieurs se dégagent, permettant au joueur de tomber, mais pas jusqu'à permettre aux points de collision latéraux de se dégager, provoquant un écrasement horizontal indésirable.

J'ai creusé la tête sur une solution, mais rien de ce que j'ai trouvé n'a particulièrement bien fonctionné, alors je me demande si quelqu'un a une idée ou un aperçu de la façon de résoudre ces problèmes.

entrez la description de l'image ici

Pour dissiper une certaine confusion, les points de collision rouges se trouveraient dans le sprite et les lignes grises n'étaient utilisées que pour désigner l'axe correspondant à chaque point de collision. Par exemple, si le sprite du personnage était un simple carré vert, les points de collion ressembleraient à ceci:

entrez la description de l'image ici

IanLarson
la source

Réponses:

34

Je pense que vous devrez tenir compte du mouvement de la boîte . Autrement dit, écraser uniquement si la boîte se déplace vers le joueur.

C'est similaire à d'autres problèmes dans les plateformes, où le mouvement est important. Par exemple, pour les plates-formes sur lesquelles vous pouvez sauter par-dessous, ne vérifiez pas la collision si le joueur se déplace vers le haut.

Un bloc ne peut donc écraser le joueur d'en haut que si le bloc se déplace vers le bas; d'en bas uniquement si le bloc se déplace vers le haut; à partir de la gauche uniquement si le bloc se déplace vers la droite, etc.

congusbongus
la source
13
+1 Tenez compte du fait que le bloc agit ici, pas le joueur. Donc, si vous cochez si la case écrase le joueur au lieu de vérifier si le joueur est écrasé, le problème devrait être plus facile à résoudre
Niels
Et quand les blocs ne bougent pas? Je me rends compte maintenant que j'ai mis des flèches sur les blocs en # 5, mais cela devait être deux blocs stationnaires.
IanLarson
Si vous décidez que les blocs stationnaires ne doivent pas s'écraser, assurez-vous simplement que le joueur n'est pas coincé et qu'il peut s'écarter.
congusbongus
Argh, je déteste être écrasé par deux objets qui s'éloignent l'un de l'autre, uniquement parce que je l'ai rendu parfait au pixel et au cadre et que le développeur était paresseux.
rhinocéros
9

Faites en sorte que les points du «test d'écrasement» se trouvent à l' intérieur de la zone grise affichée dans votre image n ° 1 - c'est-à-dire ne tuez le joueur que si vous détectez un coup sur l'un des pixels.

Peter est
la source
1
Voulez-vous dire des points de contrôle d'écrasement supplémentaires "à l'intérieur" des limites des points de collision? Le problème que je vois avec cela est que la résolution de collision se produira dans chaque axe lorsque l'un de ses points de collision est "déclenché" avant même que l'objet n'ait une chance d'atteindre les points de contrôle d'écrasement intérieurs.
IanLarson
6

En tant que personne ayant grandi avec des jeux de plateforme des années 80, mon premier commentaire est que les points de contact doivent être exactement sur le sprite, pas n'importe où en dehors. Il y avait peu d'expériences plus frustrantes que de mourir quand une arme / un broyeur / un ennemi était clairement à plusieurs pixels de votre personnage - et ce genre d'expérience est ce qui empêche les gens de jouer.

Dans cet esprit, l'idée d'avoir des points séparés pour les collisions horizontales et verticales ne marche tout simplement pas. Donc, vos cas 3 et 5 n'existent pas.

En ce qui concerne la détection des collisions, comme cela a été dit précédemment, vous devez considérer la direction du mouvement et vous avez deux axes de mouvement à considérer. Si un concasseur est en panne, le joueur ne doit pas pouvoir avancer - il doit agir comme un mur. Donc, avec des points de détection horizontaux et verticaux au même endroit, vous ne pouviez pas obtenir le cas 4, même avant d'ajouter la direction du mouvement au mélange.

Le broyeur à déplacement vers le haut ajoute une complexité supplémentaire. Si c'est si rapide que le joueur n'a aucune chance de s'échapper, alors OK. Mais si c'est plus lent, le joueur s'attendra à pouvoir courir sur la plate-forme montante et sauter de l'autre côté. Le joueur sprite monte vers le haut sur le broyeur, et la détection d'écrasement se produit au plafond .

Graham
la source
3
Petit point - vous ne savez pas à quoi ressemble son sprite. Pour tout ce que nous savons, cela pourrait être exactement comme indiqué dans les images ci-dessus, donc les cas 3 et 5 peuvent être entièrement valides.
Alex
1
Alex a raison. J'ai fait un montage pour clarifier. Je suis d'accord qu'il n'y a rien de pire que des boîtes de collision inconstantes. Je pense que je comprends votre point de ne pas utiliser des points séparés pour les différents axes. Si je le fais, cela transformerait l'exemple ci-dessus d'avoir huit points en quatre, un dans chaque coin, correct? J'ai en fait fait des tests avec cela à l'esprit (avec des résultats moins que souhaitables), mais j'hésite fortement à le faire, car avoir les coins "séparés" permet d'obtenir le comportement que je recherche presque parfaitement. Ce sont vraiment les seuls scénarios de problèmes que j'ai rencontrés.
IanLarson
0

Vous pourriez rendre l'objet "plus dur" que le sol, ce qui signifie qu'en supposant une collision, le joueur est poussé "dans" le sol, au lieu d'être poussé "dans" l'objet en mouvement.

Cela suppose que le joueur n'est pas en mesure de se pousser "dans" les objets ou le sol.

Zamfi
la source
0

Si vous pouvez détecter le chevauchement d'objets sans avoir à attendre qu'ils s'affichent, une approche simple consiste à traiter le mouvement du lecteur et des autres objets indépendamment, un pixel à la fois, avec des contrôles de collision séparés par la suite. Si le joueur se déplace librement et heurterait son objet à la suite d'un tel mouvement, reculez-le. Si une collision se produit avec un objet à la suite du mouvement de l'objet, vérifiez si le joueur peut se déplacer dans la même direction que cet objet. Si c'est le cas, déplacez le joueur. Sinon, gérez la situation "d'écrasement" de manière appropriée (endommageant ou tuant le joueur et / ou déplaçant l'objet entrant en collision en fonction du contact).

BTW, si seulement un nombre limité de combinaisons de formes peuvent entrer en collision, il peut être utile de pré-calculer les bitmaps de "détection de collision" de telle sorte que si un pixel est défini dans le premier sprite à l'offset (x1, y1) et dans le second au décalage (x2, y2) de la seconde, le pixel au décalage (x1-x2, y1-y2) sera défini dans la carte de collision. Une telle carte de collision pré-calculée permettra de détecter les collisions entre les deux sprites en vérifiant l'état d'un seul pixel dans la carte de collision.

supercat
la source
0

Il faut deux objets pour écraser un joueur. Votre détection d'écrasement devrait vérifier si le joueur se trouve entre deux objets, l'espace entre eux étant égal à la taille du joueur et la distance diminuant.

Accumulation
la source
0

Je trouve à côté de travailler jusqu'à présent. Il ne nécessite pas d'informations "externes" sur le mouvement des broyeurs et résout le problème des faux positifs. Lorsqu'un faux positif est détecté, il est traité comme une collision (et c'est ce qu'il est réellement):

L'idée est la suivante: pourquoi vérifier si le broyeur se déplace alors que nous nous soucions réellement du déplacement du personnage. Les deux peuvent répondre si l'écrasement est un faux positif provoqué par le propre mouvement du personnage ou vrai écrasé par le mouvement de l'objet broyeur.

Si le personnage est en mouvement et écrasé (collisions sur les côtés opposés pour la trame entrante), vérifiez à nouveau pour l'écrasement sur les dernières coordonnées de trame / itération:

  1. S'il n'est pas confirmé à nouveau, cela est dû au propre mouvement du personnage et le personnage doit être renvoyé aux dernières coordonnées image / itération comme une collision

  2. Si l'écrasement est confirmé la deuxième fois, procédez à l'écrasement.

Nikaas
la source