accélération progressive d'une balle de casse-brique

Hello tout le monde,

Je me suis mis à Gamemaker le weekend dernier et j'adore ! J'ai fait d'entrée le tutorial livré avec la version gratuite - je compte acheter la licence la semaine prochaine mais pour l'instant la version gratuite est largement suffisante. Le tuto était facile, tout a bien fonctionné.

J'ai ensuite enchaîné avec un remake de Breakout sur Atari 2600 en utilisant des sprites et des sons ultra-basiques "oldschool". J'en suis rendu à un jeu qui est opérationnel, avec un menu, une aide F1, des musiques de fond, etc. Pour info, j'ai suivi un tuto trouvé sur le web avec des briques qui se cassent en deux fois.



Petite description du casse-brique, version simplifiée (sans menu etc.) :

- Il y a trois vies au départ.
- A chaque fois que la balle sort de l'écran, il y a un test du nombre de vies : soit c'est supérieur à zéro et une nouvelle balle est créée ; soit c'est égal à zéro et on restart la room.
- Il y a 5 rangées de briques de couleurs différentes. Chaque rangée donne un score différent, de 50 pour le 1er rang à 125 pour le dernier.
- Il faut toucher chaque brique deux fois pour qu'elle disparaisse et que le score soit incrémenté.

Vous pouvez trouver le .gmk ici (Gamemaker 8, version simplifiée sans musique, menu, etc.) : http://zzzzra.com/partage/breakanoid_project.gmk



Maintenant j'aimerais bien faire deux choses :

1. Optimiser le jeu en utilisant un peu de GML là où c'est possible et en tenant compte de mon niveau de débutant.
2. Ajouter quelques fonctions afin de donner un poil de profondeur à ce jeu ennuyeux (mais bon, j'ai grandi avec des casse-briques oldschool^^).

En particulier, j'aimerais beaucoup que la vitesse de la balle augmente au fer et à mesure du jeu. J'ai déjà testé trois ou quatre solutions mais à chaque fois je me suis heurté à un nouveau problème. Lourd. Là-dessus je ne cracherais pas contre un petit coup de main

Je voudrais aussi inclure des éléments type "Arkanoid" de la génération qui a succédé à celle de Breakout. Notamment les célèbres bonus qui tombent de certaines briques. Je ne vois pas encore trop bien comment implémenter une telle chose...



J'espère que vous pourrez me refiler quelques tuyaux !

speed+=0.5 ?
Quels sont les problèmes rencontrés?

tu veux du gml? et ben fait un script, nommé 'speed_increase'

dedans tu met :

speed+=argument0;

En gros, quand tu appeleras le script speed_increase, met lui en premier argument la valeur d'augmentation voulue.
Sinon, au lieu d'appeler un script, tu fais 'execute a piece of code', et tu mets :
speed_increase(1)

si tu veux augmenter la vitesse de 1.

en fait, speed est une variable crée automatiquement par GM pour tous les objets, c'est la vitesse de ce dernier.
+= signifie qu'on "ajoute de façon relative", donc speed+=1 , ça ajoute 1 à speed.

argument0, c'est le nom du premier argument d'un sccript. il y en a 16 si je ne me trompe pas.

Merci je vais essayer ça.

Ce que j'aimerais en particulier c'est d'"indexer" l'accélération de la balle sur le nombre de fois où elle a touché la raquette. Au début du jeu elle va à 12, et disons que après avoir rencontré la raquette 20 fois, elle aille à 13 au lieu de 12. Au bout de 40 rencontres, 14, etc...

J'aimerais aussi que lorsque le joueur perd une vie, que la balle suivante reparte à sa vitesse initiale (dans mon cas 12).

J'ai tenté un truc qui a plutôt pas mal fonctionné, c'est de faire un test de collision entre la balle et la raquette. a chaque collision, la vitesse de la balle est augmentée très légèrement, de manière à ce que l'accélération soit très douce. Le problème c'est que dès la deuxième ou troisième collision, la balle ne touche plus la raquette, elle s'en éloigne progressivement de coups en coups même si la collision est effectuée (bounce). J'espère que je suis clair. Si vous voulez je peux aussi uploader une version .gmk de ce cas particulier.

Hmm en fait je viens de réussir à l'instant, j'arrive maintenant à accélérer la balle d'un poil à chaque fois qu'elle touche la raquette, et j'ai mis l'action "bounce" juste après le test de collision. Il n'y a plus ce phénomène de décalage de la balle de collision en collision. Je pensais que c'était la méthode qui n'était pas bonne, en fait c'était juste l'ordre des actions...

Je vais essayer maintenant de faire en sorte que la balle retrouve sa vitesse d'origine après qu'elle soit sortie de l'écran et que le joueur ait perdu une vie. Ca ne devrait pas être trop compliqué.

Quand j'aurais réussi à faire fonctionner tout ça, je transcrirai le plus de trucs possibles en code. J'ai appris il y a deux jours à me servir des scripts grâce à un tutorial, j'en utilise de très simples dans mon nouveau projet.

NB : petite question pour en avoir le coeur net... Transformer des actions D&D en GML a pour intérêt d'accélérer un peu l'exécution du jeu c'est bien ça ? C'est ce que j'imagine mais je n'ai pas encore lu ça noir sur blanc

Si j'ai bien compris Topaze quand il me la dit :
Le fait de faire le jeu en GML réduit le poids de l'exécutable et améliore de vraiment vraiment vraiment pas beaucoup les performances général du jeu

Bref au cas ou tu préférais lire le message original :

Topaze22 a écrit:

L'histoire du drag and drop, quelqu'un avait fait un teste, mais les résultats n'étaient vraiment pas du tout significatif.
Bref, dans le meilleur des cas tu y gagneras quasiment quasiment rien. En plus tes codes seront moches et incompréhensibles.

Même pour quelqu'un d'ultra maniac, il n'y a aucun intérêt.
Et jusqu'à présent, je parlais des performances.

En terme de poids, le GML sera forcément moins lourd que le drag and drop.

voilà un logiciel qui pourait t'aider :
http://www.lecbna.org/pages/logiciels.php?subaction=showfull&id=1202512066&archive=&start_from=&ucat=4&

Merci pour l'info. Ca a l'air d'être exactement ce qu'il me faut pour démarrer ! J'ai téléchargé et je vais tester ce weekend plus en profondeur.

Avec mon casse-brique j'en suis maintenant rendu à une balle qui accélère bien lentement comme il faut. Quand on perd une vie la balle revient à sa vitesse initiale. J'ai fait deux scripts, un avec le code donné plus haut par M@d_Doc, un autre avec la vitesse initiale.

Le problème c'est que la balle finit toujours, au bout d'un petit moment, par entrer en collision avec la raquette de plus en plus "à distance", sans la toucher. Parfois, selon tel ou tel rebond, la distance entre les deux objets lors d'une collision se réduit mais c'est aléatoire. Un peu lourd^^

J'ai aussi un autre problème, parfois la balle reste bloquée en position horizontale à rebondir indéfiniment entre les deux murs. Ca aussi c'est un peu lourd.
Peut être faudrait-il introduire un poil de hasard dans le mouvement de la balle ou dans sa façon d'entrer en collision avec les murs ?

PS : Mon projet mis à jour avec ce problème de collision se trouve ici : http://zzzzra.com/partage/breakanoid_7-4-2010.gmk
Dites moi ce que je pourrais faire pour l'améliorer

lol ton topic m'a inspiré, j'ai fait un casse brique en un script, tu peux le retrouver dans la section gmlscripts, hésite pas à reprendre (et surtout à comprendre) ce qui t'intéresse!

Cool ! Rien de tel qu'un petit casse-brique pour tuer le temps

Je vais tester ton script demain, là ce soir j'ai eu ma dose de creuse-méninge. Merci d'avance pour le coup de main.

Rahh ton code ne fonctionne qu'avec la version Pro. Je ne pourrais pas le tester avant d'avoir acheté cette version, ce qui est maintenant une question de jours

PS : Quelqu'un a eu le courage de regarder mon .gmk et voir ce qui ne colle pas ?

bon, pour les rebonds qui se font de plus en plus loin de la batte,
rajoute un "move to contact" avec pour argument :
direction : direction
maximum : speed
against : solid

pour éviter que la balle reste horizontale, rajoute dans son step :

if direction=0 or direction=180
{
direction+=random(20)-10
}

Super, merci infiniment ! Je vais tester ça ce soir. Je n'avais pas encore utilisé le "move to contact", je vais creuser un peu la question.

Pour le truc qui consiste à rajouer un peu de random c'est bien vu, ça me permet de voir comment on utilise la synthaxe dans un cas bien précis. Excellent.

J'apprends vraiment beaucoup depuis dix jours et ce forum m'a bien aidé pour l'instant

Ton code a super bien fonctionné M@d_doc, merci encore ! Mon casse-brique est presque terminé, il faut maintenant que je trouve le moyen de recommencer la room au départ (en gardant le score) quand il ne reste plus de briques affichées à l'écran

dans l'onglet main1, t'as un icone pour recommencer la room.

Et cherche un peu par toi même, au lieu de poser des questions à chaque problème!

Tu te doutes bien que j'ai déjà repéré cette icône depuis longtemps et que je ne demanderais pas de l'aide ici s'il s'agissait juste de se servir de cette action sans rien faire d'autre.

Il faut que je trouve un moyen de faire un test quand il n'y a plus aucune instance de brique dans la room (5 types de briques différentes affichées en même temps) afin de me servir de l'icône dont tu parles.

PS : je n'ai pas posé de question dans mon précédent message

et bien, dans ce cas :
if instance_number(objet1)+instance_number(objet2)+...=0
{
room_restart()
}

Mortel, merci encore et encore !

Le pire c'est qu'hier soir j'ai trouvé sur le web un petit bout de code quasi-identique, mais qui a le symbole && au lieu du + de l'addition comme dans le tiens.

Ca fonctionnait bien, mais seulement avec deux objets différents. Dès que j'en ajoutais une troisième ça buggait systématiquement. J'ai abandonné car j'ai cru que ce n'était pas la bonne solution...

Bon weekend !

&& signifie "et", donc qu'il faut que instance_number(1) et insntan_number(2) soient tous les deux vérifiés... Bref, que les deux fonctions retournent "vrai", c'est à dire 1.
Avec &&, on ne change de room que s'il reste exactement une brique de chaque!

Ce que j'ai fait, c'est que j'ai additionné toutes les briques, et vérifié si c'est bien égal à 0 :
blabla(1)+blabla(2)+blabla(3)=0

Topaze22 a écrit:

L'histoire du drag and drop, quelqu'un avait fait un teste, mais les résultats n'étaient vraiment pas du tout significatif.
Bref, dans le meilleur des cas tu y gagneras quasiment quasiment rien. En plus tes codes seront moches et incompréhensibles.

Même pour quelqu'un d'ultra maniac, il n'y a aucun intérêt.
Et jusqu'à présent, je parlais des performances.

En terme de poids, le GML sera forcément moins lourd que le drag and drop.

Il n'y a rien qui nous permet vraiment de savoir si le poids serait moins lourd ou plus lourd... par exemple, une action D&D pourrait très bien être moins lourde que son équivalent en GML juste par le fait qu'elle pointerait simplement vers du code déjà fait dans le moteur GM. Ce code déjà fait qui resterait dans le exe même avec aucuns D&D qui ne l'utilise. Bref, on ne peut pas trop savoir. Même chose pour le côté performance : le code déjà fait dans le moteur pourrait très bien être du code compilé contrairement au GML qui est interprété.