Puzzle-game : difficultés concernant la tombée des blocs

Bonjour à toutes, bonjour à tous.
Je (re)viens sur le forum “Aide à la création” parce que nous avons un problème dans la conception d’un moteur de puzzle-game. En fait, pour vous expliquer, parallèlement à Astral Masane (qui est notre jeu), nous aidons des confrères à faire un moteur pour leur jeu de puzzle-game.

Si Blady a réussi à faire générer des blocs aléatoirement, là où on sèche tous les deux, c’est sur la boucle pour créer une génération à l’infini : quand un bloc touche le sol, un autre est généré automatiquement en haut, donc jusque-là pas de problème… le hic, c’est que le bloc qui a touché le sol continue à descendre indéfiniment, jusqu’à sortir de l’écran. Par ailleurs, dès que le premier bloc touche le sol (et donc que le deuxième apparaît), plus rien n’est contrôlable : le deuxième bloc descend, mais impossible de le contrôler de gauche à droite.

J’appelle donc votre aide, si vous avez déjà conçu un puzzle-game, et que vous pourriez ainsi nous aider…

Petite précision concernant ce problème (vu que je bosse aussi avec ThomasCVB concernant l’élaboration de ce jeu), Game Develop considère qu’un bloc de 2 carrés est 2 objets (bloc de gauche + bloc de droite). Donc du coup, je me demande comment gérer les objets pour faire ne serait-ce qu’un Tetris avec Game Develop, car là nous séchons complètement… :frowning:

Oubliez le tetris et faites un puyo puyo. Vous n’aurez qu’un bloc à bouger.
Ca élimine le problème des blocs qui doivent se suivre mais rester ensemble.

Si je devais faire un truc de ce genre :

  • j’utiliserai la gravité pour les faire tomber tout seul
  • je mettrai une plateforme en bas pour que les pièces tombent et s’empile dessus
  • je mettrai une variable d’objet disant que si enchute ==1 alors je peux le controler, si collision alors enchute=0

Pour un Puzzle game, l’automatisme plateforme n’est pas le plus adapte quand même, par exemple les blocs ne s’empileront pas attention :slight_smile:

J’ai oublié de préciser que c’est justement un Puyo puyo-like qu’on va faire, donc jusque-là ok.
Mais le problème, c’est que ton principe de variable est pas mal mtarzaim, mais Game Develop considère que les objets du bloc sont un seul et même objet. Du coup, la collision est toujours vraie et impossible de continuer, il est là le problème…

J’ai bien essayé de faire un objet pour une couleur (8 objets dont la seule différence est la couleur) mais ça ne règle pas le problème car ça revient au même (il va recréer le même objet au bout d’un moment de toutes façons)…

Y a t-il un moyen de mieux gérer les objets ? Car je sèche…

Pourquoi pas avoir deux objets (quasi identiques) pour chaque brique. Comme ça, tu testes la collision entre cet objet caché et une brique.

En fait, actuellement j’ai fait un objet correspond au bloc de droite et un autre au bloc de gauche (ce qui fait une brique)
Mais j’ai toujours ce problème de collision renvoyée toujours vraie…

Tu veux dire quoi par “objet caché” en fait ? J’ai pas très bien compris ton principe, si tu peux mieux m’expliquer… :confused:

Pour chaque objet puyo
– si Puyo.EnChute == 1 alors on fait tomber le puyo et on controle le puyo
----- si en collision avec un puyo et que ce puyo a un EnChute == 0 alors le puyo qui tombe passe à EnChute = 0 (il arrete de tomber et ne peut plus être controlé ==> il est “empilé” )

Il va peut-être falloir passer par deux variables temporaires, une qui stocke l’id du puyo qui tombe et une qui stocke l’id du puyo collisionné qui a EnChute==0.
Ainsi, il suffit de dire “si puyo.id = xxx” pour désigner à GD le puyo en question.

Sinon, autre possibilité : découper le tableau en case, chaque case étant un sprite avec plusieurs animations (dont une animation vide pour simuler une case vide). On simule la tombée d’un puyo en changeant l’animation de la case. On empile si le numéro d’animation de la case en dessous est supérieure à 0.
Ca donne un mouvement saccadé retro, mais au moins, plus de problème de collision.

Tu peux m’expliquer plus en détail ceci ? Car j’arrive pas à le retranscrire sur Game Develop…

Et que veut-tu dire par “puyo.id” ? C’est la variable id de l’objet puyo ?

Dans mon idée, tu as un puyo qui tombe (avec un id = 5) et des puyo déjà tombés (id de 0 à 4).
Quand un puyo collisionne un puyo, tu en un forcément un qui a 5 (celui qui tombait). Tu peux donc déduire celui qui est touché (si puyo.id !=5 alors mettre = puyo.id à la variable puyoAverifier).
Une fois que tu as cet id, tu peux faire des comparaisons (si puyo.id == puyoAverifier alors ).

Oui.
En fait, tu incrémentes une variable à chaque création d’un puyo, et tu colles la valeur dans l’id du puyo créé.
Ainsi, tu peux indiquer à GD quel puyo t’intéresse, au lieu de passer par une cascade de conditionnelles.

Par contre, maintenant que j’y réfléchis plus en détails, tu vas quand même te retrouver à faire du “si puyo.animation == puyo.animation alors”.
En général, GD n’aime trop ça.

Le mieux serait alors d’avoir deux objets “puyo” :

  • un objet puyoQuiTombe, controlé par le joueur.
  • un objet puyoTombé, qui remplace un puyoQuiTombe quand celui-ci touche un autre puyo.
    Visuellement, ils seront identiques. Mais au niveau du code, tu as “si puyoQuiTombe en collision avec puyoTombé alors detruire puyoQuiTombe et créer puyoTombé avec les mêmes coordonnées que puyoQuiTombe”.
    Et comme le joueur ne peut controler qu’un objet puyoQuiTombe …

Oui c’est intelligent comme idée !
Mais maintenant je n’arrive plus à faire tomber 2 carrés en même temps (pour former un bloc), y a qu’un seul carré qui tombe… :confused:

Sachant que un carré = l’objet “Bloc” (y en a qu’un seul, et les animations correspondent aux couleurs)

Bon, j’y arrive toujours pas, je vous passe les fichiers sources, si vous arrivez à trouver le problème… :frowning:

blady.fr/gd/SnC.rar (lien cassé)

Pour rappel, je veux qu’il y ait 2 blocs qui tombent (et non 1 qui reste gentiment en haut).

EDIT : C’est bon j’ai trouvé le problème ! :smiley: