TP de Programmation sur le déroulement du jeu

Dans ce TP, nous allons mettre en place ce qui nous permettra de gérer les éléments d'une partie : début du jeu, défaite, victoire, enchainement des niveaux, introduction, conclusion, ... Vous pouvez commencer à partir de votre solution aux précédents TPs et Apnées, ou partir de l'état global Etape9.zip. Récupérez ensuite le fichiers pour ce TP dans l'archive Deroulement_Jeu.zip.

1 - État courant du casse briques

Notre jeu reprend les règles classiques d'un casse briques avec quelques petits aménagements, à savoir :

Il faut donc tenir compte de tous nos éléments de jeu présents dans le niveau et les prendre en compte de manière cohérente. La classe JeuAnime déjà écrite le fait de manière incomplète : dans la méthode rafraichit, le niveau est mis à jour (déplacement des composants et calcul des collisions, suppression des objets détruits), puis quelques tests décident de continuer, de charger un niveau ou de mettre fin au programme. Par exemple, s'il n'y a plus de briques, le niveau est remporté, il faut passer au suivant, et s'il n'y a plus de balles le joueur a échoué et il faut arrêter le jeu.

2 - Transitions

Dans l'état actuel, le démarrage d'un niveau est un peu abrupt : dès le début du jeu ou dès le début d'un nouveau niveau, la balle démarre sans aucune temporisation et part immédiatement de la raquette. Il faudrait mettre en place un petit délai avec un message annonçant à l'utilisateur le démarrage du niveau. Pour cela, nous allons avoir besoin de bloquer tous les composants pendant l'affichage du message et de tous les débloquer ensuite. Pour que cela soit visuellement plus agréable nous allons aussi mettre un effet de fondu dans l'apparition et la disparition du message.

Exercices

Cela devrait suffire pour que vos niveaux démarrent par un message d'annonce, avant que la balle ne s'élance vers les briques.

3 - Déroulement du jeu

Il faut maintenant faire en sorte de compléter le jeu avec un déroulement particulier quand le joueur perd ou quand il termine le dernier niveau. Ces déroulements particuliers seront de petites animations ou de simple messages annonçant au joueur ce qui se passe. Ces déroulements seront potentiellement complètement différents selon ce qui s'est produit avant. Au niveau du jeu cela se modélise par un ensemble d'états de jeu entre lesquels se produiront des transitions selon l'état courant de la partie. Ce modèle ressemble à celui des automates de Moore avec une légère différence : son alphabet d'entrée dépend de l'état du jeu (les différentes phases ne produisent pas les même entrées, par exemple le nombre de balles n'a aucun sens quand on fait dérouler les crédits). La sortie, elle, correspond à l'évolution du jeu à appliquer.

Exercices

4 - Un peu de colle

Pour finir, comme dans les autres casses briques, pour laisser le joueur préparer un bon départ de balle, nous allons coller la balle à la raquette pendant quelques secondes au début de chaque tentative. Il faut non seulement que la balle ne bouge plus d'elle même pendant quelques secondes, mais aussi qu'elle suive la raquette quand celle-ci se déplace. Pour cela, nous allons reprendre un design pattern consistant à lier des propriétés. Ce pattern n'est pas présent dans le livre donné en référence pour l'UE, mais il se fonde sur l'observateur que nous avons déjà vu. Le principe est le suivant : une propriété est à la fois observateur est observable. Il est possible d'attacher une propriété à une autre en l'ajoutant à ses observateurs. Lorsque la valeur d'une propriété change, elle met à jour tous ses observateurs pour qu'ils puissent prendre la même valeur. Il faut juste faire attention à éviter les boucles infinies si deux propriétés sont mutuellement attachées l'une à l'autre (cette situation ne se présentera pas pour nous).

Exercices