Alors voilà, je voudrais coder un petit jeu de casse-briques (pour l'instant, juste la base, c'est à dire, la raquette, les briques, la balle).
Mais le problème c'est que je n'arrive pas bien à visualiser comment créer le modéle. J'aimerais avoir une fenêtre, avec à gauche le jeu, et une petite partie à droit ou on verra le score.
Ce que je n'arrive pas à visualiser c'est comment coder cela. (Comment par exemple différencier la partie "jeu" de la partie "score" pour que la balle n'aille pas se balader dans le score et comment représenter les briques (tableau en 2 dimensions?) etc...
En gros, j'ai besoin d'aide pour créer une ligne directrice pour se projet.
Comme j'ai remarqué que quelques personnes ici avaient déja codé ce genre de jeu, j'imagine que vous pourrez m'aider.
J'en ai fait un il y une paire d'années, que je suis en train de refaire avec la SDL. Voir ma signature pour tester l'éditeur (et me faire des niveaux) et tester la version actuelle du jeu (ça bugue un peu, parfois, mais c'est en cours de "portage" (DirectX -> SDL) et optimisation).
J'ai personnellement pris l'approche objet, en C++. C'est-à-dire que chacun de mes objets dans le casse briques (balles, raquette, briques, bonus 3D, boulets de canon voire même les explosions) sont des objets d'une classe (un peu l'équivalent d'une structure... en plus poussé).
Ca me permet de faire un tableau d'objets. Par exemple, pour un niveau donné, si j'ai 120 briques, j'aurais un tableau de 120 objets de la classe brique (celle-ci ayant des variables aussi diverses et variées que ses coordonnées, son état, son type, etc...).
Si tu n'es pas à l'aise avec les structures ou la programmation objet, tu peux aussi t'en sortir en faisant de simples tableaux à plusieurs dimensions, mais c'est plus difficile, à mon avis (tableau où tu as les coordonnées, type et état de tes briques, etc...).
Un conseil quand même : pose sur papier la façon dont tu gèreras tes différents "objets" dans ton jeu, et ne commence à programmer que lorsque tu sais la façon dont tout s'implémentera. Un casse-briques, si tu le veux un peu poussé, n'est pas si trivial que ça.
Le C++, tout comme le C, est multi plate-forme, à condition d'utiliser des librairies multi plate-formes. C'est une des raisons pour laquelle je transpose ma version DirectX en version SDL, afin qu'elle soit portable.
Pour les tutoriels objet, ça doit être facilement trouvable, mais je n'en ai pas sous la main.
Quand mon jeu sera terminé, j'essayerais d'en faire un tuto (ou une série de tutos), car ça peut permettre de voir pas mal de choses dans la création d'un jeu (gestion du temps, sprites, gestion des différents écrans, POO...).
Edit : je fais une version Linux ce soir, car je suis également sous Linux chez moi. Je n'avais juste pas pensé à inclure la version linux sur mon site
Pour les sources, pas tout de suite, j'attends d'avoir une version plus aboutie.
Edit : allez, si je me motive, je fais un tuto sur comment commencer un casse-briques (méthodes, objets, etc...). Ca sera le préambule, si tout va bien, d'une série pour programmer le jeu en lui-même.
je serais toi je coderais les fonctions de base petit a petit :
1. tu cree un pong (raquette avec balle qui rebondit sur les murs
2. tu poses les briques (la balle rebondit sur les murs ET les briques
3. tu code le systeme de coordonees et la disparition des briques
4. tu suis le tuto texte que j ai pas encore lu et tu laisse ta balle passer sur le texte pour le moment. il sera tjrs tps de trouver comment limiter la zone de jeu plus tard !
Voilà, c'est ce que je vais faire pour l'instant. Ensuite je réécrirais sûrement le programme avec une approche objet quand le tutorial de florent28 sera écrit
Merci pour tous vos conseils.
Oh, encore une chose, pour le placement des briques (sans l'approche objet), je peux reprendre le sytème de tableau à deux dimensions comme dans le jeu de Sokoban suggéré par M@teo, non?
Pour info, je viens de finir le tuto, qui est l'introduction d'une série de tutos pour faire un casse-briques (enfin, une des méthodes, je ne prétends pas avoir la meilleure solution). D'ailleurs, cette méthode est plus ou moins valable pour n'importe quel jeu
Il est en attente de validation, vous en saurez plus quand ça sera fait
Ajoute un déplacement de la barre avec les fleches. La souris, c'est pas très pratique.
Pour les briques, utilise un tableau à deux dimensions. Les cases du tableau auront une valeur differente en fonction de son status (briques, explosions, etc..).
Pour faire rebondir la balle sur le menu, pas difficile, si tu arrive à la faire rebondir sur d'autres bords, celui-çi n'est pas plus difficile..
Sinon, au lieu d'un fonction pause, utilise un booleen pause ui vaudra '0' si on est en pause, '1' si on y est pas; ensuite, on deplace la balle et on fait les blits seulement si pause == 1.
Si tu as d'autres questions, pose-les, n'hesite pas !
personnelement je penserai à une sorte de miroir lorsque la balle arrive contre la raquette par exemple
la balle se deplace en allant a chaque fois deux pixels à gauche et 5 vers le bas.
si elle rencontre la raquette,
on defini le deplacement comme deux vers la gauche et 5 vers le haut.
(les choc horizontaux modifient la verticalité et les paroies verticale, le mouvement horizontal)
la simulation des collisions:
ta balle avance de 1 pixel en continue et tu deplace en meme temps ta raquette (sans pour autant arreter la balle fonction PollEvent)dès que ta balle rencontre une limite verticale a ne pas dépacer par exemple: 200 pixel vers la droite la balle s'arrete. Puis pour la faire redemmarer ta le choix entre choisir une direction a chaque fois quel touche cette limite ou utiliser la generation de nombre pseudo aleatoire pour que cette direction soit hasardeuse et imprevisible après pour les briques meme chose que pour les limites dès que la balle rentre dans une zone (la brique ) declencher un evenement (voir 2 pour que la balle rebondisse ).
aide pour la gestion des collision:
Merci pour vos réponses mais en fait ça j'avais déjà l'idée. Ce que je ne savais pas gérer la direction. Effectivement un nombre aléatoire c'est pas mal mais c'est pas réaliste
Pour l'effet miroir oui mais le problème c'est que plus tu te rapproche du milieu de la barre, plus c'est un vrai mirroir et plus tu t'en éloigne plus la direction change de l'effet mirroir (et en plus dans les angles ça doit renvoyer dans la même direction) alors bon c'est pas facile nonplus... d'où mon problème.
la balle se deplace en allant a chaque fois deux pixels à gauche et 5 vers le bas.
si elle rencontre la raquette,
on defini le deplacement comme deux vers la gauche et 5 vers le haut.
Bon pour l'algorithme.
Mais pour le code, je vais t'en concocter un naimbus. Parce que là, j'ai un trou de mémoire .
c'est gentil, donc tu va faire un effet miroir pour tout alors? avec une equation par rapport à la normale? car pour les angles c'est différent normalement (sauf si tu arrive à changer la normale en fonction du point d'impact, ce qui doit etre possible avec les math lol j'y avait pas pensé )
En gros, si tu utilises des vecteurs de déplacement (ix, iy) pour bouger ta balle :
- tu touches un mur à gauche ou à droite : ix devient -ix
- tu touches le mur du haut : iy devient -iy
- tu touches la raquette : il faut faire un petit calcul. Sur mon casse-briques, ça donne ça :
if(x == rqte.x){
ix = 0;
iy = -1;
n = sqrt(iy*iy+ix*ix); //norme
ix = ix / n; //on divise par la norme
iy = iy / n;
ix = ix / n; //on divise par la norme
iy = iy / n; }
sachant que x est le centre de la balle, et rqte.x est le centre de la raquette, dont la demi largeur est rqte.l (la raquette fait donc 2*l de largeur).
Il y a bien évidemment d'autres façons de gérer l'angle, notamment si vous gérez les déplacements de la balle avec un angle plutôt qu'avec des vecteurs...
ah merci j'ai compris le raisonnement mais pourquoi tu divise par la norme? c'est juste pour créer des petits deplacements?
sinon le contenu du tan, plus précisement le 1-((x - rqte.x) / (rqte.l)) je ne comprend pas vraiment ce que cela represente en angle...
Je divise par la norme pour que le vecteur soit toujours de la même taille. C'est-à-dire normé.
Ce n'est pas le vecteur qui détermine la vitesse, mais la vitesse elle-même (quand tu la multiplies au vecteur).
Pour l'angle, j'avoue qu'il y a beaucoup de parenthèses, et que ça peut gêner la lecture, mais le contenu du tan est bien plus grand que ce que tu en as lu...
Un vecteur normé pour que le déplacement soit toujours de la même taille c'est ça? (je parle de l'espace pas du temps )
Pour le tan j'ai bien vu ya la suite avec 85 + conversion en radian mais c'est juste la partie que je t'es écrite que je ne comprend pas en angle...
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
If you'd like to join us, read "How do we work at OpenClassrooms"! :)