Jusqu'à présent, dans les jeux précédents, j'ai utilisé une collision 2D simple avec des boîtes, puis en vérifiant au niveau des pixels une collision.
Si vous faites un jeu de flipper dans presque beaucoup de cadres, le ballon sera en contact avec un mur ou une autre surface, alors y a-t-il une autre approche?
Réponses:
À l'époque (1990), les anciens jeux de flipper étaient faits comme ceci:
Il existe plusieurs couches pour le champ de jeu (ce que vous voyez lorsque vous jouez au jeu):
et plusieurs couches pour les collisions:
L'image en niveaux de gris de gauche est une carte de collision pour le jeu principal, l'image de droite est une carte de collision pour une zone spéciale: les rampes de flipper.
White = zone libre pour la balle, l'indice de couleur est de 255.
Gray= la balle sera "repoussée" de cette zone. indice de couleur = angle du vecteur à ajouter à la position de la balle. gris clair = 0 deg. gris foncé = 360 deg.
Un pseudo code:
void do_ball_physics()
{
while(1)
{
byte color = read_pixel_under_ball(ballx, bally); //one pixel read
if(color == 255) //see remark below
break;
float vectorx = sin(color/255.0f * 2.0f * PI);
float vectory = cos(color/255.0f * 2.0f * PI);
ballx += vectorx; //push ball away from one unit
bally += vectory; //
}
}Certains indices de couleur spéciaux peuvent être utilisés aussi pour quelque chose d' autre que la collision, une gamme de couleurs personnalisées (par exemple: 240 - 255) peut être réservé pour détecter des zones spéciales comme spinners, triggers, bumpers, holes, ...
Comme vous pouvez le voir, c'est très simple. Il n'y a que quelques pixels "lus" par image. Pour cette raison, vous pouvez faire fonctionner la simulation physique à un taux de rafraîchissement réel élevé, par exemple: 200 ips. L'utilisation d'un taux de rafraîchissement élevé facilitera la simulation et réduira le "tunneling" (cela se produit lorsque la balle va trop vite et traverse des éléments creux sans entrer en collision). Cette simplicité est également ce qui rend les jeux de flipper fluides 386 computers(et même rapides 286) à l'époque (parmi d'autres astuces comme le cyclisme des couleurs, le défilement vga et le masquage des sprites ...).
Aujourd'hui, la plupart des jeux de flipper ne sont plus faits comme ça. Au lieu de cela, le champ de jeu est une scène 2D / 3D utilisant des polygones ou des sprites et des collisions sont effectuées contre certaines lignes simplifiées, des courbes de Bézier ou des sphères représentant une forme simplifiée de champ de jeu visuel.
exemple (du flipper visuel ):
Certaines sociétés de jeux utilisent leur propre moteur physique, mais un autre moyen plus simple consiste à utiliser un moteur physique comme Box2Dou Bullet. La plupart des jeux de flipper iPhone que j'ai vus utilisaient un moteur physique préexistant + quelques actifs 3D.
Les flippers ont des ensembles physiques très riches, non seulement des trous ou des murs, mais aussi des éléments réactifs (frappant en arrière) ou une surface inégale où la balle ralentit et retrouve ensuite sa vitesse.
Si vous voulez créer un bon flipper, le chemin à parcourir est soit d'utiliser une détection de collision 3D, soit un système auto-adapté avec chaque objet collidable ayant une méthode avec des paramètres de distance et de vitesse, en retournant des vitesses modifiées.
J'ai fait un jeu de flipper il y a quelque temps; il était également basé sur les pixels. J'avais une carte de collision qui contenait juste les données de collision. Une normale approximative de collision était facile à trouver:
Prenez la zone de la carte de collision chevauchant la balle, trouvez le centre, formez le vecteur de ce point au centre de la balle, puis normalisez.
J'espère que ça vous donne quelques idées :)
Premièrement, si vous créez un jeu de flipper, vous aurez probablement besoin de plus de détection de collision-cercle-limite que celui de la boîte-cadre :-)
Étant donné la complexité de la physique impliquée dans un flipper à part entière, je suggérerais de regarder sur un moteur physique 2D existant. Box2D a une bonne réputation en javascript, il pourrait y en avoir d'autres mais je n'en ai pas rencontré de bonne (et gratuite).
Rq1: Vous utilisez certainement (comme je le fais) la séparation classique dans votre jeu entre la mise à jour et le tirage. Et vous utilisez une minuterie (setInterval / setTimeout) et / ou RequestAnimationFrame pour appeler la mise à jour, puis dessinez, de manière régulière. Un flipper peut être le type de jeu où vous voulez avoir une mise à jour de la conduite avec minuterie et une autre avec le tirage au sort, afin que vous puissiez ajuster le taux de chacun indépendamment, pour travailler sur une large gamme d'appareils. Parce que vous ne pouvez pas simplement laisser tomber (mise à jour + dessin) si l'appareil est trop lent: si le temps entre deux mises à jour (dt) devient trop long, le moteur physique peut manquer une collision.
Vous pourriez jeter un œil au flipper visuel vs au flipper futur pour le sujet 2d vs 3d. Si vous jouez au flipper visuel (tout est fait en 2D), puis jouez au flipper futur, ou quelque chose comme Zen Pinball, vous ressentez la différence dans la façon dont ils jouent. Personnellement, je préfère le 3D, mais votre projet peut être mieux adapté au 2D, vous seul pourrez décider que